From nobody Thu Feb 1 02:48:42 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19F713172C for ; Thu, 1 Feb 2018 02:48:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 0f9ji2PNDP4h for ; Thu, 1 Feb 2018 02:48:38 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 8FF7B1316FF for ; Thu, 1 Feb 2018 02:48:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517482115; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BWynJJ+pebN1kRufl0f3cBZBsotvCkWSIsXzDBvkj58=; b=ZXOsX3w1a/WfFR4ISMrqNbxc+RM7AZj5UQHBpFQ3NvsdIn/JzuFMzcjgIN10OBW9 W6pNqii+Qctd3XbKlnfA11ejX4Fn7rkrEvPqoWjDi/y/EYYBqYMQwzUAYhLwla0A 3g8DKyYCJUtOhFfoSVVVSF21TeZxcpVq6Fg4xpmLCcg=; X-AuditID: c1b4fb3a-716549c0000037f2-28-5a72f083a761 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 36.3F.14322.380F27A5; Thu, 1 Feb 2018 11:48:35 +0100 (CET) Received: from [147.214.160.85] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 1 Feb 2018 11:48:35 +0100 To: Christer Holmberg , "tsv-art@ietf.org" CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" References: <151731848710.27439.7061415423323921488@ietfa.amsl.com> From: Magnus Westerlund Message-ID: <1d6ab623-0076-2e75-0e99-6a24e55ee934@ericsson.com> Date: Thu, 1 Feb 2018 11:48:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050303040209070805010100" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7mW7zh6Iog47bGhbHf/xht/h2odbi 2cb5LBaz9ixicWDxWLLkJ1MAYxSXTUpqTmZZapG+XQJXxvO7/1kLHrxnrOjYupilgfHCYcYu Rk4OCQETiekLP7CB2EIChxklTrxX7mLkArI3MUoc3PuFFSQhLOAi0XX+NzuILSIQL3Hg+Udm kCJmgZmMEq9/vmSE6C6V2PF7N9gkNgELiZs/GsFsXgF7iZ0b7oINYhFQkZh/9D4TiC0qECOx oPkQM0SNoMTJmU9YQGxOARuJC10HWSAWdDNK3J3YB3WetkRDUwcrxNlKEtfnXWeZwCgwC0n/ LGQ9IAlmATOJrq1djBC2tsSyha+ZIWxxiaYvK1khbGuJGb8OQtUrSkzpfsgOYZtKvD76EarX SOLdnkb2BYycqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECI+fglt9WOxgPPnc8xCjAwajE w8v/oihKiDWxrLgy9xCjCtCcRxtWX2CUYsnLz0tVEuF9sw8ozZuSWFmVWpQfX1Sak1p8iFGa g0VJnNcpzSJKSCA9sSQ1OzW1ILUIJsvEwSnVwMh77czMXHXbf2nGZrM/rGywOOohZdCZ0mQy aSHn+qiGgE1mUoJJHlZP3j7cqubOvF/2SNCfuulcrns+Rp6eNVdSd2HI/5J3pv9qngTUL6kW ydpQ5l/Y4n5fe+0jpgl2nxe8Vr/2YyVXt87N8/O3GjH9PvlhY1Dyk4MJF4z2VgtxLsxv/Hva X1aJpTgj0VCLuag4EQAfWdqjpAIAAA== Archived-At: Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 10:48:41 -0000 --------------ms050303040209070805010100 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Hi, Please see my comments inline. Den 2018-01-30 kl. 15:34, skrev Christer Holmberg: > Hi, > > Please see inline. As requested, I include my replies to the comments y= ou > already provided earlier. > >> Significant Issues: >> >> A. Section 5.2: >> >> Lite implementations only utilize host candidates. A lite >> implementation MUST, for each component of each data stream, alloc= ate >> zero or one IPv4 candidates. It MAY allocate zero or more IPv6 >> candidates, but no more than one per each IPv6 address utilized by= >> the host. Since there can be no more than one IPv4 candidate per >> component of each data stream, if an ICE agent has multiple IPv4 >> addresses, it MUST choose one for allocating the candidate. If a >> host is dual-stack, it is RECOMMENDED that it allocate one IPv4 >> candidate and one global IPv6 address. With the lite implementati= on, >> ICE cannot be used to dynamically choose amongst candidates. >> Therefore, including more than one candidate from a particular sco= pe >> is NOT RECOMMENDED, since only a connectivity check can truly >> determine whether to use one address or the other. >> >> I find it quite strange that the above text says there can only be sin= gle >> IPv4 >> based candidate, while for IPv6 a LITE implementation may have one >> candidate >> per IPv6 address. Isn't the LITE implication of having multiple >> candidates for >> the same address family similar? Yes, IPv6 kind of forces the need for= >> dealing >> with multiple IPv6 addresses on any host. However, I can see that cert= ain >> servers will actually be multi-homed in IPv4 and thus can in a sensibl= e >> way >> actually have multiple IPv4 candidates, and let the clients select whi= ch >> interface has the best reachability. >> >> Can you please be explicit on what in ICE prevents things to work for >> IPv4 but >> the same case works for IPv6? > This is text from RFC 5245. I agree it is confusing, and unfortunately = I > don=E2=80=99t have a good answer. > > I guess my approach would be to suggest that we simply remove the > restriction. In addition, there is generic text about dual-stack etc > elsewhere, > and I don=E2=80=99t see anything ICE lite specific. > > OLD: > > "Lite implementations only utilize host candidates. A lite > implementation MUST, for each component of each data stream, alloca= te > zero or one IPv4 candidates. It MAY allocate zero or more IPv6 > candidates, but no more than one per each IPv6 address utilized by > the host. Since there can be no more than one IPv4 candidate per > component of each data stream, if an ICE agent has multiple IPv4 > addresses, it MUST choose one for allocating the candidate. If a > host is dual-stack, it is RECOMMENDED that it allocate one IPv4 > candidate and one global IPv6 address. With the lite implementatio= n, > ICE cannot be used to dynamically choose amongst candidates. > Therefore, including more than one candidate from a particular scop= e > is NOT RECOMMENDED, since only a connectivity check can truly > determine whether to use one address or the other." > > > NEW: > > "Lite implementations only utilize host candidates. > With the lite implementation, ICE cannot be used to dynamically choose > amongst candidates. Therefore, including more than one candidate from a= > particular IP address family is NOT RECOMMENDED, since only a connectiv= ity > check can Truly determine whether to use one address or the other." I have read Ben's comment on this issue. I think something needs to be=20 done to avoid the confusion. There are I think two alternatives, either retain the restriction with an added note on why this restriction = exists. The second I think is to go with an amended version of the text=20 proposal, possibly with even clearer wording that if you are running=20 multiple addresses in the same family, you should really should be using = a full implementation. I noted that the "NEW" text above needs an amendment, and that is=20 because I think a very important part of what was cut needs to be retaine= d. It MAY allocate zero or more IPv6 candidates, but no more than one per each IPv6 address utilized by the host. If one generalize this what is missing is the limitation that only a=20 single candidate per IP address utilized by the host can be added by a=20 lite implementation. Using multiple would be redundant, but lets use a=20 direct statement to this affect, rather than a subordinate clause to=C2=A0= a=20 MAY statement. > --- > > >> B. Section 6.1.1: >> >> An agent MUST be prepared that the peer might re-determine the rol= es >> as part of any ICE restart, even if the criteria for doing so are = not >> fulfilled. This can happen if the peer is compliant with an older= >> version of this specification. >> >> What does it mean to be prepared for a peer that re-determine the role= s? >> What >> is it one MUST do? If the peer changes its role upon an ICE restart, >> isn't that >> going to result in a role mismatch? Thus causing yet another ICE resta= rt, >> where >> also this peer will re-evalute? Isn't that good enough? Or is it >> something else >> it can do? > The roles are re-negotiated during the ICE restart: it may, or may not,= > result in a role mismatch. > > "Prepared" means that the peer might change its role even though it doe= s > not fulfil the 5245bis criteria for being allowed to do so. Yes, but prepared is not actionable. I guess what you mean is that an=20 implementation MUST accept and perform re-determination of the role=20 initiated by the peer agent, even if the criteria are not fulfilled. > > > --- > >> C. Section 6.1.3: >> >> The ICE agent has a state determined by the state of the check lis= ts. >> The state is Completed if all check lists are Completed, Failed if= >> all check lists are Failed, and Running otherwise. >> >> Does failed really require all the checklists to fail, or simply any t= o >> fail if >> the others are completed? > If there are one or more completed, the session can still continue. As > described in section 8.1.2: > > "If at least one of the check lists for other data streams is > Completed, the controlling agent SHOULD remove the failed data > stream from the session while sending updated candidate list to > its peer." > > --- Okay, so the statement above is actually fulfilled, by pruning the=20 failed checklists through signalling, so that all lists are completed. I reacted, because it looked like you can actually arrive at a result=20 where some checklists are completed and some are failed. And if I=20 interpret this it should always be considered as running, as more can be = done before things are completed. I guess there is no real need for additional text here. Just a sense=20 from me as a reader that statements looks wrong, even if it isn't. > >> D. Section 6.1.4.2: >> >> I don't know if I misunderstand the algorithm here in the bullet list.= To >> me it >> appears that it will terminate prior to have initiated all possible >> tests, as >> it appears that it will not unfreeze some of the candidate pairs. If o= ne >> have >> tests running for a foundation, but all other candidate checks have be= en >> started, then the steps are aborted. Is the bullet list rechecked ever= y >> Ta? > No. Whenever Ta fires, one check list in Running state is checked. When= > all check lists have been checked, it will start over from the top of t= he > list. > > Or, did I misunderstand your issue? No, It was unclear that this is re-run every time Ta fires. I think the=20 reason for this is this sentence in step 4. If this happens for every single check list in the =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Running state, meaning there are no= remaining candidate pairs to =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 perform connectivity checks for, ab= ort these steps. It was unclear to me that this doesn't mean aborting the whole=20 procedure. Because if the requirement is fulfilled then there is nothing = to do until the next Ta, which will possible unfreeze another candidate=20 pair in step 2. I would recommend that you reformulate this sentence to=20 make it clear that the processing for this Ta is stopped, and processing = will be resumed the next time Ta fires. > > --- > > >> E. Section 7.2.5.2.2. ICMP Error >> >> An ICE agent MAY support processing of ICMP errors for connectivit= y >> checks. If the agent supports processing of ICMP errors, and if a= >> Binging request generates an ICMP error, the agent SHOULD set the >> state of the candidate pair to Failed. >> >> I am a bit worried by this blanket statement on ICMP errors. I think i= t >> should >> be clarified which ICMP message types that are relevant to consider as= >> errors? >> I assume Type 3 (Destination Unreachable) but maybe not all responde >> codes as >> Codes 4, 11,12 may be addressable in other ways, and likely Type 11 (T= ime >> exceeded) with response code 0, response code 1 is not a clear indicat= ion >> of a >> non working path. > This is from RFC 5245. > > I don=E2=80=99t think the ICE WG should go through all different codes = and > combinations, and determine what should be considered an error, and wha= t > not. > > If you can provide something (table, guidance etc), we are happy to > include it. Otherwise I=E2=80=99d like to keep it as it is, and let > implementations deal with it, as at least I am not aware that this woul= d > Have caused issues in ICE deployments. I think we there is a point to clarify that this applies to ICMP=20 messages indicating a non-usable path. So maybe it could be rewritten to = something like this: An ICE agent MAY support processing of ICMP messaging indicating a no= n-functioning path for connectivity checks. ICMP messages of type 3 (Destination Unreachable) are indicat= ors of a currently non-functioning path. However, the issue can be tempor= ary as it can depend on routing transients, this for example applies to c= odes 0, 1 and 5. Other messages that appear to indicate non-functioning p= ath such as Type=3D11 (Time Exceeded) with code=3D0 (Time to Live exceede= d in Transit) are not clear indicator as the IP packets potentially can r= each the destination with a larger TTL value set at transmission. Therefo= re, implementation needs to analyse the different ICMP messages types and= codes for which it considers the path as non-functioning. If the agent s= upports processing of ICMP errors, and if a Binging request generates an ICMP error, the agent SHOULD set the state of the candidate pair to Failed. What also is not addressed in this is the risk of denial of service=20 attacks using spoofed ICMP messages to shutdown certain connectivity=20 checks. The security considerations lack any discussion of this issue.=20 If ICMP processing are retained, I think a recommendation about=20 validation is needed to avoid at least off path attackers from doing=20 these attacks easily. Unfortunately ICMP response will only include the=20 IP/UDP header, thus no data from the STUN messages which would allow=20 verification that the ICMP messages matches an actually sent check. It may be simplest to recommend against reacting to ICMP errors from=20 both the perspective that it is a risk for denial of service attack, as=20 well as that it represents a risk terminating connectivity checks for a=20 transient issue. From my perspective I expect this to reduce the number=20 of sent connectivity checks very little > --- > > >> F. Section 7.2.5.2.3. Timeout >> >> If the Binding request times out, the ICE agent MUST set the >> candidate pair state to Failed. >> >> Isn't this erroneous? Timeout for the connectivity check is happening >> when all >> the (re-)transmissions have timed out, isn't it? or as simple as missi= ng >> the >> word "transaction"? > Correct. I will change to "Binding request transaction" Good! > > --- > > >> G. Section 14.3: >> >> Num-Of-Pairs: the number of pairs of candidates >> with STUN or TURN servers. >> >> I don't understand this definition. What does "with STUN or TURN serve= rs" >> mean? >> Candidate pairs where the local side is server-reflexive or relay? > The text comes from RFC 5245, but I think it=E2=80=99s wrong. There are= no pairs > during the gathering phase. > > My suggestion is to change Num-Of-Pairs to Num-Of-Cands, and say: > > "Num-Of-Cands: the number of server-reflexive and relay candidates" Sounds good to me. > > > --- > >> H. Section 14.3: >> >> Num-Waiting: the number of checks in the check list in the >> Waiting state. >> >> Num-In-Progress: the number of checks in the In-Progress state. >> >> Is "the number of checks" only per single checklist or across all the >> check >> lists? > Per single check list. Section 14.1 says: "Those formulas scale =C2=A0=C2=A0 with N, the number of checks to be performed." But, from my perspective, that number N is not on a single checklist,=20 but for the whole ICE session, i.e. all the checklists. Thus, I think=20 there needs a clarification on why this is per checklist, making it=20 clear why these two things match up. > > --- > >> I. Section 17.2.3: >> >> When VAD is being >> used, keepalives will be sent during silence periods. >> >> I would claim that this is only true for when VAD without any comfort >> noise is >> used. A lot of codecs with VAD operations still generates comfort nois= e >> on a >> frequency of a couple packets a second, way more often then the minima= l >> for ICE >> keep-alives. > What about: > > "In deployments that are not utilizing Voice Activity Detection (VAD), > without any comfort noise, > the keepalives are never..." That is also not true. As keep-alives is not expected to be needed for: 1. Continous media withouth any VAD etc. 2. Media with VAD, but with comfort noise not allowing intervals to be=20 to long (<=3D1 second). > > =3D=3D=3D=3D=3D=3D=3D > >> Minor/Editorial Issues: >> >> 1. Section 5.1.2: >> >> This section doesn't make it clear that higher priority values are mor= e >> prioritized over lower values. That really should be defined here. Now= >> that >> information only becomes evident implicitly in section 5.1.2.1. > > I suggest the following: > > "This priority will be used by ICE to determine the order of the > connectivity checks and the relative preference for candidates. > Higher priority values give more priority over lower values." Good with me. > > > --- > >> 2. Section 2.1. >> >> In order to execute ICE, an ICE agent has to identify all of its >> address candidates. >> >> I think this sentence is raising a too high requirement. An ICE agent = has >> attempt to identify as many of the address candidates as possible. The= >> better >> coverage of the potential candidates the more likely it is to function= =2E I >> would >> also argue that there are multiple cases where you will not figure out= >> that >> there are candidates that you don't know about. An obvious example is = in >> cases >> of two NATs between the local address realm and the STUN server, the a= gent >> can't figure out that there was an address given to the flow in the mi= ddle >> address realm between the two NATs. That can be only learn if the agen= t >> has a >> STUN server in that address realm. Secondly, there are cases where pol= icy >> may >> be applied to exclude certain interfaces and their related candidates.= > I suggest to replace with first sentence and simply say: > > "In order to execute ICE, an ICE agent identifies and gathers one or mo= re > address candidates." Yes, works fine in this introduction context. > >> I also noted that this first paragraph and the second has a strange >> relation. >> The first part of first paragraph is general, then there is the part o= f >> the >> host candidate. Then the second part starts with STUN and TURN derived= >> candidates. Maybe the first paragraph should be split between the gene= ral >> and >> the host part, or some other bridging is needed. > I suggest to split the first paragraph into two paragraphs, where the > second paragraph begins with the "At least one viable candidate=EB=92=B0= =EF=BF=BD > sentence. Looks like it should work. > --- > > >> 3. Section 2.3: >> >> If the transactions above succeed, the agents will set >> the nominated flag for the pairs, and will cancel any future check= s >> for that component of the data stream. >> >> Although what is stated is normal, it is not guaranteed to happen, I k= now >> this >> is intended as a simplified overview, but ignoring that there can occu= r >> some >> shuffling back and forth if high priority checks complete after low >> priority >> ones should at least be hinted or at least allowed by the use of words= =2E > One of the tasks have been to simplify section 2, because it was too > detailed for people who just wanted to get an overview of ICE. For > example, we removed the text about role conflicts. > > So, I would prefer to not cover your case in section 2. I don=C2=B9t th= ink it > is essential for people who want to get an overview. Implementers > obviously will need to read the whole spec. Okay, I understand the point. > --- > > >> 4. Section 3. >> >> As RFC 7825 do describe a significant enough different usage of ICE fr= om >> SIP, I >> think it would be good to actually included an informational reference= to >> this >> usage. > I can do that. However, note that RFC 7825 references RFC 5245. It even= > references specific sections, which may not be the same in 5245bis. > > In addition, RFC 7825 uses =C2=B3aggressive nomination=C2=B2 terminolog= y, which has > been removed from 5245bis. > > What about: > > "RFC 7825 defines an ICE usage for the Real-Time Streaming Protocol > (RTSP). Note, however, that the ICE usage is based on RFC 5245." Yes, I think that is very fair statement. But there is a point of=20 actually indicating that there are different usages therefore I think it = make sense to include that sentence. > > --- > > >> 5. Section 5.1.1.4: >> >> An ICE agent SHOULD >> monitor the interfaces it uses, invalidate candidates whose base h= as >> gone away, and acquire new candidates as appropriate when new >> interfaces appear. >> >> I am missing discussion of new addresses here. If the base disappears,= it >> might >> be that there is a new IP address that one should use. That doesn't >> necessary >> imply a new interface. > What about: > > "Host candidates do not time out, but the candidate addresses may > change or disappear for a number of reasons. An ICE agent SHOULD > monitor the interfaces it uses, invalidate candidates whose base has > gone away, and acquire new candidates as appropriate when new > IP addresses (on new or currently used interfaces) appear." Looks good to me. > > --- > >> 6. Section 7.2.5.1: >> >> If the Binding request generates a 487 (Role Conflict) error >> response, and if the ICE agent included an ICE-CONTROLLED attribut= e >> in the request, the agent MUST switch to the controlling role. If >> the agent included an ICE-CONTROLLING attribute in the request, th= e >> agent MUST switch to the controlled role. >> >> I think the first sentence should have a forward reference to Section >> 7.3.1.1 >> where the rest of the solution is described. > I will add a reference. Ok > > --- > >> 7. Section 7.3: >> >> If the agent is using Diffserv Codepoint markings [RFC2475] in its >> data packets, it SHOULD apply the same markings to Binding respons= es. >> >> I find this sentence a bit unclear. Is it intended to say: >> >> If the agent receiving the binding request, intended to use DSCP marki= ngs >> !=3D0 >> for the data, it SHOULD set, the same marking to binding responses. >> >> or >> >> If the agent receives a binding request with DSCP markings, then it sh= ould >> apply to corresponding code point when forming the binding response? > It means that it will use the same markings in Binding responses that i= t > uses in data packets (audio, video, etc). Okay, I wonder if it is the temporal aspect of the sentence that makes=20 it harder for me to parse correctly. > > >> There are unclarity of which agent is referenced and whom "it" is in t= he >> sentence. It is the STUN server. Would the following be more clear? "If the agent is using Diffserv Codepoint markings [RFC2475] in data packets that it sends, the agent SHOULD apply the same markings to Bindin= g responses." Yes, except that I stumbles "it sends" where it is more likely "it will s= end" is the correct form. =20 >> >> 8. Section 8.3.1: >> >> The procedures in Section 8 require that an ICE agent continue to >> listen for STUN requests and continue to generate triggered checks >> for a data stream, even once processing for that stream completes. >> >> That reference to Section 8, should that in fact be to Section 8.1 >> specifically? It looks strange with a self reference, which in some >> aspect a >> reference to section 8 means. I think this issue was missed. > --- > > >> 9. Section 15: >> >> 4.57566E+18 (note that >> an implementation would represent this as a 64-bit integer so as no= t >> to lose precision). >> >> Why the floating point representation? Priorities are integer numbers = and >> thus >> should be presented as such in this example. > This is from RFC 5245, and unfortunately I don=E2=80=99t know. Can you not just calculate the 64-bit integer and write it out? > > --- > >> 10. Section 17.2.1: >> >> First and foremost, ICE makes use of TURN and STUN servers, which >> would typically be located in the network operator's data centers. >> >> Is really network operator's data centers the right entity here? I wou= ld >> claim >> it is the service operators data centers, they may contract STUN servi= ces >> from >> network operators, but if the service operator isn't providing any STU= N >> service >> for its own service, then ICE is unlikely to work. > Could we simply say =E2=80=9Clocated in data centers=E2=80=9D? Yes. > > --- > >> 11. Section 18.2: >> >> Local IPv6 addresses can be preferred. >> >> I think this sentence needs to clarify that it means local to host, >> rather than >> any form of relayed or translated address, rather than a local scope o= nly >> IPv6 >> address. > I could say: > > "Local IPv6 host addresses" Maybe better: IPv6 address from the local host can be preferred. > > --- > >> 12. Section 18.5: >> >> A number of NAT boxes are now being deployed into the market that t= ry >> to provide "generic" ALG functionality. These generic ALGs hunt fo= r >> IP addresses, either in text or binary form within a packet, and >> rewrite them if they match a binding. >> >> Are actually these generic ALG functionality relevant today? They prov= ed >> to be >> a very bad idea very quickly. A note that this was a consideration at = the >> time >> RFC 5245 was published. > I don=E2=80=99t know whether the functionality is relevant. But, I gues= s it > doesn=E2=80=99t hurt to have the text. Fine, I guess it does no real harm. Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------ms050303040209070805010100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME-kryptografisk signatur MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DNEwggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNV BAoMCEVyaWNzc29uMRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJ ARYebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+ laqg5eXTqonqnzT9ykEGL2dx9mBT+2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJ HGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iV IiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpigGFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36o gzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkrbdmdnjKGrYSnJigmxw14pJugxL/Vb2Ee VcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDov L2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCBggYI KwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29t MEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29u bmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJp Y3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0 dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQG CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3 DQEBCwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4Q ihhoQR3cvhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXD yF9mhWYbSAkJyx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6 H3zO3nsq++KBmsOiSKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvE lup5n7l864FqxnC2friDo4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl 60rmc8SJlt6QXKw0wXEOE1MubauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwD ig3SZi1qP7D/Ds4V+JLIjjUJc25l9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8K v7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLCQaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3 UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Zla71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzY VBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd//n4YbY2QhDCCBsIwggSqoAMCAQICEFO4 foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUx MDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw ggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfS Tm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbX ILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfp VdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2 PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2 H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4 rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX 1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjv Zibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FN VSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoGCCsG AQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEu Y29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j b20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAE TjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnku dHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3Js LTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7 GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDU JQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHG vw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYn nl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwf ixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ8 5AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4Hd Dc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOE EHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd 3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/du jp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDGCAzswggM3AgEB MFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMA0GCWCGSAFlAwQCAQUA oIIBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAyMDEx MDQ4MzRaMC8GCSqGSIb3DQEJBDEiBCB2gnUX0egg5uWCoBh0sAg+6UAUhMqRqFp5/ij3cuCE 6jBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBlrrZreXF5 7TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMGwGCyqGSIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nz b24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62 a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAk1wg4pGAg7xIQN+ztgem5v7cs6OeWtIrGN6vP7y0 HjwnEQQ14CwK+B8tvGrar8fVMvpYhDlI1bIYun1Rf9J+Ah3eRqVgxn9QFhGa16+5xPC2F4+K jOuNITW6MOwl0xiEGJQOfU4wblQ6pDP+zhmro3e2ydXGYWSJOci5Gb5j7ZcsaenmrMOAxlsp odA2l423Kp79gX1mOYOC2fFm5q6ZWjsc6hz5jyioqxlpjzomwknNa2MeibYrb/6ql5nXhmTL +A3HRQjkaVp7CPrxI9hThsmT6uj588F/GV1uBleFWkS1UAJQXM1vEzlFNtF0svOWZGBD6z7X WmmJFci9/dQrugAAAAAAAA== --------------ms050303040209070805010100-- From nobody Thu Feb 1 04:39:46 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804F71314F6 for ; Thu, 1 Feb 2018 04:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgN0nEcUdA52 for ; Thu, 1 Feb 2018 04:39:37 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 A1C9012E871 for ; Thu, 1 Feb 2018 04:39:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517488765; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=lD/RayrwYyKbYOKsUJa6kvjexvsFzlBYGgerW7zB2OY=; b=cDaeU+N/Esw5IBdj0gm/giycSTOWnN7qgw+2mOh4rjm9EQ5jU/yPZt50zKo7XUqz HyC41fjFMaN0vlnuQIEBwSoESw6zd8lpg4xPiCcy8OSrAYIIlnZo4lb2rI+IRDDc YLKHRr8I/MbCo33cpsAbgS5J3nnKfjK3gDlKeoJ0CCc=; X-AuditID: c1b4fb3a-335ff700000037f2-97-5a730a7d3f46 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 42.B9.14322.D7A037A5; Thu, 1 Feb 2018 13:39:25 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Thu, 1 Feb 2018 13:39:25 +0100 From: Christer Holmberg To: Magnus Westerlund , "tsv-art@ietf.org" CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" Thread-Topic: Tsvart last call review of draft-ietf-ice-rfc5245bis-16 Thread-Index: AQHTmc09cSMwjiuCL0KSsp8F+FSKLqOMj1UAgALAtgCAAEO8AA== Date: Thu, 1 Feb 2018 12:39:24 +0000 Message-ID: References: <151731848710.27439.7061415423323921488@ietfa.amsl.com> <1d6ab623-0076-2e75-0e99-6a24e55ee934@ericsson.com> In-Reply-To: <1d6ab623-0076-2e75-0e99-6a24e55ee934@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.147] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3600341461_46075842" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUyM2K7mW4tV3GUwaK/8hbHf/xht/h2odbi 2cb5LBaz9ixicWDxWLLkJ1MAYxSXTUpqTmZZapG+XQJXRtfMvywFv3cxVvzZdoi5gfHmXMYu Rk4OCQETiYtTP7B2MXJxCAkcZpQ4vfwAM4SzmFFiypZ/bF2MHBxsAhYS3f+0QRpEBOIlura+ YwOpYRaYySjx+udLsEnCAi4SXed/s0MUuUpcf9XGDNIrIuAk8eOQCEiYRUBF4sflFWwgNq+A tcSSl8+gFq9mlDi66SoTSIJTwEHi+/PJLCA2o4CYxPdTa8DizALiEreezGeCuFpE4uHF02wQ tqjEy8f/WEFsUQE9iQ0nbrOD7JUQUJKYtjUNorVSon/+ZhaIvYISJ2c+YZnAKDoLydRZSMpm ISmDiBtI/Fl8ihXC1pZ48u4ClG0tMePXQTYIW1FiSvdDdgjbVOL10Y+MCxg5VjGKFqcWF+em GxnppRZlJhcX5+fp5aWWbGIExuTBLb+tdjAefO54iFGAg1GJh/cBY3GUEGtiWXFl7iFGFaA5 jzasvsAoxZKXn5eqJML7Zl9RlBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFepzSLKCGB9MSS1OzU 1ILUIpgsEwenVAOj5JcfmhZJlTv9Gmc+65NQN1FqvneyQJfjyGr9JhflPDWfn+JTS7IDe2tC fz+77s7GXuD+v0bM99pug3PvpetmZyoGTlWUqL+4QtZJQ+Bd7eFUG3a1M/++HzSftbBv2oJw y9dxR3SrmEKeu3UKiLbov72Z+r0nxK9myu9UmTXpe4McEmw2uCixFGckGmoxFxUnAgBrg6G8 0QIAAA== Archived-At: Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 12:39:41 -0000 --B_3600341461_46075842 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, >>> Significant Issues: >>> >>> A. Section 5.2: >>> >>> Lite implementations only utilize host candidates. A lite >>> implementation MUST, for each component of each data stream, >>>allocate >>> zero or one IPv4 candidates. It MAY allocate zero or more IPv6 >>> candidates, but no more than one per each IPv6 address utilized by >>> the host. Since there can be no more than one IPv4 candidate per >>> component of each data stream, if an ICE agent has multiple IPv4 >>> addresses, it MUST choose one for allocating the candidate. If a >>> host is dual-stack, it is RECOMMENDED that it allocate one IPv4 >>> candidate and one global IPv6 address. With the lite >>>implementation, >>> ICE cannot be used to dynamically choose amongst candidates. >>> Therefore, including more than one candidate from a particular >>>scope >>> is NOT RECOMMENDED, since only a connectivity check can truly >>> determine whether to use one address or the other. >>> >>> I find it quite strange that the above text says there can only be >>>single >>> IPv4 >>> based candidate, while for IPv6 a LITE implementation may have one >>> candidate >>> per IPv6 address. Isn't the LITE implication of having multiple >>> candidates for >>> the same address family similar? Yes, IPv6 kind of forces the need for >>> dealing >>> with multiple IPv6 addresses on any host. However, I can see that >>>certain >>> servers will actually be multi-homed in IPv4 and thus can in a sensible >>> way >>> actually have multiple IPv4 candidates, and let the clients select >>>which >>> interface has the best reachability. >>> >>> Can you please be explicit on what in ICE prevents things to work for >>> IPv4 but >>> the same case works for IPv6? >> This is text from RFC 5245. I agree it is confusing, and unfortunately I >> don=B9t have a good answer. >> >> I guess my approach would be to suggest that we simply remove the >> restriction. In addition, there is generic text about dual-stack etc >> elsewhere, >> and I don=B9t see anything ICE lite specific. >> >> OLD: >> >> "Lite implementations only utilize host candidates. A lite >> implementation MUST, for each component of each data stream, >>allocate >> zero or one IPv4 candidates. It MAY allocate zero or more IPv6 >> candidates, but no more than one per each IPv6 address utilized by >> the host. Since there can be no more than one IPv4 candidate per >> component of each data stream, if an ICE agent has multiple IPv4 >> addresses, it MUST choose one for allocating the candidate. If a >> host is dual-stack, it is RECOMMENDED that it allocate one IPv4 >> candidate and one global IPv6 address. With the lite >>implementation, >> ICE cannot be used to dynamically choose amongst candidates. >> Therefore, including more than one candidate from a particular scope >> is NOT RECOMMENDED, since only a connectivity check can truly >> determine whether to use one address or the other." >> >> >> NEW: >> >> "Lite implementations only utilize host candidates. >> With the lite implementation, ICE cannot be used to dynamically choose >> amongst candidates. Therefore, including more than one candidate from a >> particular IP address family is NOT RECOMMENDED, since only a >>connectivity >> check can Truly determine whether to use one address or the other." > >I have read Ben's comment on this issue. I think something needs to be >done to avoid the confusion. There are I think two alternatives, >either retain the restriction with an added note on why this restriction >exists. The second I think is to go with an amended version of the text >proposal, possibly with even clearer wording that if you are running >multiple addresses in the same family, you should really should be using >a full implementation. > >I noted that the "NEW" text above needs an amendment, and that is >because I think a very important part of what was cut needs to be >retained. > >It MAY allocate zero or more IPv6 >candidates, but no more than one per each IPv6 address utilized by > the host. > >If one generalize this what is missing is the limitation that only a >single candidate per IP address utilized by the host can be added by a >lite implementation. Using multiple would be redundant, but lets use a >direct statement to this affect, rather than a subordinate clause to a >MAY statement. Could you suggest new text? --- >>>B. Section 6.1.1: >>> >>> An agent MUST be prepared that the peer might re-determine the >>>roles >>> as part of any ICE restart, even if the criteria for doing so are >>>not >>> fulfilled. This can happen if the peer is compliant with an older >>> version of this specification. >>> >>> What does it mean to be prepared for a peer that re-determine the >>>roles? >>> What >>> is it one MUST do? If the peer changes its role upon an ICE restart, >>> isn't that >>> going to result in a role mismatch? Thus causing yet another ICE >>>restart, >>> where >>> also this peer will re-evalute? Isn't that good enough? Or is it >>> something else >>> it can do? >> The roles are re-negotiated during the ICE restart: it may, or may not, >> result in a role mismatch. >> >> "Prepared" means that the peer might change its role even though it does >> not fulfil the 5245bis criteria for being allowed to do so. > >Yes, but prepared is not actionable. I guess what you mean is that an >implementation MUST accept and perform re-determination of the role >initiated by the peer agent, even if the criteria are not fulfilled. What about: OLD: An agent MUST be prepared that the peer might re-determine the roles as part of any ICE restart, even if the criteria for doing so are not fulfilled. This can happen if the peer is compliant with an older version of this specification. NEW: An agent MUST accept if the peer initiates a re-determination of the roles even if the criteria for doing so are not fulfilled. This can happen if the peer is compliant with RFC 5245. --- ... >>> D. Section 6.1.4.2: >>> >>> I don't know if I misunderstand the algorithm here in the bullet list. >>>To >>> me it >>> appears that it will terminate prior to have initiated all possible >>> tests, as >>> it appears that it will not unfreeze some of the candidate pairs. If >>>one >>> have >>> tests running for a foundation, but all other candidate checks have >>>been >>> started, then the steps are aborted. Is the bullet list rechecked every >>> Ta? >> No. Whenever Ta fires, one check list in Running state is checked. When >> all check lists have been checked, it will start over from the top of >>the >> list. >> >> Or, did I misunderstand your issue? > >No, It was unclear that this is re-run every time Ta fires. I think the >reason for this is this sentence in step 4. > >If this happens for every single check list in the > Running state, meaning there are no remaining candidate pairs to > perform connectivity checks for, abort these steps. > >It was unclear to me that this doesn't mean aborting the whole >procedure. Because if the requirement is fulfilled then there is nothing >to do until the next Ta, which will possible unfreeze another candidate >pair in step 2. I would recommend that you reformulate this sentence to >make it clear that the processing for this Ta is stopped, and processing >will be resumed the next time Ta fires. Isn=B9t that indicated in the sentence before the list: "Whenever Ta fires, the ICE agent will perform a check for a candidate pair within the picked check list by performing the following steps:=B2 --- >>> E. Section 7.2.5.2.2. ICMP Error >>> >>> An ICE agent MAY support processing of ICMP errors for connectivity >>> checks. If the agent supports processing of ICMP errors, and if a >>> Binging request generates an ICMP error, the agent SHOULD set the >>> state of the candidate pair to Failed. >>> >>> I am a bit worried by this blanket statement on ICMP errors. I think it >>> should >>> be clarified which ICMP message types that are relevant to consider as >>> errors? >>> I assume Type 3 (Destination Unreachable) but maybe not all responde >>> codes as >>> Codes 4, 11,12 may be addressable in other ways, and likely Type 11 >>>(Time >>> exceeded) with response code 0, response code 1 is not a clear >>>indication >>> of a >>> non working path. >> This is from RFC 5245. >> >> I don=B9t think the ICE WG should go through all different codes and >> combinations, and determine what should be considered an error, and what >> not. >> >> If you can provide something (table, guidance etc), we are happy to >> include it. Otherwise I=B9d like to keep it as it is, and let >> implementations deal with it, as at least I am not aware that this would >> Have caused issues in ICE deployments. > >I think we there is a point to clarify that this applies to ICMP >messages indicating a non-usable path. So maybe it could be rewritten to >something like this: > > An ICE agent MAY support processing of ICMP messaging indicating a >non-functioning path for connectivity > checks. ICMP messages of type 3 (Destination Unreachable) are >indicators of a currently non-functioning path. However, the issue can be >temporary as it can depend on routing transients, this for example >applies to codes 0, 1 and 5. Other messages that appear to indicate >non-functioning path such as Type=3D11 (Time Exceeded) with code=3D0 (Time to >Live exceeded in Transit) are not clear indicator as the IP packets >potentially can reach the destination with a larger TTL value set at >transmission. Therefore, implementation needs to analyse the different >ICMP messages types and codes for which it considers the path as >non-functioning. If the agent supports processing of ICMP errors, and if a > Binging request generates an ICMP error, the agent SHOULD set the > state of the candidate pair to Failed. > > >What also is not addressed in this is the risk of denial of service >attacks using spoofed ICMP messages to shutdown certain connectivity >checks. The security considerations lack any discussion of this issue. >If ICMP processing are retained, I think a recommendation about >validation is needed to avoid at least off path attackers from doing >these attacks easily. Unfortunately ICMP response will only include the >IP/UDP header, thus no data from the STUN messages which would allow >verification that the ICMP messages matches an actually sent check. > >It may be simplest to recommend against reacting to ICMP errors from >both the perspective that it is a risk for denial of service attack, as >well as that it represents a risk terminating connectivity checks for a >transient issue. From my perspective I expect this to reduce the number >of sent connectivity checks very little So, are you saying that an agent should simply ignore ICMP messages? --- ... >>> H. Section 14.3: >>> >>> Num-Waiting: the number of checks in the check list in the >>> Waiting state. >>> >>> Num-In-Progress: the number of checks in the In-Progress state. >>> >>> Is "the number of checks" only per single checklist or across all the >>> check >>> lists? >> Per single check list. > >Section 14.1 says: "Those formulas scale > with N, the number of checks to be performed." > >But, from my perspective, that number N is not on a single checklist, >but for the whole ICE session, i.e. all the checklists. Thus, I think >there needs a clarification on why this is per checklist, making it >clear why these two things match up. Actually, I think I was wrong. It is per check list SET, i.e., all check lists. --- >>> I. Section 17.2.3: >>> >>> When VAD is being >>> used, keepalives will be sent during silence periods. >>> >>> I would claim that this is only true for when VAD without any comfort >>> noise is >>> used. A lot of codecs with VAD operations still generates comfort noise >>> on a >>> frequency of a couple packets a second, way more often then the minimal >>> for ICE >>> keep-alives. >> What about: >> >> "In deployments that are not utilizing Voice Activity Detection (VAD), >> without any comfort noise, >> the keepalives are never..." > >That is also not true. As keep-alives is not expected to be needed for: >1. Continous media withouth any VAD etc. >2. Media with VAD, but with comfort noise not allowing intervals to be >to long (<=3D1 second). What about: OLD: In deployments that are not utilizing Voice Activity Detection (VAD), the keepalives are never used and there is no increase in bandwidth usage. When VAD is being used, keepalives will be sent during silence periods. This involves a single packet every 15-20 seconds, far less than the packet every 20-30 ms that is sent when there is voice. Therefore, keepalives don't have any real impact on capacity planning. NEW: In deployments with continuous media and without utilizing Voice Activity Detection (VAD), or deployments where VAD is utilized together with short interval (max 1 second) comfort noise, the keepalives are never used and there is no increase in bandwidth usage. When VAD is being Used without comfort noise, keepalives will be sent during silence periods. This involves a single packet every 15-20 seconds, far less than the packet every 20-30 ms that is sent when there is voice. Therefore, keepalives don't have any real impact on capacity planning. =3D=3D=3D=3D=3D=3D=3D Minor/Editorial Issues: ... >>> 7. Section 7.3: >>> >>> If the agent is using Diffserv Codepoint markings [RFC2475] in its >>> data packets, it SHOULD apply the same markings to Binding >>>responses. >>> >>> I find this sentence a bit unclear. Is it intended to say: >>> >>> If the agent receiving the binding request, intended to use DSCP >>>markings >>> !=3D0 >>> for the data, it SHOULD set, the same marking to binding responses. >>> >>> or >>> >>> If the agent receives a binding request with DSCP markings, then it >>>should >>> apply to corresponding code point when forming the binding response? >> It means that it will use the same markings in Binding responses that it >> uses in data packets (audio, video, etc). > >Okay, I wonder if it is the temporal aspect of the sentence that makes >it harder for me to parse correctly. >>>There are unclarity of which agent is referenced and whom "it" is in the >>> sentence. > >It is the STUN server. > >Would the following be more clear? > >"If the agent is using Diffserv Codepoint markings [RFC2475] in data >packets that it sends, the agent SHOULD apply the same markings to Binding >responses." > >Yes, except that I stumbles "it sends" where it is more likely "it will >send" is the correct form. "If the agent is using Diffserv Codepoint markings [RFC2475] in data packets that it will send, the agent SHOULD apply the same markings to Binding Responses that it will send." --- >>> 8. Section 8.3.1: >>> >>> The procedures in Section 8 require that an ICE agent continue to >>> listen for STUN requests and continue to generate triggered checks >>> for a data stream, even once processing for that stream completes. >>> >>> That reference to Section 8, should that in fact be to Section 8.1 >>> specifically? It looks strange with a self reference, which in some >>> aspect a >>> reference to section 8 means. > >I think this issue was missed. Sorry for that. The text can be removed, because it refers to text further down in the same subsection (first sentence of second paragraph). --- >>> 9. Section 15: >>> >>> 4.57566E+18 (note that >>> an implementation would represent this as a 64-bit integer so as not >>> to lose precision). >>> >>> Why the floating point representation? Priorities are integer numbers >>>and >>> thus >>> should be presented as such in this example. >> This is from RFC 5245, and unfortunately I don=B9t know. > >Can you not just calculate the 64-bit integer and write it out? So, you want me to write 4575660000000000000? Regards, Christer --B_3600341461_46075842 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOQYJKoZIhvcNAQcCoIIUKjCCFCYCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIMMIIGBjCCA+6gAwIBAgIQN4YipkcuAr1/ZKbsw+1eMTANBgkqhkiG9w0BAQsFADBH MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTAzMDgwODMyWhcNMjAxMTAzMDgwODMxWjBvMREw DwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRQ2hyaXN0ZXIgSG9sbWJlcmcxLTArBgkqhkiG 9w0BCQEWHmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTEPMA0GA1UEBRMGTE1GQ0hI MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy0z3dlyw+ybHo7PhlkBY00QOJB5T NOXcMdxiQ0nL5uM1C/0xQ7/T3uuHJRjD8nvqTqnlmfJ2VCZRKD3W8LJAUXGFd8JqwLJmGGZt cS3Jp+2WBAxBR6TjtcMwDGQNYD85YCKIuqcsarOxVhzXhwISp750JC1UmR4xxX1gbSkVb8S8 DsPsBioQ/Enkiad/rP0huQFb56Ocxu2Fy2aEW06ezyxU9My4Jh/vMDh+0DBb8EfN8ovAFmMH Qj3SxVUDwnTYbPdA1v3RipF/HH0NBsNOUS8RFct6OxHG1JDbMrkY9ErEKkrHmu3JyNM1hxmy 8rJl/yDID2n6vyxkh5QFcsvOdwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0 cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCB ggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEu Y29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNz c29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEeY2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEW LGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUESOe8HpdLQz1aZdNgbOPnJlysTIw HwYDVR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqG SIb3DQEBCwUAA4ICAQBdN30YKQsw+ow1tjR6gBDuNpQagWRw7DSkYXg4ZE5k76jyXPOTa9VE 8x3MbNIbsyuVLYiVIN/lePTPi4qyt1CNBGPn4roUOuGeGQ7/dABYWNGmT0nKjjeXmqs9bt5z CrxPfVS4xeEU7D64OJtD47f069jsG5E6qENdPmrjaKmTrllfM1S9HvWeco8PwBQC5ixpiXUq t3Dyq3K0GmCgs1P7dJqup+Dt6UNF+DwgSZZeBjo3l+BtAv7StrvWdUQCqJpjUttIwzmtqsx2 NUWa1oSoqvUJ6XnJUZdT/UF390/6Uo4rnTeOWao9dkKQCaE3KvtCHBNZRv1MW0Ot3KSKnE+4 iZeUZgg1KAVQ5dhjjtXmjYoZMYoN4lE4OB2ae8LRbOrj0PE7Wvbuhs5eOyei7e6lYDHPzpLn cfcLpQmOoHal11JqympoeJQENtQl2i1p2j5KmsfUQiqD1HQaGcpH9OKXEclLCOpQ/6zafNW3 nSYFBwADNpHMNiQXxcXKxiPCfiZa2UK5RRWohIz9kY8HXvX/1E2pvtOZoymiXJviR3g2BFvM 21+LIVu3dtoEWWxtD7MyDtOe1dEZTfxLUPMpQa66znWbEQ736mmv5n/z+Aaq7OidNuOIFfO2 HbE+LBHIWhKAy9Ttqa+RqpPONMkvz3kth+G4IOBaTYEPWWHLrqXe2zCCBsIwggSqoAMCAQIC EFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25l cmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4IC DwAwggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs 0zfSTm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9 ZVbXILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvS xlfpVdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eN o4v2PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWq g5t2H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4 TlG4rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1 MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYv SBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaG K5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoG CCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25l cmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVy YS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNV HSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRv cnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8v Y3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMS MA0GCSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gV LtDUJQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyo EBHGvw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50Zk BqYnnl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEO rPwfixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1Ur RIQ85AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKX e4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNO xdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaH KWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyE G/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDCCBTgwggMg oAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEy MDA1MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMM FlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQDCvusn8CGj82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1 gouuSLasANxldewqTV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/te uuSPl2e+S46NZAdXOFVpNDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv41 4e1Qe6kwjRnTCY5oZ12/PJcYU7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1s OTlzgBbIUrAjzeA+3N08R6C7NYrimGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1v gPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdf Y2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCDLrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2 WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt6 0H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKSL2LUP2lDfA3W/Fh1AYidWBZL3rqQ /0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8wPTAPBgNVHRMBAf8EBTADAQH/ MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA389ZoG5XcUkeudQXuZ KoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyywqODAQDc19oRc XOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr7cQZ5qtM ETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65XI0G SK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI 6wzWJoi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2H dqkXlrfPDZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/ xFZT+mNl0PMcDhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjU kL8Ws9nprFlhVMgcusrByuG5IEyPOpOJpaDMv9P2daR1lm1WMYIB8TCCAe0CAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMCEDeGIqZHLgK9f2Sm7MPtXjEwDQYJYIZIAWUDBAIBBQCgaTAvBgkq hkiG9w0BCQQxIgQgaohrh9Roy1ief+KuP1xKCfVJlBjr7raHibhYjeaajvQwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwMjAxMTI1MTAxWjANBgkqhkiG 9w0BAQEFAASCAQC5JVUqNn0s2LoGI52PpACXqY8JNvV+Kx3F3BVqhK3oAiaT3BgqSwiKN9GM /0T3ALEvuuGZdLbs5P9EAe4oY1Whu0BLyBsw+hOHk9z8FIrQOMf4UwyFevtlSn/JkaOzoGsc 54Y0L/QaWy5CioUafNlgZBadoKDJf8geQ4hjaUPmSEvDC9IGqPNMblI//HwFH/C8f700y1q0 EMH9lM0LvSbO9+sTzFZ5a99fNC8yEEtwQZ7LW6qokPiAoag2b5qs0+be4bZqgsJSuDoU0x2l THcj50ksqBRoWnlq0n0uheR/P+FvwPDKc5jiOE6C1fKJ/OY4UGHo3+p7MvEE5wrdRJb3 --B_3600341461_46075842-- From nobody Thu Feb 1 11:08:14 2018 Return-Path: X-Original-To: ice@ietf.org Delivered-To: ice@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B17E12E889; Thu, 1 Feb 2018 11:08:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ben@nostrum.com, ice-chairs@ietf.org, pthatcher@webrtc.org, ice@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.71.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151751209219.24384.852480970834699544.idtracker@ietfa.amsl.com> Date: Thu, 01 Feb 2018 11:08:12 -0800 Archived-At: Subject: [Ice] ice - New Meeting Session Request for IETF 101 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 19:08:12 -0000 A new meeting session request has just been submitted by Peter Thatcher, a Chair of the ice working group. --------------------------------------------------------- Working Group Name: Interactive Connectivity Establishment Area Name: Applications and Real-Time Area Session Requester: Peter Thatcher Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 35 Conflicts to Avoid: First Priority: payload core rtcweb avtcore t2trg tls tsvarea tsvwg tram mmusic dispatch tcpm quic Second Priority: perc httpbis rmcat netvc sipbrandy stir Third Priority: ace 6lo lwig clue xrblock sipcore cbor People who must be present: Ben Campbell Ari Keranen Peter Thatcher Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Feb 1 12:07:21 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3A6129C6C; Thu, 1 Feb 2018 12:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=Nv7jjFT1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ChTIxzqz 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 vZMxPhvZuP0g; Thu, 1 Feb 2018 12:07:17 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41231129966; Thu, 1 Feb 2018 12:07:17 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 8991B20D73; Thu, 1 Feb 2018 15:07:16 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 01 Feb 2018 15:07:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=GZ1Nz2NR23HOZ1jQ3+mAjuDDfUFoBpNevBJONVaCfqE=; b=Nv7jjFT1 kIzKh354pL5IoPuV1Yev7dAQc8upb+O7jAC1VsDwfJMLVHFD8uW0Lw3tGWv5mZjq 2wPf6r6HdclT7Bfcpk1iMAQcVr1HWXpC1FeBbgLlsPPSoPWvN0xf7HdWjAJLDpgD tOJBUsKFFOJDBd+oN11wk9YPK8p9UbNPB8YRfLOTbEDQi7U5UtFFkidWhiDvtLBo JiWh9rKkhGiFa7498lSBAb2vTIG5eWgujGzXQ53yUlqIJrKGWC5xju0F1K1KSv+h FPllpQEaYl0+ZnmC/WoOAf1UGpz8nmWJTQu72CZPmmd42dwLuT2gjhC9671cmi8r B3vq6Bt+SStQzA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=GZ1Nz2NR23HOZ1jQ3+mAjuDDfUFoB pNevBJONVaCfqE=; b=ChTIxzqz2UlEpGi4vm2O1nei2U2KFWSkhKfnliVafcO1L NR49fH0L00gMoPfIwG67gqhoR6op8LkVml2pnCl7Vcnh2Ur7u8Z03lcxY/fWpDfi F1WXHWXVoSw+7wSBLDYzTO5TMtkSSXd+45iEIyxxcG28gkzcbEOm+Z/0EZta8BYg iogp5N3jGa8hJamWt8Sb7E3ZBmLZYN/uzi82YT11Adt9ohhcpAHTiBy4lmaYBs4I nYG09fV/hZGtmM1mZlXMEDsQEVLnsRUgKAmm8qw7x0J16MSksJQos5JG2NPr+3Rs 6EBnWelU0Fq75WxkSK0Gp3i0ytUH0fMb+WfARPEhQ== X-ME-Sender: Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id E26CE2463E; Thu, 1 Feb 2018 15:07:15 -0500 (EST) To: Ben Campbell , "draft-ietf-ice-rfc5245bis.all@ietf.org" Cc: draft-ietf-ice-trickle.all@ietf.org, "ice@ietf.org" References: <85ba14f8-7062-6df1-343d-9431f4a57263@stpeter.im> From: Peter Saint-Andre Message-ID: <64364b12-9bc5-5fc1-2578-3a1f11fd8f6e@stpeter.im> Date: Thu, 1 Feb 2018 13:07:14 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="CqfRZEJO97YShyHUrcyjXTwvWBrOqOmUb" Archived-At: Subject: Re: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 20:07:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CqfRZEJO97YShyHUrcyjXTwvWBrOqOmUb Content-Type: multipart/mixed; boundary="bZ3MtN4hjJnCcQTktPEBu9dDF9TlSrw7P"; protected-headers="v1" From: Peter Saint-Andre To: Ben Campbell , "draft-ietf-ice-rfc5245bis.all@ietf.org" Cc: draft-ietf-ice-trickle.all@ietf.org, "ice@ietf.org" Message-ID: <64364b12-9bc5-5fc1-2578-3a1f11fd8f6e@stpeter.im> Subject: Re: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle References: <85ba14f8-7062-6df1-343d-9431f4a57263@stpeter.im> In-Reply-To: --bZ3MtN4hjJnCcQTktPEBu9dDF9TlSrw7P Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 1/31/18 9:47 PM, Ben Campbell wrote: > Thanks for your quick response, Peter; this discussion was > helpful=E2=80=94partially by bringing up a separate but related questio= n > (more for 5245bis than for ice-trickle): >=20 > Section 13 of 5245bis talks about a series of tokens for > =E2=80=9Cice-options=E2=80=9D. But since the ice-options SDP attribute= in no longer > defined in 5245bis, did we lose the text that says that the ICE > option needs to be able to carry multiple tags, whatever the > signaling protocol is? I don't want to speak for the 5245bis authors, but it strikes me that the exact form of "the ICE option" will depend on the signaling protocol. That is, it's not necessarily the case that syntactically the signaling protocol will define a single construct for "the ICE option" that itself can include "multiple tags" - that syntax might be true for SDP but not other signaling protocols. For instance, in XMPP (for which we still need to update the relevant Jingle transport method [1]), the fact that an entity supports "ice2" and "trickle" will be signaled by advertising the 'urn:xmpp:jingle:transports:ice:0' XML namespace (whereas support for pre-ice2 is signaled by advertising the older 'urn:xmpp:jingle:transports:ice-udp:1' namespace' defined in XEP-0176). Peter [1] https://xmpp.org/extensions/xep-0371.html --bZ3MtN4hjJnCcQTktPEBu9dDF9TlSrw7P-- --CqfRZEJO97YShyHUrcyjXTwvWBrOqOmUb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAlpzc3IACgkQ6gakkSvF rak4xA//TgL7hKuEJ3XImHqDx1dvFMSG4OdU9fvPKq9LJWq9FZl2BRPwBI7MdQfJ c0Z/xJ4ejFboIbl9PmFcUE/GWDUbiCPBzhhh+K6Qo4jp6hYQU9UDoeRhDh/WW0m+ oGiMUI5C2DilU6uU9yuWSNE+Hvoziup0Ek80S6h8QxEWNVsFcpW2OKQvhcbyiTL1 hNcB7n5YDEyfHunHEwIz+BfGao5ZRcF7yIEumfSzIRviBNuSi49OADYokTe0/UKN M2INbmxElOMLekCP8ZNrs4rOw3ZhRLlY9f45KsQfAfTwZ+oUvjngh4iLFQQZkAou MdemUxKR/tA3AnFNf/8CViD5pkn7WJryhC2GAL1yKYTN295tDMU3Z/0hpkIdAsv1 UccArOi9snXBlH4++Mby6W1/nrgaaQ0cki0LC9RvAKQTDWcF1TBhD1lieUYLoYN6 0Me/JuTumm7K+boBuwEeinAkgtyznhQTv4Y84gHdpf6vya7xfeDq2wetd0xwVtlY aIfbPZFIAEwvxrSH0/APke1HsCt7/x6Vtbwmxg2OMLICGEaQeTBUEvWxRWsrhJA9 CVqwSZoF+yz0ZqHSYAe/Zx6+kgLhB5j+qiO+n8izvKORvit04EjC4rNYJ96ztY+Z lsNa4EtpDobCqLB7ucGohwZqHDzThJDQXWP2tyEvhuz/cwC8b0I= =6MYQ -----END PGP SIGNATURE----- --CqfRZEJO97YShyHUrcyjXTwvWBrOqOmUb-- From nobody Thu Feb 1 12:51:16 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26C412EC1A; Thu, 1 Feb 2018 12:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKgESpJ-hEbH; Thu, 1 Feb 2018 12:51:11 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A0D9112D7EC; Thu, 1 Feb 2018 12:51:11 -0800 (PST) Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w11KpAun068171 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 1 Feb 2018 14:51:10 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105] From: Ben Campbell Message-Id: <7D9168EE-374E-4EAD-A807-1DC86216CBE7@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_3407C089-C701-4388-9FD3-C946F6C460ED"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 1 Feb 2018 14:51:08 -0600 In-Reply-To: <64364b12-9bc5-5fc1-2578-3a1f11fd8f6e@stpeter.im> Cc: "draft-ietf-ice-rfc5245bis.all@ietf.org" , draft-ietf-ice-trickle.all@ietf.org, "ice@ietf.org" To: Peter Saint-Andre References: <85ba14f8-7062-6df1-343d-9431f4a57263@stpeter.im> <64364b12-9bc5-5fc1-2578-3a1f11fd8f6e@stpeter.im> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 20:51:15 -0000 --Apple-Mail=_3407C089-C701-4388-9FD3-C946F6C460ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 1, 2018, at 2:07 PM, Peter Saint-Andre = wrote: >=20 > On 1/31/18 9:47 PM, Ben Campbell wrote: >> Thanks for your quick response, Peter; this discussion was >> helpful=E2=80=94partially by bringing up a separate but related = question >> (more for 5245bis than for ice-trickle): >>=20 >> Section 13 of 5245bis talks about a series of tokens for >> =E2=80=9Cice-options=E2=80=9D. But since the ice-options SDP = attribute in no longer >> defined in 5245bis, did we lose the text that says that the ICE >> option needs to be able to carry multiple tags, whatever the >> signaling protocol is? >=20 > I don't want to speak for the 5245bis authors, but it strikes me that > the exact form of "the ICE option" will depend on the signaling > protocol. That is, it's not necessarily the case that syntactically = the > signaling protocol will define a single construct for "the ICE option" > that itself can include "multiple tags" - that syntax might be true = for > SDP but not other signaling protocols. Sure, I guess I meant this more conceptually than syntactically. But if = an application supports, for example, no ice, 5245bis, or 5425bis with = trickle, then you need to be able to distinguish between those. (Not to = mention if they support 5245 legacy as a separate mode.) > For instance, in XMPP (for which > we still need to update the relevant Jingle transport method [1]), the > fact that an entity supports "ice2" and "trickle" will be signaled by > advertising the 'urn:xmpp:jingle:transports:ice:0' XML namespace > (whereas support for pre-ice2 is signaled by advertising the older > 'urn:xmpp:jingle:transports:ice-udp:1' namespace' defined in = XEP-0176). IIRC, Jingle assumes trickle if you support ICE, correct? >=20 > Peter >=20 > [1] https://xmpp.org/extensions/xep-0371.html >=20 --Apple-Mail=_3407C089-C701-4388-9FD3-C946F6C460ED 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 iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpzfbwACgkQgFZKbJXz 1A3o/RAAqiCC0fr7mGUsuE283UNsNLJTOuMARQWEus60ljkDwDAPq3k+sGpi7dvQ 2hy1jz18UXQmU3793J+nLRzjQUNl5LwxdGHzu7XZgLraQKXsgsHAmP1laxDKEXpJ c44p3YRJ2k7q6LwoKEoxw96ltoJlsXj4OAKvDVhF/VFA0DBcYMHX3eL+WK1vVnzm AJypiJ6rxdYdkthE+dvyY+cQeKc1qBgYuL1DVQMWVYpK7wQz2dHN8NY2wWjUQNdX b5lGQ/Wjb92mdzwLYdtYrgiqp7HATqnkoBdqf0RnXhC/v38l2yDCRjpItf+vlea/ V21CKcLTJlsgakif5nJHR9xMPQaGPBN29JGtM7Y+jgn0NkC74htz9UhRTNOuM+xM bBK8t7rVtDrNtocoB0byRsVWnrmeInS/N4Sihb8P/LezYowD8+BfI9GMj6jz5erY AMx6uYDnaZWx3NNT3Z8WRv76WM+qULMAYRACNzFSek4wa+VZf+uamZrYrNuTvpPP IrRWV+R5VaGXJPjrf9yPBQqDhGi3ASVBk/QyepsKSfbPsTUliIEu7ghP0HpfYdvN UhBPIjOkx1CNhK62+8ZSyoHar8m9ufur8NXqJ4MPALVgYV3oTNo/1Lsp/1vzRB97 Sj5Kv9vOzWKWaoDNnHk/VhHohL2XQB0LJt+jiGXNNl2X3AWVmdA= =bTG7 -----END PGP SIGNATURE----- --Apple-Mail=_3407C089-C701-4388-9FD3-C946F6C460ED-- From nobody Thu Feb 1 12:53:53 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A61312DA2B; Thu, 1 Feb 2018 12:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=VKv2Zld8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FsI995ra 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 akbtibe5eOuD; Thu, 1 Feb 2018 12:53:50 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F10512D7EC; Thu, 1 Feb 2018 12:53:50 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E2BFA20C8B; Thu, 1 Feb 2018 15:53:49 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 01 Feb 2018 15:53:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=+NEIK4fwLKqA/XvQDREOlbADcrO7Alav7hPaae5ymeQ=; b=VKv2Zld8 eRMwE+EiwFG5MGJ9m0N6b7P3m4SliFb5gF3luIAB+A2kDkHlkFtbrxj4RYfOBXex v/C4LwGK93raKiyyZQFSXRfEuCyre/x6NHh/eT7YL+h3IvDATyadoaJ1HUsEQZB0 BIl+sjpbVZmOWmSlHxMfF1JavVFvDk3cuHG34aFlsRZae8fVPLb5A7TJNyPWBX/p Z4G8HRGIni/MIvAdT6RMNTgZ7ManFN/BkWA2O3rUDGw4fAXD34kYyu/oXxGm0C1+ GxsizvRHk6gZgOFXq2peV49KjOE9awbA+xCyvJtMN/3PvLn0id0fFl/iP0478dj6 AXd13lMAikLg6A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=+NEIK4fwLKqA/XvQDREOlbADcrO7A lav7hPaae5ymeQ=; b=FsI995raJRy2A/PcIo+/LINY2pitW5k98KZx7JkwBiwJM gTV/mmEJtwgW4/6Q/U0bLG1VGEsTnng/AdZnhyzymkAUzU4jCirKEV1KW4QsxFZy UnoLMWi/d8nP3GmPaBSLr1DXGPRwpqn41vtQ1+goa/CQrNLZBxQCQGC0t0zkozkQ Jyc/qWNswXjsT+EBmOwQnI+Zhe8GSxR4whbAcInQHEuy3rvw07GD+2o0XN9lDh9i udKCXXb0Lrn7nGdr0XOdbHK8EsNwR6EXnmsD7Prza+6ik0AA5K9bj0DSsbez/JF5 TSzSmAOqX49tp8JHFoEtcewaNcv16W9Z0WWMWMOTQ== X-ME-Sender: Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 2A7B32463E; Thu, 1 Feb 2018 15:53:49 -0500 (EST) To: Ben Campbell Cc: "draft-ietf-ice-rfc5245bis.all@ietf.org" , draft-ietf-ice-trickle.all@ietf.org, "ice@ietf.org" References: <85ba14f8-7062-6df1-343d-9431f4a57263@stpeter.im> <64364b12-9bc5-5fc1-2578-3a1f11fd8f6e@stpeter.im> <7D9168EE-374E-4EAD-A807-1DC86216CBE7@nostrum.com> From: Peter Saint-Andre Message-ID: Date: Thu, 1 Feb 2018 13:53:47 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <7D9168EE-374E-4EAD-A807-1DC86216CBE7@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iVL7x8nYOrNj9tM6auJUg0tMSTy5t7E1V" Archived-At: Subject: Re: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 20:53:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iVL7x8nYOrNj9tM6auJUg0tMSTy5t7E1V Content-Type: multipart/mixed; boundary="O65MpWVlfKGA0PTKCFUg2LsIX9hEzP0iR"; protected-headers="v1" From: Peter Saint-Andre To: Ben Campbell Cc: "draft-ietf-ice-rfc5245bis.all@ietf.org" , draft-ietf-ice-trickle.all@ietf.org, "ice@ietf.org" Message-ID: Subject: Re: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle References: <85ba14f8-7062-6df1-343d-9431f4a57263@stpeter.im> <64364b12-9bc5-5fc1-2578-3a1f11fd8f6e@stpeter.im> <7D9168EE-374E-4EAD-A807-1DC86216CBE7@nostrum.com> In-Reply-To: <7D9168EE-374E-4EAD-A807-1DC86216CBE7@nostrum.com> --O65MpWVlfKGA0PTKCFUg2LsIX9hEzP0iR Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2/1/18 1:51 PM, Ben Campbell wrote: >=20 >=20 >> On Feb 1, 2018, at 2:07 PM, Peter Saint-Andre wro= te: >> >> On 1/31/18 9:47 PM, Ben Campbell wrote: >>> Thanks for your quick response, Peter; this discussion was >>> helpful=E2=80=94partially by bringing up a separate but related quest= ion >>> (more for 5245bis than for ice-trickle): >>> >>> Section 13 of 5245bis talks about a series of tokens for >>> =E2=80=9Cice-options=E2=80=9D. But since the ice-options SDP attribu= te in no longer >>> defined in 5245bis, did we lose the text that says that the ICE >>> option needs to be able to carry multiple tags, whatever the >>> signaling protocol is? >> >> I don't want to speak for the 5245bis authors, but it strikes me that >> the exact form of "the ICE option" will depend on the signaling >> protocol. That is, it's not necessarily the case that syntactically th= e >> signaling protocol will define a single construct for "the ICE option"= >> that itself can include "multiple tags" - that syntax might be true fo= r >> SDP but not other signaling protocols. >=20 > Sure, I guess I meant this more conceptually than syntactically. But if= an application supports, for example, no ice, 5245bis, or 5425bis with t= rickle, then you need to be able to distinguish between those. (Not to me= ntion if they support 5245 legacy as a separate mode.) Indeed. >> For instance, in XMPP (for which >> we still need to update the relevant Jingle transport method [1]), the= >> fact that an entity supports "ice2" and "trickle" will be signaled by >> advertising the 'urn:xmpp:jingle:transports:ice:0' XML namespace >> (whereas support for pre-ice2 is signaled by advertising the older >> 'urn:xmpp:jingle:transports:ice-udp:1' namespace' defined in XEP-0176)= =2E >=20 > IIRC, Jingle assumes trickle if you support ICE, correct? Yes, that's been the primary data transfer method in Jingle since the beginning. Peter --O65MpWVlfKGA0PTKCFUg2LsIX9hEzP0iR-- --iVL7x8nYOrNj9tM6auJUg0tMSTy5t7E1V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAlpzflsACgkQ6gakkSvF ranB1Q//RVyDKGJ2rRyeLi7t69Zu+2zJf+V5/mC+shqFD90ELccLezQFlo+2A7Do tUZe4GLioA9r+ndRJ+n42taWDCOcxLbPfjRCkt/1yIkkYA9OCG+uoZKa5v2tEyRk 4nUEXZCYJpToThqSwUdPQx77D9hEvPiV8HpbD4iFOAfh2IkTdxdhk/p4rV9viqv0 QtMb+pJI+Gxjl6gfKD5eBHk50r/bhjD6NSXZcax9PRSGoZ+IIkBt8vhQ6oYS6tci ogF4JwO2N3WwxwQTOPNnP3uCfODXdCKgC5GX7sYBxD1nZINdD0eryzn+YAY9SZri r5lQaRqVkwgOuufYxfPWDCkM0Qh4sbrMhVrmrB1ZQMl970qZJ+rGLj+aR81dD3ay 1EGbFkC8bfp7du53oYiCHtEVQfmWaQU2Ct1CMgBxURwYO41NerGwM1gviMH6ZBri 7OZ+cLH8wcZdk7v8EAZO7pxwa/naRDTdjOIfCZLchCKkBDMcAbK5ZWtiHxA0JzCy z7FqMyDwBuD0uEWB98v+RsO7LgtFJ8PFwvRixWU3s9jWxG2/d3vbqEVjzDZQTmk5 JGmLYS/5nrgfjN5ZNT2Z3tEEPP4ittyW5cTYGWpYUMSAk8fYeMoZfwLloyHyBnVv TS+mCyiC0Mg8cpWIe/la3PEAfJPYYTzaZ3y8BADSQC3Jpr1iZzU= =GDn9 -----END PGP SIGNATURE----- --iVL7x8nYOrNj9tM6auJUg0tMSTy5t7E1V-- From nobody Thu Feb 1 13:21:00 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB8612D94C for ; Thu, 1 Feb 2018 13:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=VGTQM0in; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=I/RGVB4j 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 XaPFXUVljHpO for ; Thu, 1 Feb 2018 13:20:53 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B3112ECB3 for ; Thu, 1 Feb 2018 13:20:52 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id D3E9420C1B; Thu, 1 Feb 2018 16:20:51 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 01 Feb 2018 16:20:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=heIxTrGeaLRQ0hzaYJh6gdNII4IQEbkCdtMrET7+mrU=; b=VGTQM0in bFDw+D6kvkBlHrE5LlUSh/BDJZ/KtIFbD3o4vZu9deXipMb9D742IXJxS8rdXWBc xw+TaUhN2+vSb9br1TdWWid8KlSnZGfe/EcacZ29yI7ytxnYt1vcyxDPJjR+DsHs yAigKNHEyTEgtCfKjA5BJGRZuE+YFy4WcOhaIggrvMO42DguuJpuxzQ7rnZklCp1 KgPeUtVBdiRbW2jA3O9OWQnktMQ1y1l41oGyFQK95If1QlKFpJfJ7oPF4seBXUeg 5+kCgJOzhCE4HSHaNYrwvjrTIOIES7L4OsVJ58OGFQ5t6kzdP4vkEWrjF9Gq08iq wNgrKXl7Fa1p6A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=heIxTrGeaLRQ0hzaYJh6gdNII4IQE bkCdtMrET7+mrU=; b=I/RGVB4jZmEFOjitMdJPmxnTh53Cestb+q+XfpK5BtF8S l+oI3DlHEmCaiFcr3iueN9p52tlhv7FIjfQY43UGohDQ2sMTEbV6bkQBzW5/iT4q 5Jj3H9+D869jXZ2U9bFXPFGs1IUsHJKE9bak2ZqRK3UwrE1JBtjDXQWXuSx/7mSV aYsnVJQcln3YJn5fGh9BuBmp8Hk6QfHf3jbQUZiNGVJYSOCCPIEcO7CmJkT3jMdt aiWjk2di4w1JgADyqcUphuiz3IFfTTyxSlJIeh0qGJNqfOgnJTf20TmwV2LB4fm9 Qtd1CfDnH90EDjTAwgialFGSTwHDUdt30Pkx0Izag== X-ME-Sender: Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 44CBB24610; Thu, 1 Feb 2018 16:20:51 -0500 (EST) To: ice@ietf.org References: <879BAF1F-8DC5-4850-A7CB-711EC85DE282@nostrum.com> From: Peter Saint-Andre Message-ID: <7d5ff628-df64-3bd5-6327-cfb0ce0fa2a5@stpeter.im> Date: Thu, 1 Feb 2018 14:20:49 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <879BAF1F-8DC5-4850-A7CB-711EC85DE282@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VhfmDZKHrRryn6tXInE38wmBhjHpuQvG7" Archived-At: Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-trickle-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 21:20:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VhfmDZKHrRryn6tXInE38wmBhjHpuQvG7 Content-Type: multipart/mixed; boundary="qSjTmHueY8RJSgaKZ1Tbm9UDMsQhsJ9LA"; protected-headers="v1" From: Peter Saint-Andre To: ice@ietf.org Message-ID: <7d5ff628-df64-3bd5-6327-cfb0ce0fa2a5@stpeter.im> Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-trickle-16 References: <879BAF1F-8DC5-4850-A7CB-711EC85DE282@nostrum.com> In-Reply-To: <879BAF1F-8DC5-4850-A7CB-711EC85DE282@nostrum.com> --qSjTmHueY8RJSgaKZ1Tbm9UDMsQhsJ9LA Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 1/31/18 10:31 PM, Ben Campbell wrote: > Hi, >=20 > This is my AD evaluation of draft-ietf-ice-trickle-16. >=20 > The document is general well written and easy to follow. I have a few > comments and questions I=E2=80=99d like to address prior to IETF LC. Thanks, Ben. BTW, given that draft-ietf-ice-rfc5245bis and draft-ietf-mmusic-trickle-ice-sip are already in IETF Last Call, I hope that they will not be considered by the IESG apart from draft-ietf-ice-trickle. Concurrent review will help ensure that the specs are in sync. > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94 >=20 > - section 3, 2nd to last paragraph: >=20 > [Note: I already brought this up in a separate email, and Peter > suggested a fix. I=E2=80=99m including it here for completeness] >=20 > This paragraph is written in terms of the SDP ice-options attribute. > It should talk about the generic ICE option described in section 10 > of 5245bis. >=20 > - 4, last sentence: =E2=80=9Cearly as possible=E2=80=9D seems a bit sub= jective for > use with the SHOULD, especially since that will be very application > depended. I imagine developers trying to decide if they should send > an initial offer the second a user hovers over a contact (which may > or may not be a good idea.) Please consider restating this without > the 2119 SHOULD. OLD the initiator SHOULD generate and transmit their initial ICE description as early as possible, so that the remote party can start gathering and trickling candidates. NEW the user experience is improved if the initiator generates and transmits their initial ICE description as early as possible (thus enabling the remote party to start gathering and trickling candidates). > - 5, 2nd to last paragraph, last sentence: Should =E2=80=9Cfallback to > [RFC3264]=E2=80=9D be =E2=80=9Cfallback to non-ICE processing rules=E2=80= =9D? Yes, that's better. > -13, first sentence: "Either agent MAY convey subsequent candidate > information at any time allowed by the signaling protocol in use.=E2=80= =9D >=20 > I=E2=80=99m a little confused by this, since previous text said you MUS= T NOT > keep trickling after sending end-of-candidates. From the context of > the section, I assume this is talking about future exchanges (e.g. a > new offer) , not trickling as a result of a previous change, but the > words seem ambiguous. This would be better: Before conveying an end-of-candidates indication, either agent MAY convey subsequent candidate information at any time allowed by the signaling protocol in use. > -16, 2nd paragraph: "Therefore a candidate for a specific component > MUST NOT be conveyed prior to candidates for other components within > the same foundation.=E2=80=9D >=20 > I=E2=80=99m confused by this sentence; it seems like a deadlock where n= o > component candidates can be conveyed first. Should =E2=80=9Cother compo= nents=E2=80=9D > be =E2=80=9Cearlier components=E2=80=9D? Good catch. The term "component with a lower ID number" seems more accurate than "earlier components". I suggest: Therefore candidates for a given component MUST NOT be conveyed prior to candidates for a component with a lower ID number within the same foundation. > -16, paragraph after the SDP example: This seems to be an explanation > of the example, not a normative statement. Please consider stating > without the 2119 keywords. s/MUST/would/g > -18: Please consider using the IESG (iesg@ietf.org) as the contact. I > know we=E2=80=99ve had individual contacts for these in the past, but t= he > iesg address is (hopefully) more stable than individual or WG > addresses. Agreed. > -19, 2nd paragraph: >=20 > Stephen=E2=80=99s SecDir review[1] of 5245bis asked for a stronger stat= ement > about the application=E2=80=99s ability to control control which networ= k > interfaces are exposed in ICE candidates.. It may be that having such > a statement in 5245bis is enough, but don=E2=80=99t be surprised if it = comes > up in IETF LC or IESG review. >=20 > [1] > https://mailarchive.ietf.org/arch/msg/ice/fyhuRfrMJqdnCJnE6MJ_0peMFsw Given that draft-ietf-ice-trickle merely provides a method for communicating ICE candidates incrementally instead of all at once, it seems to me that it does not have an impact on the permissions model behind exposing ICE candidates in the first place; thus I expect that the text being added to 5245bis is enough. But thanks for the heads-up. Peter --qSjTmHueY8RJSgaKZ1Tbm9UDMsQhsJ9LA-- --VhfmDZKHrRryn6tXInE38wmBhjHpuQvG7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAlpzhLIACgkQ6gakkSvF rakPjQ//fJWZfZMGvU7R4OfnMPnQzE9J8fvBHl9N9y7Drgh7lVXOzv3aQYlLo9xg RnEwyg/RCCIdA1AfKEpIzwSW5CoElO18cg5gjhWRSnlkSDhD0Ume++RpaeNddF/N tl4VjYa3meQ2idO7cgNpODF3x/UU68tm5ZwSii5Dfast8t25Lndbnke2UrSMa59n JjTO6uXvHeNwiY6wvHeWazm9MayK8EqhBmBSPN/iIFMNbcgS5t3pnuYxIcgpQYAq fOLHglPTXDx6vqAZi0K3OPgjV0s68Jw0Uyf/5JHRxxikhkuu3xzkLY2mGSXOVkmu TvyPXluvWJTxzC+QZ0/n/i76EFOsZSGa+HZDr0L7tT77GzW5K0cbOl8zI1qqrIcs uk5MxoL+R2a+nnDM62PySJ4VI90exWNCD0kPCVp4pEHV35oP/PDNi/ZBKrUcXGm/ SS+pbdv/X9PNVmr0IwfcjmxVmiXD3AItF0AcAmCh6+ZeArse3NfVZvIZAwVmzfXp g3G1Zbrn0tMfjy3F340mQrqiKWIE5EiHXkeW7uF1kwYcoTVjnWxUivq8v7xoiqIL rqfSM7zCd6OFKqKr1QmoLXhaZICqSniG1dxrO32/IX2/f6/ZGkJRpqJ1TaWhv66B 8D12HIixwneEQX8IIZrp9K2DuDTQKSADrYG5Wx4+w8eNUOWrFQ4= =NV0a -----END PGP SIGNATURE----- --VhfmDZKHrRryn6tXInE38wmBhjHpuQvG7-- From nobody Fri Feb 2 02:13:58 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB62D12EA42 for ; Fri, 2 Feb 2018 02:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBs9rai4ktM8 for ; Fri, 2 Feb 2018 02:13:48 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 110BC12FA9A for ; Fri, 2 Feb 2018 02:13:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517566426; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xGWYscpuEBPyxnnjIvU7209QPqNHB+7vIsbQo7TZkeM=; b=Ee4R086D+B2YAHZuxJyP0OUN4Lsppm9xaUbBIC+oc2u7cen82va3bbZOdqBqQ0Yb JwO1sexThUDs7Uv/lcy9kRLhcjhZX2zrqfxE1XUlWW6Fw4QegJPFnPUVrB2FjCcu 2eRfMom3iaU9MaS4++VP5g0Yb7jLO++dpDUHGUgbJ1s=; X-AuditID: c1b4fb30-d49ff70000006bc7-4e-5a7439dae2a3 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6F.0A.27591.AD9347A5; Fri, 2 Feb 2018 11:13:46 +0100 (CET) Received: from [147.214.160.85] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 2 Feb 2018 11:13:45 +0100 To: Christer Holmberg , "tsv-art@ietf.org" CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" References: <151731848710.27439.7061415423323921488@ietfa.amsl.com> <1d6ab623-0076-2e75-0e99-6a24e55ee934@ericsson.com> From: Magnus Westerlund Message-ID: Date: Fri, 2 Feb 2018 11:13:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000802020200070801070901" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7n+4ty5Iog29X+SyO//jDbvHtQq3F s43zWSxm7VnE4sDisWTJT6YAxigum5TUnMyy1CJ9uwSujNe3LjMVbDvPWNHfcYK5gfHjKsYu Rk4OCQETiYkbbrJ3MXJxCAkcZpRY1/WAFcLZxChx494JNpAqYQEXia7zv9lBbBGBeIkDzz8y gxQxC8xklHj98yUjRMddRokll1+CdbAJWEjc/NEIZvMK2Eus3nWVBcRmEVCROPC7HcwWFYiR WNB8iBmiRlDi5MwnYHFOARuJPbOPsENs6Aa66VgLE0hCSEBboqGpgxXicCWJ6/Ous0xgFJiF pH8Wsh6QBLOArcSdubuZIWxtiWULX0PZ4hJNX1ayQtjWEjN+HWSDsBUlpnQ/ZIewTSVeH/3I CGEbSbzb08i+gJFzFaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZg9Bzc8ttgB+PL546HGAU4 GJV4eMs1S6KEWBPLiitzDzGqAM15tGH1BUYplrz8vFQlEd6vG4qjhHhTEiurUovy44tKc1KL DzFKc7AoifOe9OSNEhJITyxJzU5NLUgtgskycXBKNTA2qF2RCt/58B3TP1GroI0bXpVvuDVv s2qyjdBrSbcS4Ufe1hl57PN2mzWJsaoFlaf7n1r4bpuT7TydjZX52ZNtzzqt//WSaa6Ax6yl xzfb9GbOO7uqJsme8S/v0/aneYqBnnH7WX74b4loDOuYo3D2EM+f5YX/GA5Mmtcf1V68NULT PmnH2ZdKLMUZiYZazEXFiQDEUxhbpgIAAA== Archived-At: Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 10:13:52 -0000 --------------ms000802020200070801070901 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Hi, See inline for text proposal and clarification on that last editorial=20 issue. Den 2018-02-01 kl. 13:39, skrev Christer Holmberg: > Hi, > >>>> Significant Issues: >>>> >>>> A. Section 5.2: >>>> >>>> Lite implementations only utilize host candidates. A lite >>>> implementation MUST, for each component of each data stream, >>>> allocate >>>> zero or one IPv4 candidates. It MAY allocate zero or more IPv6= >>>> candidates, but no more than one per each IPv6 address utilized= by >>>> the host. Since there can be no more than one IPv4 candidate p= er >>>> component of each data stream, if an ICE agent has multiple IPv= 4 >>>> addresses, it MUST choose one for allocating the candidate. If= a >>>> host is dual-stack, it is RECOMMENDED that it allocate one IPv4= >>>> candidate and one global IPv6 address. With the lite >>>> implementation, >>>> ICE cannot be used to dynamically choose amongst candidates. >>>> Therefore, including more than one candidate from a particular >>>> scope >>>> is NOT RECOMMENDED, since only a connectivity check can truly >>>> determine whether to use one address or the other. >>>> >>>> I find it quite strange that the above text says there can only be >>>> single >>>> IPv4 >>>> based candidate, while for IPv6 a LITE implementation may have one >>>> candidate >>>> per IPv6 address. Isn't the LITE implication of having multiple >>>> candidates for >>>> the same address family similar? Yes, IPv6 kind of forces the need f= or >>>> dealing >>>> with multiple IPv6 addresses on any host. However, I can see that >>>> certain >>>> servers will actually be multi-homed in IPv4 and thus can in a sensi= ble >>>> way >>>> actually have multiple IPv4 candidates, and let the clients select >>>> which >>>> interface has the best reachability. >>>> >>>> Can you please be explicit on what in ICE prevents things to work fo= r >>>> IPv4 but >>>> the same case works for IPv6? >>> This is text from RFC 5245. I agree it is confusing, and unfortunatel= y I >>> don=B9t have a good answer. >>> >>> I guess my approach would be to suggest that we simply remove the >>> restriction. In addition, there is generic text about dual-stack etc >>> elsewhere, >>> and I don=B9t see anything ICE lite specific. >>> >>> OLD: >>> >>> "Lite implementations only utilize host candidates. A lite >>> implementation MUST, for each component of each data stream, >>> allocate >>> zero or one IPv4 candidates. It MAY allocate zero or more IPv6 >>> candidates, but no more than one per each IPv6 address utilized by >>> the host. Since there can be no more than one IPv4 candidate pe= r >>> component of each data stream, if an ICE agent has multiple IPv4= >>> addresses, it MUST choose one for allocating the candidate. If = a >>> host is dual-stack, it is RECOMMENDED that it allocate one IPv4 >>> candidate and one global IPv6 address. With the lite >>> implementation, >>> ICE cannot be used to dynamically choose amongst candidates. >>> Therefore, including more than one candidate from a particular s= cope >>> is NOT RECOMMENDED, since only a connectivity check can truly >>> determine whether to use one address or the other." >>> >>> >>> NEW: >>> >>> "Lite implementations only utilize host candidates. >>> With the lite implementation, ICE cannot be used to dynamically choos= e >>> amongst candidates. Therefore, including more than one candidate from= a >>> particular IP address family is NOT RECOMMENDED, since only a >>> connectivity >>> check can Truly determine whether to use one address or the other." >> I have read Ben's comment on this issue. I think something needs to be= >> done to avoid the confusion. There are I think two alternatives, >> either retain the restriction with an added note on why this restricti= on >> exists. The second I think is to go with an amended version of the tex= t >> proposal, possibly with even clearer wording that if you are running >> multiple addresses in the same family, you should really should be usi= ng >> a full implementation. >> >> I noted that the "NEW" text above needs an amendment, and that is >> because I think a very important part of what was cut needs to be >> retained. >> >> It MAY allocate zero or more IPv6 >> candidates, but no more than one per each IPv6 address utilized by >> the host. >> >> If one generalize this what is missing is the limitation that only a >> single candidate per IP address utilized by the host can be added by a= >> lite implementation. Using multiple would be redundant, but lets use a= >> direct statement to this affect, rather than a subordinate clause to = a >> MAY statement. > Could you suggest new text? What about: "Lite implementations only utilize host candidates. For each IP address, = independent of IP address family, there MUST be zero or one candidate. Wi= th the lite implementation, ICE cannot be used to dynamically choose amon= gst candidates. Therefore, including more than one candidate from a particular IP address family is NOT RECOMMENDED, since only a connectivit= y check can Truly determine whether to use one address or the other. Instea= d agents that have multiple public IP addresses are RECOMMENDED to run fu= ll ICE implementations to ensure the best usage of its addresses." > > --- > > >>>> B. Section 6.1.1: >>>> >>>> An agent MUST be prepared that the peer might re-determine the >>>> roles >>>> as part of any ICE restart, even if the criteria for doing so a= re >>>> not >>>> fulfilled. This can happen if the peer is compliant with an ol= der >>>> version of this specification. >>>> >>>> What does it mean to be prepared for a peer that re-determine the >>>> roles? >>>> What >>>> is it one MUST do? If the peer changes its role upon an ICE restart,= >>>> isn't that >>>> going to result in a role mismatch? Thus causing yet another ICE >>>> restart, >>>> where >>>> also this peer will re-evalute? Isn't that good enough? Or is it >>>> something else >>>> it can do? >>> The roles are re-negotiated during the ICE restart: it may, or may no= t, >>> result in a role mismatch. >>> >>> "Prepared" means that the peer might change its role even though it d= oes >>> not fulfil the 5245bis criteria for being allowed to do so. >> Yes, but prepared is not actionable. I guess what you mean is that an >> implementation MUST accept and perform re-determination of the role >> initiated by the peer agent, even if the criteria are not fulfilled. > What about: > > OLD: > > An agent MUST be prepared that the peer might re-determine the roles > as part of any ICE restart, even if the criteria for doing so are= not > fulfilled. This can happen if the peer is compliant with an olde= r > version of this specification. > > > NEW: > > An agent MUST accept if the peer initiates a re-determination of the ro= les > even if the criteria for doing so are not fulfilled. This can happen if= the > peer is compliant with RFC 5245. Yes, I think that is much clearer and indicates what might occur, and=20 what to do in the case and why. > --- > > ... > >>>> D. Section 6.1.4.2: >>>> >>>> I don't know if I misunderstand the algorithm here in the bullet lis= t. >>>> To >>>> me it >>>> appears that it will terminate prior to have initiated all possible >>>> tests, as >>>> it appears that it will not unfreeze some of the candidate pairs. If= >>>> one >>>> have >>>> tests running for a foundation, but all other candidate checks have >>>> been >>>> started, then the steps are aborted. Is the bullet list rechecked ev= ery >>>> Ta? >>> No. Whenever Ta fires, one check list in Running state is checked. Wh= en >>> all check lists have been checked, it will start over from the top of= >>> the >>> list. >>> >>> Or, did I misunderstand your issue? >> No, It was unclear that this is re-run every time Ta fires. I think th= e >> reason for this is this sentence in step 4. >> >> If this happens for every single check list in the >> Running state, meaning there are no remaining candidate pairs = to >> perform connectivity checks for, abort these steps. >> >> It was unclear to me that this doesn't mean aborting the whole >> procedure. Because if the requirement is fulfilled then there is nothi= ng >> to do until the next Ta, which will possible unfreeze another candidat= e >> pair in step 2. I would recommend that you reformulate this sentence t= o >> make it clear that the processing for this Ta is stopped, and processi= ng >> will be resumed the next time Ta fires. > Isn=B9t that indicated in the sentence before the list: > > "Whenever Ta fires, the ICE agent will perform a check for a candidat= e > pair within the picked check list by performing the following steps:= =B2 Yes, assuming you correctly interpret those. Which, I clearly didn't=20 that is why I am requesting additional clarity. But, if you think it is=20 good enough, I will let the issue drop. > > --- > >>>> E. Section 7.2.5.2.2. ICMP Error >>>> >>>> An ICE agent MAY support processing of ICMP errors for connecti= vity >>>> checks. If the agent supports processing of ICMP errors, and i= f a >>>> Binging request generates an ICMP error, the agent SHOULD set t= he >>>> state of the candidate pair to Failed. >>>> >>>> I am a bit worried by this blanket statement on ICMP errors. I think= it >>>> should >>>> be clarified which ICMP message types that are relevant to consider = as >>>> errors? >>>> I assume Type 3 (Destination Unreachable) but maybe not all responde= >>>> codes as >>>> Codes 4, 11,12 may be addressable in other ways, and likely Type 11 >>>> (Time >>>> exceeded) with response code 0, response code 1 is not a clear >>>> indication >>>> of a >>>> non working path. >>> This is from RFC 5245. >>> >>> I don=B9t think the ICE WG should go through all different codes and >>> combinations, and determine what should be considered an error, and w= hat >>> not. >>> >>> If you can provide something (table, guidance etc), we are happy to >>> include it. Otherwise I=B9d like to keep it as it is, and let >>> implementations deal with it, as at least I am not aware that this wo= uld >>> Have caused issues in ICE deployments. >> I think we there is a point to clarify that this applies to ICMP >> messages indicating a non-usable path. So maybe it could be rewritten = to >> something like this: >> >> An ICE agent MAY support processing of ICMP messaging indicating a= >> non-functioning path for connectivity >> checks. ICMP messages of type 3 (Destination Unreachable) are >> indicators of a currently non-functioning path. However, the issue can= be >> temporary as it can depend on routing transients, this for example >> applies to codes 0, 1 and 5. Other messages that appear to indicate >> non-functioning path such as Type=3D11 (Time Exceeded) with code=3D0 (= Time to >> Live exceeded in Transit) are not clear indicator as the IP packets >> potentially can reach the destination with a larger TTL value set at >> transmission. Therefore, implementation needs to analyse the different= >> ICMP messages types and codes for which it considers the path as >> non-functioning. If the agent supports processing of ICMP errors, and = if a >> Binging request generates an ICMP error, the agent SHOULD set the >> state of the candidate pair to Failed. >> >> >> What also is not addressed in this is the risk of denial of service >> attacks using spoofed ICMP messages to shutdown certain connectivity >> checks. The security considerations lack any discussion of this issue.= >> If ICMP processing are retained, I think a recommendation about >> validation is needed to avoid at least off path attackers from doing >> these attacks easily. Unfortunately ICMP response will only include th= e >> IP/UDP header, thus no data from the STUN messages which would allow >> verification that the ICMP messages matches an actually sent check. >> >> It may be simplest to recommend against reacting to ICMP errors from >> both the perspective that it is a risk for denial of service attack, a= s >> well as that it represents a risk terminating connectivity checks for = a >> transient issue. From my perspective I expect this to reduce the numbe= r >> of sent connectivity checks very little > So, are you saying that an agent should simply ignore ICMP messages? Yes, I think that may be the best. There are a bit to many corner cases=20 and significant attack surface that getting all the details right are=20 significant work for a relatively small reduction in sent connection=20 check messages. > > --- > > ... > >>>> H. Section 14.3: >>>> >>>> Num-Waiting: the number of checks in the check list in the >>>> Waiting state. >>>> >>>> Num-In-Progress: the number of checks in the In-Progress state= =2E >>>> >>>> Is "the number of checks" only per single checklist or across all th= e >>>> check >>>> lists? >>> Per single check list. >> Section 14.1 says: "Those formulas scale >> with N, the number of checks to be performed." >> >> But, from my perspective, that number N is not on a single checklist, >> but for the whole ICE session, i.e. all the checklists. Thus, I think >> there needs a clarification on why this is per checklist, making it >> clear why these two things match up. > Actually, I think I was wrong. It is per check list SET, i.e., all chec= k > lists. So, please correct the language to be clear on that it is across the=20 whole check list set. > > --- > >>>> I. Section 17.2.3: >>>> >>>> When VAD is being >>>> used, keepalives will be sent during silence periods. >>>> >>>> I would claim that this is only true for when VAD without any comfor= t >>>> noise is >>>> used. A lot of codecs with VAD operations still generates comfort no= ise >>>> on a >>>> frequency of a couple packets a second, way more often then the mini= mal >>>> for ICE >>>> keep-alives. >>> What about: >>> >>> "In deployments that are not utilizing Voice Activity Detection (VAD)= , >>> without any comfort noise, >>> the keepalives are never..." >> That is also not true. As keep-alives is not expected to be needed for= : >> 1. Continous media withouth any VAD etc. >> 2. Media with VAD, but with comfort noise not allowing intervals to be= >> to long (<=3D1 second). > What about: > > OLD: > > In deployments that are not utilizing Voice Activity Detection (VAD), t= he > keepalives are never > used and there is no increase in bandwidth usage. When VAD is bein= g > used, keepalives will be sent during silence periods. This involve= s > a single packet every 15-20 seconds, far less than the packet every= > 20-30 ms that is sent when there is voice. Therefore, keepalives > don't have any real impact on capacity planning. > > > > NEW: > > In deployments with continuous media and without utilizing Voice Activi= ty > Detection (VAD), > or deployments where VAD is utilized together with short interval (max = 1 > second) comfort noise, > the keepalives are never used and there is no increase in bandwidth usa= ge. > When VAD is being > Used without comfort noise, keepalives will be sent during silence > periods. This involves > a single packet every 15-20 seconds, far less than the packet every= > 20-30 ms that is sent when > there is voice. Therefore, keepalives don't have any real impact on > capacity planning. Looks good. > > =3D=3D=3D=3D=3D=3D=3D > > Minor/Editorial Issues: > > ... > >>>> 7. Section 7.3: >>>> >>>> If the agent is using Diffserv Codepoint markings [RFC2475] in its >>>> data packets, it SHOULD apply the same markings to Binding >>>> responses. >>>> >>>> I find this sentence a bit unclear. Is it intended to say: >>>> >>>> If the agent receiving the binding request, intended to use DSCP >>>> markings >>>> !=3D0 >>>> for the data, it SHOULD set, the same marking to binding responses. >>>> >>>> or >>>> >>>> If the agent receives a binding request with DSCP markings, then it >>>> should >>>> apply to corresponding code point when forming the binding response?= >>> It means that it will use the same markings in Binding responses that= it >>> uses in data packets (audio, video, etc). >> Okay, I wonder if it is the temporal aspect of the sentence that makes= >> it harder for me to parse correctly. >>>> There are unclarity of which agent is referenced and whom "it" is in= the >>>> sentence. >> It is the STUN server. >> >> Would the following be more clear? >> >> "If the agent is using Diffserv Codepoint markings [RFC2475] in data >> packets that it sends, the agent SHOULD apply the same markings to Bin= ding >> responses." >> >> Yes, except that I stumbles "it sends" where it is more likely "it wil= l >> send" is the correct form. > "If the agent is using Diffserv Codepoint markings [RFC2475] in data > packets that it will send, the agent SHOULD apply the same markings to > Binding > Responses that it will send." Yes. works for me. > > > --- > >>>> 8. Section 8.3.1: >>>> >>>> The procedures in Section 8 require that an ICE agent continue t= o >>>> listen for STUN requests and continue to generate triggered chec= ks >>>> for a data stream, even once processing for that stream complete= s. >>>> >>>> That reference to Section 8, should that in fact be to Section 8.1 >>>> specifically? It looks strange with a self reference, which in some >>>> aspect a >>>> reference to section 8 means. >> I think this issue was missed. > Sorry for that. > > The text can be removed, because it refers to text further down in the > same subsection (first sentence of second paragraph). Yes, removing that sentence works for me. > > --- > >>>> 9. Section 15: >>>> >>>> 4.57566E+18 (note that >>>> an implementation would represent this as a 64-bit integer so as= not >>>> to lose precision). >>>> >>>> Why the floating point representation? Priorities are integer number= s >>>> and >>>> thus >>>> should be presented as such in this example. >>> This is from RFC 5245, and unfortunately I don=B9t know. >> Can you not just calculate the 64-bit integer and write it out? > So, you want me to write 4575660000000000000? No, I thought the pair priority will not be 0 for the lower 32 bits and=20 that there actually are overflow in this deduction. My understanding is=20 that what should be written here is the calculation of: pair priority =3D 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) Where G and D are the priority values for $L_PRIV_1 and $R_PUB_1. $L_PRIV_1 is L's host candidate, and stated to have a priorty of 21307064= 31 $R_PUB_1 is R's host candidate and stated to have a priorty of 2130706431= So G =3D 2130706431 and D=3D2130706431 pair priority then becomes 2^32*2130706431 + 2*2130706431 + 0 =3D=20 9151314442783293438 Thus, I think the next two pair priorities in the example also needs to=20 be fixed. The first pair priority for R is the same value as for L, as G and D are = identical. But the next value will be different. To my understanding L will be controlling, i.e. L's=20 candidate will be G G=3D1694498815 D=3D 2130706431 Pair priority =3D 2^32*1694498815+2*2130706431 + 0 =3D 727781699779716710= 2 Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------ms000802020200070801070901 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME-kryptografisk signatur MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DNEwggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNV BAoMCEVyaWNzc29uMRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJ ARYebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+ laqg5eXTqonqnzT9ykEGL2dx9mBT+2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJ HGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iV IiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpigGFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36o gzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkrbdmdnjKGrYSnJigmxw14pJugxL/Vb2Ee VcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDov L2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCBggYI KwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29t MEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29u bmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJp Y3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0 dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQG CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3 DQEBCwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4Q ihhoQR3cvhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXD yF9mhWYbSAkJyx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6 H3zO3nsq++KBmsOiSKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvE lup5n7l864FqxnC2friDo4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl 60rmc8SJlt6QXKw0wXEOE1MubauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwD ig3SZi1qP7D/Ds4V+JLIjjUJc25l9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8K v7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLCQaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3 UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Zla71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzY VBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd//n4YbY2QhDCCBsIwggSqoAMCAQICEFO4 foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUx MDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw ggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfS Tm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbX ILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfp VdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2 PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2 H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4 rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX 1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjv Zibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FN VSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoGCCsG AQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEu Y29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j b20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAE TjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnku dHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3Js LTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7 GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDU JQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHG vw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYn nl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwf ixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ8 5AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4Hd Dc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOE EHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd 3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/du jp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDGCAzswggM3AgEB MFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMA0GCWCGSAFlAwQCAQUA oIIBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAyMDIx MDEzNDVaMC8GCSqGSIb3DQEJBDEiBCBTWCKlgtGoE38jSFLTtJKPNqj++bEgqESUKZIHaUxP ejBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBlrrZreXF5 7TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMGwGCyqGSIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nz b24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62 a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAUacGkDrQysWgE4I/Dtj0lJp50lmqgrDH1ADXSjyN suFGPg6rzwl7dp+4OxKG0YDPt6WNamKegZg12n6w+Bt+kkTJMQJ/UGtonFlY/Q8iF7zf5REf U5cVl/gyCCxHAaH3du7F8uQDz6TScYLEIXckpnpXtbMOMmSkzz2YHtclMEq87JAXmIPeg64e w9CA3PYVDFXGL6QwXMpmHa7Khm0eRo1qiReWw1yjj2mr3RFG+F5mDRkPMzkZ7sbCB5JOpLT0 RrCgihod3WBSm0xkJ5hQR5e2kx11BW/4HSCDey5kHKS+xNHdCwGZivKq2cOFOnSylAXzr0hw E6baUOuuy9x2rwAAAAAAAA== --------------ms000802020200070801070901-- From nobody Fri Feb 2 03:12:28 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D9E12EBB5 for ; Fri, 2 Feb 2018 03:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DK7TIvI-c8Kt for ; Fri, 2 Feb 2018 03:12:17 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 9897012EB38 for ; Fri, 2 Feb 2018 03:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517569932; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=r/EjkDFFEhdPbb55Vg+qfV1XHeOLsdfQULZAtwMDTU0=; b=Vs5KEx8kLlWEj1anOaDCixeEBKua077KZoF5ZqjvlYw9/qUeVHb0Xz0XR3/bEyNc BqYGMlHzJ/Fz+vFHUA4fX79LHTOXqczZxuF80I7e9Hko6380py4JL8YMYbHYEx+4 qy4IVSBC2XlnHTYBfMY0H3vrStQS3/Y+2J4qkt5E4Xk=; X-AuditID: c1b4fb2d-b35ff70000007932-ee-5a74478cb9c4 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 22.3F.31026.C87447A5; Fri, 2 Feb 2018 12:12:12 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Fri, 2 Feb 2018 12:12:12 +0100 From: Christer Holmberg To: Magnus Westerlund , "tsv-art@ietf.org" CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" Thread-Topic: Tsvart last call review of draft-ietf-ice-rfc5245bis-16 Thread-Index: AQHTmc09cSMwjiuCL0KSsp8F+FSKLqOMj1UAgALAtgCAAEO8AIABRN+AgAA1HYA= Date: Fri, 2 Feb 2018 11:12:11 +0000 Message-ID: References: <151731848710.27439.7061415423323921488@ietfa.amsl.com> <1d6ab623-0076-2e75-0e99-6a24e55ee934@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.18] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3600422631_47606816" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUyM2J7iG6Pe0mUwY9X2hbHf/xht/h2odbi 2cb5LBaz9ixicWDxWLLkJ1MAYxSXTUpqTmZZapG+XQJXxpnXG9gK9j5hrHh57ABrA+O7fYxd jBwcEgImEt8aFboYuTiEBA4zSty6vI8NwlnMKHHw3EE2kCI2AQuJ7n/aXYycHCIC8RJdW9+B 1TALzGSUeP3zJSNIQljARaLr/G92iCJXieuv2pghbD+Jr99OMIHYLAIqEu+XrgCr4RWwlrh/ op8VYtlkJomlM26ygCQ4BRwkJjy5wQpiMwqISXw/tQasmVlAXOLWk/lgtoSAiMTDi6fZIGxR iZeP/4HViwroSWw4cZsdIq4o8fHVPkaI3kqJ5XOWs0AsFpQ4OfMJywRG0VlIxs5CUjYLSdks oP+ZBXQk/u1ngyjRlnjy7gIrhG0tMePXQai4osSU7ofsELapxOujHxkXMHKsYhQtTi0uzk03 MtZLLcpMLi7Oz9PLSy3ZxAiMyYNbfuvuYFz92vEQowAHoxIPr5lzSZQQa2JZcWXuIUYVoDmP Nqy+wCjFkpefl6okwvt1Q3GUEG9KYmVValF+fFFpTmrxIUZpDhYlcd6TnrxRQgLpiSWp2amp BalFMFkmDk6pBsbsBXJd039Plp/8zb9e1WuTxf8b/u8vHbFXLZQ73XBaepfVvGdpB6oWSn4x 6vVfsfwVX9A0r+ZFk1NWe/qtMXnsXuV7/9tjn9ftAa/6yvuP26T+jL/wcPX7fyvib9wMdkw4 MGnHV48Lx63LI/4IeshJ5C5ZxSQc0CwwsW7PNMO2Qw6xNkdyLvxWYinOSDTUYi4qTgQA88sB CdECAAA= Archived-At: Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 11:12:21 -0000 --B_3600422631_47606816 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: quoted-printable Hi, Most issues seem to ve solved now, but I still have some comments on the ICMP suggestion, and the math stuff at the end. >>>>>Significant Issues: >>>>> >>>>> A. Section 5.2: >>>>> >>>>> Lite implementations only utilize host candidates. A lite >>>>> implementation MUST, for each component of each data stream, >>>>> allocate >>>>> zero or one IPv4 candidates. It MAY allocate zero or more IPv6 >>>>> candidates, but no more than one per each IPv6 address utilized >>>>>by >>>>> the host. Since there can be no more than one IPv4 candidate >>>>>per >>>>> component of each data stream, if an ICE agent has multiple IPv4 >>>>> addresses, it MUST choose one for allocating the candidate. If >>>>>a >>>>> host is dual-stack, it is RECOMMENDED that it allocate one IPv4 >>>>> candidate and one global IPv6 address. With the lite >>>>> implementation, >>>>> ICE cannot be used to dynamically choose amongst candidates. >>>>> Therefore, including more than one candidate from a particular >>>>> scope >>>>> is NOT RECOMMENDED, since only a connectivity check can truly >>>>> determine whether to use one address or the other. >>>>> >>>>> I find it quite strange that the above text says there can only be >>>>> single >>>>> IPv4 >>>>> based candidate, while for IPv6 a LITE implementation may have one >>>>> candidate >>>>> per IPv6 address. Isn't the LITE implication of having multiple >>>>> candidates for >>>>> the same address family similar? Yes, IPv6 kind of forces the need >>>>>for >>>>> dealing >>>>> with multiple IPv6 addresses on any host. However, I can see that >>>>> certain >>>>> servers will actually be multi-homed in IPv4 and thus can in a >>>>>sensible >>>>> way >>>>> actually have multiple IPv4 candidates, and let the clients select >>>>> which >>>>> interface has the best reachability. >>>>> >>>>> Can you please be explicit on what in ICE prevents things to work for >>>>> IPv4 but >>>>> the same case works for IPv6? >>>> This is text from RFC 5245. I agree it is confusing, and >>>>unfortunately I >>>> don=A9=F6t have a good answer. >>>> >>>> I guess my approach would be to suggest that we simply remove the >>>> restriction. In addition, there is generic text about dual-stack etc >>>> elsewhere, >>>> and I don=A9=F6t see anything ICE lite specific. >>>> >>>> OLD: >>>> >>>> "Lite implementations only utilize host candidates. A lite >>>> implementation MUST, for each component of each data stream, >>>> allocate >>>> zero or one IPv4 candidates. It MAY allocate zero or more IPv6 >>>> candidates, but no more than one per each IPv6 address utilized by >>>> the host. Since there can be no more than one IPv4 candidate per >>>> component of each data stream, if an ICE agent has multiple IPv4 >>>> addresses, it MUST choose one for allocating the candidate. If a >>>> host is dual-stack, it is RECOMMENDED that it allocate one IPv4 >>>> candidate and one global IPv6 address. With the lite >>>> implementation, >>>> ICE cannot be used to dynamically choose amongst candidates. >>>> Therefore, including more than one candidate from a particular >>>>scope >>>> is NOT RECOMMENDED, since only a connectivity check can truly >>>> determine whether to use one address or the other." >>>> >>>> >>>> NEW: >>>> >>>> "Lite implementations only utilize host candidates. >>>> With the lite implementation, ICE cannot be used to dynamically choose >>>> amongst candidates. Therefore, including more than one candidate from >>>>a >>>> particular IP address family is NOT RECOMMENDED, since only a >>>> connectivity >>>> check can Truly determine whether to use one address or the other." >>> I have read Ben's comment on this issue. I think something needs to be >>> done to avoid the confusion. There are I think two alternatives, >>> either retain the restriction with an added note on why this >>>restriction >>> exists. The second I think is to go with an amended version of the text >>> proposal, possibly with even clearer wording that if you are running >>> multiple addresses in the same family, you should really should be >>>using >>> a full implementation. >>> >>> I noted that the "NEW" text above needs an amendment, and that is >>> because I think a very important part of what was cut needs to be >>> retained. >>> >>> It MAY allocate zero or more IPv6 >>> candidates, but no more than one per each IPv6 address utilized by >>> the host. >>> >>> If one generalize this what is missing is the limitation that only a >>> single candidate per IP address utilized by the host can be added by a >>> lite implementation. Using multiple would be redundant, but lets use a >>> direct statement to this affect, rather than a subordinate clause to a >>> MAY statement. >> Could you suggest new text? > >What about: > >"Lite implementations only utilize host candidates. For each IP address, >independent of IP address family, there MUST be zero or one candidate. >With the lite implementation, ICE cannot be used to dynamically choose >amongst candidates. Therefore, including more than one candidate from a >particular IP address family is NOT RECOMMENDED, since only a connectivity >check can Truly determine whether to use one address or the other. >Instead agents that have multiple public IP addresses are RECOMMENDED to >run full ICE implementations to ensure the best usage of its addresses." Looks good. --- >>>>>B. Section 6.1.1: >>>>> >>>>> An agent MUST be prepared that the peer might re-determine the >>>>> roles >>>>> as part of any ICE restart, even if the criteria for doing so >>>>>are >>>>> not >>>>> fulfilled. This can happen if the peer is compliant with an >>>>>older >>>>> version of this specification. >>>>> >>>>> What does it mean to be prepared for a peer that re-determine the >>>>> roles? >>>>> What >>>>> is it one MUST do? If the peer changes its role upon an ICE restart, >>>>> isn't that >>>>> going to result in a role mismatch? Thus causing yet another ICE >>>>> restart, >>>>> where >>>>> also this peer will re-evalute? Isn't that good enough? Or is it >>>>> something else >>>>> it can do? >>>> The roles are re-negotiated during the ICE restart: it may, or may >>>>not, >>>> result in a role mismatch. >>>> >>>> "Prepared" means that the peer might change its role even though it >>>>does >>>> not fulfil the 5245bis criteria for being allowed to do so. >>> Yes, but prepared is not actionable. I guess what you mean is that an >>> implementation MUST accept and perform re-determination of the role >>> initiated by the peer agent, even if the criteria are not fulfilled. >> What about: >> >> OLD: >> >> An agent MUST be prepared that the peer might re-determine the roles >> as part of any ICE restart, even if the criteria for doing so are >>not >> fulfilled. This can happen if the peer is compliant with an older >> version of this specification. >> >> >> NEW: >> >> An agent MUST accept if the peer initiates a re-determination of the >>roles >> even if the criteria for doing so are not fulfilled. This can happen if >>the >> peer is compliant with RFC 5245. > >Yes, I think that is much clearer and indicates what might occur, and >what to do in the case and why. I will modify the text as above. --- >>>>>D. Section 6.1.4.2: >>>>> >>>>> I don't know if I misunderstand the algorithm here in the bullet >>>>>list. >>>>> To >>>>> me it >>>>> appears that it will terminate prior to have initiated all possible >>>>> tests, as >>>>> it appears that it will not unfreeze some of the candidate pairs. If >>>>> one >>>>> have >>>>> tests running for a foundation, but all other candidate checks have >>>>> been >>>>> started, then the steps are aborted. Is the bullet list rechecked >>>>>every >>>>> Ta? >>>> No. Whenever Ta fires, one check list in Running state is checked. >>>>When >>>> all check lists have been checked, it will start over from the top of >>>> the >>>> list. >>>> >>>> Or, did I misunderstand your issue? >>> No, It was unclear that this is re-run every time Ta fires. I think the >>> reason for this is this sentence in step 4. >>> >>> If this happens for every single check list in the >>> Running state, meaning there are no remaining candidate pairs >>>to >>> perform connectivity checks for, abort these steps. >>> >>> It was unclear to me that this doesn't mean aborting the whole >>> procedure. Because if the requirement is fulfilled then there is >>>nothing >>> to do until the next Ta, which will possible unfreeze another candidate >>> pair in step 2. I would recommend that you reformulate this sentence to >>> make it clear that the processing for this Ta is stopped, and >>>processing >>> will be resumed the next time Ta fires. >> Isn=A9=F6t that indicated in the sentence before the list: >> >> "Whenever Ta fires, the ICE agent will perform a check for a candidate >> pair within the picked check list by performing the following steps:=A9= =F7 > >Yes, assuming you correctly interpret those. Which, I clearly didn't >that is why I am requesting additional clarity. But, if you think it is >good enough, I will let the issue drop. I will keep the text as it is for now, but keep it in mind, in case I come up with something. --- >>>>> E. Section 7.2.5.2.2. ICMP Error >>>>> >>>>> An ICE agent MAY support processing of ICMP errors for >>>>>connectivity >>>>> checks. If the agent supports processing of ICMP errors, and >>>>>if a >>>>> Binging request generates an ICMP error, the agent SHOULD set >>>>>the >>>>> state of the candidate pair to Failed. >>>>> >>>>> I am a bit worried by this blanket statement on ICMP errors. I think >>>>>it >>>>> should >>>>> be clarified which ICMP message types that are relevant to consider >>>>>as >>>>> errors? >>>>> I assume Type 3 (Destination Unreachable) but maybe not all responde >>>>> codes as >>>>> Codes 4, 11,12 may be addressable in other ways, and likely Type 11 >>>>> (Time >>>>> exceeded) with response code 0, response code 1 is not a clear >>>>> indication >>>>> of a >>>>> non working path. >>>> This is from RFC 5245. >>>> >>>> I don=A9=F6t think the ICE WG should go through all different codes and >>>> combinations, and determine what should be considered an error, and >>>>what >>>> not. >>>> >>>> If you can provide something (table, guidance etc), we are happy to >>>> include it. Otherwise I=A9=F6d like to keep it as it is, and let >>>> implementations deal with it, as at least I am not aware that this >>>>would >>>> Have caused issues in ICE deployments. >>> I think we there is a point to clarify that this applies to ICMP >>> messages indicating a non-usable path. So maybe it could be rewritten >>>to >>> something like this: >>> >>> An ICE agent MAY support processing of ICMP messaging indicating a >>> non-functioning path for connectivity >>> checks. ICMP messages of type 3 (Destination Unreachable) are >>> indicators of a currently non-functioning path. However, the issue can >>>be >>> temporary as it can depend on routing transients, this for example >>> applies to codes 0, 1 and 5. Other messages that appear to indicate >>> non-functioning path such as Type=3D11 (Time Exceeded) with code=3D0 (Time >>>to >>> Live exceeded in Transit) are not clear indicator as the IP packets >>> potentially can reach the destination with a larger TTL value set at >>> transmission. Therefore, implementation needs to analyse the different >>> ICMP messages types and codes for which it considers the path as >>> non-functioning. If the agent supports processing of ICMP errors, and >>>if a >>> Binging request generates an ICMP error, the agent SHOULD set the >>> state of the candidate pair to Failed. >>> >>> >>> What also is not addressed in this is the risk of denial of service >>> attacks using spoofed ICMP messages to shutdown certain connectivity >>> checks. The security considerations lack any discussion of this issue. >>> If ICMP processing are retained, I think a recommendation about >>> validation is needed to avoid at least off path attackers from doing >>> these attacks easily. Unfortunately ICMP response will only include the >>> IP/UDP header, thus no data from the STUN messages which would allow >>> verification that the ICMP messages matches an actually sent check. >>> >>> It may be simplest to recommend against reacting to ICMP errors from >>> both the perspective that it is a risk for denial of service attack, as >>> well as that it represents a risk terminating connectivity checks for a >>> transient issue. From my perspective I expect this to reduce the number >>> of sent connectivity checks very little >> So, are you saying that an agent should simply ignore ICMP messages? > >Yes, I think that may be the best. There are a bit to many corner cases >and significant attack surface that getting all the details right are >significant work for a relatively small reduction in sent connection >check messages. I am not an expert, but aren=A1=AFt you going to get ICMP unreachable every time you try to contact a host candidate behind a NAT? Are you saying that the agent should ignore it, as the connectivity test will anyway timeout at some point? Also, note that RFC 5398 (STUN) says: "A STUN transaction over UDP is also considered failed if there has been a hard ICMP error [RFC1122].=A1=B1 I am a little worried that people would have to use ICE-specific STUN stacks if they are required to ignore ICMP errors. Couldn=A1=AFt we simply use the existing text, and add a sentence about DoS attacks? OLD: An ICE agent MAY support processing of ICMP errors for connectivity checks. If the agent supports processing of ICMP errors, and if a Binging request generates an ICMP error, the agent SHOULD set the state of the candidate pair to Failed. NEW: An ICE agent MAY support processing of ICMP errors for connectivity checks. If the agent supports processing of ICMP errors, and if a Binging request generates an ICMP error, the agent SHOULD set the state of the candidate pair to Failed. Implementers need to be aware that ICMP errors can be used as a method for denial of service attacks when making a decision on how and if to process ICMP errors. --- >>>>>H. Section 14.3: >>>>> >>>>> Num-Waiting: the number of checks in the check list in the >>>>> Waiting state. >>>>> >>>>> Num-In-Progress: the number of checks in the In-Progress state. >>>>> >>>>> Is "the number of checks" only per single checklist or across all the >>>>> check >>>>> lists? >>>> Per single check list. >>> Section 14.1 says: "Those formulas scale >>> with N, the number of checks to be performed." >>> >>> But, from my perspective, that number N is not on a single checklist, >>> but for the whole ICE session, i.e. all the checklists. Thus, I think >>> there needs a clarification on why this is per checklist, making it >>> clear why these two things match up. >> Actually, I think I was wrong. It is per check list SET, i.e., all check >> lists. > >So, please correct the language to be clear on that it is across the >whole check list set. I will s/check list/check list set. --- >>>>>I. Section 17.2.3: >>>>> >>>>> When VAD is being >>>>> used, keepalives will be sent during silence periods. >>>>> >>>>> I would claim that this is only true for when VAD without any comfort >>>>> noise is >>>>> used. A lot of codecs with VAD operations still generates comfort >>>>>noise >>>>> on a >>>>> frequency of a couple packets a second, way more often then the >>>>>minimal >>>>> for ICE >>>>> keep-alives. >>>> What about: >>>> >>>> "In deployments that are not utilizing Voice Activity Detection (VAD), >>>> without any comfort noise, >>>> the keepalives are never..." >>> That is also not true. As keep-alives is not expected to be needed for: >>> 1. Continous media withouth any VAD etc. >>> 2. Media with VAD, but with comfort noise not allowing intervals to be >>> to long (<=3D1 second). >> What about: >> >> OLD: >> >> In deployments that are not utilizing Voice Activity Detection (VAD), >>the >> keepalives are never >> used and there is no increase in bandwidth usage. When VAD is being >> used, keepalives will be sent during silence periods. This involves >> a single packet every 15-20 seconds, far less than the packet every >> 20-30 ms that is sent when there is voice. Therefore, keepalives >> don't have any real impact on capacity planning. >> >> >> >> NEW: >> >> In deployments with continuous media and without utilizing Voice >>Activity >> Detection (VAD), >> or deployments where VAD is utilized together with short interval (max 1 >> second) comfort noise, >> the keepalives are never used and there is no increase in bandwidth >>usage. >> When VAD is being >> Used without comfort noise, keepalives will be sent during silence >> periods. This involves >> a single packet every 15-20 seconds, far less than the packet every >> 20-30 ms that is sent when >> there is voice. Therefore, keepalives don't have any real impact on >> capacity planning. > >Looks good. I will modify the text as above. =3D=3D=3D=3D=3D=3D=3D Minor/Editorial Issues: ... >>>>> 7. Section 7.3: >>>>> >>>>> If the agent is using Diffserv Codepoint markings [RFC2475] in its >>>>> data packets, it SHOULD apply the same markings to Binding >>>>> responses. >>>>> >>>>> I find this sentence a bit unclear. Is it intended to say: >>>>> >>>>> If the agent receiving the binding request, intended to use DSCP >>>>> markings >>>>> !=3D0 >>>>> for the data, it SHOULD set, the same marking to binding responses. >>>>> >>>>> or >>>>> >>>>> If the agent receives a binding request with DSCP markings, then it >>>>> should >>>>> apply to corresponding code point when forming the binding response? >>>> It means that it will use the same markings in Binding responses that >>>>it >>>> uses in data packets (audio, video, etc). >>> Okay, I wonder if it is the temporal aspect of the sentence that makes >>> it harder for me to parse correctly. >>>>> There are unclarity of which agent is referenced and whom "it" is in >>>>>the >>>>> sentence. >>> It is the STUN server. >>> >>> Would the following be more clear? >>> >>> "If the agent is using Diffserv Codepoint markings [RFC2475] in data >>> packets that it sends, the agent SHOULD apply the same markings to >>>Binding >>> responses." >>> >>> Yes, except that I stumbles "it sends" where it is more likely "it will >>> send" is the correct form. >> "If the agent is using Diffserv Codepoint markings [RFC2475] in data >> packets that it will send, the agent SHOULD apply the same markings to >> Binding >> Responses that it will send." > >Yes. works for me. I will modify the text as above. --- >>>>> 8. Section 8.3.1: >>>>> >>>>> The procedures in Section 8 require that an ICE agent continue to >>>>> listen for STUN requests and continue to generate triggered >>>>>checks >>>>> for a data stream, even once processing for that stream >>>>>completes. >>>>> >>>>> That reference to Section 8, should that in fact be to Section 8.1 >>>>> specifically? It looks strange with a self reference, which in some >>>>> aspect a >>>>> reference to section 8 means. >>> I think this issue was missed. >> Sorry for that. >> >> The text can be removed, because it refers to text further down in the >> same subsection (first sentence of second paragraph). > >Yes, removing that sentence works for me. Will be removed. --- >>>>>9. Section 15: >>>>> >>>>> 4.57566E+18 (note that >>>>> an implementation would represent this as a 64-bit integer so as >>>>>not >>>>> to lose precision). >>>>> >>>>> Why the floating point representation? Priorities are integer numbers >>>>> and >>>>> thus >>>>> should be presented as such in this example. >>>> This is from RFC 5245, and unfortunately I don=A9=F6t know. >>> Can you not just calculate the 64-bit integer and write it out? >> So, you want me to write 4575660000000000000? > >No, I thought the pair priority will not be 0 for the lower 32 bits and >that there actually are overflow in this deduction. My understanding is >that what should be written here is the calculation of: > >pair priority =3D 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) > >Where G and D are the priority values for $L_PRIV_1 and $R_PUB_1. > >$L_PRIV_1 is L's host candidate, and stated to have a priorty of >2130706431 > >$R_PUB_1 is R's host candidate and stated to have a priorty of 2130706431 > >So G =3D 2130706431 and D=3D2130706431 > >pair priority then becomes 2^32*2130706431 + 2*2130706431 + 0 =3D >9151314442783293438 > >Thus, I think the next two pair priorities in the example also needs to >be fixed. > >The first pair priority for R is the same value as for L, as G and D are >identical. But the next value will >be different. To my understanding L will be controlling, i.e. L's >candidate will be G > >G=3D1694498815 >D=3D 2130706431 > >Pair priority =3D 2^32*1694498815+2*2130706431 + 0 =3D 7277816997797167102 Please provide text for the section (or, at least the modified paragraphs) :) Regards, Christer --B_3600422631_47606816 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOQYJKoZIhvcNAQcCoIIUKjCCFCYCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIMMIIGBjCCA+6gAwIBAgIQN4YipkcuAr1/ZKbsw+1eMTANBgkqhkiG9w0BAQsFADBH MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTAzMDgwODMyWhcNMjAxMTAzMDgwODMxWjBvMREw DwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRQ2hyaXN0ZXIgSG9sbWJlcmcxLTArBgkqhkiG 9w0BCQEWHmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTEPMA0GA1UEBRMGTE1GQ0hI MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy0z3dlyw+ybHo7PhlkBY00QOJB5T NOXcMdxiQ0nL5uM1C/0xQ7/T3uuHJRjD8nvqTqnlmfJ2VCZRKD3W8LJAUXGFd8JqwLJmGGZt cS3Jp+2WBAxBR6TjtcMwDGQNYD85YCKIuqcsarOxVhzXhwISp750JC1UmR4xxX1gbSkVb8S8 DsPsBioQ/Enkiad/rP0huQFb56Ocxu2Fy2aEW06ezyxU9My4Jh/vMDh+0DBb8EfN8ovAFmMH Qj3SxVUDwnTYbPdA1v3RipF/HH0NBsNOUS8RFct6OxHG1JDbMrkY9ErEKkrHmu3JyNM1hxmy 8rJl/yDID2n6vyxkh5QFcsvOdwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0 cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCB ggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEu Y29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNz c29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEeY2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEW LGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUESOe8HpdLQz1aZdNgbOPnJlysTIw HwYDVR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqG SIb3DQEBCwUAA4ICAQBdN30YKQsw+ow1tjR6gBDuNpQagWRw7DSkYXg4ZE5k76jyXPOTa9VE 8x3MbNIbsyuVLYiVIN/lePTPi4qyt1CNBGPn4roUOuGeGQ7/dABYWNGmT0nKjjeXmqs9bt5z CrxPfVS4xeEU7D64OJtD47f069jsG5E6qENdPmrjaKmTrllfM1S9HvWeco8PwBQC5ixpiXUq t3Dyq3K0GmCgs1P7dJqup+Dt6UNF+DwgSZZeBjo3l+BtAv7StrvWdUQCqJpjUttIwzmtqsx2 NUWa1oSoqvUJ6XnJUZdT/UF390/6Uo4rnTeOWao9dkKQCaE3KvtCHBNZRv1MW0Ot3KSKnE+4 iZeUZgg1KAVQ5dhjjtXmjYoZMYoN4lE4OB2ae8LRbOrj0PE7Wvbuhs5eOyei7e6lYDHPzpLn cfcLpQmOoHal11JqympoeJQENtQl2i1p2j5KmsfUQiqD1HQaGcpH9OKXEclLCOpQ/6zafNW3 nSYFBwADNpHMNiQXxcXKxiPCfiZa2UK5RRWohIz9kY8HXvX/1E2pvtOZoymiXJviR3g2BFvM 21+LIVu3dtoEWWxtD7MyDtOe1dEZTfxLUPMpQa66znWbEQ736mmv5n/z+Aaq7OidNuOIFfO2 HbE+LBHIWhKAy9Ttqa+RqpPONMkvz3kth+G4IOBaTYEPWWHLrqXe2zCCBsIwggSqoAMCAQIC EFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25l cmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4IC DwAwggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs 0zfSTm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9 ZVbXILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvS xlfpVdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eN o4v2PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWq g5t2H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4 TlG4rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1 MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYv SBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaG K5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoG CCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25l cmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVy YS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNV HSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRv cnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8v Y3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMS MA0GCSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gV LtDUJQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyo EBHGvw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50Zk BqYnnl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEO rPwfixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1Ur RIQ85AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKX e4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNO xdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaH KWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyE G/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDCCBTgwggMg oAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEy MDA1MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMM FlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQDCvusn8CGj82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1 gouuSLasANxldewqTV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/te uuSPl2e+S46NZAdXOFVpNDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv41 4e1Qe6kwjRnTCY5oZ12/PJcYU7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1s OTlzgBbIUrAjzeA+3N08R6C7NYrimGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1v gPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdf Y2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCDLrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2 WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt6 0H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKSL2LUP2lDfA3W/Fh1AYidWBZL3rqQ /0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8wPTAPBgNVHRMBAf8EBTADAQH/ MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN AQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA389ZoG5XcUkeudQXuZ KoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyywqODAQDc19oRc XOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr7cQZ5qtM ETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65XI0G SK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI 6wzWJoi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2H dqkXlrfPDZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/ xFZT+mNl0PMcDhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjU kL8Ws9nprFlhVMgcusrByuG5IEyPOpOJpaDMv9P2daR1lm1WMYIB8TCCAe0CAQEwWzBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMCEDeGIqZHLgK9f2Sm7MPtXjEwDQYJYIZIAWUDBAIBBQCgaTAvBgkq hkiG9w0BCQQxIgQgaruBvoK9s5XwuVL1SJ2V662M9EJJae9e19499J671BswGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwMjAyMTEyMzUxWjANBgkqhkiG 9w0BAQEFAASCAQB2TUOchSLI+6tTb+XoGaHA9zvYvtxPCCbCAz17NBt0vL1Ni2Y5BczMfBwD orXrNVBdBtHD2XcUlxe93qX+LXqCymwMUoR7+h2p8efH3cd5AEjhXtHIbazVb7chEdorxEN2 qpdd92bvowtsu4ePoVfPg12eFdOQTEeXgj1cZCT/ikEYn6AfUSB68bgKrUywASojfmDh3cyW LVDlbjrVllTrNMrpke96vkVOIgVlIthAW7fFtLo6ZHyzCnxWgo7wHrsF/vLJt4mt1VhWVXMC Phmq1HaSZ9hSSiez5UsjZTLOd1BBRM33kdgerzbfe9KkKfgIqqZG1g1cXIzq5Ofs1M/F --B_3600422631_47606816-- From nobody Fri Feb 2 06:28:58 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B7F12D881 for ; Fri, 2 Feb 2018 06:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJsc24tctzMT for ; Fri, 2 Feb 2018 06:28:54 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 8D33B12D863 for ; Fri, 2 Feb 2018 06:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517581731; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Q7aN33QTne7XFPZ03i4EP5Y2CyrPvPw6GpIrhLuuH4M=; b=Y0SlgxjOff+zzFrxPbdL2OZPO4KnwrkWxANx42nZ7hGxIVnDD3b6frOhlbA6ZePk 71hPbhTF6iFsQKkDZ4c8fRSSN3NAL3hr9VV2DjZn7ly0tzxTn9g2qK1k9iebOO1k MMxmLpjUfqAhiZCHUJJa7cbUXiqJQGwVbA+P0oz+8p0=; X-AuditID: c1b4fb3a-335ff700000037f2-76-5a7475a39364 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CC.80.14322.3A5747A5; Fri, 2 Feb 2018 15:28:51 +0100 (CET) Received: from [147.214.160.85] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.75) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 2 Feb 2018 15:28:51 +0100 To: Christer Holmberg , "tsv-art@ietf.org" CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" References: <151731848710.27439.7061415423323921488@ietfa.amsl.com> <1d6ab623-0076-2e75-0e99-6a24e55ee934@ericsson.com> From: Magnus Westerlund Message-ID: Date: Fri, 2 Feb 2018 15:28:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070900000300020107030609" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7t+7i0pIog+Z3ZhbHf/xht/h2odbi 2cb5LBaz9ixicWDxWLLkJ1MAYxSXTUpqTmZZapG+XQJXxrlTDawFp1sZK66+38rYwLinqIuR k0NCwETi+NpLbF2MXBxCAocZJfYd/MsE4WxilLg87SsjSJWwgItE1/nf7CC2iEC8xIHnH5lB ipgFZjJKvP75khGi4yiTxISr75lAqtgELCRu/mhkA7F5Bewlpp96BjaJRUBF4ltDC1hcVCBG YkHzIWaIGkGJkzOfsIDYnAI2ElPezgGbwyzQzSjxs8sKxBYS0JZoaOpghbhbSeL6vOssExgF ZiFpn4WkBcI2k+ja2sUIYWtLLFv4mhnCFpdo+rKSFcK2lpjx6yAbhK0oMaX7ITuEbSrx+uhH qF4jiXd7GtkXMHKuYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMm4NbflvtYDz43PEQowAH oxIP77KSkigh1sSy4srcQ4wqQHMebVh9gVGKJS8/L1VJhHebL1CaNyWxsiq1KD++qDQntfgQ ozQHi5I4r1OaRZSQQHpiSWp2ampBahFMlomDU6qBMVtx92NFkXsPLzRfMXllma16ll/88lPd 2H9ftlvZHz5wxLpli7abnNW65NfvNxjxfrPyCFHzu9W5R37ekmyV6ZVm3xz3TjkYffjE25+r Lr6ev0VQZu0yTiHbnlSbs/4SffsYos8XfNvU8ovtyb1N395OC9t9xoLzp+8hsebTJc/bd2oJ lLYsWK7EUpyRaKjFXFScCACTi1PpowIAAA== Archived-At: Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 14:28:57 -0000 --------------ms070900000300020107030609 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Hi, See responses inline Den 2018-02-02 kl. 12:12, skrev Christer Holmberg: > > --- > > >>>>>> E. Section 7.2.5.2.2. ICMP Error >>>>>> >>>>>> An ICE agent MAY support processing of ICMP errors for >>>>>> connectivity >>>>>> checks. If the agent supports processing of ICMP errors, an= d >>>>>> if a >>>>>> Binging request generates an ICMP error, the agent SHOULD se= t >>>>>> the >>>>>> state of the candidate pair to Failed. >>>>>> >>>>>> I am a bit worried by this blanket statement on ICMP errors. I thi= nk >>>>>> it >>>>>> should >>>>>> be clarified which ICMP message types that are relevant to conside= r >>>>>> as >>>>>> errors? >>>>>> I assume Type 3 (Destination Unreachable) but maybe not all respon= de >>>>>> codes as >>>>>> Codes 4, 11,12 may be addressable in other ways, and likely Type 1= 1 >>>>>> (Time >>>>>> exceeded) with response code 0, response code 1 is not a clear >>>>>> indication >>>>>> of a >>>>>> non working path. >>>>> This is from RFC 5245. >>>>> >>>>> I don=C2=B9t think the ICE WG should go through all different codes= and >>>>> combinations, and determine what should be considered an error, and= >>>>> what >>>>> not. >>>>> >>>>> If you can provide something (table, guidance etc), we are happy to= >>>>> include it. Otherwise I=C2=B9d like to keep it as it is, and let >>>>> implementations deal with it, as at least I am not aware that this >>>>> would >>>>> Have caused issues in ICE deployments. >>>> I think we there is a point to clarify that this applies to ICMP >>>> messages indicating a non-usable path. So maybe it could be rewritte= n >>>> to >>>> something like this: >>>> >>>> An ICE agent MAY support processing of ICMP messaging indicatin= g a >>>> non-functioning path for connectivity >>>> checks. ICMP messages of type 3 (Destination Unreachable) are >>>> indicators of a currently non-functioning path. However, the issue c= an >>>> be >>>> temporary as it can depend on routing transients, this for example >>>> applies to codes 0, 1 and 5. Other messages that appear to indicate >>>> non-functioning path such as Type=3D11 (Time Exceeded) with code=3D0= (Time >>>> to >>>> Live exceeded in Transit) are not clear indicator as the IP packets >>>> potentially can reach the destination with a larger TTL value set at= >>>> transmission. Therefore, implementation needs to analyse the differe= nt >>>> ICMP messages types and codes for which it considers the path as >>>> non-functioning. If the agent supports processing of ICMP errors, an= d >>>> if a >>>> Binging request generates an ICMP error, the agent SHOULD set t= he >>>> state of the candidate pair to Failed. >>>> >>>> >>>> What also is not addressed in this is the risk of denial of service >>>> attacks using spoofed ICMP messages to shutdown certain connectivity= >>>> checks. The security considerations lack any discussion of this issu= e. >>>> If ICMP processing are retained, I think a recommendation about >>>> validation is needed to avoid at least off path attackers from doing= >>>> these attacks easily. Unfortunately ICMP response will only include = the >>>> IP/UDP header, thus no data from the STUN messages which would allow= >>>> verification that the ICMP messages matches an actually sent check. >>>> >>>> It may be simplest to recommend against reacting to ICMP errors from= >>>> both the perspective that it is a risk for denial of service attack,= as >>>> well as that it represents a risk terminating connectivity checks fo= r a >>>> transient issue. From my perspective I expect this to reduce the num= ber >>>> of sent connectivity checks very little >>> So, are you saying that an agent should simply ignore ICMP messages? >> Yes, I think that may be the best. There are a bit to many corner case= s >> and significant attack surface that getting all the details right are >> significant work for a relatively small reduction in sent connection >> check messages. > I am not an expert, but aren=E2=80=99t you going to get ICMP unreachabl= e every > time you try to contact a host candidate behind a NAT? Are you saying t= hat > the agent should ignore it, as the connectivity test will anyway timeou= t > at some point? To my understanding NATs and firewalls do not send ICMP unreachable=20 because that would violates its role as a gateway rather than end-host,=20 also it want to avoid giving away information about its internal side,=20 and is a risk in creating a lot of load on the middlebox. > > Also, note that RFC 5398 (STUN) says: > > "A STUN transaction over UDP is also considered failed if there has = been > a > hard ICMP error [RFC1122].=E2=80=9D > > I am a little worried that people would have to use ICE-specific STUN > stacks if they are required to ignore ICMP errors. > > Couldn=E2=80=99t we simply use the existing text, and add a sentence ab= out DoS > attacks? > > > > OLD: > > An ICE agent MAY support processing of ICMP errors for connectivity > checks. If the agent supports processing of ICMP errors, and if a > Binging request generates an ICMP error, the agent SHOULD set the > state of the candidate pair to Failed. > > > > NEW: > > An ICE agent MAY support processing of ICMP errors for connectivity > checks. If the agent supports processing of ICMP errors, and if a > Binging request generates an ICMP error, the agent SHOULD set the > state of the candidate pair to Failed. Implementers need to be aware > that ICMP errors can be used as a method for denial of service attacks > when making a decision on how and if to process ICMP errors. I think you need to at least make it clear that it is "hard ICMP=20 errors". Which RFC 1122 defined as Type 3 with codes 2-4 for TCP. So, in = that case one could just as well be explicit. I don't know if any of the = later defined codes are defined as hard errors. When it comes to the security consideration, I am actually quite worried = by this. To spoof ICMP so that they arrive back at the client, you need=20 to be able to send an ICMP packet back that matches the NAT's binding.=20 That requires that you now the connectivity checks intended target=20 address+port, and the NAT's source address+port. With that information=20 you can generate an ICMP message that will arrive at the agent as long=20 as the attacker can route a packet to the NATs address. And if you are=20 in the local address domain to the agent, you can fake an ICMP error=20 with only the information matching the peer agents candidate. I think this issue do need security considerations text. > =3D=3D=3D=3D=3D=3D=3D > > Minor/Editorial Issues: > > =20 > > --- > >>>>>> 9. Section 15: >>>>>> >>>>>> 4.57566E+18 (note that >>>>>> an implementation would represent this as a 64-bit integer so= as >>>>>> not >>>>>> to lose precision). >>>>>> >>>>>> Why the floating point representation? Priorities are integer numb= ers >>>>>> and >>>>>> thus >>>>>> should be presented as such in this example. >>>>> This is from RFC 5245, and unfortunately I don=C2=B9t know. >>>> Can you not just calculate the 64-bit integer and write it out? >>> So, you want me to write 4575660000000000000? >> No, I thought the pair priority will not be 0 for the lower 32 bits an= d >> that there actually are overflow in this deduction. My understanding i= s >> that what should be written here is the calculation of: >> >> pair priority =3D 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) >> >> Where G and D are the priority values for $L_PRIV_1 and $R_PUB_1. >> >> $L_PRIV_1 is L's host candidate, and stated to have a priorty of >> 2130706431 >> >> $R_PUB_1 is R's host candidate and stated to have a priorty of 2130706= 431 >> >> So G =3D 2130706431 and D=3D2130706431 >> >> pair priority then becomes 2^32*2130706431 + 2*2130706431 + 0 =3D >> 9151314442783293438 >> >> Thus, I think the next two pair priorities in the example also needs t= o >> be fixed. >> >> The first pair priority for R is the same value as for L, as G and D a= re >> identical. But the next value will >> be different. To my understanding L will be controlling, i.e. L's >> candidate will be G >> >> G=3D1694498815 >> D=3D 2130706431 >> >> Pair priority =3D 2^32*1694498815+2*2130706431 + 0 =3D 727781699779716= 7102 > Please provide text for the section (or, at least the modified paragrap= hs) > :) Fine, I can put in the numbers in the right place. But please check my=20 calculations: OLD: =C2=A0=C2=A0 Agents L and R both pair up the candidates.=C2=A0 They both= initially have =C2=A0=C2=A0 two pairs.=C2=A0 However, agent L will prune the pair conta= ining its =C2=A0=C2=A0 server reflexive candidate, resulting in just one.=C2=A0 At= agent L, this =C2=A0=C2=A0 pair has a local candidate of $L_PRIV_1 and remote candidat= e of =C2=A0=C2=A0 $R_PUB_1, and has a candidate pair priority of 4.57566E+18 = (note that =C2=A0=C2=A0 an implementation would represent this as a 64-bit integer = so as not =C2=A0=C2=A0 to lose precision).=C2=A0 At agent R, there are two pairs.=C2= =A0 The highest =C2=A0=C2=A0 priority has a local candidate of $R_PUB_1 and remote candi= date of =C2=A0=C2=A0 $L_PRIV_1 and has a priority of 4.57566E+18, and the second= has a =C2=A0=C2=A0 local candidate of $R_PUB_1 and remote candidate of $NAT_PU= B_1 and =C2=A0=C2=A0 priority 3.63891E+18. NEW: =C2=A0=C2=A0 Agents L and R both pair up the candidates.=C2=A0 They both= initially have =C2=A0=C2=A0 two pairs.=C2=A0 However, agent L will prune the pair conta= ining its =C2=A0=C2=A0 server reflexive candidate, resulting in just one.=C2=A0 At= agent L, this =C2=A0=C2=A0 pair has a local candidate of $L_PRIV_1 and remote candidat= e of =C2=A0=C2=A0 $R_PUB_1, and has a candidate pair priority of 915131444278= 3293438. =C2=A0=C2=A0 At agent R, there are two pairs.=C2=A0 The highest =C2=A0=C2=A0 priority has a local candidate of $R_PUB_1 and remote candi= date of =C2=A0=C2=A0 $L_PRIV_1 and has a priority of 9151314442783293438, and th= e second=20 has a =C2=A0=C2=A0 local candidate of $R_PUB_1 and remote candidate of $NAT_PU= B_1 and =C2=A0=C2=A0 priority 7277816997797167102. Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------ms070900000300020107030609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME-kryptografisk signatur MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DNEwggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNV BAoMCEVyaWNzc29uMRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJ ARYebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+ laqg5eXTqonqnzT9ykEGL2dx9mBT+2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJ HGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iV IiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpigGFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36o gzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkrbdmdnjKGrYSnJigmxw14pJugxL/Vb2Ee VcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDov L2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCBggYI KwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29t MEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29u bmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJp Y3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0 dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQG CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3 DQEBCwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4Q ihhoQR3cvhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXD yF9mhWYbSAkJyx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6 H3zO3nsq++KBmsOiSKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvE lup5n7l864FqxnC2friDo4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl 60rmc8SJlt6QXKw0wXEOE1MubauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwD ig3SZi1qP7D/Ds4V+JLIjjUJc25l9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8K v7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLCQaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3 UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Zla71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzY VBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd//n4YbY2QhDCCBsIwggSqoAMCAQICEFO4 foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUx MDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw ggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfS Tm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbX ILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfp VdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2 PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2 H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4 rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX 1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjv Zibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FN VSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoGCCsG AQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEu Y29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j b20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAE TjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnku dHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3Js LTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7 GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDU JQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHG vw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYn nl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwf ixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ8 5AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4Hd Dc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOE EHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd 3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/du jp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDGCAzswggM3AgEB MFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMA0GCWCGSAFlAwQCAQUA oIIBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAyMDIx NDI4NTBaMC8GCSqGSIb3DQEJBDEiBCBRsGRdiLfMmFWENTgPnVY/lOl0h+FMfzC1NF8/n+B+ LjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBlrrZreXF5 7TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMGwGCyqGSIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nz b24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62 a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAHCUnQX+jcbYVZWHeHVE58dW1dtcnM3cEu8pncVez sfyH3QmytRLyQRZIxlnelLLpYBT7j5Slm5D5q0Dq68l1rfxgYT089CAUAUwfZHGOj5zTV5i2 efayWS3Xv+PEdUuovHF+uPQ8bI42w/A7aNgriKcEXuA0MuSEck6EaGOq9tkq9o92H9w1uMv2 trlpc4Yw/aCTKDRxMHOE9Cz+mOL/BPpJqUxP6vLjNcpfJWMqmj09Cqzo2fiFil9GQ+EypSwJ F+q2iceroTHYP0RJHxxIRbEKNykk71Hx+U0rnfuYmcAzvF5c7iZiolhbZezGFaLs0+404Q+p bnU5bfrzJZQhiQAAAAAAAA== --------------ms070900000300020107030609-- From nobody Fri Feb 2 08:05:17 2018 Return-Path: X-Original-To: ice@ietfa.amsl.com Delivered-To: ice@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54B412DA09 for ; Fri, 2 Feb 2018 08:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dVfzFDXt-bVz for ; Fri, 2 Feb 2018 08:04:56 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 7AF6E12DA4C for ; Fri, 2 Feb 2018 08:04:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517587475; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ddCq9tZkZBtkV3Me7aSAmcGOj/OnwwuTSl26MI8xPSE=; b=Ba0RCu8KXxru5Z6zweyNBKpNIHAouARw5LzjUijRZSdcDb1RMKbnF2xotHfMGHoi RCPRRo+6Pm64+TCkJWfYE0oetdAAQhl/zj0W4TaK4YZ6dULt8rhYmlH5wcMC1b8e HdzvZsjGgYdg1KYu5n1w8G94ooleN/k0AZl/78M1tP0=; X-AuditID: c1b4fb30-3b1ff70000004778-47-5a748c127480 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C8.4A.18296.21C847A5; Fri, 2 Feb 2018 17:04:35 +0100 (CET) Received: from [147.214.160.85] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 2 Feb 2018 17:04:33 +0100 From: Magnus Westerlund To: Christer Holmberg , "tsv-art@ietf.org" CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" References: <151731848710.27439.7061415423323921488@ietfa.amsl.com> <1d6ab623-0076-2e75-0e99-6a24e55ee934@ericsson.com> Message-ID: Date: Fri, 2 Feb 2018 17:04:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030203090104080801090301" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2K7qK5wT0mUQe8UYYvjP/6wW3y7UGvx bON8FotZexaxOLB4LFnykymAMYrLJiU1J7MstUjfLoErY9LSH4wFvbeYKk4d3cfewNj+g7GL kZNDQsBE4sG5/cxdjFwcQgKHGSW6WlZBOZsYJeZebgFyODiEBbwk+jcagzSwCVhI3PzRyAZi iwjESxx4/hGsnllgJqPE658vGSGafzNJ3F7cwwJSxStgLzFp9lmwdSwCKhI3t50Bi4sKxEgs aD7EDFEjKHFy5hOwOKeAg0THm8OMEFO7GSW+n/oKlhAS0JZoaOpghbhbSeL6vOssExgFZiHp n4WsZxbQ5cwCYRJHX0mB1DALiEs0fVnJCmGbSczb/JAZwtaWWLbwNTNEuZrEslYlVGEQ21pi xq+DbBC2osSU7ofsELapxOujHxkhbCOJd3sa2Rcw8qxiFC1OLU7KTTcy0kstykwuLs7P08tL LdnECIy/g1t+G+xgfPnc8RCjAAejEg/vtJKSKCHWxLLiytxDjCpAcx5tWH2BUYolLz8vVUmE d5svUJo3JbGyKrUoP76oNCe1+BCjNAeLkjjvSU/eKCGB9MSS1OzU1ILUIpgsEwenVANjVM3J CYETuZbezTxxjlHxV5gZW9fXhVaKJszBv/sExd0t3p1Qzuu6zeoe69Pc/8e79eF9m4xVzYXb Xq5e/rgzOlsq8VZI3enr9RbSq7n2hhuv77EvWrDQtJ1B5Bn7hL8OX8/Mf/OvuKrqepvgzf0x Xro13zbZ1oQsYkhp3JO+KiAufoa6fJsSS3FGoqEWc1FxIgDBhItUxwIAAA== Archived-At: Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-rfc5245bis-16 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 16:05:12 -0000 --------------ms030203090104080801090301 Content-Type: multipart/alternative; boundary="------------82A28E284C156C52D96DBADC" Content-Language: en-GB This is a multi-part message in MIME format. --------------82A28E284C156C52D96DBADC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, On Christer's request I have written a text proposal for a security=20 consideration addition regarding the ICMP message. From my perspective,=20 WG input is needed into this issue! New paragraph: =C2=A0=C2=A0 Spoofed ICMP Hard Errors (Type 3, codes 2-4) can also be us= ed to =C2=A0=C2=A0 create false invalid results. If an ICE agent implements a = response =C2=A0=C2=A0 to these ICMP errors, and the attacker is capable of genera= ting an =C2=A0=C2=A0 ICMP message that is delivered to the agent sending the con= nectivity =C2=A0=C2=A0 check. The validation of the ICMP error message by the agen= t is its =C2=A0=C2=A0 only defence. For Type 3 code=3D4 the outer IP header provi= des no =C2=A0=C2=A0 validation, unless the connectivity check was sent with DF=3D= 0. =C2=A0=C2=A0 For code 2 or 3, which are originated by the host, the =C2=A0=C2=A0 address is expected to be any of the remote agents host, re= flexive,=20 or relay =C2=A0=C2=A0 candidates IP addresses. The ICMP message include the IP he= ader and UDP =C2=A0=C2=A0 header of the message triggering the error. These fields al= so needs to =C2=A0=C2=A0 be validated. The IP destination and UDP destination port n= eeds to=20 match =C2=A0=C2=A0 either the targeted candidate address and port, or the cand= idates base =C2=A0=C2=A0 address. The source IP address and port can be any candidat= e for the=20 same =C2=A0=C2=A0 base address of the agent sending the connectivity check. T= hus any=20 attacker =C2=A0=C2=A0 having access to the exchange of the candidates will have t= he necessary =C2=A0=C2=A0 information. Thus the validation is a weak defence, and the= sending of =C2=A0=C2=A0 spoofed ICMP attacks is possible also for off-path attacker= s from a=20 node =C2=A0=C2=A0 in a network without source address validation. Intended to be added in Section 19.1=C2=A0 between two existing paragraph= s as=20 indicated below. =2E. exchange signaling is secured, the attacker will not have the =C2=A0=C2=A0 password and its response will be discarded. [The new paragraph] Forcing the fake valid result works in a similar way.=C2=A0 The agent ...= I hope this helps making it clear how relatively easy this attack can be = performed, and why I think it is actually safer to ignore any ICMP=20 errors for the connectivity checks. Den 2018-02-02 kl. 15:28, skrev Magnus Westerlund: > Hi, > > See responses inline > > > Den 2018-02-02 kl. 12:12, skrev Christer Holmberg: >> >> --- >> >> >>>>>>> E. Section 7.2.5.2.2.=C2=A0 ICMP Error >>>>>>> >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 An ICE agent MAY support processin= g of ICMP errors for >>>>>>> connectivity >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 checks.=C2=A0 If the agent support= s processing of ICMP errors, and >>>>>>> if a >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Binging request generates an ICMP = error, the agent SHOULD set >>>>>>> the >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 state of the candidate pair to Fai= led. >>>>>>> >>>>>>> I am a bit worried by this blanket statement on ICMP errors. I=20 >>>>>>> think >>>>>>> it >>>>>>> should >>>>>>> be clarified which ICMP message types that are relevant to consid= er >>>>>>> as >>>>>>> errors? >>>>>>> I assume Type 3 (Destination Unreachable) but maybe not all=20 >>>>>>> responde >>>>>>> codes as >>>>>>> Codes 4, 11,12 may be addressable in other ways, and likely Type = 11 >>>>>>> (Time >>>>>>> exceeded) with response code 0, response code 1 is not a clear >>>>>>> indication >>>>>>> of a >>>>>>> non working path. >>>>>> This is from RFC 5245. >>>>>> >>>>>> I don=C2=B9t think the ICE WG should go through all different code= s and >>>>>> combinations, and determine what should be considered an error, an= d >>>>>> what >>>>>> not. >>>>>> >>>>>> If you can provide something (table, guidance etc), we are happy t= o >>>>>> include it. Otherwise I=C2=B9d like to keep it as it is, and let >>>>>> implementations deal with it, as at least I am not aware that this= >>>>>> would >>>>>> Have caused issues in ICE deployments. >>>>> I think we there is a point to clarify that this applies to ICMP >>>>> messages indicating a non-usable path. So maybe it could be rewritt= en >>>>> to >>>>> something like this: >>>>> >>>>> =C2=A0=C2=A0=C2=A0=C2=A0 An ICE agent MAY support processing of ICM= P messaging=20 >>>>> indicating a >>>>> non-functioning path for connectivity >>>>> =C2=A0=C2=A0=C2=A0=C2=A0 checks. ICMP messages of type 3 (Destinati= on Unreachable) are >>>>> indicators of a currently non-functioning path. However, the issue = >>>>> can >>>>> be >>>>> temporary as it can depend on routing transients, this for example >>>>> applies to codes 0, 1 and 5. Other messages that appear to indicate= >>>>> non-functioning path such as Type=3D11 (Time Exceeded) with code=3D= 0=20 >>>>> (Time >>>>> to >>>>> Live exceeded in Transit) are not clear indicator as the IP packets= >>>>> potentially can reach the destination with a larger TTL value set a= t >>>>> transmission. Therefore, implementation needs to analyse the=20 >>>>> different >>>>> ICMP messages types and codes for which it considers the path as >>>>> non-functioning. If the agent supports processing of ICMP errors, a= nd >>>>> if a >>>>> =C2=A0=C2=A0=C2=A0=C2=A0 Binging request generates an ICMP error, t= he agent SHOULD set=20 >>>>> the >>>>> =C2=A0=C2=A0=C2=A0=C2=A0 state of the candidate pair to Failed. >>>>> >>>>> >>>>> What also is not addressed in this is the risk of denial of service= >>>>> attacks using spoofed ICMP messages to shutdown certain connectivit= y >>>>> checks. The security considerations lack any discussion of this=20 >>>>> issue. >>>>> If ICMP processing are retained, I think a recommendation about >>>>> validation is needed to avoid at least off path attackers from doin= g >>>>> these attacks easily. Unfortunately ICMP response will only=20 >>>>> include the >>>>> IP/UDP header, thus no data from the STUN messages which would allo= w >>>>> verification that the ICMP messages matches an actually sent check.= >>>>> >>>>> It may be simplest to recommend against reacting to ICMP errors fro= m >>>>> both the perspective that it is a risk for denial of service=20 >>>>> attack, as >>>>> well as that it represents a risk terminating connectivity checks=20 >>>>> for a >>>>> transient issue. From my perspective I expect this to reduce the=20 >>>>> number >>>>> of sent connectivity checks very little >>>> So, are you saying that an agent should simply ignore ICMP messages?= >>> Yes, I think that may be the best. There are a bit to many corner cas= es >>> and significant attack surface that getting all the details right are= >>> significant work for a relatively small reduction in sent connection >>> check messages. >> I am not an expert, but aren=E2=80=99t you going to get ICMP unreachab= le every >> time you try to contact a host candidate behind a NAT? Are you saying = >> that >> the agent should ignore it, as the connectivity test will anyway timeo= ut >> at some point? > > To my understanding NATs and firewalls do not send ICMP unreachable=20 > because that would violates its role as a gateway rather than=20 > end-host, also it want to avoid giving away information about its=20 > internal side, and is a risk in creating a lot of load on the middlebox= =2E > >> >> Also, note that RFC 5398 (STUN) says: >> >> =C2=A0=C2=A0 "A STUN transaction over UDP is also considered failed if= there=20 >> has been >> a >> =C2=A0=C2=A0=C2=A0 hard ICMP error [RFC1122].=E2=80=9D >> >> I am a little worried that people would have to use ICE-specific STUN >> stacks if they are required to ignore ICMP errors. >> >> Couldn=E2=80=99t we simply use the existing text, and add a sentence a= bout DoS >> attacks? >> >> >> >> OLD: >> >> =C2=A0 An ICE agent MAY support processing of ICMP errors for connecti= vity >> =C2=A0 checks.=C2=A0 If the agent supports processing of ICMP errors, = and if a >> =C2=A0 Binging request generates an ICMP error, the agent SHOULD set t= he >> =C2=A0 state of the candidate pair to Failed. >> >> >> >> NEW: >> >> =C2=A0 An ICE agent MAY support processing of ICMP errors for connecti= vity >> =C2=A0 checks. If the agent supports processing of ICMP errors, and if= a >> =C2=A0 Binging request generates an ICMP error, the agent SHOULD set t= he >> =C2=A0 state of the candidate pair to Failed. Implementers need to be = aware >> that ICMP errors can be used as a method for denial of service attacks= >> when making a decision on how and if to process ICMP errors. > > I think you need to at least make it clear that it is "hard ICMP=20 > errors". Which RFC 1122 defined as Type 3 with codes 2-4 for TCP. So,=20 > in that case one could just as well be explicit. I don't know if any=20 > of the later defined codes are defined as hard errors. > > When it comes to the security consideration, I am actually quite=20 > worried by this. To spoof ICMP so that they arrive back at the client, = > you need to be able to send an ICMP packet back that matches the NAT's = > binding. That requires that you now the connectivity checks intended=20 > target address+port, and the NAT's source address+port. With that=20 > information you can generate an ICMP message that will arrive at the=20 > agent as long as the attacker can route a packet to the NATs address.=20 > And if you are in the local address domain to the agent, you can fake=20 > an ICMP error with only the information matching the peer agents=20 > candidate. > > I think this issue do need security considerations text. > >> =3D=3D=3D=3D=3D=3D=3D >> >> Minor/Editorial Issues: >> >> >> --- >> >>>>>>> 9. Section 15: >>>>>>> >>>>>>> 4.57566E+18 (note that >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 an implementation would represent this a= s a 64-bit integer=20 >>>>>>> so as >>>>>>> not >>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 to lose precision). >>>>>>> >>>>>>> Why the floating point representation? Priorities are integer=20 >>>>>>> numbers >>>>>>> and >>>>>>> thus >>>>>>> should be presented as such in this example. >>>>>> This is from RFC 5245, and unfortunately I don=C2=B9t know. >>>>> Can you not just calculate the 64-bit integer and write it out? >>>> So, you want me to write 4575660000000000000? >>> No, I thought the pair priority will not be 0 for the lower 32 bits a= nd >>> that there actually are overflow in this deduction. My understanding = is >>> that what should be written here is the calculation of: >>> >>> pair priority =3D 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0) >>> >>> Where G and D are the priority values for $L_PRIV_1 and $R_PUB_1. >>> >>> $L_PRIV_1 is L's host candidate, and stated to have a priorty of >>> 2130706431 >>> >>> $R_PUB_1 is R's host candidate and stated to have a priorty of=20 >>> 2130706431 >>> >>> So G =3D 2130706431 and D=3D2130706431 >>> >>> pair priority then becomes 2^32*2130706431 + 2*2130706431 + 0 =3D >>> 9151314442783293438 >>> >>> Thus, I think the next two pair priorities in the example also needs = to >>> be fixed. >>> >>> The first pair priority for R is the same value as for L, as G and D = >>> are >>> identical. But the next value will >>> be different. To my understanding L will be controlling, i.e. L's >>> candidate will be G >>> >>> G=3D1694498815 >>> D=3D 2130706431 >>> >>> Pair priority =3D 2^32*1694498815+2*2130706431 + 0 =3D 72778169977971= 67102 >> Please provide text for the section (or, at least the modified=20 >> paragraphs) >> :) > > Fine, I can put in the numbers in the right place. But please check my = > calculations: > > OLD: > > =C2=A0=C2=A0 Agents L and R both pair up the candidates.=C2=A0 They bot= h initially have > =C2=A0=C2=A0 two pairs.=C2=A0 However, agent L will prune the pair cont= aining its > =C2=A0=C2=A0 server reflexive candidate, resulting in just one.=C2=A0 A= t agent L, this > =C2=A0=C2=A0 pair has a local candidate of $L_PRIV_1 and remote candida= te of > =C2=A0=C2=A0 $R_PUB_1, and has a candidate pair priority of 4.57566E+18= (note that > =C2=A0=C2=A0 an implementation would represent this as a 64-bit integer= so as not > =C2=A0=C2=A0 to lose precision).=C2=A0 At agent R, there are two pairs.= =C2=A0 The highest > =C2=A0=C2=A0 priority has a local candidate of $R_PUB_1 and remote cand= idate of > =C2=A0=C2=A0 $L_PRIV_1 and has a priority of 4.57566E+18, and the secon= d has a > =C2=A0=C2=A0 local candidate of $R_PUB_1 and remote candidate of $NAT_P= UB_1 and > =C2=A0=C2=A0 priority 3.63891E+18. > > NEW: > > =C2=A0=C2=A0 Agents L and R both pair up the candidates.=C2=A0 They bot= h initially have > =C2=A0=C2=A0 two pairs.=C2=A0 However, agent L will prune the pair cont= aining its > =C2=A0=C2=A0 server reflexive candidate, resulting in just one.=C2=A0 A= t agent L, this > =C2=A0=C2=A0 pair has a local candidate of $L_PRIV_1 and remote candida= te of > =C2=A0=C2=A0 $R_PUB_1, and has a candidate pair priority of 91513144427= 83293438. > =C2=A0=C2=A0 At agent R, there are two pairs.=C2=A0 The highest > =C2=A0=C2=A0 priority has a local candidate of $R_PUB_1 and remote cand= idate of > =C2=A0=C2=A0 $L_PRIV_1 and has a priority of 9151314442783293438, and t= he second=20 > has a > =C2=A0=C2=A0 local candidate of $R_PUB_1 and remote candidate of $NAT_P= UB_1 and > =C2=A0=C2=A0 priority 7277816997797167102. > > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Media Technologies, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB=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=C2=A0=C2=A0=C2=A0 | Phone=C2=A0 +46 10 7148287 > Torshamnsgatan 23=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice --=20 Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------82A28E284C156C52D96DBADC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi,

On Christer's request I have written a text proposal for a security consideration addition regarding the ICMP message. From my perspective, WG input is needed into this issue!

New paragraph:


=C2=A0=C2=A0 Spoofed ICMP Hard Errors (Type 3, codes 2-4) can also = be used to
=C2=A0=C2=A0 create false invalid results. If an ICE agent implemen= ts a response
=C2=A0=C2=A0 to these ICMP errors, and the attacker is capable of g= enerating an
=C2=A0=C2=A0 ICMP message that is delivered to the agent sending th= e connectivity
=C2=A0=C2=A0 check. The validation of the ICMP error message by the= agent is its
=C2=A0=C2=A0 only defence. For Type 3 code=3D4 the outer IP header = provides no
=C2=A0=C2=A0 validation, unless the connectivity check was sent wit= h DF=3D0.
=C2=A0=C2=A0 For code 2 or 3, which are originated by the host, the=
=C2=A0=C2=A0 address is expected to be any of the remote agents hos= t, reflexive, or relay
=C2=A0=C2=A0 candidates IP addresses. The ICMP message include the = IP header and UDP
=C2=A0=C2=A0 header of the message triggering the error. These fiel= ds also needs to
=C2=A0=C2=A0 be validated. The IP destination and UDP destination p= ort needs to match
=C2=A0=C2=A0 either the targeted candidate address and port, or the= candidates base
=C2=A0=C2=A0 address. The source IP address and port can be any can= didate for the same
=C2=A0=C2=A0 base address of the agent sending the connectivity che= ck. Thus any attacker
=C2=A0=C2=A0 having access to the exchange of the candidates will h= ave the necessary
=C2=A0=C2=A0 information. Thus the validation is a weak defence, an= d the sending of
=C2=A0=C2=A0 spoofed ICMP attacks is possible also for off-path att= ackers from a node
=C2=A0=C2=A0 in a network without source address validation.

Intended to be added in Section 19.1=C2=A0 between two existing paragraphs as indicated below.

.. exchange signaling is secured, the attacker will not have the
=C2=A0=C2=A0 password and its response will be discarded.

[The new paragraph]

Forcing the fake valid result works in a similar way.=C2=A0 The age= nt ...


I hope this helps making it clear how relatively easy this attack can be performed, and why I think it is actually safer to ignore any ICMP errors for the connectivity checks.




Den 2018-02-02 kl. 15:28, skrev Magnus= Westerlund:
Hi,

See responses inline


Den 2018-02-02 kl. 12:12, skrev Christer Holmberg:

---


E. Section 7.2.5.2.2.=C2=A0 ICM= P Error

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 An ICE agent MAY support= processing of ICMP errors for
connectivity
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 checks.=C2=A0 If the age= nt supports processing of ICMP errors, and
if a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Binging request generate= s an ICMP error, the agent SHOULD set
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 state of the candidate p= air to Failed.

I am a bit worried by this blanket statement on ICMP errors. I think
it
should
be clarified which ICMP message types that are relevant to consider
as
errors?
I assume Type 3 (Destination Unreachable) but maybe not all responde
codes as
Codes 4, 11,12 may be addressable in other ways, and likely Type 11
(Time
exceeded) with response code 0, response code 1 is not a clear
indication
of a
non working path.
This is from RFC 5245.

I don=C2=B9t think the ICE WG should go through all diffe= rent codes and
combinations, and determine what should be considered an error, and
what
not.

If you can provide something (table, guidance etc), we are happy to
include it. Otherwise I=C2=B9d like to keep it as it is, = and let
implementations deal with it, as at least I am not aware that this
would
Have caused issues in ICE deployments.
I think we there is a point to clarify that this applies to ICMP
messages indicating a non-usable path. So maybe it could be rewritten
to
something like this:

=C2=A0=C2=A0=C2=A0=C2=A0 An ICE agent MAY support processin= g of ICMP messaging indicating a
non-functioning path for connectivity
=C2=A0=C2=A0=C2=A0=C2=A0 checks. ICMP messages of type 3 (D= estination Unreachable) are
indicators of a currently non-functioning path. However, the issue can
be
temporary as it can depend on routing transients, this for example
applies to codes 0, 1 and 5. Other messages that appear to indicate
non-functioning path such as Type=3D11 (Time Exceeded) with= code=3D0 (Time
to
Live exceeded in Transit) are not clear indicator as the IP packets
potentially can reach the destination with a larger TTL value set at
transmission. Therefore, implementation needs to analyse the different
ICMP messages types and codes for which it considers the path as
non-functioning. If the agent supports processing of ICMP errors, and
if a
=C2=A0=C2=A0=C2=A0=C2=A0 Binging request generates an ICMP = error, the agent SHOULD set the
=C2=A0=C2=A0=C2=A0=C2=A0 state of the candidate pair to Fai= led.


What also is not addressed in this is the risk of denial of service
attacks using spoofed ICMP messages to shutdown certain connectivity
checks. The security considerations lack any discussion of this issue.
If ICMP processing are retained, I think a recommendation about
validation is needed to avoid at least off path attackers from doing
these attacks easily. Unfortunately ICMP response will only include the
IP/UDP header, thus no data from the STUN messages which would allow
verification that the ICMP messages matches an actually sent check.

It may be simplest to recommend against reacting to ICMP errors from
both the perspective that it is a risk for denial of service attack, as
well as that it represents a risk terminating connectivity checks for a
transient issue. From my perspective I expect this to reduce the number
of sent connectivity checks very little
So, are you saying that an agent should simply ignore ICMP messages?
Yes, I think that may be the best. There are a bit to many corner cases
and significant attack surface that getting all the details right are
significant work for a relatively small reduction in sent connection
check messages.
I am not an expert, but aren=E2=80=99t you going to get ICMP unre= achable every
time you try to contact a host candidate behind a NAT? Are you saying that
the agent should ignore it, as the connectivity test will anyway timeout
at some point?

To my understanding NATs and firewalls do not send ICMP unreachable because that would violates its role as a gateway rather than end-host, also it want to avoid giving away information about its internal side, and is a risk in creating a lot of load on the middlebox.


Also, note that RFC 5398 (STUN) says:

=C2=A0=C2=A0 "A STUN transaction over UDP is also considered fail= ed if there has been
a
=C2=A0=C2=A0=C2=A0 hard ICMP error [RFC1122].=E2=80=9D

I am a little worried that people would have to use ICE-specific STUN
stacks if they are required to ignore ICMP errors.

Couldn=E2=80=99t we simply use the existing text, and add a sente= nce about DoS
attacks?



OLD:

=C2=A0 An ICE agent MAY support processing of ICMP errors for connectivity
=C2=A0 checks.=C2=A0 If the agent supports processing of ICMP err= ors, and if a
=C2=A0 Binging request generates an ICMP error, the agent SHOULD = set the
=C2=A0 state of the candidate pair to Failed.



NEW:

=C2=A0 An ICE agent MAY support processing of ICMP errors for connectivity
=C2=A0 checks. If the agent supports processing of ICMP errors, a= nd if a
=C2=A0 Binging request generates an ICMP error, the agent SHOULD = set the
=C2=A0 state of the candidate pair to Failed. Implementers need t= o be aware
that ICMP errors can be used as a method for denial of service attacks
when making a decision on how and if to process ICMP errors.

I think you need to at least make it clear that it is "hard ICMP errors". Which RFC 1122 defined as Type 3 with codes 2-4 for TCP. So, in that case one could just as well be explicit. I don't know if any of the later defined codes are defined as hard errors.

When it comes to the security consideration, I am actually quite worried by this. To spoof ICMP so that they arrive back at the client, you need to be able to send an ICMP packet back that matches the NAT's binding. That requires that you now the connectivity checks intended target address+port, and the NAT's source address+port. With that information you can generate an ICMP message that will arrive at the agent as long as the attacker can route a packet to the NATs address. And if you are in the local address domain to the agent, you can fake an ICMP error with only the information matching the peer agents candidate.

I think this issue do need security considerations text.

=3D=3D=3D=3D=3D=3D=3D

Minor/Editorial Issues:

=C2=A0
---

9. Section 15:

4.57566E+18 (note that
=C2=A0=C2=A0=C2=A0=C2=A0 an implementation would repres= ent this as a 64-bit integer so as
not
=C2=A0=C2=A0=C2=A0=C2=A0 to lose precision).

Why the floating point representation? Priorities are integer numbers
and
thus
should be presented as such in this example.
This is from RFC 5245, and unfortunately I don=C2=B9t kno= w.
Can you not just calculate the 64-bit integer and write it out?
So, you want me to write 4575660000000000000?
No, I thought the pair priority will not be 0 for the lower 32 bits and
that there actually are overflow in this deduction. My understanding is
that what should be written here is the calculation of:

pair priority =3D 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)

Where G and D are the priority values for $L_PRIV_1 and $R_PUB_1.

$L_PRIV_1 is L's host candidate, and stated to have a priorty of
2130706431

$R_PUB_1 is R's host candidate and stated to have a priorty of 2130706431

So G =3D 2130706431 and D=3D2130706431

pair priority then becomes 2^32*2130706431 + 2*2130706431 + 0 =3D
9151314442783293438

Thus, I think the next two pair priorities in the example also needs to
be fixed.

The first pair priority for R is the same value as for L, as G and D are
identical. But the next value will
be different. To my understanding L will be controlling, i.e. L's
candidate will be G

G=3D1694498815
D=3D 2130706431

Pair priority =3D 2^32*1694498815+2*2130706431 + 0 =3D 7277816997797167102
Please provide text for the section (or, at least the modified paragraphs)
:)

Fine, I can put in the numbers in the right place. But please check my calculations:

OLD:

=C2=A0=C2=A0 Agents L and R both pair up the candidates.=C2=A0 They= both initially have
=C2=A0=C2=A0 two pairs.=C2=A0 However, agent L will prune the pair = containing its
=C2=A0=C2=A0 server reflexive candidate, resulting in just one.=C2=A0= At agent L, this
=C2=A0=C2=A0 pair has a local candidate of $L_PRIV_1 and remote can= didate of
=C2=A0=C2=A0 $R_PUB_1, and has a candidate pair priority of 4.57566= E+18 (note that
=C2=A0=C2=A0 an implementation would represent this as a 64-bit int= eger so as not
=C2=A0=C2=A0 to lose precision).=C2=A0 At agent R, there are two pa= irs.=C2=A0 The highest
=C2=A0=C2=A0 priority has a local candidate of $R_PUB_1 and remote = candidate of
=C2=A0=C2=A0 $L_PRIV_1 and has a priority of 4.57566E+18, and the s= econd has a
=C2=A0=C2=A0 local candidate of $R_PUB_1 and remote candidate of $N= AT_PUB_1 and
=C2=A0=C2=A0 priority 3.63891E+18.

NEW:

=C2=A0=C2=A0 Agents L and R both pair up the candidates.=C2=A0 They= both initially have
=C2=A0=C2=A0 two pairs.=C2=A0 However, agent L will prune the pair = containing its
=C2=A0=C2=A0 server reflexive candidate, resulting in just one.=C2=A0= At agent L, this
=C2=A0=C2=A0 pair has a local candidate of $L_PRIV_1 and remote can= didate of
=C2=A0=C2=A0 $R_PUB_1, and has a candidate pair priority of 9151314442783293438.
=C2=A0=C2=A0 At agent R, there are two pairs.=C2=A0 The highest
=C2=A0=C2=A0 priority has a local candidate of $R_PUB_1 and remote = candidate of
=C2=A0=C2=A0 $L_PRIV_1 and has a priority of 9151314442783293438, a= nd the second has a
=C2=A0=C2=A0 local candidate of $R_PUB_1 and remote candidate of $N= AT_PUB_1 and
=C2=A0=C2=A0 priority 7277816997797167102.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB=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=C2=A0=C2=A0=C2=A0 | Phone=C2=A0 +46 10 7148287
Torshamnsgatan 23=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
---------------------------------------------------------------------- 




_______________________________________________
Ice mailing list
Ice@ie=
tf.org
https://www.ietf.org/mailman/listinfo/ice


--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@erics=
son.com
----------------------------------------------------------------------
  


--------------82A28E284C156C52D96DBADC--

--------------ms030203090104080801090301
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME-kryptografisk signatur

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DNEwggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNV
BAoMCEVyaWNzc29uMRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJ
ARYebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+
laqg5eXTqonqnzT9ykEGL2dx9mBT+2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJ
HGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iV
IiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpigGFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36o
gzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkrbdmdnjKGrYSnJigmxw14pJugxL/Vb2Ee
VcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDov
L2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCBggYI
KwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29t
MEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29u
bmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJp
Y3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0
dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQG
CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD
VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3
DQEBCwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4Q
ihhoQR3cvhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXD
yF9mhWYbSAkJyx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6
H3zO3nsq++KBmsOiSKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvE
lup5n7l864FqxnC2friDo4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl
60rmc8SJlt6QXKw0wXEOE1MubauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwD
ig3SZi1qP7D/Ds4V+JLIjjUJc25l9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8K
v7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLCQaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3
UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Zla71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzY
VBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd//n4YbY2QhDCCBsIwggSqoAMCAQICEFO4
foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx
HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUx
MDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM
HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw
ggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfS
Tm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbX
ILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfp
VdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2
PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2
H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4
rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX
1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjv
Zibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FN
VSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoGCCsG
AQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEu
Y29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j
b20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAE
TjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnku
dHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3Js
LTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1Ud
JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7
GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G
CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDU
JQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHG
vw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYn
nl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwf
ixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ8
5AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4Hd
Dc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOE
EHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd
3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/du
jp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDGCAzswggM3AgEB
MFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMA0GCWCGSAFlAwQCAQUA
oIIBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAyMDIx
NjA0MzNaMC8GCSqGSIb3DQEJBDEiBCBLyUjKpcoM2/zXAmrV4BuPtTdiA5hG4N3ROyoxGCmM
azBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjEl
MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBlrrZreXF5
7TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMGwGCyqGSIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nz
b24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62
a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAJoTCVZCQsWJxnxpQXL4vrfN+EF7OVEbKkw9zdki6
Z2ead3eYNShK53/sSKN00YJ9S/HHNCHsNo+g4bTM0pm/ro/BPSgtsw2By+Oh6R0PwX4Dz55P
MGp4nQJbRb/Z83pa6yfsTWNF2PNvtlUDc7pTm/0uNaQJl7UtfepkmNPANcadg319v8lAZ+JE
gcDw4HJ5zAKrIw270TMRkvlEpxdh1YmdNQnbIaueqLeYXLcQ8UMstP2OJs8jt/lUZNpexmMw
I0nWcw+4CAcJVlWK71knlJre06WZRQcuR79Hz5HI6xnWXJnP6urB2uVq8GDr4ns64LOvN5WK
Yf1SF/AhuFaWAwAAAAAAAA==
--------------ms030203090104080801090301--


From nobody Fri Feb  2 08:10:12 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7FB12DA42 for ; Fri,  2 Feb 2018 08:10:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.319
X-Spam-Level: 
X-Spam-Status: No, score=-4.319 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suF3vkt2sZee for ; Fri,  2 Feb 2018 08:10:06 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 4338912DA28 for ; Fri,  2 Feb 2018 08:10:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517587803; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fSbQtsP8KaXnnxPydZQ7q/o7fYMCqbAXkTqoMSx3WBk=; b=TogpT51i7C93xNbkxh5vr9gDkRbbGueIXnkqQ3FljD5InibkmDkaqzS3bE59yD9l niZd+TosVT6n8bQW35/mWrUqkAgCTaRmUj2dflS+rxcFt8PKa4z9Qm28INussPl7 9Bav0JXJ8a/M7zuKSN2VRIIyd3iVrD1HsvliydsF2+4=;
X-AuditID: c1b4fb30-3b1ff70000004778-f7-5a748d5b2f1b
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 94.1B.18296.B5D847A5; Fri,  2 Feb 2018 17:10:03 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0352.000; Fri, 2 Feb 2018 17:10:03 +0100
From: Christer Holmberg 
To: Magnus Westerlund , "tsv-art@ietf.org" 
CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" 
Thread-Topic: [Ice] Tsvart last call review of draft-ietf-ice-rfc5245bis-16
Thread-Index: AQHTmc09cSMwjiuCL0KSsp8F+FSKLqOMj1UAgALAtgCAAEO8AIABRN+AgAA1HYCAABIoAIAAGr6AgAAmU4A=
Date: Fri, 2 Feb 2018 16:10:02 +0000
Message-ID: 
References: <151731848710.27439.7061415423323921488@ietfa.amsl.com>  <1d6ab623-0076-2e75-0e99-6a24e55ee934@ericsson.com>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.16]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3600440503_48608703"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUyM2K7pW50b0mUwcw7KhbHf/xht/h2odbi 2cb5LBaz9ixicWDxWLLkJ1MAYxSXTUpqTmZZapG+XQJXxv4D5gW9X5kq3n1sYG9gvNLL1MXI ySEhYCJxcP1qIJuLQ0jgMKPE5b1v2SGcxYwS184vBcpwcLAJWEh0/9MGaRARiJfo2vqODaSG WWAmo8Trny8ZQWqEBbwk+jcaQ9R4S6z5dYURwk6SeLZ3OjuIzSKgInHmeT8biM0rYC3x5Vg3 1K6NzBLHr5wHK+IUcJA4cOYMC4jNKCAm8f3UGrBLmQXEJW49mQ91tYjEw4un2SBsUYmXj/+x gtiiAnoSG07cZoeIK0rsPNvODNFbKXHh4HFGiMWCEidnPmGZwCg6C8nYWUjKZiEpg4i7S8w6 /xDI5gCydST+7WeDCGtLPHl3gRXGfjdrEzOmuLXEjF8HoeoVJaZ0P2SHsE0lXh/9yLiAkXsV o2hxanFSbrqRkV5qUWZycXF+nl5easkmRmBkH9zy22AH48vnjocYBTgYlXh4+XtKooRYE8uK K3MPMaoAzXm0YfUFRimWvPy8VCUR3m2+QGnelMTKqtSi/Pii0pzU4kOM0hwsSuK8Jz15o4QE 0hNLUrNTUwtSi2CyTBycUg2MTDE8URd/hs7U+L9SUMr4xadbj6xkpZqPCC9KuRr+t2y1ztrw wiPi3+TOJuuxrtvLZdaUx7EgXZhbNP5K1JruUukbC/v3t4eGCi1aeU7VczljiNjOmaW7Hqhb fJteq8yt8uhHXpdI1a4PcnrXrfrutkYs9kp6zbgi6jyr8UynCU2VThbL5/IqsRRnJBpqMRcV JwIAinqg2/QCAAA=
Archived-At: 
Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-rfc5245bis-16
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 02 Feb 2018 16:10:11 -0000

--B_3600440503_48608703
Content-type: multipart/alternative;
	boundary="B_3600440503_48571726"


--B_3600440503_48571726
Content-type: text/plain;
	charset="EUC-KR"
Content-transfer-encoding: quoted-printable

Hi,

The text looks good to me.

I will add it, and submit a new version of the draft, so that we can move
forward.

IF someone has issues with the text, we can always fix it as part of
upcoming IESG review fixes.

Regards,

Christer

From:  Magnus Westerlund 
Date:  Friday 2 February 2018 at 18:04
To:  Christer Holmberg , "tsv-art@ietf.org"

Cc:  "draft-ietf-ice-rfc5245bis.all@ietf.org"
, IETF Discussion ,
"ice@ietf.org" 
Subject:  Re: [Ice] Tsvart last call review of draft-ietf-ice-rfc5245bis-16

   =20
=20

Hi,
=20

On Christer's request I have written a text proposal for a security
consideration addition regarding the ICMP message. From my perspective, WG
input is needed into this issue!
=20
=20

New paragraph:
=20
=20


    Spoofed ICMP Hard Errors (Type 3, codes 2-4) can also be used to
    create false invalid results. If an ICE agent implements a response
    to these ICMP errors, and the attacker is capable of generating an
    ICMP message that is delivered to the agent sending the connectivity
    check. The validation of the ICMP error message by the agent is its
    only defence. For Type 3 code=3D4 the outer IP header provides no
    validation, unless the connectivity check was sent with DF=3D0.
    For code 2 or 3, which are originated by the host, the
    address is expected to be any of the remote agents host, reflexive, or
relay=20
    candidates IP addresses. The ICMP message include the IP header and UDP
    header of the message triggering the error. These fields also needs to
    be validated. The IP destination and UDP destination port needs to matc=
h
    either the targeted candidate address and port, or the candidates base
    address. The source IP address and port can be any candidate for the
same=20
    base address of the agent sending the connectivity check. Thus any
attacker=20
    having access to the exchange of the candidates will have the necessary
    information. Thus the validation is a weak defence, and the sending of
    spoofed ICMP attacks is possible also for off-path attackers from a nod=
e
    in a network without source address validation.
=20
 Intended to be added in Section 19.1  between two existing paragraphs as
indicated below.
=20
 .. exchange signaling is secured, the attacker will not have the
    password and its response will be discarded.
=20
 [The new paragraph]
=20
 Forcing the fake valid result works in a similar way.  The agent ...
=20


=20
=20

I hope this helps making it clear how relatively easy this attack can be
performed, and why I think it is actually safer to ignore any ICMP errors
for the connectivity checks.
=20
=20


=20
=20


=20
=20
=20
Den 2018-02-02 kl. 15:28, skrev Magnus Westerlund:
=20
=20
> Hi,=20
> =20
>  See responses inline
> =20
> =20
>  Den 2018-02-02 kl. 12:12, skrev Christer Holmberg:
> =20
>> =20
>>  ---=20
>> =20
>> =20
>> =20
>>> =20
>>>> =20
>>>>> =20
>>>>>> =20
>>>>>>> E. Section 7.2.5.2.2.  ICMP Error
>>>>>>> =20
>>>>>>>        An ICE agent MAY support processing of ICMP errors for
>>>>>>>  connectivity
>>>>>>>        checks.  If the agent supports processing of ICMP errors, an=
d
>>>>>>>  if a=20
>>>>>>>        Binging request generates an ICMP error, the agent SHOULD se=
t
>>>>>>>  the=20
>>>>>>>        state of the candidate pair to Failed.
>>>>>>> =20
>>>>>>>  I am a bit worried by this blanket statement on ICMP errors. I thi=
nk
>>>>>>>  it=20
>>>>>>>  should=20
>>>>>>>  be clarified which ICMP message types that are relevant to conside=
r
>>>>>>>  as=20
>>>>>>>  errors?=20
>>>>>>>  I assume Type 3 (Destination Unreachable) but maybe not all respon=
de
>>>>>>>  codes as=20
>>>>>>>  Codes 4, 11,12 may be addressable in other ways, and likely Type 1=
1
>>>>>>>  (Time=20
>>>>>>>  exceeded) with response code 0, response code 1 is not a clear
>>>>>>>  indication
>>>>>>>  of a=20
>>>>>>>  non working path.
>>>>>>> =20
>>>>>>  This is from RFC 5245.
>>>>>> =20
>>>>>>  I don=A9=F6t think the ICE WG should go through all different codes and
>>>>>>  combinations, and determine what should be considered an error, and
>>>>>>  what=20
>>>>>>  not.=20
>>>>>> =20
>>>>>>  If you can provide something (table, guidance etc), we are happy to
>>>>>>  include it. Otherwise I=A9=F6d like to keep it as it is, and let
>>>>>>  implementations deal with it, as at least I am not aware that this
>>>>>>  would=20
>>>>>>  Have caused issues in ICE deployments.
>>>>>> =20
>>>>>  I think we there is a point to clarify that this applies to ICMP
>>>>>  messages indicating a non-usable path. So maybe it could be rewritte=
n
>>>>>  to=20
>>>>>  something like this:
>>>>> =20
>>>>>       An ICE agent MAY support processing of ICMP messaging indicatin=
g a
>>>>>  non-functioning path for connectivity
>>>>>       checks. ICMP messages of type 3 (Destination Unreachable) are
>>>>>  indicators of a currently non-functioning path. However, the issue c=
an
>>>>>  be=20
>>>>>  temporary as it can depend on routing transients, this for example
>>>>>  applies to codes 0, 1 and 5. Other messages that appear to indicate
>>>>>  non-functioning path such as Type=3D11 (Time Exceeded) with code=3D0 (Ti=
me
>>>>>  to=20
>>>>>  Live exceeded in Transit) are not clear indicator as the IP packets
>>>>>  potentially can reach the destination with a larger TTL value set at
>>>>>  transmission. Therefore, implementation needs to analyse the differe=
nt
>>>>>  ICMP messages types and codes for which it considers the path as
>>>>>  non-functioning. If the agent supports processing of ICMP errors, an=
d
>>>>>  if a=20
>>>>>       Binging request generates an ICMP error, the agent SHOULD set t=
he
>>>>>       state of the candidate pair to Failed.
>>>>> =20
>>>>> =20
>>>>>  What also is not addressed in this is the risk of denial of service
>>>>>  attacks using spoofed ICMP messages to shutdown certain connectivity
>>>>>  checks. The security considerations lack any discussion of this issu=
e.
>>>>>  If ICMP processing are retained, I think a recommendation about
>>>>>  validation is needed to avoid at least off path attackers from doing
>>>>>  these attacks easily. Unfortunately ICMP response will only include =
the
>>>>>  IP/UDP header, thus no data from the STUN messages which would allow
>>>>>  verification that the ICMP messages matches an actually sent check.
>>>>> =20
>>>>>  It may be simplest to recommend against reacting to ICMP errors from
>>>>>  both the perspective that it is a risk for denial of service attack,=
 as
>>>>>  well as that it represents a risk terminating connectivity checks fo=
r a
>>>>>  transient issue. From my perspective I expect this to reduce the num=
ber
>>>>>  of sent connectivity checks very little
>>>>> =20
>>>>  So, are you saying that an agent should simply ignore ICMP messages?
>>>> =20
>>>  Yes, I think that may be the best. There are a bit to many corner case=
s
>>>  and significant attack surface that getting all the details right are
>>>  significant work for a relatively small reduction in sent connection
>>>  check messages.
>>> =20
>>  I am not an expert, but aren=A1=AFt you going to get ICMP unreachable every
>>  time you try to contact a host candidate behind a NAT? Are you saying t=
hat
>>  the agent should ignore it, as the connectivity test will anyway timeou=
t
>>  at some point?=20
>> =20
> =20
>  To my understanding NATs and firewalls do not send ICMP unreachable beca=
use
> that would violates its role as a gateway rather than end-host, also it w=
ant
> to avoid giving away information about its internal side, and is a risk i=
n
> creating a lot of load on the middlebox.
> =20
> =20
>> =20
>>  Also, note that RFC 5398 (STUN) says:
>> =20
>>     "A STUN transaction over UDP is also considered failed if there has =
been
>>  a=20
>>      hard ICMP error [RFC1122].=A1=B1
>> =20
>>  I am a little worried that people would have to use ICE-specific STUN
>>  stacks if they are required to ignore ICMP errors.
>> =20
>>  Couldn=A1=AFt we simply use the existing text, and add a sentence about DoS
>>  attacks?=20
>> =20
>> =20
>> =20
>>  OLD:=20
>> =20
>>    An ICE agent MAY support processing of ICMP errors for connectivity
>>    checks.  If the agent supports processing of ICMP errors, and if a
>>    Binging request generates an ICMP error, the agent SHOULD set the
>>    state of the candidate pair to Failed.
>> =20
>> =20
>> =20
>>  NEW:=20
>> =20
>>    An ICE agent MAY support processing of ICMP errors for connectivity
>>    checks. If the agent supports processing of ICMP errors, and if a
>>    Binging request generates an ICMP error, the agent SHOULD set the
>>    state of the candidate pair to Failed. Implementers need to be aware
>>  that ICMP errors can be used as a method for denial of service attacks
>>  when making a decision on how and if to process ICMP errors.
>> =20
> =20
>  I think you need to at least make it clear that it is "hard ICMP errors"=
.
> Which RFC 1122 defined as Type 3 with codes 2-4 for TCP. So, in that case=
 one
> could just as well be explicit. I don't know if any of the later defined =
codes
> are defined as hard errors.
> =20
>  When it comes to the security consideration, I am actually quite worried=
 by
> this. To spoof ICMP so that they arrive back at the client, you need to b=
e
> able to send an ICMP packet back that matches the NAT's binding. That req=
uires
> that you now the connectivity checks intended target address+port, and th=
e
> NAT's source address+port. With that information you can generate an ICMP
> message that will arrive at the agent as long as the attacker can route a
> packet to the NATs address. And if you are in the local address domain to=
 the
> agent, you can fake an ICMP error with only the information matching the =
peer
> agents candidate.
> =20
>  I think this issue do need security considerations text.
> =20
> =20
>> =3D=3D=3D=3D=3D=3D=3D=20
>> =20
>>  Minor/Editorial Issues:
>> =20
>>   =20
>>  ---=20
>> =20
>> =20
>>> =20
>>>> =20
>>>>> =20
>>>>>> =20
>>>>>>> 9. Section 15:
>>>>>>> =20
>>>>>>>  4.57566E+18 (note that
>>>>>>>       an implementation would represent this as a 64-bit integer so=
 as
>>>>>>>  not=20
>>>>>>>       to lose precision).
>>>>>>> =20
>>>>>>>  Why the floating point representation? Priorities are integer numb=
ers
>>>>>>>  and=20
>>>>>>>  thus=20
>>>>>>>  should be presented as such in this example.
>>>>>>> =20
>>>>>>  This is from RFC 5245, and unfortunately I don=A9=F6t know.
>>>>>> =20
>>>>>  Can you not just calculate the 64-bit integer and write it out?
>>>>> =20
>>>>  So, you want me to write 4575660000000000000?
>>>> =20
>>>  No, I thought the pair priority will not be 0 for the lower 32 bits an=
d
>>>  that there actually are overflow in this deduction. My understanding i=
s
>>>  that what should be written here is the calculation of:
>>> =20
>>>  pair priority =3D 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
>>> =20
>>>  Where G and D are the priority values for $L_PRIV_1 and $R_PUB_1.
>>> =20
>>>  $L_PRIV_1 is L's host candidate, and stated to have a priorty of
>>>  2130706431=20
>>> =20
>>>  $R_PUB_1 is R's host candidate and stated to have a priorty of 2130706=
431
>>> =20
>>>  So G =3D 2130706431 and D=3D2130706431
>>> =20
>>>  pair priority then becomes 2^32*2130706431 + 2*2130706431 + 0 =3D
>>>  9151314442783293438
>>> =20
>>>  Thus, I think the next two pair priorities in the example also needs t=
o
>>>  be fixed.=20
>>> =20
>>>  The first pair priority for R is the same value as for L, as G and D a=
re
>>>  identical. But the next value will
>>>  be different. To my understanding L will be controlling, i.e. L's
>>>  candidate will be G
>>> =20
>>>  G=3D1694498815=20
>>>  D=3D 2130706431=20
>>> =20
>>>  Pair priority =3D 2^32*1694498815+2*2130706431 + 0 =3D 7277816997797167102
>>> =20
>>  Please provide text for the section (or, at least the modified paragrap=
hs)
>>  :)=20
>> =20
> =20
>  Fine, I can put in the numbers in the right place. But please check my
> calculations:=20
> =20
>  OLD:=20
> =20
>     Agents L and R both pair up the candidates.  They both initially have
>     two pairs.  However, agent L will prune the pair containing its
>     server reflexive candidate, resulting in just one.  At agent L, this
>     pair has a local candidate of $L_PRIV_1 and remote candidate of
>     $R_PUB_1, and has a candidate pair priority of 4.57566E+18 (note that
>     an implementation would represent this as a 64-bit integer so as not
>     to lose precision).  At agent R, there are two pairs.  The highest
>     priority has a local candidate of $R_PUB_1 and remote candidate of
>     $L_PRIV_1 and has a priority of 4.57566E+18, and the second has a
>     local candidate of $R_PUB_1 and remote candidate of $NAT_PUB_1 and
>     priority 3.63891E+18.
> =20
>  NEW:=20
> =20
>     Agents L and R both pair up the candidates.  They both initially have
>     two pairs.  However, agent L will prune the pair containing its
>     server reflexive candidate, resulting in just one.  At agent L, this
>     pair has a local candidate of $L_PRIV_1 and remote candidate of
>     $R_PUB_1, and has a candidate pair priority of 9151314442783293438.
>     At agent R, there are two pairs.  The highest
>     priority has a local candidate of $R_PUB_1 and remote candidate of
>     $L_PRIV_1 and has a priority of 9151314442783293438, and the second h=
as a
>     local candidate of $R_PUB_1 and remote candidate of $NAT_PUB_1 and
>     priority 7277816997797167102.
> =20
> =20
>  Cheers=20
> =20
>  Magnus Westerlund
> =20
> ----------------------------------------------------------------------
>  Media Technologies, Ericsson Research
> ----------------------------------------------------------------------
>  Ericsson AB                 | Phone  +46 10 7148287
>  Torshamnsgatan 23           | Mobile +46 73 0949079
>  SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> =20
> =20
> =20
>  =20
> =20
> _______________________________________________
> Ice mailing list
> Ice@ietf.orghttps://www.ietf.org/mailman/listinfo/ice
> =20
=20
=20
--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
=20



--B_3600440503_48571726
Content-type: text/html;
	charset="EUC-KR"
Content-transfer-encoding: quoted-printable


Hi,

=
The text looks good to me.

I will add it, and submi=
t a new version of the draft, so that we can move forward.

IF someone has issues with the text, we can always fix it as part of=
 upcoming IESG review fixes.

Regards,
Christer

From: <=
/span> Magnus Westerlund <magnus.westerlund@ericsson.com>
Da=
te:  Friday 2 February 2018 at 18:04
To:  Christer Holmberg <christer.holmberg@ericsson.com>, "tsv-art@ietf.org" <tsv-art@i=
etf.org>
Cc:  "draft-ietf-ice-rfc5245bis.all@iet=
f.org" <draft=
-ietf-ice-rfc5245bis.all@ietf.org>, IETF Discussion <ietf@ietf.org>, "ice@=
ietf.org" <ice@ietf.org>
Subject:  Re: [Ice] Tsvart last call revie=
w of draft-ietf-ice-rfc5245bis-16


  
    
  
  

    
Hi,

    
On Christer's request I have written a text proposal for a
      security consideration addition regarding the ICMP message. From
      my perspective, WG input is needed into this issue!

    

    
New paragraph:

    

    


         Spoofed ICMP Hard Errors (Type 3, codes 2-4) can also be=
 used
      to
      

         create false invalid results. If an ICE agent implements=
 a
      response
      

         to these ICMP errors, and the attacker is capable of gen=
erating
      an
      

         ICMP message that is delivered to the agent sending the
      connectivity
      

         check. The validation of the ICMP error message by the a=
gent is
      its
      

         only defence. For Type 3 code=3D4 the outer IP header prov=
ides no
      

         validation, unless the connectivity check was sent with =
DF=3D0.
      

         For code 2 or 3, which are originated by the host, the
      

         address is expected to be any of the remote agents host,=

      reflexive, or relay
      

         candidates IP addresses. The ICMP message include the IP=
 header
      and UDP
      

         header of the message triggering the error. These fields=
 also
      needs to
      

         be validated. The IP destination and UDP destination por=
t needs
      to match
      

         either the targeted candidate address and port, or the
      candidates base
      

         address. The source IP address and port can be any candi=
date
      for the same
      

         base address of the agent sending the connectivity check=
. Thus
      any attacker
      

         having access to the exchange of the candidates will hav=
e the
      necessary
      

         information. Thus the validation is a weak defence, and =
the
      sending of
      

         spoofed ICMP attacks is possible also for off-path attac=
kers
      from a node
      

         in a network without source address validation.
      

      

      Intended to be added in Section 19.1  between two existing
      paragraphs as indicated below.

      

      .. exchange signaling is secured, the attacker will not have the
      

         password and its response will be discarded.
      

      

      [The new paragraph]
      

      

      Forcing the fake valid result works in a similar way.  The agent=

      ...
    

    


    

    
I hope this helps making it clear how relatively easy this attack
      can be performed, and why I think it is actually safer to ignore
      any ICMP errors for the connectivity checks. 

    

    


    

    


    

    

    
Den 2018-02-02 kl. 15:28, skrev Magnus
      Westerlund:

    

    
Hi,
      

      

      See responses inline
      

      

      

      Den 2018-02-02 kl. 12:12, skrev Christer Holmberg:
      

      

        

        ---
        

        

        

        

          

            

              

                
E. Section 7.2.5.2.2.  ICMP
                  Error
                  

                  

                        An ICE agent MAY support p=
rocessing of ICMP
                  errors for
                  

                  connectivity
                  

                        checks.  If the agent=
 supports processing of
                  ICMP errors, and
                  

                  if a
                  

                        Binging request generates =
an ICMP error, the
                  agent SHOULD set
                  

                  the
                  

                        state of the candidate pai=
r to Failed.
                  

                  

                  I am a bit worried by this blanket statement on ICMP
                  errors. I think
                  

                  it
                  

                  should
                  

                  be clarified which ICMP message types that are
                  relevant to consider
                  

                  as
                  

                  errors?
                  

                  I assume Type 3 (Destination Unreachable) but maybe
                  not all responde
                  

                  codes as
                  

                  Codes 4, 11,12 may be addressable in other ways, and
                  likely Type 11
                  

                  (Time
                  

                  exceeded) with response code 0, response code 1 is not
                  a clear
                  

                  indication
                  

                  of a
                  

                  non working path.
                  

                

                This is from RFC 5245.
                

                

                I don=A9=F6t think the ICE WG should go through all different
                codes and
                

                combinations, and determine what should be considered an
                error, and
                

                what
                

                not.
                

                

                If you can provide something (table, guidance etc), we
                are happy to
                

                include it. Otherwise I=A9=F6d like to keep it as it is, and
                let
                

                implementations deal with it, as at least I am not aware
                that this
                

                would
                

                Have caused issues in ICE deployments.
                

              

              I think we there is a point to clarify that this applies
              to ICMP
              

              messages indicating a non-usable path. So maybe it could
              be rewritten
              

              to
              

              something like this:
              

              

                   An ICE agent MAY support processing =
of ICMP messaging
              indicating a
              

              non-functioning path for connectivity
              

                   checks. ICMP messages of type 3 (Des=
tination
              Unreachable) are
              

              indicators of a currently non-functioning path. However,
              the issue can
              

              be
              

              temporary as it can depend on routing transients, this for
              example
              

              applies to codes 0, 1 and 5. Other messages that appear to
              indicate
              

              non-functioning path such as Type=3D11 (Time Exceeded) with
              code=3D0 (Time
              

              to
              

              Live exceeded in Transit) are not clear indicator as the
              IP packets
              

              potentially can reach the destination with a larger TTL
              value set at
              

              transmission. Therefore, implementation needs to analyse
              the different
              

              ICMP messages types and codes for which it considers the
              path as
              

              non-functioning. If the agent supports processing of ICMP
              errors, and
              

              if a
              

                   Binging request generates an ICMP er=
ror, the agent
              SHOULD set the
              

                   state of the candidate pair to Faile=
d.
              

              

              

              What also is not addressed in this is the risk of denial
              of service
              

              attacks using spoofed ICMP messages to shutdown certain
              connectivity
              

              checks. The security considerations lack any discussion of
              this issue.
              

              If ICMP processing are retained, I think a recommendation
              about
              

              validation is needed to avoid at least off path attackers
              from doing
              

              these attacks easily. Unfortunately ICMP response will
              only include the
              

              IP/UDP header, thus no data from the STUN messages which
              would allow
              

              verification that the ICMP messages matches an actually
              sent check.
              

              

              It may be simplest to recommend against reacting to ICMP
              errors from
              

              both the perspective that it is a risk for denial of
              service attack, as
              

              well as that it represents a risk terminating connectivity
              checks for a
              

              transient issue. From my perspective I expect this to
              reduce the number
              

              of sent connectivity checks very little
              

            

            So, are you saying that an agent should simply ignore ICMP
            messages?
            

          

          Yes, I think that may be the best. There are a bit to many
          corner cases
          

          and significant attack surface that getting all the details
          right are
          

          significant work for a relatively small reduction in sent
          connection
          

          check messages.
          

        

        I am not an expert, but aren’t you going to get ICMP unreacha=
ble
        every
        

        time you try to contact a host candidate behind a NAT? Are you
        saying that
        

        the agent should ignore it, as the connectivity test will anyway
        timeout
        

        at some point?
        

      

      

      To my understanding NATs and firewalls do not send ICMP
      unreachable because that would violates its role as a gateway
      rather than end-host, also it want to avoid giving away
      information about its internal side, and is a risk in creating a
      lot of load on the middlebox.
      

      

      

        

        Also, note that RFC 5398 (STUN) says:
        

        

           "A STUN transaction over UDP is also considered failed=
 if
        there has been
        

        a
        

            hard ICMP error [RFC1122].”
        

        

        I am a little worried that people would have to use ICE-specific
        STUN
        

        stacks if they are required to ignore ICMP errors.
        

        

        Couldn’t we simply use the existing text, and add a sentence
        about DoS
        

        attacks?
        

        

        

        

        OLD:
        

        

          An ICE agent MAY support processing of ICMP errors for
        connectivity
        

          checks.  If the agent supports processing of ICMP error=
s, and
        if a
        

          Binging request generates an ICMP error, the agent SHOULD se=
t
        the
        

          state of the candidate pair to Failed.
        

        

        

        

        NEW:
        

        

          An ICE agent MAY support processing of ICMP errors for
        connectivity
        

          checks. If the agent supports processing of ICMP errors, and=

        if a
        

          Binging request generates an ICMP error, the agent SHOULD se=
t
        the
        

          state of the candidate pair to Failed. Implementers need to =
be
        aware
        

        that ICMP errors can be used as a method for denial of service
        attacks
        

        when making a decision on how and if to process ICMP errors.
        

      

      

      I think you need to at least make it clear that it is "hard ICMP
      errors". Which RFC 1122 defined as Type 3 with codes 2-4 for TCP.
      So, in that case one could just as well be explicit. I don't know
      if any of the later defined codes are defined as hard errors.
      

      

      When it comes to the security consideration, I am actually quite
      worried by this. To spoof ICMP so that they arrive back at the
      client, you need to be able to send an ICMP packet back that
      matches the NAT's binding. That requires that you now the
      connectivity checks intended target address+port, and the NAT's
      source address+port. With that information you can generate an
      ICMP message that will arrive at the agent as long as the attacker
      can route a packet to the NATs address. And if you are in the
      local address domain to the agent, you can fake an ICMP error with
      only the information matching the peer agents candidate.
      

      

      I think this issue do need security considerations text.
      

      

      
=3D=3D=3D=3D=3D=3D=3D
        

        

        Minor/Editorial Issues:
        

        

          

        ---
        

        

        

          

            

              

                
9. Section 15:
                  

                  

                  4.57566E+18 (note that
                  

                       an implementation would represen=
t this as a
                  64-bit integer so as
                  

                  not
                  

                       to lose precision).
                  

                  

                  Why the floating point representation? Priorities are
                  integer numbers
                  

                  and
                  

                  thus
                  

                  should be presented as such in this example.
                  

                

                This is from RFC 5245, and unfortunately I don=A9=F6t know.
                

              

              Can you not just calculate the 64-bit integer and write it
              out?
              

            

            So, you want me to write 4575660000000000000?
            

          

          No, I thought the pair priority will not be 0 for the lower 32
          bits and
          

          that there actually are overflow in this deduction. My
          understanding is
          

          that what should be written here is the calculation of:
          

          

          pair priority =3D 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
          

          

          Where G and D are the priority values for $L_PRIV_1 and
          $R_PUB_1.
          

          

          $L_PRIV_1 is L's host candidate, and stated to have a priorty
          of
          

          2130706431
          

          

          $R_PUB_1 is R's host candidate and stated to have a priorty of
          2130706431
          

          

          So G =3D 2130706431 and D=3D2130706431
          

          

          pair priority then becomes 2^32*2130706431 + 2*2130706431 + 0
          =3D
          

          9151314442783293438
          

          

          Thus, I think the next two pair priorities in the example also
          needs to
          

          be fixed.
          

          

          The first pair priority for R is the same value as for L, as G
          and D are
          

          identical. But the next value will
          

          be different. To my understanding L will be controlling, i.e.
          L's
          

          candidate will be G
          

          

          G=3D1694498815
          

          D=3D 2130706431
          

          

          Pair priority =3D 2^32*1694498815+2*2130706431 + 0 =3D
          7277816997797167102
          

        

        Please provide text for the section (or, at least the modified
        paragraphs)
        

        :)
        

      

      

      Fine, I can put in the numbers in the right place. But please
      check my calculations:
      

      

      OLD:
      

      

         Agents L and R both pair up the candidates.  They b=
oth
      initially have
      

         two pairs.  However, agent L will prune the pair co=
ntaining its
      

         server reflexive candidate, resulting in just one. =
 At agent L,
      this
      

         pair has a local candidate of $L_PRIV_1 and remote candi=
date of
      

         $R_PUB_1, and has a candidate pair priority of 4.57566E+=
18
      (note that
      

         an implementation would represent this as a 64-bit integ=
er so
      as not
      

         to lose precision).  At agent R, there are two pair=
s.  The
      highest
      

         priority has a local candidate of $R_PUB_1 and remote ca=
ndidate
      of
      

         $L_PRIV_1 and has a priority of 4.57566E+18, and the sec=
ond has
      a
      

         local candidate of $R_PUB_1 and remote candidate of $NAT=
_PUB_1
      and
      

         priority 3.63891E+18.
      

      

      NEW:
      

      

         Agents L and R both pair up the candidates.  They b=
oth
      initially have
      

         two pairs.  However, agent L will prune the pair co=
ntaining its
      

         server reflexive candidate, resulting in just one. =
 At agent L,
      this
      

         pair has a local candidate of $L_PRIV_1 and remote candi=
date of
      

         $R_PUB_1, and has a candidate pair priority of
      9151314442783293438.
      

         At agent R, there are two pairs.  The highest
      

         priority has a local candidate of $R_PUB_1 and remote ca=
ndidate
      of
      

         $L_PRIV_1 and has a priority of 9151314442783293438, and=
 the
      second has a
      

         local candidate of $R_PUB_1 and remote candidate of $NAT=
_PUB_1
      and
      

         priority 7277816997797167102.
      

      

      

      Cheers
      

      

      Magnus Westerlund
      

      

----------------------------------------------------------------------
      

      Media Technologies, Ericsson Research
      

----------------------------------------------------------------------
      

      Ericsson AB         &nbs=
p;       | Phone  +46 10 7148287
      

      Torshamnsgatan 23        &nbs=
p;  | Mobile +46 73 0949079
      

      SE-164 80 Stockholm, Sweden | mailto:
      magnus.westerlund@ericsson.com
      

----------------------------------------------------------------------
      

      

      

      

      

      

      
_______________________________________________
Ice mailing list
Ice@ietf.org=
https://www.ietf.org/mailman/listinfo/ice

    

    

    
-- 

Magnus Westerlund 

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
  


--B_3600440503_48571726--

--B_3600440503_48608703
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUOQYJKoZIhvcNAQcCoIIUKjCCFCYCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghIMMIIGBjCCA+6gAwIBAgIQN4YipkcuAr1/ZKbsw+1eMTANBgkqhkiG9w0BAQsFADBH
MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M
IEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTAzMDgwODMyWhcNMjAxMTAzMDgwODMxWjBvMREw
DwYDVQQKDAhFcmljc3NvbjEaMBgGA1UEAwwRQ2hyaXN0ZXIgSG9sbWJlcmcxLTArBgkqhkiG
9w0BCQEWHmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTEPMA0GA1UEBRMGTE1GQ0hI
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy0z3dlyw+ybHo7PhlkBY00QOJB5T
NOXcMdxiQ0nL5uM1C/0xQ7/T3uuHJRjD8nvqTqnlmfJ2VCZRKD3W8LJAUXGFd8JqwLJmGGZt
cS3Jp+2WBAxBR6TjtcMwDGQNYD85YCKIuqcsarOxVhzXhwISp750JC1UmR4xxX1gbSkVb8S8
DsPsBioQ/Enkiad/rP0huQFb56Ocxu2Fy2aEW06ezyxU9My4Jh/vMDh+0DBb8EfN8ovAFmMH
Qj3SxVUDwnTYbPdA1v3RipF/HH0NBsNOUS8RFct6OxHG1JDbMrkY9ErEKkrHmu3JyNM1hxmy
8rJl/yDID2n6vyxkh5QFcsvOdwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0
cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCB
ggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEu
Y29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNz
c29ubmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEeY2hyaXN0ZXIuaG9sbWJlcmdA
ZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEW
LGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQW
MBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUESOe8HpdLQz1aZdNgbOPnJlysTIw
HwYDVR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqG
SIb3DQEBCwUAA4ICAQBdN30YKQsw+ow1tjR6gBDuNpQagWRw7DSkYXg4ZE5k76jyXPOTa9VE
8x3MbNIbsyuVLYiVIN/lePTPi4qyt1CNBGPn4roUOuGeGQ7/dABYWNGmT0nKjjeXmqs9bt5z
CrxPfVS4xeEU7D64OJtD47f069jsG5E6qENdPmrjaKmTrllfM1S9HvWeco8PwBQC5ixpiXUq
t3Dyq3K0GmCgs1P7dJqup+Dt6UNF+DwgSZZeBjo3l+BtAv7StrvWdUQCqJpjUttIwzmtqsx2
NUWa1oSoqvUJ6XnJUZdT/UF390/6Uo4rnTeOWao9dkKQCaE3KvtCHBNZRv1MW0Ot3KSKnE+4
iZeUZgg1KAVQ5dhjjtXmjYoZMYoN4lE4OB2ae8LRbOrj0PE7Wvbuhs5eOyei7e6lYDHPzpLn
cfcLpQmOoHal11JqympoeJQENtQl2i1p2j5KmsfUQiqD1HQaGcpH9OKXEclLCOpQ/6zafNW3
nSYFBwADNpHMNiQXxcXKxiPCfiZa2UK5RRWohIz9kY8HXvX/1E2pvtOZoymiXJviR3g2BFvM
21+LIVu3dtoEWWxtD7MyDtOe1dEZTfxLUPMpQa66znWbEQ736mmv5n/z+Aaq7OidNuOIFfO2
HbE+LBHIWhKAy9Ttqa+RqpPONMkvz3kth+G4IOBaTYEPWWHLrqXe2zCCBsIwggSqoAMCAQIC
EFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25l
cmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcN
MjUxMDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV
BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4IC
DwAwggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs
0zfSTm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9
ZVbXILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvS
xlfpVdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eN
o4v2PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWq
g5t2H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4
TlG4rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1
MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYv
SBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaG
K5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoG
CCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25l
cmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVy
YS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNV
HSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRv
cnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8v
Y3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0G
A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYE
FBx7GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMS
MA0GCSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gV
LtDUJQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyo
EBHGvw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50Zk
BqYnnl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEO
rPwfixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1Ur
RIQ85AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKX
e4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNO
xdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaH
KWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyE
G/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDCCBTgwggMg
oAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl
bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEy
MDA1MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMM
FlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC
AQDCvusn8CGj82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1
gouuSLasANxldewqTV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/te
uuSPl2e+S46NZAdXOFVpNDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv41
4e1Qe6kwjRnTCY5oZ12/PJcYU7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1s
OTlzgBbIUrAjzeA+3N08R6C7NYrimGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1v
gPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdf
Y2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCDLrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2
WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt6
0H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKSL2LUP2lDfA3W/Fh1AYidWBZL3rqQ
/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8wPTAPBgNVHRMBAf8EBTADAQH/
MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7qhfoExIwDQYJKoZIhvcN
AQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA389ZoG5XcUkeudQXuZ
KoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyywqODAQDc19oRc
XOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr7cQZ5qtM
ETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65XI0G
SK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl
kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI
6wzWJoi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2H
dqkXlrfPDZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/
xFZT+mNl0PMcDhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjU
kL8Ws9nprFlhVMgcusrByuG5IEyPOpOJpaDMv9P2daR1lm1WMYIB8TCCAe0CAQEwWzBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu
ZGl2aWR1YWwgQ0EgdjMCEDeGIqZHLgK9f2Sm7MPtXjEwDQYJYIZIAWUDBAIBBQCgaTAvBgkq
hkiG9w0BCQQxIgQgvQk0G8Tv7cEukZWhOzXURUu4NkHgvMn3Q0+lvH7TLe8wGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwMjAyMTYyMTQzWjANBgkqhkiG
9w0BAQEFAASCAQBE0px7F7rr3FTAwH7NsX9aklc0rVST8/A40SgEetVUBvgENekpfWJxWRkv
9hHNanftv1yW6XaNhyQZeTdHUk4d1Sg0hhs42as+ecQ5GFJLDgp6VY3cNGdAxxf8ruxeW9M2
kBCyFoLT6lJPuaVscPe3hQAZpR9Hf+Fkv44W4Sa3WX7hUDfQ/jxkGccgGghARNEmbotcukfy
cgpnHOSDWB+N4IVXeHIrRUVdoI1WI88GbyA7NkYbQ/KBDIt4uZNb/xr9uBP/iGi5sveLTLK1
PvF5snPLbxQbv3lmW4KKwBCj2nN6G3Mcutt0Z6fHOOXNSySRn8HZhMxH4Zuws6tcWoSq

--B_3600440503_48608703--


From nobody Fri Feb  2 08:14:15 2018
Return-Path: 
X-Original-To: ice@ietf.org
Delivered-To: ice@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA7D712DA05; Fri,  2 Feb 2018 08:14:14 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: ice@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.71.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151758805480.31782.9509633211886540427@ietfa.amsl.com>
Date: Fri, 02 Feb 2018 08:14:14 -0800
Archived-At: 
Subject: [Ice] I-D Action: draft-ietf-ice-rfc5245bis-17.txt
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 02 Feb 2018 16:14:15 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interactive Connectivity Establishment WG of the IETF.

        Title           : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
        Authors         : Ari Keranen
                          Christer Holmberg
                          Jonathan Rosenberg
	Filename        : draft-ietf-ice-rfc5245bis-17.txt
	Pages           : 95
	Date            : 2018-02-02

Abstract:
   This document describes a protocol for Network Address Translator
   (NAT) traversal for UDP-based communication.  This protocol is called
   Interactive Connectivity Establishment (ICE).  ICE makes use of the
   Session Traversal Utilities for NAT (STUN) protocol and its
   extension, Traversal Using Relay NAT (TURN).

   This document obsoletes RFC 5245.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-17
https://datatracker.ietf.org/doc/html/draft-ietf-ice-rfc5245bis-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-rfc5245bis-17


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Feb  2 08:19:09 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D672A12DA23 for ; Fri,  2 Feb 2018 08:18:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXpJSPzbgCpB for ; Fri,  2 Feb 2018 08:18:53 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 E03C112DA28 for ; Fri,  2 Feb 2018 08:18:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517588327; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ABGCiz6H6gBAaCPrfDWhS4BFB1GHSfsg4+CtQn/voXw=; b=Qv6/VIdPRXFi1mvVlc5GpbZb8dJx4bIJworsxjNkVbyNzbkc09I2q3cEij1ia/Mf AP/WEkOOaS9cRf+0q2GqQGoRKS3iL/qUszSKLEx4ZaaooJzDqeu8B0fdaCv+d7jC YNN8ugTNVrgDjI4K+pgfSDosScOYM+bWvV/p9xDqi7M=;
X-AuditID: c1b4fb30-399ff70000004778-d4-5a748f67906d
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2B.5C.18296.76F847A5; Fri,  2 Feb 2018 17:18:47 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Fri, 2 Feb 2018 17:18:47 +0100
From: Christer Holmberg 
To: "ice@ietf.org" , "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" , "tsv-art@ietf.org" , "ops-dir@ietf.org" , "gen-art@ietf.org" ,  "secdir@ietf.org" 
Thread-Topic: Draft new version: rfc5245bis-17
Thread-Index: AQHTnEGAcUvoKBl4Z0eS6V6HGGyjQw==
Date: Fri, 2 Feb 2018 16:18:46 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.146]
Content-Type: multipart/alternative; boundary="_000_D69A5EC32A6C2christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7um56f0mUwe0rBhbHf/xht7j66jOL xbcLtRbPNs5nsehtWsJs8WHhQxaLWXsWsTiweyxZ8pMpgDGKyyYlNSezLLVI3y6BK2PCgfnM BTs5Ky7cvMDcwDiPo4uRk0NCwERiZtNhZhBbSOAwo8TyVuMuRi4gezGjRMfPM4xdjBwcbAIW Et3/tEHiIgLXmCQmLzzPAtIgLKAp8XXDF3YQW0RAT+LXwSOMMPbli//ZQHpZBFQkDnzhBQnz ClhLPJl1CKyVUUBM4vupNUwgNrOAuMStJ/OZIO4RkFiy5zwzhC0q8fLxP1YQWxRo5IYTt9kh 4koSPzZcYoHoTZBYcPI8I8R8QYmTM5+wTGAUmoVk7CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZ xj5z4DFUr7XE+Qn3mJDVLGDkWMUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGGMHt/w22MH4 8rnjIUYBDkYlHl7+npIoIdbEsuLK3EOMEhzMSiK823yBQrwpiZVVqUX58UWlOanFhxilOViU xHlPevJGCQmkJ5akZqemFqQWwWSZODilGhjnT5uw780DDrPe1ruqPA/0VP7FPG+4Ocu9Rr5z RmgDv+Pywk/r14d66j/0ubhCeEqGVGHkj+3bWmau1unaujugNm650/7H2Yr1bvfzbN8rX6/u L3pcULI4+VZl4yO+uCV/S+ZP/vx1/61I+8wkncQQ28Q+j8oT+bfDNT+kS0qfELlgc+n8CSUl luKMREMt5qLiRACNuKD3rQIAAA==
Archived-At: 
Subject: [Ice] Draft new version: rfc5245bis-17
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 02 Feb 2018 16:18:54 -0000

--_000_D69A5EC32A6C2christerholmbergericssoncom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Based on the gen-art, ops-dir, sec-dir and tsv-art directorate reviews, I h=
ave submitted a new version (-17) of draft-ietf-ice-rfc5245bis.

Thank You!

Regards,

Christer

--_000_D69A5EC32A6C2christerholmbergericssoncom_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi,







Based on the gen-art, ops-dir, sec-dir and tsv-art directorate reviews=
, I have submitted a new version (-17) of draft-ietf-ice-rfc5245bis.







Thank You!







Regards,







Christer




--_000_D69A5EC32A6C2christerholmbergericssoncom_--


From nobody Fri Feb  2 13:54:44 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F9C126C23 for ; Fri,  2 Feb 2018 13:54:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level: 
X-Spam-Status: No, score=-2.721 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=j7Og/Wda; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UFshSnZr
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 ZJSgD-9PaM_w for ; Fri,  2 Feb 2018 13:54:41 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43ABB1243FE for ; Fri,  2 Feb 2018 13:54:41 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id DFBC022936; Fri,  2 Feb 2018 16:54:25 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 02 Feb 2018 16:54:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=SH0WhW/2EICvgXlfAnRpVCi61cwnB5IEYWzpeE2gkOI=; b=j7Og/Wda Whd5oQYfT+D0aM6xgd8zXxrKKSB+TneX7vZYy2XTjFMVNo/LA//uETTOXVupGR6X N3r1GzjQvZSevpxw8VUEcdzJlcA9ppjIkgXhbv+Uo0wg8aw0qX0GR9jGND62UPvO UC69SEUGSZU8J+6X6YVJGKEpAUFKQpo9tAVBEecU5tWFQJwS+pLnJuNNmc1NuB0n xzc5yHPibdhJa39FeGQpCERivHUN+Qx9VTHKnQT0o28oe+g76YXoIgcjD7Yv9Ao3 aCkrHxbsDyWvAPe+rckrebVoe/CFxEiyyL4rWHe9Fo55obYS7jstoZqZPxcGu0bi qniTnEge8uqbBw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=SH0WhW/2EICvgXlfAnRpVCi61cwnB 5IEYWzpeE2gkOI=; b=UFshSnZrEnVkb0ucf1Tl/h/vr3OD+9tp2O0Ytb2lziBQ0 PtYrhFvTPk34YtqShpasnHsiyIDbsImI3Jo+vaPnAefnXPJ14S7c5V0e5EGuoybP xNSE0egq5D5Je1ewnU0Evv/2Z71bM5Pr4nJhREquhsjq+tesGvfxHN+4JbssHvVj kGKYdg+TSQVPitlJ6hYI+Zk6FmPaYW7NuhxGNLxdkSUEqMxKpkt/dWCzDs2D+DN7 Mne/L7ZF2I5ipuioFNzqN7cDYECdYnDXNOLh3TX4PBE6Cp7BczLe/M4iM/VSLL+b EhTT3ckewmZRgnvwUnfbiPsJUU5qJJh0vuq0MH3TQ==
X-ME-Sender: 
Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 6573724989; Fri,  2 Feb 2018 16:54:25 -0500 (EST)
From: Peter Saint-Andre 
References: <879BAF1F-8DC5-4850-A7CB-711EC85DE282@nostrum.com> <7d5ff628-df64-3bd5-6327-cfb0ce0fa2a5@stpeter.im>
To: "ice@ietf.org" 
Message-ID: 
Date: Fri, 2 Feb 2018 14:54:23 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <7d5ff628-df64-3bd5-6327-cfb0ce0fa2a5@stpeter.im>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QeM9rY7PabajB6ZTZoN39RpTQOTxvIKvP"
Archived-At: 
Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-trickle-16
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 02 Feb 2018 21:54:43 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--QeM9rY7PabajB6ZTZoN39RpTQOTxvIKvP
Content-Type: multipart/mixed; boundary="c7noFnrlpRrTuzxvmIerhYrOVUDf9jn4E";
 protected-headers="v1"
From: Peter Saint-Andre 
To: "ice@ietf.org" 
Message-ID: 
Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-trickle-16
References: <879BAF1F-8DC5-4850-A7CB-711EC85DE282@nostrum.com>
 <7d5ff628-df64-3bd5-6327-cfb0ce0fa2a5@stpeter.im>
In-Reply-To: <7d5ff628-df64-3bd5-6327-cfb0ce0fa2a5@stpeter.im>

--c7noFnrlpRrTuzxvmIerhYrOVUDf9jn4E
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Ben, if it's OK with you I will submit a revised I-D containing these fix=
es.

Peter

On 2/1/18 2:20 PM, Peter Saint-Andre wrote:
> On 1/31/18 10:31 PM, Ben Campbell wrote:
>> Hi,
>>
>> This is my AD evaluation of draft-ietf-ice-trickle-16.
>>
>> The document is general well written and easy to follow. I have a few
>> comments and questions I=E2=80=99d like to address prior to IETF LC.
>=20
> Thanks, Ben.
>=20
> BTW, given that draft-ietf-ice-rfc5245bis and
> draft-ietf-mmusic-trickle-ice-sip are already in IETF Last Call, I hope=

> that they will not be considered by the IESG apart from
> draft-ietf-ice-trickle. Concurrent review will help ensure that the
> specs are in sync.
>=20
>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=
=80=94=E2=80=94
>>
>> - section 3, 2nd to last paragraph:
>>
>> [Note: I already brought this up in a separate email, and Peter
>> suggested a fix. I=E2=80=99m including it here for completeness]
>>
>> This paragraph is written in terms of the SDP ice-options attribute.
>> It should talk about the generic ICE option described in section 10
>> of 5245bis.
>>
>> - 4, last sentence: =E2=80=9Cearly as possible=E2=80=9D seems a bit su=
bjective for
>> use with the SHOULD, especially since that will be very application
>> depended. I imagine developers trying to decide if they should send
>> an initial offer the second a user hovers over a contact (which may
>> or may not be a good idea.) Please consider restating this without
>> the 2119 SHOULD.
>=20
> OLD
>    the initiator SHOULD generate and transmit their initial ICE
>    description as early as possible, so that the remote party can start=

>    gathering and trickling candidates.
>=20
> NEW
>    the user experience is improved if the initiator generates and
>    transmits their initial ICE description as early as possible (thus
>    enabling the remote party to start gathering and trickling
>    candidates).
>=20
>> - 5, 2nd to last paragraph, last sentence: Should =E2=80=9Cfallback to=

>> [RFC3264]=E2=80=9D be =E2=80=9Cfallback to non-ICE processing rules=E2=
=80=9D?
>=20
> Yes, that's better.
>=20
>> -13, first sentence: "Either agent MAY convey subsequent candidate
>> information at any time allowed by the signaling protocol in use.=E2=80=
=9D
>>
>> I=E2=80=99m a little confused by this, since previous text said you MU=
ST NOT
>> keep trickling after sending end-of-candidates. From the context of
>> the section, I assume this is talking about future exchanges (e.g. a
>> new offer) , not trickling as a result of a previous change, but the
>> words seem ambiguous.
>=20
> This would be better:
>=20
>    Before conveying an end-of-candidates indication, either agent MAY
>    convey subsequent candidate information at any time allowed by the
>    signaling protocol in use.
>=20
>> -16, 2nd paragraph: "Therefore a candidate for a specific component
>> MUST NOT be conveyed prior to candidates for other components within
>> the same foundation.=E2=80=9D
>>
>> I=E2=80=99m confused by this sentence; it seems like a deadlock where =
no
>> component candidates can be conveyed first. Should =E2=80=9Cother comp=
onents=E2=80=9D
>> be =E2=80=9Cearlier components=E2=80=9D?
>=20
> Good catch. The term "component with a lower ID number" seems more
> accurate than "earlier components". I suggest:
>=20
>    Therefore candidates for a given component MUST NOT be conveyed prio=
r
>    to candidates for a component with a lower ID number within the same=

>    foundation.
>=20
>> -16, paragraph after the SDP example: This seems to be an explanation
>> of the example, not a normative statement. Please consider stating
>> without the 2119 keywords.
>=20
> s/MUST/would/g
>=20
>> -18: Please consider using the IESG (iesg@ietf.org) as the contact. I
>> know we=E2=80=99ve had individual contacts for these in the past, but =
the
>> iesg address is (hopefully) more stable than individual or WG
>> addresses.
>=20
> Agreed.
>=20
>> -19, 2nd paragraph:
>>
>> Stephen=E2=80=99s SecDir review[1] of 5245bis asked for a stronger sta=
tement
>> about the application=E2=80=99s ability to control control which netwo=
rk
>> interfaces are exposed in ICE candidates.. It may be that having such
>> a statement in 5245bis is enough, but don=E2=80=99t be surprised if it=
 comes
>> up in IETF LC or IESG review.
>>
>> [1]
>> https://mailarchive.ietf.org/arch/msg/ice/fyhuRfrMJqdnCJnE6MJ_0peMFsw
>=20
> Given that draft-ietf-ice-trickle merely provides a method for
> communicating ICE candidates incrementally instead of all at once, it
> seems to me that it does not have an impact on the permissions model
> behind exposing ICE candidates in the first place; thus I expect that
> the text being added to 5245bis is enough. But thanks for the heads-up.=

>=20
> Peter
>=20
>=20



--c7noFnrlpRrTuzxvmIerhYrOVUDf9jn4E--

--QeM9rY7PabajB6ZTZoN39RpTQOTxvIKvP
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAlp03g8ACgkQ6gakkSvF
ralmWw/9Em+okkws6i30BknH28Bm+SvrkkwFiRdcCARCWtY7gsADF6cZFnxGDgv7
ubFOKOMrCnomuqdZpbbIIbDuaX+j6S/JTptSQdhNvFzr7VQd6mGkGNv4MSyzQDQ9
y6VnCata1Tn/lK95A9Ds+9nWnAnez0Wfn0HvEgeg43ghLOujIs/AUC1+Jes+bQLi
LVxsURj4l9kcAnCn9rN76R6cRghwJntY1DPSiyECuO3Zn9VZjNIL2jJxiZi6Toge
ScfjViikwtDiLUVZ11ibTGKgAExMPRa/P70Dl6DqHpXu3OtdTTjNl9rpIwnt6cSK
IrAk98vng3eQ+VBM5KSZhGp7iCNw7bJGVzfNXJ8RltD/HdN70J2Zxe45alCY/Oy+
MnxyTWQGjX8Wctr902HVAumPMJFrd39Haz6Jee7Cf5WuH76LWq6YxAcjySfXg99Y
HUilOCe88slvLwy2598KWyPeWBA+XtdslEKyJd+uT4RrpgJYEnetHpJWzNxuVLoE
8GFFUhvcSP42QkRTsCI7RM6pWoSoxBkBFYD1K3tAmKRbEhh8nOmpGST2ntcOaA9N
Uz2X8lYpilbiQq3inaCq106IPTdLAyVSyAHMywd47JaYyUvisBkaTaNrKX1HIcU+
SLowBP8d80s5+NmAwu9ueO/a73VN4S3P8vivwo07vEiDLlBI1P8=
=4n7m
-----END PGP SIGNATURE-----

--QeM9rY7PabajB6ZTZoN39RpTQOTxvIKvP--


From nobody Fri Feb  2 14:01:36 2018
Return-Path: 
X-Original-To: ice@ietf.org
Delivered-To: ice@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A2F1204DA; Fri,  2 Feb 2018 14:01:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: ice@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.71.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151760889450.14592.15838718976846609035@ietfa.amsl.com>
Date: Fri, 02 Feb 2018 14:01:34 -0800
Archived-At: 
Subject: [Ice] I-D Action: draft-ietf-ice-trickle-16.txt
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 02 Feb 2018 22:01:34 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interactive Connectivity Establishment WG of the IETF.

        Title           : Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol
        Authors         : Emil Ivov
                          Eric Rescorla
                          Justin Uberti
                          Peter Saint-Andre
	Filename        : draft-ietf-ice-trickle-16.txt
	Pages           : 32
	Date            : 2018-02-02

Abstract:
   This document describes "Trickle ICE", an extension to the
   Interactive Connectivity Establishment (ICE) protocol that enables
   ICE agents to send and receive candidates incrementally rather than
   exchanging complete lists.  With such incremental provisioning, ICE
   agents can begin connectivity checks while they are still gathering
   candidates and considerably shorten the time necessary for ICE
   processing to complete.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ice-trickle-16
https://datatracker.ietf.org/doc/html/draft-ietf-ice-trickle-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-16


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Feb  6 06:36:27 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D35512E059 for ; Tue,  6 Feb 2018 06:36:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.319
X-Spam-Level: 
X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YlU8q9sgcNM for ; Tue,  6 Feb 2018 06:36:06 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 71B6012D7F5 for ; Tue,  6 Feb 2018 06:36:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517927757; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1RFPQqIZx4oCz+CyrbGLtT0yfJn7VuAXY67abStvzQE=; b=W74XBS3y+YXzYADxkHArYHoMRjnbuzdEEIPhcESXrnG78i/x08QdQ26VTIMJXK8X 0ZklTxMJUZagMqMrafjHo1rGshmw7WkGL9DwHmMRpSLTOkAjdvbZszgJjKJikxnq BCjrzrR+1TPq+T6WuRCIA47dzdeoWzRB1FjiK65oLhQ=;
X-AuditID: c1b4fb30-399ff70000004778-82-5a79bd4d481f
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6D.72.18296.D4DB97A5; Tue,  6 Feb 2018 15:35:57 +0100 (CET)
Received: from [100.94.51.8] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.66) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 6 Feb 2018 15:35:56 +0100
To: Christer Holmberg , "tsv-art@ietf.org" 
CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" 
References: <151731848710.27439.7061415423323921488@ietfa.amsl.com>  <1d6ab623-0076-2e75-0e99-6a24e55ee934@ericsson.com>      
From: Magnus Westerlund 
Message-ID: <729b73e6-d3a1-433a-df41-1262b89bcc19@ericsson.com>
Date: Tue, 6 Feb 2018 15:35:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050102080100000905020701"
X-Originating-IP: [153.88.183.153]
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2K7k67v3soog0WbRSyO//jDbvHtQq3F s43zWSxm7VnE4sDisWTJT6YAxigum5TUnMyy1CJ9uwSujIYfB5kLemcxV7T9fc7awHhiIVMX IyeHhICJRMvkK2xdjFwcQgKHGSXWvXrNCOGsZ5T4+HURaxcjB4ewgJdE/0ZjkAYRgXiJA88/ MoPUMAvMZJR4/fMlVMNjZolH/S2MIFVsAhYSN380soHYvAL2Ei3b7oLFWQRUJM79+skOYosK xEhM/biRFaJGUOLkzCcsIDangI3ElyUdYDXMAt2MEhffVILYQgLaEg1NHawQZytJXJ93nWUC o8AsJO2zkLRA2GES0zbfZIOwxSWavqxkhbDNJLq2djFC2NoSyxa+Zoaw1SRub7vKjiluLTHj 10GoOYoSU7ofQtWYSrw++hFqjpHEuz2N7AsYeVYxihanFiflphsZ6aUWZSYXF+fn6eWllmxi BMbfwS2/DXYwvnzueIhRgINRiYe3qbAySog1say4MvcQowrQnEcbVl9glGLJy89LVRLhDdoE lOZNSaysSi3Kjy8qzUktPsQozcGiJM570pM3SkggPbEkNTs1tSC1CCbLxMEp1cAYy9zA+0NQ /GxK8R8L1oauSO23Zm9Pt6okaUi9tXK47y9jevu635HpFgIz29YrTRHlyXpccMHhYol2ysmG E8z/Hs0QSDJ6/fHt94Nhiqdtio7ffpu3+q/bvtLFN+wv3BKY6ce7vym82djm80KXSWeSQ1YY dTQ2aBzfc0qJe77WpFsVv0X0rr5QYinOSDTUYi4qTgQAKLLQiscCAAA=
Archived-At: 
Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-rfc5245bis-16
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Feb 2018 14:36:11 -0000

--------------ms050102080100000905020701
Content-Type: multipart/alternative;
 boundary="------------9FCB7E032DF35808461677E0"
Content-Language: en-GB

This is a multi-part message in MIME format.
--------------9FCB7E032DF35808461677E0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

I have reviewed the submitted updated document.

 From my perspective, it resolves my issues. However, I think you need=20
to ensure that there are WG consensus on these changes.

Nit:

OLD:
IPv6 address from the local host can be preferred.

NEW:
IPv6 addresses from the local host can be preferred.

Cheers

Magnus

Den 2018-02-02 kl. 17:10, skrev Christer Holmberg:
> Hi,
>
> The text looks good to me.
>
> I will add it, and submit a new version of the draft, so that we can=20
> move forward.
>
> IF someone has issues with the text, we can always fix it as part of=20
> upcoming IESG review fixes.
>
> Regards,
>
> Christer
>
> From: Magnus Westerlund  >
> Date: Friday 2 February 2018 at 18:04
> To: Christer Holmberg  >, "tsv-art@ietf.org=20
> " >=

> Cc: "draft-ietf-ice-rfc5245bis.all@ietf.org=20
> "=20
>  >, IETF Discussion=20
> >, "ice@ietf.org=20
> " >
> Subject: Re: [Ice] Tsvart last call review of draft-ietf-ice-rfc5245bis=
-16
>
> Hi,
>
> On Christer's request I have written a text proposal for a security=20
> consideration addition regarding the ICMP message. From my=20
> perspective, WG input is needed into this issue!
>
> New paragraph:
>
>
> =C2=A0=C2=A0 Spoofed ICMP Hard Errors (Type 3, codes 2-4) can also be u=
sed to
> =C2=A0=C2=A0 create false invalid results. If an ICE agent implements a=
 response
> =C2=A0=C2=A0 to these ICMP errors, and the attacker is capable of gener=
ating an
> =C2=A0=C2=A0 ICMP message that is delivered to the agent sending the co=
nnectivity
> =C2=A0=C2=A0 check. The validation of the ICMP error message by the age=
nt is its
> =C2=A0=C2=A0 only defence. For Type 3 code=3D4 the outer IP header prov=
ides no
> =C2=A0=C2=A0 validation, unless the connectivity check was sent with DF=
=3D0.
> =C2=A0=C2=A0 For code 2 or 3, which are originated by the host, the
> =C2=A0=C2=A0 address is expected to be any of the remote agents host, r=
eflexive,=20
> or relay
> =C2=A0=C2=A0 candidates IP addresses. The ICMP message include the IP h=
eader and=20
> UDP
> =C2=A0=C2=A0 header of the message triggering the error. These fields a=
lso needs to
> =C2=A0=C2=A0 be validated. The IP destination and UDP destination port =
needs to=20
> match
> =C2=A0=C2=A0 either the targeted candidate address and port, or the can=
didates base
> =C2=A0=C2=A0 address. The source IP address and port can be any candida=
te for=20
> the same
> =C2=A0=C2=A0 base address of the agent sending the connectivity check. =
Thus any=20
> attacker
> =C2=A0=C2=A0 having access to the exchange of the candidates will have =
the=20
> necessary
> =C2=A0=C2=A0 information. Thus the validation is a weak defence, and th=
e sending of
> =C2=A0=C2=A0 spoofed ICMP attacks is possible also for off-path attacke=
rs from a=20
> node
> =C2=A0=C2=A0 in a network without source address validation.
>
> Intended to be added in Section 19.1=C2=A0 between two existing paragra=
phs=20
> as indicated below.
>
> .. exchange signaling is secured, the attacker will not have the
> =C2=A0=C2=A0 password and its response will be discarded.
>
> [The new paragraph]
>
> Forcing the fake valid result works in a similar way.=C2=A0 The agent .=
=2E.
>
>
> I hope this helps making it clear how relatively easy this attack can=20
> be performed, and why I think it is actually safer to ignore any ICMP=20
> errors for the connectivity checks.
>
>
>
>
> Den 2018-02-02 kl. 15:28, skrev Magnus Westerlund:
>> Hi,
>>
>> See responses inline
>>
>>
>> Den 2018-02-02 kl. 12:12, skrev Christer Holmberg:
>>>
>>> ---
>>>
>>>
>>>>>>>> E. Section 7.2.5.2.2. ICMP Error
>>>>>>>>
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 An ICE agent MAY support processi=
ng of ICMP errors for
>>>>>>>> connectivity
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 checks.=C2=A0 If the agent suppor=
ts processing of ICMP errors,=20
>>>>>>>> and
>>>>>>>> if a
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Binging request generates an ICMP=
 error, the agent SHOULD=20
>>>>>>>> set
>>>>>>>> the
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 state of the candidate pair to Fa=
iled.
>>>>>>>>
>>>>>>>> I am a bit worried by this blanket statement on ICMP errors. I=20
>>>>>>>> think
>>>>>>>> it
>>>>>>>> should
>>>>>>>> be clarified which ICMP message types that are relevant to=20
>>>>>>>> consider
>>>>>>>> as
>>>>>>>> errors?
>>>>>>>> I assume Type 3 (Destination Unreachable) but maybe not all=20
>>>>>>>> responde
>>>>>>>> codes as
>>>>>>>> Codes 4, 11,12 may be addressable in other ways, and likely=20
>>>>>>>> Type 11
>>>>>>>> (Time
>>>>>>>> exceeded) with response code 0, response code 1 is not a clear
>>>>>>>> indication
>>>>>>>> of a
>>>>>>>> non working path.
>>>>>>> This is from RFC 5245.
>>>>>>>
>>>>>>> I don=C2=B9t think the ICE WG should go through all different cod=
es and
>>>>>>> combinations, and determine what should be considered an error, a=
nd
>>>>>>> what
>>>>>>> not.
>>>>>>>
>>>>>>> If you can provide something (table, guidance etc), we are happy =
to
>>>>>>> include it. Otherwise I=C2=B9d like to keep it as it is, and let
>>>>>>> implementations deal with it, as at least I am not aware that thi=
s
>>>>>>> would
>>>>>>> Have caused issues in ICE deployments.
>>>>>> I think we there is a point to clarify that this applies to ICMP
>>>>>> messages indicating a non-usable path. So maybe it could be=20
>>>>>> rewritten
>>>>>> to
>>>>>> something like this:
>>>>>>
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 An ICE agent MAY support processing of IC=
MP messaging=20
>>>>>> indicating a
>>>>>> non-functioning path for connectivity
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 checks. ICMP messages of type 3 (Destinat=
ion Unreachable) are
>>>>>> indicators of a currently non-functioning path. However, the=20
>>>>>> issue can
>>>>>> be
>>>>>> temporary as it can depend on routing transients, this for example=

>>>>>> applies to codes 0, 1 and 5. Other messages that appear to indicat=
e
>>>>>> non-functioning path such as Type=3D11 (Time Exceeded) with code=3D=
0=20
>>>>>> (Time
>>>>>> to
>>>>>> Live exceeded in Transit) are not clear indicator as the IP packet=
s
>>>>>> potentially can reach the destination with a larger TTL value set =
at
>>>>>> transmission. Therefore, implementation needs to analyse the=20
>>>>>> different
>>>>>> ICMP messages types and codes for which it considers the path as
>>>>>> non-functioning. If the agent supports processing of ICMP errors, =

>>>>>> and
>>>>>> if a
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 Binging request generates an ICMP error, =
the agent SHOULD=20
>>>>>> set the
>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 state of the candidate pair to Failed.
>>>>>>
>>>>>>
>>>>>> What also is not addressed in this is the risk of denial of servic=
e
>>>>>> attacks using spoofed ICMP messages to shutdown certain connectivi=
ty
>>>>>> checks. The security considerations lack any discussion of this=20
>>>>>> issue.
>>>>>> If ICMP processing are retained, I think a recommendation about
>>>>>> validation is needed to avoid at least off path attackers from doi=
ng
>>>>>> these attacks easily. Unfortunately ICMP response will only=20
>>>>>> include the
>>>>>> IP/UDP header, thus no data from the STUN messages which would all=
ow
>>>>>> verification that the ICMP messages matches an actually sent check=
=2E
>>>>>>
>>>>>> It may be simplest to recommend against reacting to ICMP errors fr=
om
>>>>>> both the perspective that it is a risk for denial of service=20
>>>>>> attack, as
>>>>>> well as that it represents a risk terminating connectivity checks =

>>>>>> for a
>>>>>> transient issue. From my perspective I expect this to reduce the=20
>>>>>> number
>>>>>> of sent connectivity checks very little
>>>>> So, are you saying that an agent should simply ignore ICMP messages=
?
>>>> Yes, I think that may be the best. There are a bit to many corner=20
>>>> cases
>>>> and significant attack surface that getting all the details right ar=
e
>>>> significant work for a relatively small reduction in sent connection=

>>>> check messages.
>>> I am not an expert, but aren=E2=80=99t you going to get ICMP unreacha=
ble every
>>> time you try to contact a host candidate behind a NAT? Are you=20
>>> saying that
>>> the agent should ignore it, as the connectivity test will anyway=20
>>> timeout
>>> at some point?
>>
>> To my understanding NATs and firewalls do not send ICMP unreachable=20
>> because that would violates its role as a gateway rather than=20
>> end-host, also it want to avoid giving away information about its=20
>> internal side, and is a risk in creating a lot of load on the middlebo=
x.
>>
>>>
>>> Also, note that RFC 5398 (STUN) says:
>>>
>>> =C2=A0=C2=A0 "A STUN transaction over UDP is also considered failed i=
f there=20
>>> has been
>>> a
>>> =C2=A0=C2=A0=C2=A0 hard ICMP error [RFC1122].=E2=80=9D
>>>
>>> I am a little worried that people would have to use ICE-specific STUN=

>>> stacks if they are required to ignore ICMP errors.
>>>
>>> Couldn=E2=80=99t we simply use the existing text, and add a sentence =
about DoS
>>> attacks?
>>>
>>>
>>>
>>> OLD:
>>>
>>> =C2=A0 An ICE agent MAY support processing of ICMP errors for connect=
ivity
>>> =C2=A0 checks.=C2=A0 If the agent supports processing of ICMP errors,=
 and if a
>>> =C2=A0 Binging request generates an ICMP error, the agent SHOULD set =
the
>>> =C2=A0 state of the candidate pair to Failed.
>>>
>>>
>>>
>>> NEW:
>>>
>>> =C2=A0 An ICE agent MAY support processing of ICMP errors for connect=
ivity
>>> =C2=A0 checks. If the agent supports processing of ICMP errors, and i=
f a
>>> =C2=A0 Binging request generates an ICMP error, the agent SHOULD set =
the
>>> =C2=A0 state of the candidate pair to Failed. Implementers need to be=
 aware
>>> that ICMP errors can be used as a method for denial of service attack=
s
>>> when making a decision on how and if to process ICMP errors.
>>
>> I think you need to at least make it clear that it is "hard ICMP=20
>> errors". Which RFC 1122 defined as Type 3 with codes 2-4 for TCP. So, =

>> in that case one could just as well be explicit. I don't know if any=20
>> of the later defined codes are defined as hard errors.
>>
>> When it comes to the security consideration, I am actually quite=20
>> worried by this. To spoof ICMP so that they arrive back at the=20
>> client, you need to be able to send an ICMP packet back that matches=20
>> the NAT's binding. That requires that you now the connectivity checks =

>> intended target address+port, and the NAT's source address+port. With =

>> that information you can generate an ICMP message that will arrive at =

>> the agent as long as the attacker can route a packet to the NATs=20
>> address. And if you are in the local address domain to the agent, you =

>> can fake an ICMP error with only the information matching the peer=20
>> agents candidate.
>>
>> I think this issue do need security considerations text.
>>
>>> =3D=3D=3D=3D=3D=3D=3D
>>>
>>> Minor/Editorial Issues:
>>>
>>>
>>> ---
>>>
>>>>>>>> 9. Section 15:
>>>>>>>>
>>>>>>>> 4.57566E+18 (note that
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 an implementation would represent this =
as a 64-bit integer=20
>>>>>>>> so as
>>>>>>>> not
>>>>>>>> =C2=A0=C2=A0=C2=A0=C2=A0 to lose precision).
>>>>>>>>
>>>>>>>> Why the floating point representation? Priorities are integer=20
>>>>>>>> numbers
>>>>>>>> and
>>>>>>>> thus
>>>>>>>> should be presented as such in this example.
>>>>>>> This is from RFC 5245, and unfortunately I don=C2=B9t know.
>>>>>> Can you not just calculate the 64-bit integer and write it out?
>>>>> So, you want me to write 4575660000000000000?
>>>> No, I thought the pair priority will not be 0 for the lower 32 bits =

>>>> and
>>>> that there actually are overflow in this deduction. My=20
>>>> understanding is
>>>> that what should be written here is the calculation of:
>>>>
>>>> pair priority =3D 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
>>>>
>>>> Where G and D are the priority values for $L_PRIV_1 and $R_PUB_1.
>>>>
>>>> $L_PRIV_1 is L's host candidate, and stated to have a priorty of
>>>> 2130706431
>>>>
>>>> $R_PUB_1 is R's host candidate and stated to have a priorty of=20
>>>> 2130706431
>>>>
>>>> So G =3D 2130706431 and D=3D2130706431
>>>>
>>>> pair priority then becomes 2^32*2130706431 + 2*2130706431 + 0 =3D
>>>> 9151314442783293438
>>>>
>>>> Thus, I think the next two pair priorities in the example also=20
>>>> needs to
>>>> be fixed.
>>>>
>>>> The first pair priority for R is the same value as for L, as G and=20
>>>> D are
>>>> identical. But the next value will
>>>> be different. To my understanding L will be controlling, i.e. L's
>>>> candidate will be G
>>>>
>>>> G=3D1694498815
>>>> D=3D 2130706431
>>>>
>>>> Pair priority =3D 2^32*1694498815+2*2130706431 + 0 =3D 7277816997797=
167102
>>> Please provide text for the section (or, at least the modified=20
>>> paragraphs)
>>> :)
>>
>> Fine, I can put in the numbers in the right place. But please check=20
>> my calculations:
>>
>> OLD:
>>
>> =C2=A0=C2=A0 Agents L and R both pair up the candidates.=C2=A0 They bo=
th initially have
>> =C2=A0=C2=A0 two pairs.=C2=A0 However, agent L will prune the pair con=
taining its
>> =C2=A0=C2=A0 server reflexive candidate, resulting in just one.=C2=A0 =
At agent L, this
>> =C2=A0=C2=A0 pair has a local candidate of $L_PRIV_1 and remote candid=
ate of
>> =C2=A0=C2=A0 $R_PUB_1, and has a candidate pair priority of 4.57566E+1=
8 (note that
>> =C2=A0=C2=A0 an implementation would represent this as a 64-bit intege=
r so as not
>> =C2=A0=C2=A0 to lose precision).=C2=A0 At agent R, there are two pairs=
=2E The highest
>> =C2=A0=C2=A0 priority has a local candidate of $R_PUB_1 and remote can=
didate of
>> =C2=A0=C2=A0 $L_PRIV_1 and has a priority of 4.57566E+18, and the seco=
nd has a
>> =C2=A0=C2=A0 local candidate of $R_PUB_1 and remote candidate of $NAT_=
PUB_1 and
>> =C2=A0=C2=A0 priority 3.63891E+18.
>>
>> NEW:
>>
>> =C2=A0=C2=A0 Agents L and R both pair up the candidates.=C2=A0 They bo=
th initially have
>> =C2=A0=C2=A0 two pairs.=C2=A0 However, agent L will prune the pair con=
taining its
>> =C2=A0=C2=A0 server reflexive candidate, resulting in just one.=C2=A0 =
At agent L, this
>> =C2=A0=C2=A0 pair has a local candidate of $L_PRIV_1 and remote candid=
ate of
>> =C2=A0=C2=A0 $R_PUB_1, and has a candidate pair priority of 9151314442=
783293438.
>> =C2=A0=C2=A0 At agent R, there are two pairs.=C2=A0 The highest
>> =C2=A0=C2=A0 priority has a local candidate of $R_PUB_1 and remote can=
didate of
>> =C2=A0=C2=A0 $L_PRIV_1 and has a priority of 9151314442783293438, and =
the=20
>> second has a
>> =C2=A0=C2=A0 local candidate of $R_PUB_1 and remote candidate of $NAT_=
PUB_1 and
>> =C2=A0=C2=A0 priority 7277816997797167102.
>>
>>
>> Cheers
>>
>> Magnus Westerlund
>>
>> ----------------------------------------------------------------------=

>> Media Technologies, Ericsson Research
>> ----------------------------------------------------------------------=

>> Ericsson AB=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=C2=A0=C2=A0=C2=A0 | Phone=C2=A0 +46 10 7148287
>> Torshamnsgatan 23=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>> ----------------------------------------------------------------------=

>>
>>
>>
>>
>> _______________________________________________
>> Ice mailing list
>> Ice@ietf.orghttps://www.ietf.org/mailman/listinfo/ice
>
> --=20
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Media Technologies, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto:magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------

--=20

Magnus Westerlund

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


--------------9FCB7E032DF35808461677E0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
Hi,

    I have reviewed the submitted updated document. 

    

    From my perspective, it resolves my issues. However, I think you
    need to ensure that there are WG consensus on these changes. 

    

    Nit:

    

    OLD:

    IPv6 address from the local host can be
      preferred. 

    

    NEW: 

    IPv6 addresses
      from the local host can be preferred. 

    

    Cheers

    

    Magnus

    

    
Den 2018-02-02 kl. 17:10, skrev
      Christer Holmberg:

    

    

      
Hi,

      


      

      
The text looks good to me.

      


      

      
I will add it, and submit a new version of the draft, so that
        we can move forward.

      


      

      
IF someone has issues with the text, we can always fix it as
        part of upcoming IESG review fixes.

      


      

      
Regards,

      


      

      
Christer

      


      

      
        
From:  Magnus Westerlund
          <magnus.westerlund@ericsson.com&g=
t;

          Date:  Friday 2
          February 2018 at 18:04

          To:  Christer Holmberg
          <christer.holmberg@ericsson.com&g=
t;,
          "t=
sv-art@ietf.org"
          <tsv-art@ietf.org>

          Cc:  "draft-ietf-ice-rfc5245bis.all@ietf.o=
rg"
          <draft-ietf-ice-rfc5245bis.all@ietf.o=
rg>,
          IETF Discussion <ietf@ietf.org>, "ice@iet=
f.org"
          <ic=
e@ietf.org>

          Subject:  Re: [Ice]
          Tsvart last call review of draft-ietf-ice-rfc5245bis-16

        

        


        

        

          
          

            
Hi,

            
On Christer's request I have written a text proposal for
              a security consideration addition regarding the ICMP
              message. From my perspective, WG input is needed into this
              issue!

            

            
New paragraph:

            

            


              =C2=A0=C2=A0 Spoofed ICMP Hard Errors (Type 3, codes 2-4) c=
an also
              be used to 

              =C2=A0=C2=A0 create false invalid results. If an ICE agent
              implements a response 

              =C2=A0=C2=A0 to these ICMP errors, and the attacker is capa=
ble of
              generating an 

              =C2=A0=C2=A0 ICMP message that is delivered to the agent se=
nding the
              connectivity 

              =C2=A0=C2=A0 check. The validation of the ICMP error messag=
e by the
              agent is its 

              =C2=A0=C2=A0 only defence. For Type 3 code=3D4 the outer IP=
 header
              provides no 

              =C2=A0=C2=A0 validation, unless the connectivity check was =
sent with
              DF=3D0. 

              =C2=A0=C2=A0 For code 2 or 3, which are originated by the h=
ost, the
              

              =C2=A0=C2=A0 address is expected to be any of the remote ag=
ents
              host, reflexive, or relay 

              =C2=A0=C2=A0 candidates IP addresses. The ICMP message incl=
ude the
              IP header and UDP 

              =C2=A0=C2=A0 header of the message triggering the error. Th=
ese
              fields also needs to 

              =C2=A0=C2=A0 be validated. The IP destination and UDP desti=
nation
              port needs to match 

              =C2=A0=C2=A0 either the targeted candidate address and port=
, or the
              candidates base 

              =C2=A0=C2=A0 address. The source IP address and port can be=
 any
              candidate for the same 

              =C2=A0=C2=A0 base address of the agent sending the connecti=
vity
              check. Thus any attacker 

              =C2=A0=C2=A0 having access to the exchange of the candidate=
s will
              have the necessary 

              =C2=A0=C2=A0 information. Thus the validation is a weak def=
ence, and
              the sending of 

              =C2=A0=C2=A0 spoofed ICMP attacks is possible also for off-=
path
              attackers from a node 

              =C2=A0=C2=A0 in a network without source address validation=
=2E 

              

              Intended to be added in Section 19.1=C2=A0 between two exis=
ting
              paragraphs as indicated below.

              

              .. exchange signaling is secured, the attacker will not
              have the 

              =C2=A0=C2=A0 password and its response will be discarded. <=
br>
              

              [The new paragraph] 

              

              Forcing the fake valid result works in a similar way.=C2=A0=
 The
              agent ... 

            


            

            
I hope this helps making it clear how relatively easy
              this attack can be performed, and why I think it is
              actually safer to ignore any ICMP errors for the
              connectivity checks. 

            

            


            

            


            

            

            
Den 2018-02-02 kl. 15:28, skre=
v
              Magnus Westerlund:

            

            
Hi,
              

              

              See responses inline 

              

              

              Den 2018-02-02 kl. 12:12, skrev Christer Holmberg: 

              
 

                --- 

                

                

                

                  

                    

                      

                        
E. Section 7.2.5.2.2.=C2=
=A0
                          ICMP Error 

                          

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 An ICE agent MAY=
 support processing of
                          ICMP errors for 

                          connectivity 

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 checks.=C2=A0 If=
 the agent supports
                          processing of ICMP errors, and 

                          if a 

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Binging request =
generates an ICMP error,
                          the agent SHOULD set 

                          the 

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 state of the can=
didate pair to Failed. 

                          

                          I am a bit worried by this blanket statement
                          on ICMP errors. I think 

                          it 

                          should 

                          be clarified which ICMP message types that are
                          relevant to consider 

                          as 

                          errors? 

                          I assume Type 3 (Destination Unreachable) but
                          maybe not all responde 

                          codes as 

                          Codes 4, 11,12 may be addressable in other
                          ways, and likely Type 11 

                          (Time 

                          exceeded) with response code 0, response code
                          1 is not a clear 

                          indication 

                          of a 

                          non working path. 

                        

                        This is from RFC 5245. 

                        

                        I don=C2=B9t think the ICE WG should go through a=
ll
                        different codes and 

                        combinations, and determine what should be
                        considered an error, and 

                        what 

                        not. 

                        

                        If you can provide something (table, guidance
                        etc), we are happy to 

                        include it. Otherwise I=C2=B9d like to keep it as=
 it
                        is, and let 

                        implementations deal with it, as at least I am
                        not aware that this 

                        would 

                        Have caused issues in ICE deployments. 

                      

                      I think we there is a point to clarify that this
                      applies to ICMP 

                      messages indicating a non-usable path. So maybe it
                      could be rewritten 

                      to 

                      something like this: 

                      

                      =C2=A0=C2=A0=C2=A0=C2=A0 An ICE agent MAY support p=
rocessing of ICMP
                      messaging indicating a 

                      non-functioning path for connectivity 

                      =C2=A0=C2=A0=C2=A0=C2=A0 checks. ICMP messages of t=
ype 3 (Destination
                      Unreachable) are 

                      indicators of a currently non-functioning path.
                      However, the issue can 

                      be 

                      temporary as it can depend on routing transients,
                      this for example 

                      applies to codes 0, 1 and 5. Other messages that
                      appear to indicate 

                      non-functioning path such as Type=3D11 (Time
                      Exceeded) with code=3D0 (Time 

                      to 

                      Live exceeded in Transit) are not clear indicator
                      as the IP packets 

                      potentially can reach the destination with a
                      larger TTL value set at 

                      transmission. Therefore, implementation needs to
                      analyse the different 

                      ICMP messages types and codes for which it
                      considers the path as 

                      non-functioning. If the agent supports processing
                      of ICMP errors, and 

                      if a 

                      =C2=A0=C2=A0=C2=A0=C2=A0 Binging request generates =
an ICMP error, the
                      agent SHOULD set the 

                      =C2=A0=C2=A0=C2=A0=C2=A0 state of the candidate pai=
r to Failed. 

                      

                      

                      What also is not addressed in this is the risk of
                      denial of service 

                      attacks using spoofed ICMP messages to shutdown
                      certain connectivity 

                      checks. The security considerations lack any
                      discussion of this issue. 

                      If ICMP processing are retained, I think a
                      recommendation about 

                      validation is needed to avoid at least off path
                      attackers from doing 

                      these attacks easily. Unfortunately ICMP response
                      will only include the 

                      IP/UDP header, thus no data from the STUN messages
                      which would allow 

                      verification that the ICMP messages matches an
                      actually sent check. 

                      

                      It may be simplest to recommend against reacting
                      to ICMP errors from 

                      both the perspective that it is a risk for denial
                      of service attack, as 

                      well as that it represents a risk terminating
                      connectivity checks for a 

                      transient issue. From my perspective I expect this
                      to reduce the number 

                      of sent connectivity checks very little 

                    

                    So, are you saying that an agent should simply
                    ignore ICMP messages? 

                  

                  Yes, I think that may be the best. There are a bit to
                  many corner cases 

                  and significant attack surface that getting all the
                  details right are 

                  significant work for a relatively small reduction in
                  sent connection 

                  check messages. 

                

                I am not an expert, but aren=E2=80=99t you going to get I=
CMP
                unreachable every 

                time you try to contact a host candidate behind a NAT?
                Are you saying that 

                the agent should ignore it, as the connectivity test
                will anyway timeout 

                at some point? 

              

              

              To my understanding NATs and firewalls do not send ICMP
              unreachable because that would violates its role as a
              gateway rather than end-host, also it want to avoid giving
              away information about its internal side, and is a risk in
              creating a lot of load on the middlebox. 

              

              
 

                Also, note that RFC 5398 (STUN) says: 

                

                =C2=A0=C2=A0 "A STUN transaction over UDP is also conside=
red
                failed if there has been 

                a 

                =C2=A0=C2=A0=C2=A0 hard ICMP error [RFC1122].=E2=80=9D 
                

                I am a little worried that people would have to use
                ICE-specific STUN 

                stacks if they are required to ignore ICMP errors. 

                

                Couldn=E2=80=99t we simply use the existing text, and add=
 a
                sentence about DoS 

                attacks? 

                

                

                

                OLD: 

                

                =C2=A0 An ICE agent MAY support processing of ICMP errors=
 for
                connectivity 

                =C2=A0 checks.=C2=A0 If the agent supports processing of =
ICMP
                errors, and if a 

                =C2=A0 Binging request generates an ICMP error, the agent=

                SHOULD set the 

                =C2=A0 state of the candidate pair to Failed. 

                

                

                

                NEW: 

                

                =C2=A0 An ICE agent MAY support processing of ICMP errors=
 for
                connectivity 

                =C2=A0 checks. If the agent supports processing of ICMP
                errors, and if a 

                =C2=A0 Binging request generates an ICMP error, the agent=

                SHOULD set the 

                =C2=A0 state of the candidate pair to Failed. Implementer=
s
                need to be aware 

                that ICMP errors can be used as a method for denial of
                service attacks 

                when making a decision on how and if to process ICMP
                errors. 

              

              

              I think you need to at least make it clear that it is
              "hard ICMP errors". Which RFC 1122 defined as Type 3 with
              codes 2-4 for TCP. So, in that case one could just as well
              be explicit. I don't know if any of the later defined
              codes are defined as hard errors. 

              

              When it comes to the security consideration, I am actually
              quite worried by this. To spoof ICMP so that they arrive
              back at the client, you need to be able to send an ICMP
              packet back that matches the NAT's binding. That requires
              that you now the connectivity checks intended target
              address+port, and the NAT's source address+port. With that
              information you can generate an ICMP message that will
              arrive at the agent as long as the attacker can route a
              packet to the NATs address. And if you are in the local
              address domain to the agent, you can fake an ICMP error
              with only the information matching the peer agents
              candidate. 

              

              I think this issue do need security considerations text. 
              

              
=3D=3D=3D=3D=3D=3D=3D 

                

                Minor/Editorial Issues: 

                

                =C2=A0 

                --- 

                

                

                  

                    

                      

                        
9. Section 15: 

                          

                          4.57566E+18 (note that 

                          =C2=A0=C2=A0=C2=A0=C2=A0 an implementation woul=
d represent this as
                          a 64-bit integer so as 

                          not 

                          =C2=A0=C2=A0=C2=A0=C2=A0 to lose precision). 
                          

                          Why the floating point representation?
                          Priorities are integer numbers 

                          and 

                          thus 

                          should be presented as such in this example. 
                        

                        This is from RFC 5245, and unfortunately I don=C2=
=B9t
                        know. 

                      

                      Can you not just calculate the 64-bit integer and
                      write it out? 

                    

                    So, you want me to write 4575660000000000000? 

                  

                  No, I thought the pair priority will not be 0 for the
                  lower 32 bits and 

                  that there actually are overflow in this deduction. My
                  understanding is 

                  that what should be written here is the calculation
                  of: 

                  

                  pair priority =3D 2^32*MIN(G,D) + 2*MAX(G,D) +
                  (G>D?1:0) 

                  

                  Where G and D are the priority values for $L_PRIV_1
                  and $R_PUB_1. 

                  

                  $L_PRIV_1 is L's host candidate, and stated to have a
                  priorty of 

                  2130706431 

                  

                  $R_PUB_1 is R's host candidate and stated to have a
                  priorty of 2130706431 

                  

                  So G =3D 2130706431 and D=3D2130706431 

                  

                  pair priority then becomes 2^32*2130706431 +
                  2*2130706431 + 0 =3D 

                  9151314442783293438 

                  

                  Thus, I think the next two pair priorities in the
                  example also needs to 

                  be fixed. 

                  

                  The first pair priority for R is the same value as for
                  L, as G and D are 

                  identical. But the next value will 

                  be different. To my understanding L will be
                  controlling, i.e. L's 

                  candidate will be G 

                  

                  G=3D1694498815 

                  D=3D 2130706431 

                  

                  Pair priority =3D 2^32*1694498815+2*2130706431 + 0 =3D
                  7277816997797167102 

                

                Please provide text for the section (or, at least the
                modified paragraphs) 

                :) 

              

              

              Fine, I can put in the numbers in the right place. But
              please check my calculations: 

              

              OLD: 

              

              =C2=A0=C2=A0 Agents L and R both pair up the candidates.=C2=
=A0 They both
              initially have 

              =C2=A0=C2=A0 two pairs.=C2=A0 However, agent L will prune t=
he pair
              containing its 

              =C2=A0=C2=A0 server reflexive candidate, resulting in just =
one.=C2=A0 At
              agent L, this 

              =C2=A0=C2=A0 pair has a local candidate of $L_PRIV_1 and re=
mote
              candidate of 

              =C2=A0=C2=A0 $R_PUB_1, and has a candidate pair priority of=

              4.57566E+18 (note that 

              =C2=A0=C2=A0 an implementation would represent this as a 64=
-bit
              integer so as not 

              =C2=A0=C2=A0 to lose precision).=C2=A0 At agent R, there ar=
e two pairs.=C2=A0
              The highest 

              =C2=A0=C2=A0 priority has a local candidate of $R_PUB_1 and=
 remote
              candidate of 

              =C2=A0=C2=A0 $L_PRIV_1 and has a priority of 4.57566E+18, a=
nd the
              second has a 

              =C2=A0=C2=A0 local candidate of $R_PUB_1 and remote candida=
te of
              $NAT_PUB_1 and 

              =C2=A0=C2=A0 priority 3.63891E+18. 

              

              NEW: 

              

              =C2=A0=C2=A0 Agents L and R both pair up the candidates.=C2=
=A0 They both
              initially have 

              =C2=A0=C2=A0 two pairs.=C2=A0 However, agent L will prune t=
he pair
              containing its 

              =C2=A0=C2=A0 server reflexive candidate, resulting in just =
one.=C2=A0 At
              agent L, this 

              =C2=A0=C2=A0 pair has a local candidate of $L_PRIV_1 and re=
mote
              candidate of 

              =C2=A0=C2=A0 $R_PUB_1, and has a candidate pair priority of=

              9151314442783293438. 

              =C2=A0=C2=A0 At agent R, there are two pairs.=C2=A0 The hig=
hest 

              =C2=A0=C2=A0 priority has a local candidate of $R_PUB_1 and=
 remote
              candidate of 

              =C2=A0=C2=A0 $L_PRIV_1 and has a priority of 91513144427832=
93438,
              and the second has a 

              =C2=A0=C2=A0 local candidate of $R_PUB_1 and remote candida=
te of
              $NAT_PUB_1 and 

              =C2=A0=C2=A0 priority 7277816997797167102. 

              

              

              Cheers 

              

              Magnus Westerlund 

              

---------------------------------------------------------------------- 
              Media Technologies, Ericsson Research 

---------------------------------------------------------------------- 
              Ericsson AB=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=C2=A0=C2=A0=C2=A0 | Phone=C2=A0 +46 10 714=
8287 

              Torshamnsgatan 23=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 | Mobile +46 73 0949079 

              SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
              

---------------------------------------------------------------------- 
              

              

              

              

              

              
____________________________________________=
___
Ice mailing list
Ice@ietf.org=
https://www.ietf.org/mailman/listinfo/ice

            

            

            
--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
          

        

      
    

    

    
--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Media Technologies, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@erics=
son.com
----------------------------------------------------------------------
  


--------------9FCB7E032DF35808461677E0--

--------------ms050102080100000905020701
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME-kryptografisk signatur

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DNEwggYHMIID76ADAgECAhALRm3NcHtuMGWutmt5cXntMA0GCSqGSIb3DQEBCwUAMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MzAeFw0xNzEyMTUwNzIyMjNaFw0yMDEyMTUwNzIyMjJaMHAxETAPBgNV
BAoMCEVyaWNzc29uMRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJ
ARYebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsKlHZvB3TsmLEDtPSiFFKAh73S2wApt+
laqg5eXTqonqnzT9ykEGL2dx9mBT+2WZiIKxo4w2sisVl3EEYTqXTkctpur7cN29gLC8F3tJ
HGI2sUVpO9AwpVrN+UuHEVetHt7hdxW9uYd0LJJ8TP6/wGkIfAFaZxlZUn79O2eHElfih1iV
IiTZXLcEe1rBJtzhUNRHWgOm2vQlDJ4sCpigGFq5w+XSRviEQMkQZRvw1CQmb35QS/C/T36o
gzIRHDuAdkoSaiUOY/S2dLp4HkwvOOg+tADpaHkrbdmdnjKGrYSnJigmxw14pJugxL/Vb2Ee
VcgpAfVVst7Lm4POPRI8+wIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDov
L2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCBggYI
KwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29t
MEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29u
bmxpbmRpdmlkdWFsY2F2My5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJp
Y3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0
dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQG
CCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU5ivuhpU51W4UhBDBWwf8XsU837YwHwYD
VR0jBBgwFoAUHHsZnpecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3
DQEBCwUAA4ICAQBn0FKukg00UN/c/ESpxSIaYTrsd8liHHMu5rLpOBNOacpGNBMGNgUDDt4Q
ihhoQR3cvhYXCrAM59NTvw0HNlgqHZoEeVY7YnJJYnJXDCLUfkK5Dn28E3QrzykkF6giUOXD
yF9mhWYbSAkJyx0Yj0Xc8en3wYNyoFYEqjlKtZrdV0pcgFzEeXVLS8DWrzSy7+KfUtDOEiM6
H3zO3nsq++KBmsOiSKkWn4oYERZg5KElEAHis9av+3KIaEPnOAt8QRWRpFfGZ4d89F16qFvE
lup5n7l864FqxnC2friDo4hLQY6ENaOaYIihXhbl2UYxAGDk89aJm/S5pYyq7wzm+KK3IcUl
60rmc8SJlt6QXKw0wXEOE1MubauYKMsad2s8jD+rEkXp+agTRl+sezWaRxHBpxuUKDd6MhwD
ig3SZi1qP7D/Ds4V+JLIjjUJc25l9tvMGC9+lqI0P+vMI3Zyrou0NNfb55uLQaq18O+7BZ8K
v7jvFdxYyUgbxQ0SPEiyhylcLHAmJeLCQaiZHmCREBkCLKSf0O4lE2TrVzdOD38wjzuQ27U3
UddVCD9EQ3tF7o6EVhpxJJUlB6xe/2UWwy4Zla71dKLUhakdVrN5abzxqFWvzOAT9nBa2HzY
VBtpbcu6KGh72YJ+M79fa9iIkcQCgUnw3gIAeWd//n4YbY2QhDCCBsIwggSqoAMCAQICEFO4
foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx
HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUx
MDI3MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM
HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAw
ggIKAoICAQDs8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfS
Tm+7meisbhkqUXkL7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbX
ILlLhRummTdDdxhVW4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfp
VdiCulPTlmsmV2RSBSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2
PUmE0rhu+Zs0nujnwhljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2
H/E0XY1LwJez89W07nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4
rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX
1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjv
Zibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FN
VSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoGCCsG
AQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEu
Y29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5j
b20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAE
TjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnku
dHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3Js
LTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1Ud
JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7
GZ6XnHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0G
CSqGSIb3DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDU
JQEPRs5QtaZiObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHG
vw5RY6vRlZrj0uKvdASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYn
nl2t3D3oBX2NZCQysshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwf
ixWms+C8sF0r9qN1uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ8
5AKjqzBnLSsjRGgbMgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4Hd
Dc1P+UMYm16m2L6LkIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOE
EHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd
3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/du
jp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDGCAzswggM3AgEB
MFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzAhALRm3NcHtuMGWutmt5cXntMA0GCWCGSAFlAwQCAQUA
oIIBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xODAyMDYx
NDM1NTZaMC8GCSqGSIb3DQEJBDEiBCB5NNgfX/ZrKOGfGSucdyp3CuDJw7EcsHpcciGQ5lT7
HjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjEl
MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQC0ZtzXB7bjBlrrZreXF5
7TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMGwGCyqGSIb3DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nz
b24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEAtGbc1we24wZa62
a3lxee0wDQYJKoZIhvcNAQEBBQAEggEAnS1NjXaJ8RVOkdWNliw1kWCDEajV2/5rMGczTVfD
0OtMZz4d78Rv13krIGXYxwIh/vP94zHkx7OUJlSu+QCw8Y06lY5PLCCAhLdaLcJXd7cuQWjD
d9PoHQwwvOExD/nxSKSf9Jh8malH681EAszHBEzxnPGjNE+EuI1B1cJZYCKcLLJ4mWTHjAMQ
HbLRIjcR3pUUcXE/ERBP3x3xZms/5u5ulu2EL9Njq0o3ijbNEafX8wa1ZfabA3NLBMTi1zKp
+jjLttMNVS9vwTdTuQNKE3s3MRI8oZvBrlKmj32maDaXFYOcS7PF5+JO6VckwWWj9Iki7bo8
K0TZQGJ3VizMxAAAAAAAAA==
--------------ms050102080100000905020701--


From nobody Wed Feb  7 08:11:03 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2302D12E03A for ; Wed,  7 Feb 2018 08:11:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ryywRDRzQeWP for ; Wed,  7 Feb 2018 08:10:57 -0800 (PST)
Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 5189E12DFDB for ; Wed,  7 Feb 2018 08:10:57 -0800 (PST)
Received: by mail-wr0-x229.google.com with SMTP id v31so1606092wrc.11 for ; Wed, 07 Feb 2018 08:10:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YAFyTKUEolHdgba9Mwh8WsuqPLcf5n8N60h/J0unO7Y=; b=E0ltah2MkrWP85/kasWVfD1nggzI4cHl8S4C562dGXDAUgmgWy3H3R2H9FPAPltDGG He86C+3c7/5VRM/i7x+My2cZFCP4ss/5ledS+OHYIFbjP5YhcF4hvhayrfO/xRpSoxjT 6OvklFe+QVMqwx0sg5JoFD2rp0w0+c4gVVPjAZFj+d2Hb5Z/thhICEYBQtVkHUsIPSrk aZSxBPdUkMR1NqjSEhpBJegFps7+QZZeoJMJUJG2NlhUFf/N/YV/XK3hKF8TqQQ3OHi9 Vp3X0kAoeoxmx2IZE6esIe02zY21lRYsjWrNeABPcO2l0LTfd63aytl2HINcA0KMX5/t 0GBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YAFyTKUEolHdgba9Mwh8WsuqPLcf5n8N60h/J0unO7Y=; b=CAIFk1IZi9oT/7Ix22iDWOpPGmaHwTJE+cxA1kzd3RzekEdE3ptypctyF8Lizhn0Xq FDByefiBuhYxE2W/tTxUKoQhB4CpOn4vmkQQL8D6kYkOCblFgYOnOrXTJzB0OK/im2bj U9FlnYjQXwijXRpw+qFlcYpzzmLVnr7mKC9jNUxUAvGBTYEQKX2dQA1zkCJSmAvGKvaD q7Ak0jm4s7I+71FnNofshPR5iELWFVf2xetdK+EY2qi/dQt0auaEmU1nuCDaV7fWUUXp zh6Pd3RNjWwFi/soxmWJ9hcDzfWji01KLfxtmobRcI7G/SinB4kZSUacyTvXnWdEUr9S kK3w==
X-Gm-Message-State: APf1xPAzrzn4wE7I0K0Rm0HMc/uYUmPSKKY76RxMisScmmIAHpsOAYTy 6hHY2XBmjuyjZ0bPgnGQpfEhXbom6V8yk6FyMlZIxA==
X-Google-Smtp-Source: AH8x226rdgcMuj4I4AGw3YwOKHP3U44mrmbJKfyPe/ni0pSVNGdQ3LT49cBpVzvcWH7Nm7fKZhjM4dXdxILlkWjSXRo=
X-Received: by 10.223.168.120 with SMTP id l111mr6516180wrc.118.1518019855507;  Wed, 07 Feb 2018 08:10:55 -0800 (PST)
MIME-Version: 1.0
References: <151751209219.24384.852480970834699544.idtracker@ietfa.amsl.com>
In-Reply-To: <151751209219.24384.852480970834699544.idtracker@ietfa.amsl.com>
From: Peter Thatcher 
Date: Wed, 07 Feb 2018 16:10:43 +0000
Message-ID: 
To: IETF Meeting Session Request Tool 
Cc: ben@nostrum.com, ice-chairs@ietf.org, pthatcher@webrtc.org, ice@ietf.org
Content-Type: multipart/alternative; boundary="f403045d5cee40a7510564a18a1b"
Archived-At: 
Subject: Re: [Ice] ice - New Meeting Session Request for IETF 101
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Feb 2018 16:11:00 -0000

--f403045d5cee40a7510564a18a1b
Content-Type: text/plain; charset="UTF-8"

FYI, this was requested just in case there are things that need to be
discussed regarding reviews of ICEbis.  But if it turns out there isn't any
need, we'll cancel it.

On Thu, Feb 1, 2018 at 11:08 AM IETF Meeting Session Request Tool <
session-request@ietf.org> wrote:

>
>
> A new meeting session request has just been submitted by Peter Thatcher, a
> Chair of the ice working group.
>
>
> ---------------------------------------------------------
> Working Group Name: Interactive Connectivity Establishment
> Area Name: Applications and Real-Time Area
> Session Requester: Peter Thatcher
>
> Number of Sessions: 1
> Length of Session(s):  1 Hour
> Number of Attendees: 35
> Conflicts to Avoid:
>  First Priority: payload core rtcweb avtcore t2trg tls tsvarea tsvwg tram
> mmusic dispatch tcpm quic
>  Second Priority: perc httpbis rmcat netvc sipbrandy stir
>  Third Priority: ace 6lo lwig clue xrblock sipcore cbor
>
>
> People who must be present:
>   Ben Campbell
>   Ari Keranen
>   Peter Thatcher
>
> Resources Requested:
>
> Special Requests:
>
> ---------------------------------------------------------
>
>

--f403045d5cee40a7510564a18a1b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


FYI, this was requested just in case there are th=
ings that need to be discussed regarding reviews of ICEbis.=C2=A0 But if it=
 turns out there isn't any need, we'll cancel it. =C2=A0

On Thu, Feb 1, 2018 =
at 11:08 AM IETF Meeting Session Request Tool <session-request@ietf.org> wrote:




A new meeting session request has just been submitted by Peter Thatcher, a =
Chair of the ice working group.





---------------------------------------------------------

Working Group Name: Interactive Connectivity Establishment

Area Name: Applications and Real-Time Area

Session Requester: Peter Thatcher



Number of Sessions: 1

Length of Session(s):=C2=A0 1 Hour

Number of Attendees: 35

Conflicts to Avoid:

=C2=A0First Priority: payload core rtcweb avtcore t2trg tls tsvarea tsvwg t=
ram mmusic dispatch tcpm quic

=C2=A0Second Priority: perc httpbis rmcat netvc sipbrandy stir

=C2=A0Third Priority: ace 6lo lwig clue xrblock sipcore cbor





People who must be present:

=C2=A0 Ben Campbell

=C2=A0 Ari Keranen

=C2=A0 Peter Thatcher



Resources Requested:



Special Requests:



---------------------------------------------------------






--f403045d5cee40a7510564a18a1b--


From nobody Thu Feb  8 13:47:51 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF3312D84C for ; Thu,  8 Feb 2018 13:47:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXIZ6Auz4wK1 for ; Thu,  8 Feb 2018 13:47:47 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 384881275C5 for ; Thu,  8 Feb 2018 13:47:47 -0800 (PST)
Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w18Llj6S090278 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 8 Feb 2018 15:47:46 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105]
From: Ben Campbell 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_2822DE55-DDAE-4F42-A9B7-C58AC3D62F80"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Thu, 8 Feb 2018 15:47:44 -0600
In-Reply-To: 
Cc: "ice@ietf.org" 
To: Peter Saint-Andre 
References: <879BAF1F-8DC5-4850-A7CB-711EC85DE282@nostrum.com> <7d5ff628-df64-3bd5-6327-cfb0ce0fa2a5@stpeter.im> 
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-trickle-16
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Feb 2018 21:47:49 -0000

--Apple-Mail=_2822DE55-DDAE-4F42-A9B7-C58AC3D62F80
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Apologies for the delay in responding; it=E2=80=99s been a pretty crazy =
week.

Your responses look good to me; I will request IETF LC on version 16.

You recommended considering all of the ICE drafts together. The current =
plan is to consider ice-trickle and trickle-ice-sip together. I don=E2=80=99=
t want to delay 5245bis to accomplish that unless it=E2=80=99s =
absolutely necessary. The IESG will probably review 5245bis on the Feb =
22 telechat, then the two trickle drafts on the next telechat=E2=80=94I =
think that ICE will still be fresh in people=E2=80=99s minds by then. =
Hopefully they will all be on a telechat prior to London.

Thanks!

Ben.

> On Feb 2, 2018, at 3:54 PM, Peter Saint-Andre  =
wrote:
>=20
> Ben, if it's OK with you I will submit a revised I-D containing these =
fixes.
>=20
> Peter
>=20
> On 2/1/18 2:20 PM, Peter Saint-Andre wrote:
>> On 1/31/18 10:31 PM, Ben Campbell wrote:
>>> Hi,
>>>=20
>>> This is my AD evaluation of draft-ietf-ice-trickle-16.
>>>=20
>>> The document is general well written and easy to follow. I have a =
few
>>> comments and questions I=E2=80=99d like to address prior to IETF LC.
>>=20
>> Thanks, Ben.
>>=20
>> BTW, given that draft-ietf-ice-rfc5245bis and
>> draft-ietf-mmusic-trickle-ice-sip are already in IETF Last Call, I =
hope
>> that they will not be considered by the IESG apart from
>> draft-ietf-ice-trickle. Concurrent review will help ensure that the
>> specs are in sync.
>>=20
>>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=
=80=94=E2=80=94
>>>=20
>>> - section 3, 2nd to last paragraph:
>>>=20
>>> [Note: I already brought this up in a separate email, and Peter
>>> suggested a fix. I=E2=80=99m including it here for completeness]
>>>=20
>>> This paragraph is written in terms of the SDP ice-options attribute.
>>> It should talk about the generic ICE option described in section 10
>>> of 5245bis.
>>>=20
>>> - 4, last sentence: =E2=80=9Cearly as possible=E2=80=9D seems a bit =
subjective for
>>> use with the SHOULD, especially since that will be very application
>>> depended. I imagine developers trying to decide if they should send
>>> an initial offer the second a user hovers over a contact (which may
>>> or may not be a good idea.) Please consider restating this without
>>> the 2119 SHOULD.
>>=20
>> OLD
>>   the initiator SHOULD generate and transmit their initial ICE
>>   description as early as possible, so that the remote party can =
start
>>   gathering and trickling candidates.
>>=20
>> NEW
>>   the user experience is improved if the initiator generates and
>>   transmits their initial ICE description as early as possible (thus
>>   enabling the remote party to start gathering and trickling
>>   candidates).
>>=20
>>> - 5, 2nd to last paragraph, last sentence: Should =E2=80=9Cfallback =
to
>>> [RFC3264]=E2=80=9D be =E2=80=9Cfallback to non-ICE processing =
rules=E2=80=9D?
>>=20
>> Yes, that's better.
>>=20
>>> -13, first sentence: "Either agent MAY convey subsequent candidate
>>> information at any time allowed by the signaling protocol in use.=E2=80=
=9D
>>>=20
>>> I=E2=80=99m a little confused by this, since previous text said you =
MUST NOT
>>> keep trickling after sending end-of-candidates. =46rom the context =
of
>>> the section, I assume this is talking about future exchanges (e.g. a
>>> new offer) , not trickling as a result of a previous change, but the
>>> words seem ambiguous.
>>=20
>> This would be better:
>>=20
>>   Before conveying an end-of-candidates indication, either agent MAY
>>   convey subsequent candidate information at any time allowed by the
>>   signaling protocol in use.
>>=20
>>> -16, 2nd paragraph: "Therefore a candidate for a specific component
>>> MUST NOT be conveyed prior to candidates for other components within
>>> the same foundation.=E2=80=9D
>>>=20
>>> I=E2=80=99m confused by this sentence; it seems like a deadlock =
where no
>>> component candidates can be conveyed first. Should =E2=80=9Cother =
components=E2=80=9D
>>> be =E2=80=9Cearlier components=E2=80=9D?
>>=20
>> Good catch. The term "component with a lower ID number" seems more
>> accurate than "earlier components". I suggest:
>>=20
>>   Therefore candidates for a given component MUST NOT be conveyed =
prior
>>   to candidates for a component with a lower ID number within the =
same
>>   foundation.
>>=20
>>> -16, paragraph after the SDP example: This seems to be an =
explanation
>>> of the example, not a normative statement. Please consider stating
>>> without the 2119 keywords.
>>=20
>> s/MUST/would/g
>>=20
>>> -18: Please consider using the IESG (iesg@ietf.org) as the contact. =
I
>>> know we=E2=80=99ve had individual contacts for these in the past, =
but the
>>> iesg address is (hopefully) more stable than individual or WG
>>> addresses.
>>=20
>> Agreed.
>>=20
>>> -19, 2nd paragraph:
>>>=20
>>> Stephen=E2=80=99s SecDir review[1] of 5245bis asked for a stronger =
statement
>>> about the application=E2=80=99s ability to control control which =
network
>>> interfaces are exposed in ICE candidates.. It may be that having =
such
>>> a statement in 5245bis is enough, but don=E2=80=99t be surprised if =
it comes
>>> up in IETF LC or IESG review.
>>>=20
>>> [1]
>>> =
https://mailarchive.ietf.org/arch/msg/ice/fyhuRfrMJqdnCJnE6MJ_0peMFsw
>>=20
>> Given that draft-ietf-ice-trickle merely provides a method for
>> communicating ICE candidates incrementally instead of all at once, it
>> seems to me that it does not have an impact on the permissions model
>> behind exposing ICE candidates in the first place; thus I expect that
>> the text being added to 5245bis is enough. But thanks for the =
heads-up.
>>=20
>> Peter
>>=20
>>=20
>=20
>=20
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice


--Apple-Mail=_2822DE55-DDAE-4F42-A9B7-C58AC3D62F80
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

iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlp8xYAACgkQgFZKbJXz
1A1Ugw//e1FcMkYZcf4/j6JmGwwyBoM/bG2ID5Lu8gdLlK3z+DcGHpNX7DJVK9dP
VcyByKGe4xLQ8Ss3B+GgW9ULt2QX77EdbSSaljoHBOgVjI61Lz/n+rCnpP18I4Z2
QMfFB572845p7roQks7vVp7H+AxIz6LRf8aR6oNXdH5Xuyg1XkOj6MitrmO+9y5Z
sy2R2KeEctkTECDsCr0+QCe3gDQrgZCo2DQCNOpqAO7FsMZcH9WvqF0XHQ1G1p4J
TblOTxpHinY8eCxLP+A09Lw0sybCnK1zzzyjJywD39QPowrXSIXFKt8efdc4UQTc
5mPWekVcu+QxtguR87r1vd+SN/nf5OvsZUDlP+wBlMoW/sY6PNH155DGmdyEtAYG
ug1mki9opjqukHAKKDmJDfqH4IR2kpTLexfdqWr/0up+1y2J5Cl5Qc4/8Wje1Mnr
Uw8R3Qs5Ke0dN/EHGFu/zpNPpG2CkKMa8YiMjaVDaeIS8JY5DkvRPNwICj+IuiWi
+7n+U8keruNz11buupXRrIV9en5yibK/oRe9gU0DqStIrL0yNTNqMO4VXXRTR4a8
y8mfC61AOTl+NIgk4H29tTxvsAOdBgYEFz5R5zQQBp1gCgtTuup+7ynjOJambQcW
s+CSplPSGPOpNS5a6ea6JUTz3yxSY1tNfpjOlmzI27UEps5L8ao=
=ovGn
-----END PGP SIGNATURE-----

--Apple-Mail=_2822DE55-DDAE-4F42-A9B7-C58AC3D62F80--


From nobody Thu Feb  8 14:00:02 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B741127AD4 for ; Thu,  8 Feb 2018 14:00:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level: 
X-Spam-Status: No, score=-2.721 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=AJSLBcMI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nZ6RZPpH
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 MCjEtITNz1f1 for ; Thu,  8 Feb 2018 13:59:59 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0820D12785F for ; Thu,  8 Feb 2018 13:59:59 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 45D0320D33; Thu,  8 Feb 2018 16:59:58 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 08 Feb 2018 16:59:58 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=tVJiwQ8qYl7JbrR+O0PF9Pbw+8xM0fetCvRrKU+/ZD8=; b=AJSLBcMI 6k//2qVe9Pju4mk2x1lBrY5dkDekPW49K5bDWvArJGOjRc1WTyuecuDVjnKhx8tT 58gy7jN0rCaqNiJE+JrJSr8uK6zX6deJlbc2Y0KDiD1bCs6JCFalOcT+HXM7ZNSA bpRwnQX9huQf2Sry9Dk0S9jyruckQtBv89/MgcJ2Z5IDcsdX3epzFPWzEWekoR9c 0gr2UB5Sj0GZ0jvv4bpAygyPOQeduirj7sJL9fC5HfeG7foKnIUPzATdplfn/d6H sMZ/iSi2gI17fUhGz7RBVUGgXOwvpuwOC9eBJix1T24+kmU24sYfrrB87DR6AO5C y9Lxg3K7t8/tpw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=tVJiwQ8qYl7JbrR+O0PF9Pbw+8xM0 fetCvRrKU+/ZD8=; b=nZ6RZPpHiryD1Bee4GtI6dkHT6FErPC1JW/wy7V6JqDy3 VKb9FejfbmbffpuHp8TE/7OC4/iA2C0xZDCEwN/6fZd9gQnEfy6Zed4Z4UJ4Xv3F qnALGS3+sJBREYKJDjWQtV27QuEUw1OmneGcLzsfeWPpXVeUMf+5Z//dqHJjcGd0 +ZNqBsil6WzZaLpL8M8kePalyaIfo00KteT6i98dazxBpLcTiUKtFa9O1avns3mk v2cf5KjkettCCW413myUjLI1+37JawnuDhmlFNEIlo4NdOkSrm8MIQ73Vz3PZnQU xlHbTqcB8s3tDQtM68LoIhAbKp7ZfgXwC/StOg0eQ==
X-ME-Sender: 
Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id C40B27E3DF; Thu,  8 Feb 2018 16:59:57 -0500 (EST)
To: Ben Campbell 
Cc: "ice@ietf.org" 
References: <879BAF1F-8DC5-4850-A7CB-711EC85DE282@nostrum.com> <7d5ff628-df64-3bd5-6327-cfb0ce0fa2a5@stpeter.im>  
From: Peter Saint-Andre 
Message-ID: <32906e72-eb6e-03b1-7554-a4518d056564@stpeter.im>
Date: Thu, 8 Feb 2018 14:59:56 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3mt0I9PlSNMM3zCEK5BJClqjmmoTuvVoW"
Archived-At: 
Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-trickle-16
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Feb 2018 22:00:01 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--3mt0I9PlSNMM3zCEK5BJClqjmmoTuvVoW
Content-Type: multipart/mixed; boundary="DnObC2eppGIZgkWRIsKEWGtIIPr48Pw0s";
 protected-headers="v1"
From: Peter Saint-Andre 
To: Ben Campbell 
Cc: "ice@ietf.org" 
Message-ID: <32906e72-eb6e-03b1-7554-a4518d056564@stpeter.im>
Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-trickle-16
References: <879BAF1F-8DC5-4850-A7CB-711EC85DE282@nostrum.com>
 <7d5ff628-df64-3bd5-6327-cfb0ce0fa2a5@stpeter.im>
 
 
In-Reply-To: 

--DnObC2eppGIZgkWRIsKEWGtIIPr48Pw0s
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2/8/18 2:47 PM, Ben Campbell wrote:
> Apologies for the delay in responding; it=E2=80=99s been a pretty crazy=

> week.
>=20
> Your responses look good to me; I will request IETF LC on version
> 16.

Excellent.

> You recommended considering all of the ICE drafts together. The
> current plan is to consider ice-trickle and trickle-ice-sip together.
> I don=E2=80=99t want to delay 5245bis to accomplish that unless it=E2=80=
=99s
> absolutely necessary. The IESG will probably review 5245bis on the
> Feb 22 telechat, then the two trickle drafts on the next telechat=E2=80=
=94I
> think that ICE will still be fresh in people=E2=80=99s minds by then.
> Hopefully they will all be on a telechat prior to London.

That works! My concern about spreading them out too widely has been allay=
ed.

Thanks, Ben.

Peter


--DnObC2eppGIZgkWRIsKEWGtIIPr48Pw0s--

--3mt0I9PlSNMM3zCEK5BJClqjmmoTuvVoW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAlp8yFwACgkQ6gakkSvF
ramoxw/8Dqu7lNzC0mY+K0NaRQxTru5eUOiajYAMiYvzkBY9XDWBVdomOhswv3yJ
a2O0po3NLymAwUH23//egXIn+maVf1hyQpNV8Hb+rVDA0WNAvpvIKXdq79Jfpv38
cTvH5wkIwPHKYq5WplUNh/QteXvG7A3uqDtsGNwehEaBId5ECPfXdnGhLYfu42dU
qrk93D88RGVyWDm++dg+1o7e2Pt4yGsXC5P8T/RVaIsc4zXfgphkl9hqtY5M3Fqi
46v6vG1kyGkN+RbAHpc2h0rQMWxR5z3TcKcESEVZ8k6hjmRkl7TPYy1htxP++YPC
zGdHUgGSDws4DkQMtYhMVlTZj0ozJs8Hw/iPtvoaGebNQKYBRIpQYCfQBrsy4I2o
H3yhYATpi8aSYpD6zd2zkItQv+BkkE0aB6+ZgmDMauhRwEN2eYspi6BkoKzfXZy3
RrPzQwdLa6v/ukFW2rf84250qPJQx/yROTVA3qwM5hNjyVFDOnKcdrdhAY60+cFF
1RFgFhYGH5YlYI+lAc0t4KUsqfFyp8FCmeYIpeooRbjsagE8B7XUmMbSqX/f7Qd/
Le71oYD921yQwXOMiStBmv5cutNbNgs8xbK0WM0VSX2sO6AGGT9UYgg5FCBqOjoL
/J6p138LhoEKYGjviXUKnA0Lv63IM35T+2PQdabCQgphN2k9G4o=
=SUT0
-----END PGP SIGNATURE-----

--3mt0I9PlSNMM3zCEK5BJClqjmmoTuvVoW--


From nobody Thu Feb  8 14:06:32 2018
Return-Path: 
X-Original-To: ice@ietf.org
Delivered-To: ice@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 182541277BB; Thu,  8 Feb 2018 14:06:31 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.0
Auto-Submitted: auto-generated
Precedence: bulk
CC: ben@nostrum.com, ice-chairs@ietf.org, Nils Ohlmeier , draft-ietf-ice-trickle@ietf.org, ice@ietf.org, nohlmeier@mozilla.com
Reply-To: ietf@ietf.org
Sender: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <151812759109.1212.16569751871305046898.idtracker@ietfa.amsl.com>
Date: Thu, 08 Feb 2018 14:06:31 -0800
Archived-At: 
Subject: [Ice] Last Call:  (Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol) to Proposed Standard
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Feb 2018 22:06:31 -0000

The IESG has received a request from the Interactive Connectivity
Establishment WG (ice) to consider the following document: - 'Trickle ICE:
Incremental Provisioning of Candidates for the
   Interactive Connectivity Establishment (ICE) Protocol'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-02-22. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   This document describes "Trickle ICE", an extension to the
   Interactive Connectivity Establishment (ICE) protocol that enables
   ICE agents to send and receive candidates incrementally rather than
   exchanging complete lists.  With such incremental provisioning, ICE
   agents can begin connectivity checks while they are still gathering
   candidates and considerably shorten the time necessary for ICE
   processing to complete.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ballot/


No IPR declarations have been submitted directly on this I-D.





From nobody Fri Feb  9 01:01:27 2018
Return-Path: 
X-Original-To: ice@ietf.org
Delivered-To: ice@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC141200E5; Fri,  9 Feb 2018 01:01:20 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell 
To: 
Cc: draft-ietf-ice-rfc5245bis.all@ietf.org, ietf@ietf.org, ice@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151816688090.1120.13030962642627909709@ietfa.amsl.com>
Date: Fri, 09 Feb 2018 01:01:20 -0800
Archived-At: 
Subject: [Ice] Secdir telechat review of draft-ietf-ice-rfc5245bis-17
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Feb 2018 09:01:21 -0000

Reviewer: Stephen Farrell
Review result: Ready

The diff from -16 to -17 resolved the issues I raised earlier so 
this one seems ready to me. 


From nobody Fri Feb  9 01:15:24 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FF2127735 for ; Fri,  9 Feb 2018 01:15:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RwczqGB4rfh for ; Fri,  9 Feb 2018 01:15:21 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A9D12422F for ; Fri,  9 Feb 2018 01:15:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518167719; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BX9hLP8IVCLmtjboahS84jX1lA3RjLILkSPznZxELbE=; b=AbnfYZ0709zNdfe7vSjhNkQB9KRpV3gC5jLkRdgE2JsoaGB4YPmNLva4nwodsWG+ uB/tndW7XIVlklztbCnZlj/bktEzwJsPnv8DvKCtqvxiBfs8LgCeFxtxRPBrBlCv cGmeHOIGS2UsJk+pzD5GCTDLkpAifeET04/+8EoGjZI=;
X-AuditID: c1b4fb25-859119c00000341b-0e-5a7d66a7922d
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 34.AD.13339.7A66D7A5; Fri,  9 Feb 2018 10:15:19 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Fri, 9 Feb 2018 10:15:15 +0100
From: Christer Holmberg 
To: Stephen Farrell , "secdir@ietf.org" 
CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" 
Thread-Topic: Secdir telechat review of draft-ietf-ice-rfc5245bis-17
Thread-Index: AQHToYSPAt637vBTKkqDdD+xiXa7uqObyeWw
Date: Fri, 9 Feb 2018 09:15:14 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C16131E@ESESSMB109.ericsson.se>
References: <151816688090.1120.13030962642627909709@ietfa.amsl.com>
In-Reply-To: <151816688090.1120.13030962642627909709@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbFdS3d5Wm2Uwb5XhhbHf/xht/h2odbi 2cb5LBYfFj5ksZi+9xq7A6vH2u6rbB5LlvxkCmCK4rJJSc3JLEst0rdL4MrY0dPHXNDFWrHh egdTA+MPli5GTg4JAROJ2c3L2boYuTiEBA4zSsx+8xXKWcwo8erQAfYuRg4ONgELie5/2iAN IgJhEvffH2IFqWEWmMko8frnS0aQhLCAs8SMBe+YIYpcJG7eamKCsI0klrRsAbNZBFQkjq99 xQZi8wr4SrRfngnWKwTU+23hZrCLOIF6v7WeAoszCohJfD+1BqyXWUBc4taT+UwQVwtILNlz nhnCFpV4+fgfK4StJLHo9mcmkJuZBTQl1u/Sh2hVlJjS/ZAdYq2gxMmZT1gmMIrOQjJ1FkLH LCQds5B0LGBkWcUoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGEEHt/xW3cF4+Y3jIUYBDkYl Ht5DFrVRQqyJZcWVuYcYJTiYlUR4y2KBQrwpiZVVqUX58UWlOanFhxilOViUxHlPevJGCQmk J5akZqemFqQWwWSZODilGhgt7Scu2fioM5Ft4c1TKe3mr/33rZzXZXnsG1u/u8az5irBcs/0 WZqiLfFzfzNP4+3bdyZAS8dkxfJ76mumRJ7XZfum2nBeZ2VQclz7141HvTNV3HU1Si0P9PCm vnu5Q0bkgO0si9nch157tbrPPWpjETlRaubf5UdS39ce5K7e+9mnUn/C/5NKLMUZiYZazEXF iQDY+9uenAIAAA==
Archived-At: 
Subject: Re: [Ice] Secdir telechat review of draft-ietf-ice-rfc5245bis-17
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Feb 2018 09:15:23 -0000

VGhhbmtzIFN0ZXBoZW4hIDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCi0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGVwaGVuIEZhcnJlbGwgW21haWx0bzpzdGVwaGVuLmZh
cnJlbGxAY3MudGNkLmllXSANClNlbnQ6IDA5IEZlYnJ1YXJ5IDIwMTggMTE6MDENClRvOiBzZWNk
aXJAaWV0Zi5vcmcNCkNjOiBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzLmFsbEBpZXRmLm9yZzsg
aWV0ZkBpZXRmLm9yZzsgaWNlQGlldGYub3JnDQpTdWJqZWN0OiBTZWNkaXIgdGVsZWNoYXQgcmV2
aWV3IG9mIGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXMtMTcNCg0KUmV2aWV3ZXI6IFN0ZXBoZW4g
RmFycmVsbA0KUmV2aWV3IHJlc3VsdDogUmVhZHkNCg0KVGhlIGRpZmYgZnJvbSAtMTYgdG8gLTE3
IHJlc29sdmVkIHRoZSBpc3N1ZXMgSSByYWlzZWQgZWFybGllciBzbyB0aGlzIG9uZSBzZWVtcyBy
ZWFkeSB0byBtZS4gDQoNCg==


From nobody Fri Feb  9 01:45:52 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303A912741D; Fri,  9 Feb 2018 01:45:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 aq4sKNn7NWQw; Fri,  9 Feb 2018 01:45:48 -0800 (PST)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4: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 5D840127342; Fri,  9 Feb 2018 01:45:45 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 76D1C280BE8; Fri,  9 Feb 2018 10:45:43 +0100 (CET)
Received: by mx4.nic.fr (Postfix, from userid 500) id 6F3D8280BEB; Fri,  9 Feb 2018 10:45:43 +0100 (CET)
Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 6622D280BE8; Fri,  9 Feb 2018 10:45:43 +0100 (CET)
Received: from b12.nic.fr (b12.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 62FFD642C581; Fri,  9 Feb 2018 10:45:43 +0100 (CET)
Received: by b12.nic.fr (Postfix, from userid 1000) id 56133401CC; Fri,  9 Feb 2018 10:45:43 +0100 (CET)
Date: Fri, 9 Feb 2018 10:45:43 +0100
From: Stephane Bortzmeyer 
To: ietf@ietf.org
Cc: ben@nostrum.com, ice-chairs@ietf.org, ice@ietf.org, draft-ietf-ice-trickle@ietf.org, nohlmeier@mozilla.com
Message-ID: <20180209094543.ahd55p4ubo4ib5wx@nic.fr>
References: <151812759109.1212.16569751871305046898.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <151812759109.1212.16569751871305046898.idtracker@ietfa.amsl.com>
X-Operating-System: Debian GNU/Linux 9.3
X-Kernel: Linux 4.9.0-5-amd64 x86_64
X-Charlie: Je suis Charlie
Organization: NIC France
X-URL: http://www.nic.fr/
User-Agent: NeoMutt/20170113 (1.7.2)
X-Bogosity: No, tests=bogofilter, spamicity=0.088704, version=1.2.2
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.2.9.93916
Archived-At: 
Subject: Re: [Ice] Last Call:  (Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol) to Proposed Standard
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Feb 2018 09:45:51 -0000

On Thu, Feb 08, 2018 at 02:06:31PM -0800,
 The IESG  wrote 
 a message of 38 lines which said:

> The IESG has received a request from the Interactive Connectivity
> Establishment WG (ice) to consider the following document: - 'Trickle ICE:
> Incremental Provisioning of Candidates for the
>    Interactive Connectivity Establishment (ICE) Protocol'
>    as Proposed Standard

It may seem a detail, but we already have something named Trickle, in
RFC 6206. Is this name collision a good idea?


From nobody Fri Feb  9 09:26:54 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D65612426E; Fri,  9 Feb 2018 09:26:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level: 
X-Spam-Status: No, score=-2.721 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=iiWiNb2I; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=c3G414Y2
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 cgBHyItUe_60; Fri,  9 Feb 2018 09:26:50 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F2C120454; Fri,  9 Feb 2018 09:26:50 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5604D21196; Fri,  9 Feb 2018 12:26:49 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Fri, 09 Feb 2018 12:26:49 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=hiEBjqhyx9pzjQ2eBo2YBmcew23ZcEeQAQsTWtUnKfI=; b=iiWiNb2I V+9IUZbEg4c459xkKaeeae51Cn+Pplw2isK23GAGYumlHxAVKgo/jNUOL/BhaeMz sjE4o2V8nYGxNKrTEA4AViSFcXZMMgFwpXzxJHXwYLnl1/5hRS2S5/Pag8XfCinI JEL2WgHb6alFxOQrIQcvV8o/6iJ/IAaEZ3fPr5hUu5p9TqEUXGSc0or0DkJJSM8R 2lWPbcNV4+7HGA4EjvyCcTWjrDAAcO4DS6Fr/MVayEVWiLe6ZM6bnEYcI8cd0/ZQ ZbfB735srz6ZunojX1mEWEVHSe9qPeDGZO++e20lYzVErxroXCMDFGSaWmrSYBcY GbYXhg6gM6BUUw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=hiEBjqhyx9pzjQ2eBo2YBmcew23Zc EeQAQsTWtUnKfI=; b=c3G414Y2HdQ+HKttrvaLeosgzXpYeFSC9eRxStjl7kFLh IKnIii8//oe+lHDr5NUYcTZqSLaSELcZ+H23URYQhGD3pyHplI87jD/+fsBIICKd 7BuS3b12IXL2lX24ECf5Mnb6Mmq6cvit6a2FsTwuzZBnp+A9GGMQbzP/0lEC8NgN AwaDM6HcRWsgDjGsQrwdbGz/jkNxGmakuDlpH0HIqJKPQRwncJiNWrH7d9JcOkrc +yPwkckJfR3h/XucL6Th76zDQWE7btRHReFlDFv4DEYghlSzk41CJQr6jtKuMhK9 bM6LJBnv3BSRTuTzogir6gciwr7LCGYx0LB5bePuQ==
X-ME-Sender: 
Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id 7D8E77E321; Fri,  9 Feb 2018 12:26:48 -0500 (EST)
To: Stephane Bortzmeyer , ietf@ietf.org
Cc: ben@nostrum.com, ice-chairs@ietf.org, nohlmeier@mozilla.com, draft-ietf-ice-trickle@ietf.org, ice@ietf.org
References: <151812759109.1212.16569751871305046898.idtracker@ietfa.amsl.com> <20180209094543.ahd55p4ubo4ib5wx@nic.fr>
From: Peter Saint-Andre 
Message-ID: <3660e154-ab85-4a56-c6af-f7b34ccbec71@stpeter.im>
Date: Fri, 9 Feb 2018 10:26:47 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180209094543.ahd55p4ubo4ib5wx@nic.fr>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5bkdZZcvNkLOXTL1xFbUD81ExiWoeBjBe"
Archived-At: 
Subject: Re: [Ice] Last Call:  (Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol) to Proposed Standard
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Feb 2018 17:26:52 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--5bkdZZcvNkLOXTL1xFbUD81ExiWoeBjBe
Content-Type: multipart/mixed; boundary="rIp1ztxLfQtxVhuLXJbaKXmYJYMuiWeFr";
 protected-headers="v1"
From: Peter Saint-Andre 
To: Stephane Bortzmeyer , ietf@ietf.org
Cc: ben@nostrum.com, ice-chairs@ietf.org, nohlmeier@mozilla.com,
 draft-ietf-ice-trickle@ietf.org, ice@ietf.org
Message-ID: <3660e154-ab85-4a56-c6af-f7b34ccbec71@stpeter.im>
Subject: Re: [Ice] Last Call:  (Trickle ICE:
 Incremental Provisioning of Candidates for the Interactive Connectivity
 Establishment (ICE) Protocol) to Proposed Standard
References: <151812759109.1212.16569751871305046898.idtracker@ietfa.amsl.com>
 <20180209094543.ahd55p4ubo4ib5wx@nic.fr>
In-Reply-To: <20180209094543.ahd55p4ubo4ib5wx@nic.fr>

--rIp1ztxLfQtxVhuLXJbaKXmYJYMuiWeFr
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2/9/18 2:45 AM, Stephane Bortzmeyer wrote:
> On Thu, Feb 08, 2018 at 02:06:31PM -0800,
>  The IESG  wrote=20
>  a message of 38 lines which said:
>=20
>> The IESG has received a request from the Interactive Connectivity
>> Establishment WG (ice) to consider the following document: - 'Trickle =
ICE:
>> Incremental Provisioning of Candidates for the
>>    Interactive Connectivity Establishment (ICE) Protocol'
>>    as Proposed Standard
>=20
> It may seem a detail, but we already have something named Trickle, in
> RFC 6206. Is this name collision a good idea?

It's not a great thing (I for one didn't notice RFC 6206 until now).
However, this I-D defines "Trickle ICE" and its domain of operation and
implementation is quite different (NAT traversal vs. local multicast).
Thus I don't see significant harm, but you'd expect me to say that...

Peter

P.S. There are two kinds of "Jabber" too (the Ethernet error condition
and the instant messaging protocol).


--rIp1ztxLfQtxVhuLXJbaKXmYJYMuiWeFr--

--5bkdZZcvNkLOXTL1xFbUD81ExiWoeBjBe
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAlp92dcACgkQ6gakkSvF
ramrsw/+IUj6vHVWLEq0toipf1kvdOnLBy3xXrqWEiq2YIazBFwx1gZNRxkIooLg
QrbkoYb6i467jZ5k1a1FYm9wVOVem3GJTo+firjjXrH7P9Dv8NAiA4O8MCe4tD2Z
TApQaT1T/NcumDr8Uu9BIgoo4042he7OFCeX/BOvxA+JqeWzw8KPOPA0fun4ugAP
Q2YjI4C1zGv1Zi1uYQPVGLcfi1Qa8aXnO6ef6NJA4whNT7qICEno72gHYEu1gUgj
g4bziwkGbFmdsUpFm1h/FS9i6FAP1TSTLIxtPVnbSBVQhY6Q7VLUlACn88gOoRk3
6jDLIlGem9aKrzuHkU5b4OluHH44zaCwDyzoqtdHGEn9nKd93GJvNc3kQaXqWVqj
/6+YGIyO8oqWonZAc3cJ0LFVlJmooyCuIJ+YPzN93kEZ8DkINK7aeTXRO8eRf0B3
Uy2SxzZ7cxlvFsXT2tkibuMmhfM/AOdZiYzp1BQBiP+qyXYNt5O1Z0zHmsaE7kvx
OzbGYRomKpGojTYdrBv5H4Xko1Lmr/3GRYsSqdEYYQw19M31INdJ/O4ev2BrSO5P
1M9vqOvvHpEc2Bn25tFACiu0ZmERxF5kKyxSHEJGaxZ3ak+9Y86DVz0tK80xi77B
jX1U4TwC1pK0WcyrO8welRJ9YYA5EkwuTYC7kH3WjQKVzaRsj60=
=R8B6
-----END PGP SIGNATURE-----

--5bkdZZcvNkLOXTL1xFbUD81ExiWoeBjBe--


From nobody Sun Feb 11 04:54:16 2018
Return-Path: 
X-Original-To: ice@ietf.org
Delivered-To: ice@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B065126BFD; Sun, 11 Feb 2018 04:54:15 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Roni Even 
To: 
Cc: draft-ietf-ice-trickle.all@ietf.org, ietf@ietf.org, ice@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151835365522.17100.3382413286251834508@ietfa.amsl.com>
Date: Sun, 11 Feb 2018 04:54:15 -0800
Archived-At: 
Subject: [Ice] Genart last call review of draft-ietf-ice-trickle-16
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Feb 2018 12:54:15 -0000

Reviewer: Roni Even
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-ice-trickle-??
Reviewer: Roni Even
Review Date: 2018-02-11
IETF LC End Date: 2018-02-22
IESG Telechat date: 2018-03-08

Summary:
The document is ready for publication as a standard track RFC
Major issues:

Minor issues:

Nits/editorial comments:
In appendix B third paragraph "When performing full trickle, a full ICE
implementation could conveying the initial ICE description or response thereto
..."  change to "convey"



From nobody Mon Feb 12 10:39:38 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996CF12D881; Mon, 12 Feb 2018 10:39:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level: 
X-Spam-Status: No, score=-2.721 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=cfc4+jrL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RquxG7uT
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 rIbk_tK4MF8u; Mon, 12 Feb 2018 10:39:35 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514EC12D872; Mon, 12 Feb 2018 10:39:35 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 8E8F521519; Mon, 12 Feb 2018 13:39:34 -0500 (EST)
Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 12 Feb 2018 13:39:34 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=CT3u7Di/u6/gLIv6RtDlJN4GL8P9qzbbaDvaxxmWJlc=; b=cfc4+jrL fj61GiqvXCxPKTqMueUNGYG9uDbFRQ6eMiz5cd4edxbwui9t6F0W2YyoQ7qM40Re A1g+UV4YcwaKOG+VVi3MdVa6wXPjMtlyVPbBmBLXUexC8DLpI75cf4dMuNi6WMFn hs80qn2P5TMsfjfQ8w4iYA+aU/sFkqV+gIFt5dinQ2bVtFIqVMPs/TEn/7Rfpa3O NCYAkVqFaFgYgjkBGb1HbQGQgjUpewnmKJr1U5Lbtc14D1wl5ebKKOnTca9r2pwT jZlYPDb3bbc5Jz96GSLPBZ3fDfw0dDL6W9c5s5VTyavY5HjunJ8tiD0BMU4JCzu1 +EiKu1oCLboi/A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=CT3u7Di/u6/gLIv6RtDlJN4GL8P9q zbbaDvaxxmWJlc=; b=RquxG7uTT+7N5F2u/1wrkrfWOAhDPvJojim5MHPbh4gib Ym9PtLGg8S/WZ24vmiFAf7QtCjCIehoJW+lfloi9wzoRC8VrrKmzxVvPUjhEHuij hp/hGMtWUvbkcqMGecPTm4vJaz/goKvXwpXFd8kHWznbSZ1IjLQc5xGmU1UluZxT ZL/VC9Ah4bd/A5kVZNyDA1B5R00ovcWPg3Bc6xLhOT8TRmmbhVZz72xA70M4vhbK U5i8vBdtfrtoKXPxs/sdQDHKhFos3koOhjKh7el7Wkk+p0/q67TS9mRfna6KGpnM BZbuK3tfl3en5cQBHyfqhBLyrVDgJEXEDUXbXcptA==
X-ME-Sender: 
Received: from aither.local (unknown [76.25.3.152]) by mail.messagingengine.com (Postfix) with ESMTPA id DB8E62460B; Mon, 12 Feb 2018 13:39:33 -0500 (EST)
To: Roni Even , gen-art@ietf.org
Cc: draft-ietf-ice-trickle.all@ietf.org, ice@ietf.org
References: <151835365522.17100.3382413286251834508@ietfa.amsl.com>
From: Peter Saint-Andre 
Message-ID: <7485ad71-d2f1-6f93-6a25-0872e38fcc30@stpeter.im>
Date: Mon, 12 Feb 2018 11:39:32 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <151835365522.17100.3382413286251834508@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bkQRPQ4JkTBwFNasUPyBnWBoBbswvKZ2R"
Archived-At: 
Subject: Re: [Ice] Genart last call review of draft-ietf-ice-trickle-16
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 18:39:38 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--bkQRPQ4JkTBwFNasUPyBnWBoBbswvKZ2R
Content-Type: multipart/mixed; boundary="LSXfF9mz3ADcbIBKw4OlAkhfQQAIUfLwD";
 protected-headers="v1"
From: Peter Saint-Andre 
To: Roni Even , gen-art@ietf.org
Cc: draft-ietf-ice-trickle.all@ietf.org, ice@ietf.org
Message-ID: <7485ad71-d2f1-6f93-6a25-0872e38fcc30@stpeter.im>
Subject: Re: [Ice] Genart last call review of draft-ietf-ice-trickle-16
References: <151835365522.17100.3382413286251834508@ietfa.amsl.com>
In-Reply-To: <151835365522.17100.3382413286251834508@ietfa.amsl.com>

--LSXfF9mz3ADcbIBKw4OlAkhfQQAIUfLwD
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2/11/18 5:54 AM, Roni Even wrote:
> Reviewer: Roni Even
> Review result: Ready with Nits
>=20
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>=20
> For more information, please see the FAQ at
>=20
> .
>=20
> Document: draft-ietf-ice-trickle-??
> Reviewer: Roni Even
> Review Date: 2018-02-11
> IETF LC End Date: 2018-02-22
> IESG Telechat date: 2018-03-08
>=20
> Summary:
> The document is ready for publication as a standard track RFC
> Major issues:
>=20
> Minor issues:
>=20
> Nits/editorial comments:
> In appendix B third paragraph "When performing full trickle, a full ICE=

> implementation could conveying the initial ICE description or response =
thereto
> ..."  change to "convey"

Noted and fixed under source control:

https://github.com/ice-wg/trickle/commit/3c86705bd211e1b5bc2c8f7fc199ec2c=
2db7595d#diff-f7ced034e08b14404c7832d8f5f19567

Thanks for the review!

Peter



--LSXfF9mz3ADcbIBKw4OlAkhfQQAIUfLwD--

--bkQRPQ4JkTBwFNasUPyBnWBoBbswvKZ2R
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIzBAEBCAAdFiEEO1gGYnPG8aeH+JR96gakkSvFrakFAlqB32QACgkQ6gakkSvF
ran7oQ//cEr+7x1jYLSJ2CvxKKPXIXIzg5M5GBVWtRWcgacp0JcFr155mWTA0oZM
eBJkGMdKhp3pH5GM+Os/IUoKRJ/ZY1DUGGJ0ATczbQVLIJDfMfosxiPOiozBOePF
Nw+ucf7IBi7Gc+fZ3lRfoEoUCplrnmB9b7o/yDBAi4C3t+g/lREFayvOcwnZOYrp
lMZfFWlztEyq2jKPgTxQTDVu18D8u43wPHY8AoAR8mUmt9Vq6Mhqy4vjPQsadjT8
2rfTNXSgljkmtr1Rq06KfUirPZzOWAE48XZalDm7YKHNCDF6cVG3FFKu273eKQAG
yqh2NywdPGiW4+hyQLCtFNnI71ux/xOvEyFrykWtjqVASr/Y6KehPQSkFhUAehyU
RZ3zjvEQB2owgCzHesOUyQEzcIWGP3CH/+Kh0qER2rLy9bB0DeC63SyYsc7ZAWJ8
5gtw21ui04cSToJuE6W+XxxH21HVa9oSty5MZC2QJTND6Hrf1BciEQACDXS3s7ji
5OON9DoHZQy5g6Xqp5fkGsslAUIcQkFPAPix7IfIbI7keUX3TAjU8wvqt7ShcL79
WF+CqX0fseQhqrYk6DOFNWjvxuJirjVy/XQd8yYDXY84K0P4IY/78g4KaDNk+s96
wO2JOBbNAYyFF+YZsnsplzpWvWc9ON6dESbnJgOVfcTPkJUWdbU=
=aUtx
-----END PGP SIGNATURE-----

--bkQRPQ4JkTBwFNasUPyBnWBoBbswvKZ2R--


From nobody Fri Feb 16 05:45:58 2018
Return-Path: 
X-Original-To: ice@ietf.org
Delivered-To: ice@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 029EF1273B1; Fri, 16 Feb 2018 05:45:47 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stewart Bryant 
To: 
Cc: draft-ietf-ice-rfc5245bis.all@ietf.org, ietf@ietf.org, ice@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151878874692.4869.5442673693779488735@ietfa.amsl.com>
Date: Fri, 16 Feb 2018 05:45:46 -0800
Archived-At: 
Subject: [Ice] Genart telechat review of draft-ietf-ice-rfc5245bis-17
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Feb 2018 13:45:47 -0000

Reviewer: Stewart Bryant
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-ice-rfc5245bis-17
Reviewer: Stewart Bryant
Review Date: 2018-02-16
IETF LC End Date: 2018-01-26
IESG Telechat date: 2018-02-22

Summary: A well written document ready for publication.

Major issues: None

Minor issues: None

Nits/editorial comments: None



From nobody Fri Feb 16 06:03:08 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082AF1273B1 for ; Fri, 16 Feb 2018 06:02:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WB4ye9phNcE5 for ; Fri, 16 Feb 2018 06:02:55 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 7D70712D87B for ; Fri, 16 Feb 2018 06:02:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518789772; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wz8067spF2eR2+/7X5MKMrxkYiu4GJelN0iZLsBanwM=; b=PXP8sP1qjVcPxWITVaJbbQw2i8arTfsQrSCIvBUYXd6tk/6ev/Nx9yMlZm+Hhioa PiYjANO+7E/B2RV4w2RLokNq4iLJ+xPSXbYYgPsaOVzfql7GUA5ObAZX5mgDiHIZ Hv1sNo7HYMYDyX15koayy7+/5SB+RvHHZptRa2g12FM=;
X-AuditID: c1b4fb3a-728f89c0000067b4-04-5a86e48b372e
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id C2.D3.26548.B84E68A5; Fri, 16 Feb 2018 15:02:52 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Fri, 16 Feb 2018 15:02:36 +0100
From: Christer Holmberg 
To: Stewart Bryant , "gen-art@ietf.org" 
CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "ietf@ietf.org" , "ice@ietf.org" 
Thread-Topic: Genart telechat review of draft-ietf-ice-rfc5245bis-17
Thread-Index: AQHTpyx0qMyQcQfTPUWp22MEsiC0U6OnDz+A
Date: Fri, 16 Feb 2018 14:02:35 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C17233D@ESESSMB109.ericsson.se>
References: <151878874692.4869.5442673693779488735@ietfa.amsl.com>
In-Reply-To: <151878874692.4869.5442673693779488735@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbFdQrfnSVuUwc+V7BbHf/xht7j66jOL xbcLtRbPNs5nsTj1INGB1WPnrLvsHkuW/GQKYIrisklJzcksSy3St0vgypi6bDFzQRt3xd2/ fUwNjA+4uhg5OSQETCSmPDvO1MXIxSEkcJhR4urLA2wQzhJGiU0TXwNlODjYBCwkuv9pgzSI CIRJXN5wnRmkhllgJqPE658vGUESwgLOEpNvzGSGKHKR+LX8OyOEbSSxfv9edpA5LAKqEi+/ 54OEeQV8JdrmdLCA2EICThLfzz9mBbE5gcY8OPkGrJVRQEzi+6k1TCA2s4C4xK0n85kgjhaQ WLLnPDOELSrx8vE/VghbSWLR7c9gJzMLaEqs36UP0aooMaX7ITvEWkGJkzOfsExgFJ2FZOos hI5ZSDpmIelYwMiyilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMweg5u+W21g/Hgc8dDjAIc jEo8vBW32qKEWBPLiitzDzFKcDArifCa3gcK8aYkVlalFuXHF5XmpBYfYpTmYFES53VKs4gS EkhPLEnNTk0tSC2CyTJxcEo1MC5oundBs3cZ84v65/c+ywYVBeqfOuzj948pKlfbKNbw7vtw zoKZ9w3ZpnOdCD7jI6J2Oip3ykKv91M3LZB9tCnt/oPtEjO+MTNffRZ46f5fB97lmgrKbjJN 9w877ZqpxcARwJLAZcI348yXgwf2qpxg/HlY/dQvQadCy9fXJ3rdMXCre+RnL6jEUpyRaKjF XFScCAAEAHsamgIAAA==
Archived-At: 
Subject: Re: [Ice] Genart telechat review of draft-ietf-ice-rfc5245bis-17
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Feb 2018 14:02:57 -0000

VGhhbmsgWW91ISA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogU3Rld2FydCBCcnlhbnQgW21haWx0bzpzdGV3YXJ0LmJyeWFudEBn
bWFpbC5jb21dIA0KU2VudDogMTYgRmVicnVhcnkgMjAxOCAxNTo0Ng0KVG86IGdlbi1hcnRAaWV0
Zi5vcmcNCkNjOiBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzLmFsbEBpZXRmLm9yZzsgaWV0ZkBp
ZXRmLm9yZzsgaWNlQGlldGYub3JnDQpTdWJqZWN0OiBHZW5hcnQgdGVsZWNoYXQgcmV2aWV3IG9m
IGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXMtMTcNCg0KUmV2aWV3ZXI6IFN0ZXdhcnQgQnJ5YW50
DQpSZXZpZXcgcmVzdWx0OiBSZWFkeQ0KDQpJIGFtIHRoZSBhc3NpZ25lZCBHZW4tQVJUIHJldmll
d2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgR2VuZXJhbCBBcmVhIFJldmlldyBUZWFtIChHZW4tQVJU
KSByZXZpZXdzIGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cg
Zm9yIHRoZSBJRVRGIENoYWlyLiBQbGVhc2Ugd2FpdCBmb3IgZGlyZWN0aW9uIGZyb20geW91ciBk
b2N1bWVudCBzaGVwaGVyZCBvciBBRCBiZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRo
ZSBkcmFmdC4NCg0KRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIEZBUSBhdA0K
DQo8aHR0cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvZ2VuL3dpa2kvR2VuQXJ0ZmFxPi4NCg0KRG9j
dW1lbnQ6IGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXMtMTcNClJldmlld2VyOiBTdGV3YXJ0IEJy
eWFudA0KUmV2aWV3IERhdGU6IDIwMTgtMDItMTYNCklFVEYgTEMgRW5kIERhdGU6IDIwMTgtMDEt
MjYNCklFU0cgVGVsZWNoYXQgZGF0ZTogMjAxOC0wMi0yMg0KDQpTdW1tYXJ5OiBBIHdlbGwgd3Jp
dHRlbiBkb2N1bWVudCByZWFkeSBmb3IgcHVibGljYXRpb24uDQoNCk1ham9yIGlzc3VlczogTm9u
ZQ0KDQpNaW5vciBpc3N1ZXM6IE5vbmUNCg0KTml0cy9lZGl0b3JpYWwgY29tbWVudHM6IE5vbmUN
Cg0KDQo=


From nobody Fri Feb 16 10:41:02 2018
Return-Path: 
X-Original-To: ice@ietf.org
Delivered-To: ice@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCD312D7E2; Fri, 16 Feb 2018 10:40:40 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Mirja_K=C3=BChlewind?= 
To: "The IESG" 
Cc: draft-ietf-ice-rfc5245bis@ietf.org, Peter Thatcher ,  ice-chairs@ietf.org, pthatcher@google.com, ice@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151880644066.1349.3259038582910377902.idtracker@ietfa.amsl.com>
Date: Fri, 16 Feb 2018 10:40:40 -0800
Archived-At: 
Subject: [Ice] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-ice-rfc5245bis-17=3A_=28with_COMMENT=29?=
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Feb 2018 18:40:44 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-ice-rfc5245bis-17: No Objection

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


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Important nits; please address:

1) Sec 14.2: RFC 6928, RFC 5389, and RFC 6298 should be actual references and
listed in the reference section.

2) Sec 14.2: Maybe you should really not use normative language in the
reasoning part of this section?!
    I find especially this SHOULD in the following sentence confusing (as it
    doesn't give a reference to another RFC that defines this):
   "Let MinPacing be the minimum pacing interval between
          transactions, which SHOULD be 5ms."
   Given that the previous text says:
  "all transactions from all agents [...] MUST NOT be sent more often than once
   every 5ms"
  My recommendation: please use lower cases "shoulds" and "musts" in the
  reasoning part!

3) Sec 19.4.1: "(say, Ta=20ms)"
Maybe use also a value of 50ms here to avoid confusion.



From nobody Sat Feb 17 00:36:45 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C131200E5 for ; Sat, 17 Feb 2018 00:36:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNcK_OzElgW7 for ; Sat, 17 Feb 2018 00:36:38 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4949512025C for ; Sat, 17 Feb 2018 00:36:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518856594; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=r2Bs0UAF8ya3pjnKsKtJVG/5WQmXW92Bjd20gPPtv9A=; b=CQJQQ5NhUIKF+AY4I0r948cPDE2BGHo0ryC05K2otGLs9G0qVXJ3trmaCjWmdnDk twqzBMA3V4LvwVUNSLTXrOgcW8qxEgiyNsEgWaSz7sPHbUuLup4EBl1qmKITbu9g qsAPK0tcxwG1ypytPmWOm10tEJtPDXNbkWJJClE5uT8=;
X-AuditID: c1b4fb25-83bff700000038f0-3e-5a87e9929faf
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 63.BA.14576.299E78A5; Sat, 17 Feb 2018 09:36:34 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Sat, 17 Feb 2018 09:36:33 +0100
From: Christer Holmberg 
To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG 
CC: "draft-ietf-ice-rfc5245bis@ietf.org" ,  Peter Thatcher , "ice-chairs@ietf.org" , "pthatcher@google.com" , "ice@ietf.org" 
Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?Q?-ice-rfc5245bis-17:_(with_COMMENT)?=
Thread-Index: AQHTp1WoWOjQpysasEqeZZnwr634Z6OoPcdQ
Date: Sat, 17 Feb 2018 08:36:33 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1730C8@ESESSMB109.ericsson.se>
References: <151880644066.1349.3259038582910377902.idtracker@ietfa.amsl.com>
In-Reply-To: <151880644066.1349.3259038582910377902.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.164]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7je6kl+1RBqefKlrMP3md2eLirMls Ft8u1FrM+DOR2eLF9Y/MFteWv2Z1YPNYsKnUY8mSn0weLR8XsgYwR3HZpKTmZJalFunbJXBl zGs+w1rwQKBiwd4DjA2MKwS6GDk4JARMJHqmc3QxcnEICRxmlJizdCIrhLOEUWL5wyssIEVs AhYS3f+0uxg5OUQEoiSe7P3CDlLDLPCVUWLFxp1MII6wQBujxNbWVWCOiEA7o8SeWeuZIVqM JCb1vGEDsVkEVCU2vpnGBGLzCvhKNE07BFYjJOAjMfXvb7A4J1B8yvtFYDajgJjE91NrwGxm AXGJW0/mg9kSAgISS/acZ4awRSVePv7HCmErSZz9MoUN5GpmAU2J9bv0IVoVJaZ0P2SHWCso cXLmE5YJjKKzkEydhdAxC0nHLCQdCxhZVjGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIERtXB Lb9VdzBefuN4iFGAg1GJhzcAGG1CrIllxZW5hxglOJiVRHgZTIBCvCmJlVWpRfnxRaU5qcWH GKU5WJTEeecIA6UE0hNLUrNTUwtSi2CyTBycUg2MetfktjQubNstHfWdac5zv3V7XZO/W8z5 67JwJteTPdOc7265tmH/vM8aqiG7NSvtFQXNLlfxPLwoYlY+PTQx+lOS0ATjDdNfvG7oirTv rS4v4rrwykn+2yzGSJ2ne4JzDC5MDf1xwpV9rpjPo5Sb3HedH+5P09RNvZvKpqlkvONQ88mw ese3SizFGYmGWsxFxYkAMhvJKqYCAAA=
Archived-At: 
Subject: Re: [Ice]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-ice-rfc5245bis-17=3A_=28with_COMMENT=29?=
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Feb 2018 08:36:40 -0000

SGkgTWlyamEsDQoNClRoYW5rIFlvdSBmb3IgeW91ciByZXZpZXcgYW5kIGNvbW1lbnRzISBQbGVh
c2Ugc2VlIGlubGluZS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N
Cg0KSW1wb3J0YW50IG5pdHM7IHBsZWFzZSBhZGRyZXNzOg0KDQo+MSkgU2VjIDE0LjI6IFJGQyA2
OTI4LCBSRkMgNTM4OSwgYW5kIFJGQyA2Mjk4IHNob3VsZCBiZSBhY3R1YWwgcmVmZXJlbmNlcyBh
bmQgbGlzdGVkIGluIHRoZSByZWZlcmVuY2Ugc2VjdGlvbi4NCg0KV2lsbCBiZSBmaXhlZCBhcyBz
dWdnZXN0ZWQuDQoNCi0tLQ0KDQo+IDIpIFNlYyAxNC4yOiBNYXliZSB5b3Ugc2hvdWxkIHJlYWxs
eSBub3QgdXNlIG5vcm1hdGl2ZSBsYW5ndWFnZSBpbiB0aGUgcmVhc29uaW5nIHBhcnQgb2YgdGhp
cyBzZWN0aW9uPyENCj4gICAgSSBmaW5kIGVzcGVjaWFsbHkgdGhpcyBTSE9VTEQgaW4gdGhlIGZv
bGxvd2luZyBzZW50ZW5jZSBjb25mdXNpbmcgKGFzIGl0DQo+ICAgIGRvZXNuJ3QgZ2l2ZSBhIHJl
ZmVyZW5jZSB0byBhbm90aGVyIFJGQyB0aGF0IGRlZmluZXMgdGhpcyk6DQo+ICAgIkxldCBNaW5Q
YWNpbmcgYmUgdGhlIG1pbmltdW0gcGFjaW5nIGludGVydmFsIGJldHdlZW4NCj4gICAgICAgICAg
dHJhbnNhY3Rpb25zLCB3aGljaCBTSE9VTEQgYmUgNW1zLiINCj4gICBHaXZlbiB0aGF0IHRoZSBw
cmV2aW91cyB0ZXh0IHNheXM6DQo+ICAiYWxsIHRyYW5zYWN0aW9ucyBmcm9tIGFsbCBhZ2VudHMg
Wy4uLl0gTVVTVCBOT1QgYmUgc2VudCBtb3JlIG9mdGVuIHRoYW4gb25jZQ0KPiAgIGV2ZXJ5IDVt
cyINCj4NCj4gIE15IHJlY29tbWVuZGF0aW9uOiBwbGVhc2UgdXNlIGxvd2VyIGNhc2VzICJzaG91
bGRzIiBhbmQgIm11c3RzIiBpbiB0aGUNCj4gIHJlYXNvbmluZyBwYXJ0IQ0KDQpJIHRoaW5rIGl0
IHdvdWxkIGJlIGdvb2QgdG8ga2VlcCB1cHBlciBjYXNlcyBpbiBtb3N0IGluc3RhbmNlcywgYnV0
IEkgZG8gYWdyZWUgdGhhdCB0aGUgdXNhZ2Ugb2YgU0hPVUxEIGluIHRoZSBNaW5QYWNpbmcgc2Vu
dGVuY2UgaXMgY29uZnVzaW5nLCBzbyB3aGF0IGFib3V0IHRoZSBmb2xsb3dpbmcgY2hhbmdlOg0K
DQpPTEQ6DQoNCiJMZXQgTWluUGFjaW5nIGJlIHRoZSBtaW5pbXVtIHBhY2luZyBpbnRlcnZhbCBi
ZXR3ZWVuIHRyYW5zYWN0aW9ucywgd2hpY2ggU0hPVUxEIGJlIDVtcy4iDQoNCk5FVzoNCg0KIkxl
dCBNaW5QYWNpbmcgYmUgdGhlIG1pbmltdW0gcGFjaW5nIGludGVydmFsIGJldHdlZW4gdHJhbnNh
Y3Rpb25zLCB3aGljaCBpcyA1IG1zIChzZWUgYWJvdmUpLiINCg0KLS0tDQoNCj4gMykgU2VjIDE5
LjQuMTogIihzYXksIFRhPTIwbXMpIg0KPiBNYXliZSB1c2UgYWxzbyBhIHZhbHVlIG9mIDUwbXMg
aGVyZSB0byBhdm9pZCBjb25mdXNpb24uDQoNCldpbGwgYmUgZml4ZWQgYXMgc3VnZ2VzdGVkLg0K
DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo=


From nobody Sat Feb 17 01:35:43 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A95712708C for ; Sat, 17 Feb 2018 01:35:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8DAf9zDTSoK for ; Sat, 17 Feb 2018 01:35:34 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 BEC7E12711A for ; Sat, 17 Feb 2018 01:35:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518860129; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Q7O1+UvA3RooPvntWCgZdIn/4KNJkHIkUA4JBzZ14Bk=; b=ORkWSBwK1btvdWVjvOvbGH/iDPBaDk3sTT1BXEi2VfiktXfMrwIYgtUVXoAjZ1xT 2944nTf0yq2Pn2NieqrNYX/IqfgHKsdPVrmZfkIHlE8cFzAXRXOKk3f0kkynHKrQ ssnbQafatTqz+Ch9lkfUiDcI2+3fAiVTo1VetlqFKrI=;
X-AuditID: c1b4fb3a-728f89c0000067b4-1b-5a87f7616940
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4B.E2.26548.167F78A5; Sat, 17 Feb 2018 10:35:29 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Sat, 17 Feb 2018 10:35:23 +0100
From: Christer Holmberg 
To: Christer Holmberg , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG 
CC: "draft-ietf-ice-rfc5245bis@ietf.org" ,  Peter Thatcher , "ice-chairs@ietf.org" , "pthatcher@google.com" , "ice@ietf.org" 
Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRm?= =?utf-8?B?LWljZS1yZmM1MjQ1YmlzLTE3OiAod2l0aCBDT01NRU5UKSAtIFB1bGwgUmVx?= =?utf-8?Q?uest?=
Thread-Index: AdOn0qb6Oj0UxHAhTQC6ulymm59V3w==
Date: Sat, 17 Feb 2018 09:35:22 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C17321B@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.164]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7im7i9/Yog2k/+S3mn7zObHFx1mQ2 i28Xai1m/JnIbPHi+kdmi2vLX7M6sHks2FTqsWTJTyaPlo8LWQOYo7hsUlJzMstSi/TtErgy TncuYC9oEK84tO8vWwPjFrEuRg4OCQETiQ3XfLsYuTiEBA4zSvTNfs0G4SxhlDg55zczSBGb gIVE9z9tkLiIwARGiZUbjoMVMQt8ZZRYsXEnE4gjLLCZUWLpqvfMEGVbGCWWzf/C2MXICeTo SUw/+JMNxGYRUJXY3TYbzOYV8JXY+GAFM4jNKCAm8f3UGiYQm1lAXOLWk/lgtoSAgMSSPeeZ IWxRiZeP/7FC2EoSZ79MYQM5j1lAU2L9Ln2IVkWJKd0P2SHGC0qcnPmEZQKj8CwkU2chdMxC 0jELSccCRpZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIFxcnDLb6sdjAefOx5iFOBgVOLh 3fCqPUqINbGsuDL3EKMEB7OSCC+DCVCINyWxsiq1KD++qDQntfgQozQHi5I4r1OaRZSQQHpi SWp2ampBahFMlomDU6qBMdDw+Pf7IXJ18zKcl+nOzBD28FOTe2Axueznf/as7xN2q4kfTbrh 3ZWwbfHc2uo53/9c1GfRF1y1p6SdY+GvbzP2h5qdDc8yU+KaOEGj9Ykf38KnXoctmErDtoSL Pg8I+qGVscPI7f10x3D1/XceF96Se3ZIN6rKNcNp9aKQzmnZFzXZb22UUGIpzkg01GIuKk4E ALNfEySPAgAA
Archived-At: 
Subject: Re: [Ice]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-ice-rfc5245bis-17=3A_=28with_COMMENT=29_-_Pull_Request?=
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Feb 2018 09:35:35 -0000

SGksDQoNCkkgaGF2ZSBjcmVhdGVkIGEgcHVsbCByZXF1ZXN0IGZvciB0aGUgY2hhbmdlcyBiYXNl
ZCBvbiB0aGUgSUVTRyByZXZpZXdzOg0KDQpodHRwczovL2dpdGh1Yi5jb20vaWNlLXdnL3JmYzUy
NDViaXMvcHVsbC81OQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQpGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyBbbWFpbHRvOmNocmlzdGVyLmhv
bG1iZXJnQGVyaWNzc29uLmNvbV0gDQpTZW50OiAxNyBGZWJydWFyeSAyMDE4IDEwOjM3DQpUbzog
TWlyamEgS8O8aGxld2luZCA8aWV0ZkBrdWVobGV3aW5kLm5ldD47IFRoZSBJRVNHIDxpZXNnQGll
dGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXNAaWV0Zi5vcmc7IFBldGVyIFRo
YXRjaGVyIDxwdGhhdGNoZXJAZ29vZ2xlLmNvbT47IGljZS1jaGFpcnNAaWV0Zi5vcmc7IHB0aGF0
Y2hlckBnb29nbGUuY29tOyBpY2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBNaXJqYSBLw7xobGV3
aW5kJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXMtMTc6ICh3aXRo
IENPTU1FTlQpDQoNCkhpIE1pcmphLA0KDQpUaGFuayBZb3UgZm9yIHlvdXIgcmV2aWV3IGFuZCBj
b21tZW50cyEgUGxlYXNlIHNlZSBpbmxpbmUuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQot
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQoNCkltcG9ydGFudCBuaXRzOyBwbGVhc2UgYWRkcmVzczoNCg0KPjEpIFNl
YyAxNC4yOiBSRkMgNjkyOCwgUkZDIDUzODksIGFuZCBSRkMgNjI5OCBzaG91bGQgYmUgYWN0dWFs
IHJlZmVyZW5jZXMgYW5kIGxpc3RlZCBpbiB0aGUgcmVmZXJlbmNlIHNlY3Rpb24uDQoNCldpbGwg
YmUgZml4ZWQgYXMgc3VnZ2VzdGVkLg0KDQotLS0NCg0KPiAyKSBTZWMgMTQuMjogTWF5YmUgeW91
IHNob3VsZCByZWFsbHkgbm90IHVzZSBub3JtYXRpdmUgbGFuZ3VhZ2UgaW4gdGhlIHJlYXNvbmlu
ZyBwYXJ0IG9mIHRoaXMgc2VjdGlvbj8hDQo+ICAgIEkgZmluZCBlc3BlY2lhbGx5IHRoaXMgU0hP
VUxEIGluIHRoZSBmb2xsb3dpbmcgc2VudGVuY2UgY29uZnVzaW5nIChhcyBpdA0KPiAgICBkb2Vz
bid0IGdpdmUgYSByZWZlcmVuY2UgdG8gYW5vdGhlciBSRkMgdGhhdCBkZWZpbmVzIHRoaXMpOg0K
PiAgICJMZXQgTWluUGFjaW5nIGJlIHRoZSBtaW5pbXVtIHBhY2luZyBpbnRlcnZhbCBiZXR3ZWVu
DQo+ICAgICAgICAgIHRyYW5zYWN0aW9ucywgd2hpY2ggU0hPVUxEIGJlIDVtcy4iDQo+ICAgR2l2
ZW4gdGhhdCB0aGUgcHJldmlvdXMgdGV4dCBzYXlzOg0KPiAgImFsbCB0cmFuc2FjdGlvbnMgZnJv
bSBhbGwgYWdlbnRzIFsuLi5dIE1VU1QgTk9UIGJlIHNlbnQgbW9yZSBvZnRlbiB0aGFuIG9uY2UN
Cj4gICBldmVyeSA1bXMiDQo+DQo+ICBNeSByZWNvbW1lbmRhdGlvbjogcGxlYXNlIHVzZSBsb3dl
ciBjYXNlcyAic2hvdWxkcyIgYW5kICJtdXN0cyIgaW4gDQo+IHRoZSAgcmVhc29uaW5nIHBhcnQh
DQoNCkkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBrZWVwIHVwcGVyIGNhc2VzIGluIG1vc3Qg
aW5zdGFuY2VzLCBidXQgSSBkbyBhZ3JlZSB0aGF0IHRoZSB1c2FnZSBvZiBTSE9VTEQgaW4gdGhl
IE1pblBhY2luZyBzZW50ZW5jZSBpcyBjb25mdXNpbmcsIHNvIHdoYXQgYWJvdXQgdGhlIGZvbGxv
d2luZyBjaGFuZ2U6DQoNCk9MRDoNCg0KIkxldCBNaW5QYWNpbmcgYmUgdGhlIG1pbmltdW0gcGFj
aW5nIGludGVydmFsIGJldHdlZW4gdHJhbnNhY3Rpb25zLCB3aGljaCBTSE9VTEQgYmUgNW1zLiIN
Cg0KTkVXOg0KDQoiTGV0IE1pblBhY2luZyBiZSB0aGUgbWluaW11bSBwYWNpbmcgaW50ZXJ2YWwg
YmV0d2VlbiB0cmFuc2FjdGlvbnMsIHdoaWNoIGlzIDUgbXMgKHNlZSBhYm92ZSkuIg0KDQotLS0N
Cg0KPiAzKSBTZWMgMTkuNC4xOiAiKHNheSwgVGE9MjBtcykiDQo+IE1heWJlIHVzZSBhbHNvIGEg
dmFsdWUgb2YgNTBtcyBoZXJlIHRvIGF2b2lkIGNvbmZ1c2lvbi4NCg0KV2lsbCBiZSBmaXhlZCBh
cyBzdWdnZXN0ZWQuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg==


From nobody Sat Feb 17 02:31:04 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B83B127241 for ; Sat, 17 Feb 2018 02:31:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjKFcVeDkFO0 for ; Sat, 17 Feb 2018 02:31:00 -0800 (PST)
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 A78AC127137 for ; Sat, 17 Feb 2018 02:30:59 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net;  b=TuvwnlH+73RFjvCUtLGrKrXHWi+EhgghqFP3gsNzb2edlBjMgTN73cGuVtvYVTtpM2gpPEyaS0OVE7+PuJlpnCYElP9UP6lkHedRKVoTYEyqSuheAblbGeA/mw8mUPfeZH8PGuvDzH6jRzKS6Ussc7T0Kl2sedt+bznncaCe/vo=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 6974 invoked from network); 17 Feb 2018 11:29:57 +0100
Received: from i577bce1a.versanet.de (HELO ?192.168.178.33?) (87.123.206.26) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 17 Feb 2018 11:29:57 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: "Mirja Kuehlewind (IETF)" 
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1730C8@ESESSMB109.ericsson.se>
Date: Sat, 17 Feb 2018 11:29:55 +0100
Cc: The IESG , "ice-chairs@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" ,  "pthatcher@google.com" , "ice@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <40AA3D31-5AE8-414E-AAC9-000D462B7FEB@kuehlewind.net>
References: <151880644066.1349.3259038582910377902.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C1730C8@ESESSMB109.ericsson.se>
To: Christer Holmberg 
X-Mailer: Apple Mail (2.3445.5.20)
X-PPP-Message-ID: <20180217102957.6965.29128@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: 
Subject: Re: [Ice]  =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-ice-rfc5245bis-17=3A_=28with_COMMENT=29?=
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 17 Feb 2018 10:31:03 -0000

Thanks, that helps!

> Am 17.02.2018 um 09:36 schrieb Christer Holmberg =
:
>=20
> Hi Mirja,
>=20
> Thank You for your review and comments! Please see inline.
>=20
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
> Important nits; please address:
>=20
>> 1) Sec 14.2: RFC 6928, RFC 5389, and RFC 6298 should be actual =
references and listed in the reference section.
>=20
> Will be fixed as suggested.
>=20
> ---
>=20
>> 2) Sec 14.2: Maybe you should really not use normative language in =
the reasoning part of this section?!
>>   I find especially this SHOULD in the following sentence confusing =
(as it
>>   doesn't give a reference to another RFC that defines this):
>>  "Let MinPacing be the minimum pacing interval between
>>         transactions, which SHOULD be 5ms."
>>  Given that the previous text says:
>> "all transactions from all agents [...] MUST NOT be sent more often =
than once
>>  every 5ms"
>>=20
>> My recommendation: please use lower cases "shoulds" and "musts" in =
the
>> reasoning part!
>=20
> I think it would be good to keep upper cases in most instances, but I =
do agree that the usage of SHOULD in the MinPacing sentence is =
confusing, so what about the following change:
>=20
> OLD:
>=20
> "Let MinPacing be the minimum pacing interval between transactions, =
which SHOULD be 5ms."
>=20
> NEW:
>=20
> "Let MinPacing be the minimum pacing interval between transactions, =
which is 5 ms (see above)."
>=20
> ---
>=20
>> 3) Sec 19.4.1: "(say, Ta=3D20ms)"
>> Maybe use also a value of 50ms here to avoid confusion.
>=20
> Will be fixed as suggested.
>=20
> Regards,
>=20
> Christer
>=20


From nobody Sun Feb 18 12:00:57 2018
Return-Path: 
X-Original-To: ice@ietf.org
Delivered-To: ice@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E07126BF6; Sun, 18 Feb 2018 12:00:55 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla 
To: "The IESG" 
Cc: draft-ietf-ice-rfc5245bis@ietf.org, Peter Thatcher ,  ice-chairs@ietf.org, pthatcher@google.com, ice@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151898405535.27743.14420100629801089802.idtracker@ietfa.amsl.com>
Date: Sun, 18 Feb 2018 12:00:55 -0800
Archived-At: 
Subject: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Feb 2018 20:00:55 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-ice-rfc5245bis-17: No Objection

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


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Review in context at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3312

IMPORTANT:

*  If the agent's tie-breaker value is larger than or equal to the
         contents of the ICE-CONTROLLING attribute, the agent generates
IMPORTANT: This algorithm seems like it's not going to work properly.
Consider the case where A and B happen to have the same tie-breaker
and both think they are controlling, and the Binding Requests
cross. Each now sends a 487 and then they switch to
controlled. Ugh. Unless I'm missing something, if the tie-breakers
match, you are stuck. Given that the chance is 2^{-64} this seems
to not be a critical failing, but the algorithm still seems wrong.

REST:
   single solution that is flexible enough to work well in all
   situations.
This section seems pretty dated. Aren't ICE and ICE-style solutions pretty much
the de facto standard now.

   may not be aware of it.  The type of NAT and its properties are also
   unknown.  L and R are capable of engaging in an candidate exchange
   process, whose purpose is to set up a data session between L and R.
Nit: a candidate exchange. This appears to be a result of changing offer/answer
(where "an" was appropriate) to "candidate"

   At least one viable candidate has a transport address obtained
   directly from a local interface.  Such a candidate is called a host
Nit: this is awkward. Perhaps "The first category of candidates are those with
a transport ..."

   When the agent sends the TURN Allocate request from IP address and
   port X:x, the NAT (assuming there is one) will create a binding
Nit: "a TURN Allocate"

   the next candidate pair on the list periodically.  These are called
   ordinary checks.  When a STUN transaction succeeds, one or more
   candidate pairs will become so called valid pairs, and will be added
Nit: I would quote "ordinary check" here and "triggered check" below.

   provide means to exchange candidate information between the ICE
   agents.  The specific details of (i.e how to encode candidate
   information and the actual candidate exchange process) for different
Nit: i.e -> i.e.,

   Nomination, Regular Nomination:  The process of the controlling agent
      indicating to the controlled agent which candidate pair the ICE
Given that you have removed Aggressive Nomination, do you still need to refer
to "Regular Nomination"

   candidate gathering, (2) candidate prioritization, (3) redundant
   candidate elimination, and (4) sending of the candidates to the peer.
This is an odd diagram. There's no reason why these have to happen in sequence
and in fact in Trickle ICE, they don't, so this diagram seems misleading., as
well as potentially contradicting the beginning of S 5.1.1.

"An ICE agent gathers candidates when it believes that communication is
imminent. "

   When candidates are obtained, unless the agent knows for sure that
   RTP/RTCP multiplexing will be used (i.e. the agent knows that the
   other agent also supports, and is willing to use, RTP/RTCP
Nit: "i.e.,"

      addresses that do allow location tracking, that are configured on
      the same interface, and are part of the same network prefix MUST
      NOT be gathered.
You need to remove both of these commas, because they indicate a nonrestrictive
clause, but this is a restrictive clause.

   The gathering process is controlled using a timer, Ta.  Every time Ta
   expires, the agent can generate another new STUN or TURN transaction.
No comma here.

   The agent will receive a Binding or Allocate response.  A successful
   Allocate response will provide the agent with a server reflexive
Or nothing or an error.

              (2^8)*(IP precedence) +
              (2^0)*(256 - component ID)
Isn't this the same formula as in S 5.1.2.1.

      Foundation:  A sequence of up to 32 characters.
The Foundation is never transmitted, AFAIK. So why does it have to be up to 32
characters? It certainly wasn't exchanged in 5245.

   data stream, and for updating the peer with the ICE's selection, when
   needed.  The controlled agent is told which candidate pairs to use
   for each data stream, and does not require updating the peer to
Told by who?

   pair priorities, orders pairs by priority, prunes pairs, removes
   lower-priority pairs, and sets check list states.  If candidates are
   added to a check list (e.g, due to detection of peer reflexive
Please fix your subject verb agreement here.

      pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
This was kinda terrible in 5245. Given that you use it once, maybe just have

+ GT(G, D)

And then say GT(G, D) == 1 if G>D and 0 otherwwise.

                       Figure 8: Initial Pair State
This figure caption is kind of a mess. I suggest just removing it.

   state in the check list set has been processed, the first check list
   is picked again.  Etc.
Nit: "again, etc."

   pair to the remote candidate of the pair, as described in
   Section 7.2.4.
IMPORTANT: You don't just send a STUN request, you start a STUN transaction,

   lists.  On the other hand the responding agent either performs the
   triggered or ordinary checks as described above.
I don't understand this paragraph. What distinction are you trying to draw.

   o  The base is local candidate of the candidate pair from which the
      Binding request was sent.
Nit: "is the local"

   The ICE agent constructs a candidate pair whose local candidate
   equals the mapped address of the response, and whose remote candidate
IMPORTANT: When does this happen?

   a different check list than the one to which the pair that generated
   the connectivity checks), or it may be a pair not currently in any
   check list.
IMPORTANT: How would a valid pair be on some other check list?

      this specification.  There may be a conflict, but it cannot be
      detected.
What previous version? This was required in 5245. Maybe at this point we can
just deprecate this?

7.3.1.3.  Learning Peer Reflexive Candidates
This entire section seems to duplicate 7.2.5.3.1

         in-progress transaction.  Cancellation means that the agent
         will not retransmit the request, will not treat the lack of
         response to be a failure, but will wait the duration of the
Why are you cancelling In-Progress checks when you receive a peer-reflective
check? If you receive two in a row, then it seems like this delays a successful
check. More generally, this document should explain how you end up in this
situation: you only get here when "the source transport address of the request
does not match any existing remote candidate", so how can it be on a check list
unless this is the second observation of a peer reflexive.

   Prior to nominating, the controlling agent let connectivity checks
   continue until some stopping criterion is met.  After that, based on
lets.

   The criterion details for stopping the connectivity checks and for
   selecting a pair for nomination, are outside the scope of this
"criterion details" seems ungrammatical. 5245 had "criteria". What's wrong with
that?

   have ceased using a given local candidate (a candidate may be used by
   multiple ICE sessions, e.g. in forking scenarios), the agent can free
   that candidate.  The three-second delay handles cases when aggressive
Nit: "e.g.,"

   Session Description Protocol (SDP) [RFC4566] is defined in
   [I-D.ietf-mmusic-ice-sip-sdp].
Presumably you want to cite 5245 S 14, which states:

Consequently, when a controlling agent is communicating with a peer
that supports options it doesn't know about, the agent MUST run a
regular nomination algorithm.  When regular nomination is used, ICE
will converge perfectly even when both agents use different pair
prioritization algorithms.

   15 seconds.  Agents MAY use a bigger value, but MUST NOT use a value
   smaller than 15 seconds.
This is a very old number. Is it supported by an modern measurement?

   will converge perfectly even when both agents use different pair
   prioritization algorithms.  One of the keys to such convergence is
   triggered checks, which ensure that the nominated pair is validated
Given that you have removes aggressive, you presumably want to revise this
section

16.  STUN Extensions
None of the stuff here is "New" any longer, as it was allocated in RFC 5245.

   First and foremost, ICE makes use of TURN and STUN servers, which
   would typically be located in the data centers.  The STUN servers
   require relatively little bandwidth.  For each component of each data
Nit: this used to read "the network operators data centers" and when you
removed "network operators" this became ungrammatical

   there will be four transactions per call (one for RTP and one for
   RTCP, for both caller and callee).  Each transaction is a single
   request and a single response, the former being 20 bytes long, and
Is this currently true? How many people still don't support RTP-MUX?

   can and will vary over time.  In a network with 100% behave-compliant
   NAT, it is exactly zero.  At time of writing, large-scale consumer
   deployments were seeing between 5 and 10 percent of calls requiring
This text dates to 5245. Is that still true?

   something incorrect about the results of the connectivity checks.
   The possible false conclusions an attacker can try and cause are:
IMPORTANT: This section would be a lot stronger if it was factored by attacker
capabilities as well. As-is it is very hard to understand.

   possible attack.  Fortunately, this attack is mitigated completely
   through the STUN short-term credential mechanism.  The attacker needs
   to inject a fake response, and in order for this response to be
This text is a bit confusing. If you can generate a drop, then you can mount
this attack.

   invalid attack, this attack is mitigated by the STUN short-term
   credential mechanism in conjunction with a secure candidate exchange.
This also isn't quite correct. Consider the case where A is behind a filtering
element (e.g., a firewall) and shares a broadcast network with the attacker.
The attacker then captures an outgoing message that would have been filtered
and tunnels it to B, and then tunnels the response back. This can cause B and A
to think they have a valid path when they do not. It seems like this attack is
described several paragraphs down, but in sort of a confusing way.

19.4.1.  STUN Amplification Attack
It's probably worth noting that this form of attack is a lot worse when WebRTC
is involved.

   rate at which they will create new bindings.  Experiments have shown
   that once every 5 ms is well supported.  This is why Ta has a lower
   bound of 5 ms.  Furthermore, transmission of these packets on the
Citation needed.



From nobody Mon Feb 19 06:19:41 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8531242F7 for ; Mon, 19 Feb 2018 06:19:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxEkpcXvPVWI for ; Mon, 19 Feb 2018 06:19:32 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 AFDBD127735 for ; Mon, 19 Feb 2018 06:19:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519049965; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rZ3SFMqv97xaD1C8axRkdEH0TlJLpgYhuTNZj0mgAME=; b=Fsi/zWz1OB7yweO/H19xo8I9BqNcoO2+xUNcHwich8jHBbGI1GpcUNItvsM0uqss EM8hyaMZHgdXx0xj0XL9TKwXOxXMpe+1MEJbkp+eSSlZlg0FlpaMYF/5IBK0wRCR 1P9twRDJKpM9wyQNoyvV6KTElj9PjNNm2J/cCXxcZAk=;
X-AuditID: c1b4fb3a-728f89c0000067b4-64-5a8adcecb9a3
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F1.ED.26548.CECDA8A5; Mon, 19 Feb 2018 15:19:25 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Mon, 19 Feb 2018 15:18:35 +0100
From: Christer Holmberg 
To: Eric Rescorla , The IESG 
CC: "draft-ietf-ice-rfc5245bis@ietf.org" ,  Peter Thatcher , "ice-chairs@ietf.org" , "pthatcher@google.com" , "ice@ietf.org" 
Thread-Topic: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
Thread-Index: AdOpa677O8VqdAW5ThyXNM/NhWOUGQ==
Date: Mon, 19 Feb 2018 14:18:35 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.171]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7lu7bO11RBju3sFjMP3md2WLF63Ps FhdnTWaz+Hah1mLGn4nMFteWv2Z1YPNYsKnUY8mSn0wekx+3MQcwR3HZpKTmZJalFunbJXBl nL9wk7HgyDbGiiebnzA1ML7ZyNjFyMkhIWAisf/gVuYuRi4OIYHDjBLPt3SxQThLGCXmLFzJ 2sXIwcEmYCHR/U8bpEFEwEri1e9rLCA1zAJfGSVWbNzJBJIQFqiXeLSqH6xZRKCBUeLLpSms EB16Em+eHmcBsVkEVCUON20Ci/MK+Eq86fzJBmIzCohJfD+1BmwQs4C4xK0n85kgzhOQWLLn PDOELSrx8vE/VghbSeLEw0ZmkOOYBTQl1u/Sh2hVlJjS/ZAdYrygxMmZT1gmMArPQjJ1FkLH LCQds5B0LGBkWcUoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGCkHt/y22sF48LnjIUYBDkYl Hl7/k11RQqyJZcWVuYcYJTiYlUR4fW4AhXhTEiurUovy44tKc1KLDzFKc7AoifM6pVlECQmk J5akZqemFqQWwWSZODilGhhZ/WsvJzkbLZ7XsL1lx5bshzazQ5yieuc4Ml+13FeWyGofr+e1 WDduUvuJOwnLf+9fa/LdPsdi3uKMiCkPWrrqwzJm/tTOKD/Pcznrss5OxmWtG+9KaIVGvAhj n9DYycYmzBtU4hK4dP8foVoHhuX8u+9V+DyalxejxDLVZeuplKl2a48uPa/EUpyRaKjFXFSc CAB66G1IkAIAAA==
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Feb 2018 14:19:34 -0000

SGkgRWtyLA0KDQpUaGFuayBZb3UgZm9yIHRoZSByZXZpZXcgYW5kIGNvbW1lbnRzISBQbGVhc2Ug
c2VlIGlubGluZS4NCg0KTm90ZSB0aGF0IEkgd2lsbCBhZGRyZXNzIHlvdXIgY29tbWVudHMgb24g
dGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGluIGEgc2VwYXJhdGUgcmVwbHkuDQoNCi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClJldmlldyBpbiBjb250ZXh0IGF0
Og0KaHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQvRDMzMTINCg0KPiBJ
TVBPUlRBTlQ6DQo+DQo+ICogIElmIHRoZSBhZ2VudCdzIHRpZS1icmVha2VyIHZhbHVlIGlzIGxh
cmdlciB0aGFuIG9yIGVxdWFsIHRvIHRoZSBjb250ZW50cyBvZiB0aGUgSUNFLUNPTlRST0xMSU5H
IGF0dHJpYnV0ZSwgdGhlIGFnZW50IGdlbmVyYXRlcw0KPiBJTVBPUlRBTlQ6IFRoaXMgYWxnb3Jp
dGhtIHNlZW1zIGxpa2UgaXQncyBub3QgZ29pbmcgdG8gd29yayBwcm9wZXJseS4NCj4gQ29uc2lk
ZXIgdGhlIGNhc2Ugd2hlcmUgQSBhbmQgQiBoYXBwZW4gdG8gaGF2ZSB0aGUgc2FtZSB0aWUtYnJl
YWtlciBhbmQgYm90aCB0aGluayB0aGV5IGFyZSBjb250cm9sbGluZywgYW5kIHRoZSANCj4gQmlu
ZGluZyBSZXF1ZXN0cyBjcm9zcy4gRWFjaCBub3cgc2VuZHMgYSA0ODcgYW5kIHRoZW4gdGhleSBz
d2l0Y2ggdG8gY29udHJvbGxlZC4gVWdoLiBVbmxlc3MgSSdtIG1pc3Npbmcgc29tZXRoaW5nLCAN
Cj4gaWYgdGhlIHRpZS1icmVha2VycyBtYXRjaCwgeW91IGFyZSBzdHVjay4gR2l2ZW4gdGhhdCB0
aGUgY2hhbmNlIGlzIDJeey02NH0gdGhpcyBzZWVtcyB0byBub3QgYmUgYSBjcml0aWNhbCBmYWls
aW5nLCBidXQgdGhlIGFsZ29yaXRobSANCj4gc3RpbGwgc2VlbXMgd3JvbmcuDQoNClRoZSBhbGdv
cml0aG0gaGFzbid0IGNoYW5nZWQgc2luY2UgUkZDIDUyNDUsIGFuZCBub2JvZHkgaW5kaWNhdGVk
IHRoYXQgaXQgZG9lc24ndCB3b3JrLiBJIGd1ZXNzIHBlb3BsZSBhc3N1bWUgdGhhdCBkdWUgdG8g
dGhlIHJhbmRvbSBjaGFyYWN0ZXJpc3RpY3MsIHRoZSBjaGFuY2Ugb2YgYm90aCBhZ2VudHMgdXNp
bmcgdGhlIHNhbWUgdmFsdWUgaXMgZXh0cmVtZWx5IHNtYWxsLg0KDQpBbHNvIG5vdGUgdGhhdCBp
dCBpcyBvbmx5IGluIHNwZWNpYWwgY2FzZXMgd2hlcmUgYm90aCBlbmRwb2ludHMgd2lsbCBpbmRp
Y2F0ZSB0aGUgc2FtZSByb2xlIHRvIGJlZ2luIHdpdGguDQoNCi0tLQ0KDQpSRVNUOg0KDQo+ICAg
c2luZ2xlIHNvbHV0aW9uIHRoYXQgaXMgZmxleGlibGUgZW5vdWdoIHRvIHdvcmsgd2VsbCBpbiBh
bGwNCj4gICBzaXR1YXRpb25zLg0KPiBUaGlzIHNlY3Rpb24gc2VlbXMgcHJldHR5IGRhdGVkLiBB
cmVuJ3QgSUNFIGFuZCBJQ0Utc3R5bGUgc29sdXRpb25zIHByZXR0eSBtdWNoIHRoZSBkZSBmYWN0
byBzdGFuZGFyZCBub3cuDQoNCkkgc3VnZ2VzdCB0byByZW1vdmUgdGhlIHNlbnRlbmNlLg0KDQot
LS0NCg0KPiAgIG1heSBub3QgYmUgYXdhcmUgb2YgaXQuICBUaGUgdHlwZSBvZiBOQVQgYW5kIGl0
cyBwcm9wZXJ0aWVzIGFyZSBhbHNvDQo+ICB1bmtub3duLiAgTCBhbmQgUiBhcmUgY2FwYWJsZSBv
ZiBlbmdhZ2luZyBpbiBhbiBjYW5kaWRhdGUgZXhjaGFuZ2UNCj4gICBwcm9jZXNzLCB3aG9zZSBw
dXJwb3NlIGlzIHRvIHNldCB1cCBhIGRhdGEgc2Vzc2lvbiBiZXR3ZWVuIEwgYW5kIFIuDQo+IE5p
dDogYSBjYW5kaWRhdGUgZXhjaGFuZ2UuIFRoaXMgYXBwZWFycyB0byBiZSBhIHJlc3VsdCBvZiBj
aGFuZ2luZyBvZmZlci9hbnN3ZXIgKHdoZXJlICJhbiIgd2FzIGFwcHJvcHJpYXRlKSB0byAiY2Fu
ZGlkYXRlIg0KDQpDb3JyZWN0LiBJIHdpbGwgZml4IGFzIHN1Z2dlc3RlZC4NCg0KLS0tDQoNCj4g
ICBBdCBsZWFzdCBvbmUgdmlhYmxlIGNhbmRpZGF0ZSBoYXMgYSB0cmFuc3BvcnQgYWRkcmVzcyBv
YnRhaW5lZA0KPiAgIGRpcmVjdGx5IGZyb20gYSBsb2NhbCBpbnRlcmZhY2UuICBTdWNoIGEgY2Fu
ZGlkYXRlIGlzIGNhbGxlZCBhIGhvc3QNCj4gTml0OiB0aGlzIGlzIGF3a3dhcmQuIFBlcmhhcHMg
IlRoZSBmaXJzdCBjYXRlZ29yeSBvZiBjYW5kaWRhdGVzIGFyZSB0aG9zZSB3aXRoIGEgdHJhbnNw
b3J0IC4uLiINCg0KSSB3aWxsIGZpeCBhcyBzdWdnZXN0ZWQuDQoNCi0tLQ0KDQo+ICAgV2hlbiB0
aGUgYWdlbnQgc2VuZHMgdGhlIFRVUk4gQWxsb2NhdGUgcmVxdWVzdCBmcm9tIElQIGFkZHJlc3Mg
YW5kDQo+ICAgcG9ydCBYOngsIHRoZSBOQVQgKGFzc3VtaW5nIHRoZXJlIGlzIG9uZSkgd2lsbCBj
cmVhdGUgYSBiaW5kaW5nDQo+Tml0OiAiYSBUVVJOIEFsbG9jYXRlIg0KDQpJIHdpbGwgZml4IGFz
IHN1Z2dlc3RlZC4NCg0KLS0tDQoNCj4gICB0aGUgbmV4dCBjYW5kaWRhdGUgcGFpciBvbiB0aGUg
bGlzdCBwZXJpb2RpY2FsbHkuICBUaGVzZSBhcmUgY2FsbGVkDQo+ICAgb3JkaW5hcnkgY2hlY2tz
LiAgV2hlbiBhIFNUVU4gdHJhbnNhY3Rpb24gc3VjY2VlZHMsIG9uZSBvciBtb3JlDQo+ICAgY2Fu
ZGlkYXRlIHBhaXJzIHdpbGwgYmVjb21lIHNvIGNhbGxlZCB2YWxpZCBwYWlycywgYW5kIHdpbGwg
YmUgYWRkZWQNCj4gTml0OiBJIHdvdWxkIHF1b3RlICJvcmRpbmFyeSBjaGVjayIgaGVyZSBhbmQg
InRyaWdnZXJlZCBjaGVjayIgYmVsb3cuDQoNCkkgd2lsbCBmaXggYXMgc3VnZ2VzdGVkLg0KDQot
LS0NCg0KPiAgIHByb3ZpZGUgbWVhbnMgdG8gZXhjaGFuZ2UgY2FuZGlkYXRlIGluZm9ybWF0aW9u
IGJldHdlZW4gdGhlIElDRQ0KPiAgIGFnZW50cy4gIFRoZSBzcGVjaWZpYyBkZXRhaWxzIG9mIChp
LmUgaG93IHRvIGVuY29kZSBjYW5kaWRhdGUNCj4gICBpbmZvcm1hdGlvbiBhbmQgdGhlIGFjdHVh
bCBjYW5kaWRhdGUgZXhjaGFuZ2UgcHJvY2VzcykgZm9yIGRpZmZlcmVudA0KPiBOaXQ6IGkuZSAt
PiBpLmUuLA0KDQpJIHdpbGwgZml4IGFzIHN1Z2dlc3RlZC4NCg0KLS0tDQoNCj4gICBOb21pbmF0
aW9uLCBSZWd1bGFyIE5vbWluYXRpb246ICBUaGUgcHJvY2VzcyBvZiB0aGUgY29udHJvbGxpbmcg
YWdlbnQNCj4gICAgICBpbmRpY2F0aW5nIHRvIHRoZSBjb250cm9sbGVkIGFnZW50IHdoaWNoIGNh
bmRpZGF0ZSBwYWlyIHRoZSBJQ0UgR2l2ZW4gdGhhdCB5b3UgaGF2ZSANCj4gICAgICByZW1vdmVk
IEFnZ3Jlc3NpdmUgTm9taW5hdGlvbiwgZG8geW91IHN0aWxsIG5lZWQgdG8gcmVmZXIgdG8gIlJl
Z3VsYXIgTm9taW5hdGlvbiINCg0KUGVvcGxlIGFza2VkIHRvIGtlZXAgaXQgaW4gdGhlIFRlcm1p
bm9sb2d5IHNlY3Rpb24sIHRvIG1ha2UgaXQgY2xlYXIgdGhhdCAibm9taW5hdGlvbiIgaXMgNTI0
NWJpcyByZWZlcnMgdG8gd2hhdCB3YXMgY2FsbGVkICJyZWd1bGFyIG5vbWluYXRpb24iIGluIFJG
QyA1MjQ1Lg0KDQpIb3dldmVyLCBJIHN1Z2dlc3QgdG8gcy9yZWd1bGFyIG5vbWluYXRpb24vbm9t
aW5hdGlvbiBpbiBzZWN0aW9uIDEzLg0KDQotLS0NCg0KPiAgIGNhbmRpZGF0ZSBnYXRoZXJpbmcs
ICgyKSBjYW5kaWRhdGUgcHJpb3JpdGl6YXRpb24sICgzKSByZWR1bmRhbnQNCj4gIGNhbmRpZGF0
ZSBlbGltaW5hdGlvbiwgYW5kICg0KSBzZW5kaW5nIG9mIHRoZSBjYW5kaWRhdGVzIHRvIHRoZSBw
ZWVyLg0KPiBUaGlzIGlzIGFuIG9kZCBkaWFncmFtLiBUaGVyZSdzIG5vIHJlYXNvbiB3aHkgdGhl
c2UgaGF2ZSB0byBoYXBwZW4gaW4gc2VxdWVuY2UgYW5kIGluIGZhY3QgaW4gVHJpY2tsZSBJQ0Us
IHRoZXkgZG9uJ3QsIHNvIA0KPiB0aGlzIGRpYWdyYW0gc2VlbXMgbWlzbGVhZGluZy4sIGFzIHdl
bGwgYXMgcG90ZW50aWFsbHkgY29udHJhZGljdGluZyB0aGUgYmVnaW5uaW5nIG9mIFMgNS4xLjEu
DQo+DQo+ICJBbiBJQ0UgYWdlbnQgZ2F0aGVycyBjYW5kaWRhdGVzIHdoZW4gaXQgYmVsaWV2ZXMg
dGhhdCBjb21tdW5pY2F0aW9uIGlzIGltbWluZW50LiAiDQoNCkkgdGhpbmsgdGhlIHNlcXVlbmNl
IGFwcGxpZXMgdG8gY29yZSBJQ0UsIGFuZCBpcyBhbHNvIGhvdyBpdCdzIGRvbmUgaW4gNTI0NS4g
DQoNClRoZSBmYWN0IHRoYXQgdHJpY2tsZSBJQ0UgZG9lcyBpdCBkaWZmZXJlbnRseSBJIHRoaW5r
IHNoYWxsIGJlIGRlc2NyaWJlZCBpbiB0aGUgdHJpY2tsZSBzcGVjLg0KDQpIb3dldmVyLCBpdCBp
ZiBoZWxwcywgSSBjb3VsZCBhZGQgdGhlIGZvbGxvd2luZyBub3RlOg0KDQoiTk9URTogVGhpcyBz
cGVjaWZpY2F0aW9uIGFzc3VtZXMgdGhhdCBhbGwgY2FuZGlkYXRlcyBhcmUgZ2F0aGVyZWQgYmVm
b3JlIHRoZXkgYXJlIHNlbnQgdG8gdGhlIHBlZXIuIFRoZSB0cmlja2xlIElDRSBleHRlbnNpb25z
IGRlZmluZSBwcm9jZWR1cmVzDQp3aGVyZSBnYXRoZXJlZCBjYW5kaWRhdGVzIGNhbiBiZSBzZW50
IHRvIHRoZSBwZWVyIGFzIHNvb24gYXMgdGhleSBoYXZlIGJlZW4gZ2F0aGVyZWQsIHdoaWxlIGFk
ZGl0aW9uYWwgY2FuZGlkYXRlcyBhcmUgc3RpbGwgZ2F0aGVyZWQuIg0KDQotLS0NCg0KPiAgIFdo
ZW4gY2FuZGlkYXRlcyBhcmUgb2J0YWluZWQsIHVubGVzcyB0aGUgYWdlbnQga25vd3MgZm9yIHN1
cmUgdGhhdA0KPiAgIFJUUC9SVENQIG11bHRpcGxleGluZyB3aWxsIGJlIHVzZWQgKGkuZS4gdGhl
IGFnZW50IGtub3dzIHRoYXQgdGhlDQo+ICAgb3RoZXIgYWdlbnQgYWxzbyBzdXBwb3J0cywgYW5k
IGlzIHdpbGxpbmcgdG8gdXNlLCBSVFAvUlRDUA0KPiBOaXQ6ICJpLmUuLCINCg0KSSB3aWxsIGZp
eCBhcyBzdWdnZXN0ZWQuDQoNCi0tLQ0KDQo+ICAgICAgYWRkcmVzc2VzIHRoYXQgZG8gYWxsb3cg
bG9jYXRpb24gdHJhY2tpbmcsIHRoYXQgYXJlIGNvbmZpZ3VyZWQgb24NCj4gICAgICB0aGUgc2Ft
ZSBpbnRlcmZhY2UsIGFuZCBhcmUgcGFydCBvZiB0aGUgc2FtZSBuZXR3b3JrIHByZWZpeCBNVVNU
DQo+ICAgICAgTk9UIGJlIGdhdGhlcmVkLg0KPiBZb3UgbmVlZCB0byByZW1vdmUgYm90aCBvZiB0
aGVzZSBjb21tYXMsIGJlY2F1c2UgdGhleSBpbmRpY2F0ZSBhIG5vbnJlc3RyaWN0aXZlIGNsYXVz
ZSwgYnV0IHRoaXMgaXMgYSByZXN0cmljdGl2ZSBjbGF1c2UuDQoNCkkgd2lsbCBmaXggYXMgc3Vn
Z2VzdGVkLg0KDQotLS0NCg0KPiAgIFRoZSBnYXRoZXJpbmcgcHJvY2VzcyBpcyBjb250cm9sbGVk
IHVzaW5nIGEgdGltZXIsIFRhLiAgRXZlcnkgdGltZSBUYQ0KPiAgIGV4cGlyZXMsIHRoZSBhZ2Vu
dCBjYW4gZ2VuZXJhdGUgYW5vdGhlciBuZXcgU1RVTiBvciBUVVJOIHRyYW5zYWN0aW9uLg0KPiBO
byBjb21tYSBoZXJlLg0KDQpJIHdpbGwgZml4IGFzIHN1Z2dlc3RlZC4NCg0KLS0tDQoNCj4gICBU
aGUgYWdlbnQgd2lsbCByZWNlaXZlIGEgQmluZGluZyBvciBBbGxvY2F0ZSByZXNwb25zZS4gIEEg
c3VjY2Vzc2Z1bA0KPiAgIEFsbG9jYXRlIHJlc3BvbnNlIHdpbGwgcHJvdmlkZSB0aGUgYWdlbnQg
d2l0aCBhIHNlcnZlciByZWZsZXhpdmUgT3Igbm90aGluZyBvciBhbiBlcnJvci4NCj4NCj4gICAg
ICAgICAgICAgICgyXjgpKihJUCBwcmVjZWRlbmNlKSArDQo+ICAgICAgICAgICAgICAoMl4wKSoo
MjU2IC0gY29tcG9uZW50IElEKSANCj4NCj4gSXNuJ3QgdGhpcyB0aGUgc2FtZSBmb3JtdWxhIGFz
IGluIFMgNS4xLjIuMS4NCg0KU2VjdGlvbiA1LjEuMi4xIGRlZmluZXMgdGhlIGdlbmVyaWMgZm9y
bXVsYS4gVGhpcyBpbnN0YW5jZSBpcyB3aGVuIGl0IGlzIHVzZWQgYnkgYSBMaXRlIGltcGxlbWVu
dGF0aW9uLg0KDQpPZiBjb3Vyc2UsIGluIG9yZGVyIHRvIGFsaWduLCBJIGNvdWxkIHJlcGxhY2Ug
IklQIHByZWNlZGVuY2UiIHdpdGggImxvY2FsIHByZWZlcmVuY2UiLg0KDQotLS0NCg0KPiAgICAg
IEZvdW5kYXRpb246ICBBIHNlcXVlbmNlIG9mIHVwIHRvIDMyIGNoYXJhY3RlcnMuDQo+DQo+IFRo
ZSBGb3VuZGF0aW9uIGlzIG5ldmVyIHRyYW5zbWl0dGVkLCBBRkFJSy4gU28gd2h5IGRvZXMgaXQg
aGF2ZSB0byBiZSB1cCB0byAzMiBjaGFyYWN0ZXJzPyBJdCBjZXJ0YWlubHkgd2Fzbid0IGV4Y2hh
bmdlZCBpbiA1MjQ1Lg0KDQpJdCBpcyBpbmNsdWRlZCBpbiB0aGUgY2FuZGlkYXRlIGF0dHJpYnV0
ZSBkZWZpbmVkIGluIDUyNDUgKFNlY3Rpb24gMTUuMSk6DQoNCiAgICBjYW5kaWRhdGUtYXR0cmli
dXRlICAgPSAiY2FuZGlkYXRlIiAiOiIgZm91bmRhdGlvbiBTUCBjb21wb25lbnQtaWQgU1ANCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0cmFuc3BvcnQgU1ANCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBwcmlvcml0eSBTUA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIGNvbm5lY3Rpb24tYWRkcmVzcyBTUCAgICAgO2Zyb20gUkZDIDQ1NjYNCg0KICAgIGZvdW5k
YXRpb24gICAgICAgICAgICA9IDEqMzJpY2UtY2hhcg0KDQotLS0NCg0KPiAgIGRhdGEgc3RyZWFt
LCBhbmQgZm9yIHVwZGF0aW5nIHRoZSBwZWVyIHdpdGggdGhlIElDRSdzIHNlbGVjdGlvbiwgd2hl
bg0KPiAgIG5lZWRlZC4gIFRoZSBjb250cm9sbGVkIGFnZW50IGlzIHRvbGQgd2hpY2ggY2FuZGlk
YXRlIHBhaXJzIHRvIHVzZQ0KPiAgIGZvciBlYWNoIGRhdGEgc3RyZWFtLCBhbmQgZG9lcyBub3Qg
cmVxdWlyZSB1cGRhdGluZyB0aGUgcGVlciB0bw0KPg0KPiBUb2xkIGJ5IHdobz8NCg0KVGhlIHRl
eHQgc2VlbXMgdG8gYmUgYSBsZWZ0b3Zlci4NCg0KSW4gZmFjdCwgbXkgc3VnZ2VzdGlvbiB3b3Vs
ZCBiZSB0byBvbmx5IGtlZXAgdGhlIGZvbGxvd2luZzoNCg0KICAgIkZvciBlYWNoIHNlc3Npb24s
IGVhY2ggSUNFIGFnZW50IChJbml0aWF0aW5nIGFuZCBSZXNwb25kaW5nKSB0YWtlcyBvbg0KICAg
YSByb2xlLiAgVGhlcmUgYXJlIHR3byByb2xlcyAtLSBjb250cm9sbGluZyBhbmQgY29udHJvbGxl
ZC4gIFRoZQ0KICAgY29udHJvbGxpbmcgYWdlbnQgaXMgcmVzcG9uc2libGUgZm9yIHRoZSBjaG9p
Y2Ugb2YgdGhlIGZpbmFsDQogICBjYW5kaWRhdGUgcGFpcnMgdXNlZCBmb3IgY29tbXVuaWNhdGlv
bnMuIFRoZSBzZWN0aW9ucyBiZWxvdw0KICAgZGVzY3JpYmUgaW4gZGV0YWlsIHRoZSAgYWN0dWFs
IHByb2NlZHVyZXMgZm9sbG93ZWQgYnkgY29udHJvbGxpbmcgYW5kIA0KICAgY29udHJvbGxlZCBh
Z2VudHMuIg0KDQpXaGF0IGEgZnVsbCBhbmQgbGl0ZSBpbXBsZW1lbnRhdGlvbiBkbyBpcyBkZXNj
cmliZWQgaW4gdGhlIHRleHQgYmVsb3cuDQoNCi0tLQ0KDQo+ICAgcGFpciBwcmlvcml0aWVzLCBv
cmRlcnMgcGFpcnMgYnkgcHJpb3JpdHksIHBydW5lcyBwYWlycywgcmVtb3Zlcw0KPiAgIGxvd2Vy
LXByaW9yaXR5IHBhaXJzLCBhbmQgc2V0cyBjaGVjayBsaXN0IHN0YXRlcy4gIElmIGNhbmRpZGF0
ZXMgYXJlDQo+ICAgYWRkZWQgdG8gYSBjaGVjayBsaXN0IChlLmcsIGR1ZSB0byBkZXRlY3Rpb24g
b2YgcGVlciByZWZsZXhpdmUgDQo+DQo+IFBsZWFzZSBmaXggeW91ciBzdWJqZWN0IHZlcmIgYWdy
ZWVtZW50IGhlcmUuDQoNCkkgd2lsbCByZW1vdmUgdGhlIHM6ZXMuDQoNCi0tLQ0KDQo+ICAgICAg
cGFpciBwcmlvcml0eSA9IDJeMzIqTUlOKEcsRCkgKyAyKk1BWChHLEQpICsgKEc+RD8xOjApIA0K
Pg0KPiBUaGlzIHdhcyBraW5kYSB0ZXJyaWJsZSBpbiA1MjQ1LiBHaXZlbiB0aGF0IHlvdSB1c2Ug
aXQgb25jZSwgbWF5YmUganVzdCBoYXZlICsgR1QoRywgRCkNCj4NCj4gQW5kIHRoZW4gc2F5IEdU
KEcsIEQpID09IDEgaWYgRz5EIGFuZCAwIG90aGVyd2lzZS4NCg0KSSBwcm9iYWJseSBqdXN0IGRv
bid0IHNlZSBpdCwgYnV0IHdoYXQgaXMgdGhlIGRpZmZlcmVuY2U/DQoNCi0tLQ0KDQo+ICAgICAg
ICAgICAgICAgICAgICAgICBGaWd1cmUgODogSW5pdGlhbCBQYWlyIFN0YXRlIFRoaXMgZmlndXJl
IGNhcHRpb24gaXMga2luZCBvZiBhIG1lc3MuIEkgc3VnZ2VzdCBqdXN0IHJlbW92aW5nIGl0Lg0K
DQpJIHdpbGwgcmVtb3ZlIGl0Lg0KDQotLS0NCg0KPiAgIHN0YXRlIGluIHRoZSBjaGVjayBsaXN0
IHNldCBoYXMgYmVlbiBwcm9jZXNzZWQsIHRoZSBmaXJzdCBjaGVjayBsaXN0DQo+ICAgaXMgcGlj
a2VkIGFnYWluLiAgRXRjLg0KPiBOaXQ6ICJhZ2FpbiwgZXRjLiINCg0KSSB3aWxsIGZpeCBhcyBz
dWdnZXN0ZWQuDQoNCi0tLQ0KDQo+ICAgcGFpciB0byB0aGUgcmVtb3RlIGNhbmRpZGF0ZSBvZiB0
aGUgcGFpciwgYXMgZGVzY3JpYmVkIGluDQo+ICAgU2VjdGlvbiA3LjIuNC4NCj4gSU1QT1JUQU5U
OiBZb3UgZG9uJ3QganVzdCBzZW5kIGEgU1RVTiByZXF1ZXN0LCB5b3Ugc3RhcnQgYSBTVFVOIHRy
YW5zYWN0aW9uLA0KDQpUaGVyZSBhcmUgbXVsdGlwbGUgaW5zdGFuY2VzIGluIHRoZSBzcGVjIHdo
ZXJlIGl0IHRhbGtzIGFib3V0IHNlbmRpbmcgU1RVTiByZXF1ZXN0cyBvciBCaW5kaW5nIHJlcXVl
c3RzLg0KDQpTZWN0aW9uIDcuMiBwcm92aWRlcyB0aGUgU1RVTiBjbGllbnQgZGV0YWlscywgaW5j
bHVkaW5nIGhvdyB0byBwcm9jZXNzIHRoZSByZXNwb25zZSBldGMuDQoNCi0tLQ0KDQo+ICAgbGlz
dHMuICBPbiB0aGUgb3RoZXIgaGFuZCB0aGUgcmVzcG9uZGluZyBhZ2VudCBlaXRoZXIgcGVyZm9y
bXMgdGhlDQo+ICAgdHJpZ2dlcmVkIG9yIG9yZGluYXJ5IGNoZWNrcyBhcyBkZXNjcmliZWQgYWJv
dmUuDQo+DQo+IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlzIHBhcmFncmFwaC4gV2hhdCBkaXN0aW5j
dGlvbiBhcmUgeW91IHRyeWluZyB0byBkcmF3Lg0KDQpJIGRvbid0IHVuZGVyc3RhbmQgdGhlIHRl
eHQgZWl0aGVyLiBJIHN1Z2dlc3QgdG8gcmVtb3ZlIHRoZSB3aG9sZSBwYXJhZ3JhcGguDQoNCi0t
LQ0KDQo+ICAgbyAgVGhlIGJhc2UgaXMgbG9jYWwgY2FuZGlkYXRlIG9mIHRoZSBjYW5kaWRhdGUg
cGFpciBmcm9tIHdoaWNoIHRoZQ0KPiAgICAgIEJpbmRpbmcgcmVxdWVzdCB3YXMgc2VudC4NCj4g
Tml0OiAiaXMgdGhlIGxvY2FsIg0KDQpJIHdpbGwgZml4IGFzIHN1Z2dlc3RlZC4NCg0KLS0tDQoN
Cj4gICBUaGUgSUNFIGFnZW50IGNvbnN0cnVjdHMgYSBjYW5kaWRhdGUgcGFpciB3aG9zZSBsb2Nh
bCBjYW5kaWRhdGUNCj4gICBlcXVhbHMgdGhlIG1hcHBlZCBhZGRyZXNzIG9mIHRoZSByZXNwb25z
ZSwgYW5kIHdob3NlIHJlbW90ZSBjYW5kaWRhdGUNCj4NCj4gSU1QT1JUQU5UOiBXaGVuIGRvZXMg
dGhpcyBoYXBwZW4/DQoNClRoZSBsYXN0IHNlbnRlbmNlIG9mIHRoZSBwYXJlbnQgc2VjdGlvbiAo
Ny4yLjUuMykgIHNheXM6DQoNCiJJZiBhIGNoZWNrIGlzIGNvbnNpZGVyZWQgYSBzdWNjZXNzLCB0
aGUgSUNFIGFnZW50IHBlcmZvcm1zIChpbiBvcmRlcikgdGhlIGFjdGlvbnMgZGVzY3JpYmVkIGlu
IHRoZSBmb2xsb3dpbmcgc2VjdGlvbnMuIg0KDQotLS0NCg0KPiAgIGEgZGlmZmVyZW50IGNoZWNr
IGxpc3QgdGhhbiB0aGUgb25lIHRvIHdoaWNoIHRoZSBwYWlyIHRoYXQgZ2VuZXJhdGVkDQo+ICAg
dGhlIGNvbm5lY3Rpdml0eSBjaGVja3MpLCBvciBpdCBtYXkgYmUgYSBwYWlyIG5vdCBjdXJyZW50
bHkgaW4gYW55DQo+ICAgY2hlY2sgbGlzdC4NCj4gSU1QT1JUQU5UOiBIb3cgd291bGQgYSB2YWxp
ZCBwYWlyIGJlIG9uIHNvbWUgb3RoZXIgY2hlY2sgbGlzdD8NCg0KVGhhdCBzZWVtcyBsaWtlIGFu
IGVycm9yLCBidXQgSSB3aWxsIHRoaW5rIGEgbGl0dGxlIG1vcmUgYWJvdXQgaXQuDQoNCi0tLQ0K
DQo+ICAgICAgdGhpcyBzcGVjaWZpY2F0aW9uLiAgVGhlcmUgbWF5IGJlIGEgY29uZmxpY3QsIGJ1
dCBpdCBjYW5ub3QgYmUNCj4gICAgICBkZXRlY3RlZC4NCj4gV2hhdCBwcmV2aW91cyB2ZXJzaW9u
PyBUaGlzIHdhcyByZXF1aXJlZCBpbiA1MjQ1LiBNYXliZSBhdCB0aGlzIHBvaW50IHdlIGNhbiBq
dXN0IGRlcHJlY2F0ZSB0aGlzPw0KDQpJIHN1Z2dlc3QgdG8gcmVtb3ZlIHRoZSB3aG9sZSBidWxs
ZXQuDQoNCi0tLQ0KDQo+IDcuMy4xLjMuICBMZWFybmluZyBQZWVyIFJlZmxleGl2ZSBDYW5kaWRh
dGVzIA0KPg0KPlRoaXMgZW50aXJlIHNlY3Rpb24gc2VlbXMgdG8gZHVwbGljYXRlIDcuMi41LjMu
MQ0KDQpTZWN0aW9uIDcuMi41LjMuMSBkZXNjcmliZXMgaG93IGEgU1RVTiBjbGllbnQgZGV0ZWN0
cyBhIHBlZXIgcmVmbGV4aXZlIGNhbmRpZGF0ZSB0aGVuIGl0IHJlY2VpdmVzIGEgU1RVTiByZXNw
b25zZS4NCg0KU2VjdGlvbiA3LjMuMS4zIGRlc2NyaWJlcyBob3cgYSBTVFVOIHNlcnZlciBkZXRl
Y3RzIGEgcGVlciByZWZsZXhpdmUgY2FuZGlkYXRlIHdoZW4gaXQgcmVjZWl2ZXMgYSBTVFVOIHJl
cXVlc3QuDQoNClN1cmUsIHRoZSB0ZXh0IGlzIHNpbWlsYXIsIGJ1dCBzZXBhcmF0ZSBwcm9jZWR1
cmVzLg0KDQotLS0NCg0KPiAgICAgICAgIGluLXByb2dyZXNzIHRyYW5zYWN0aW9uLiAgQ2FuY2Vs
bGF0aW9uIG1lYW5zIHRoYXQgdGhlIGFnZW50DQo+ICAgICAgICAgd2lsbCBub3QgcmV0cmFuc21p
dCB0aGUgcmVxdWVzdCwgd2lsbCBub3QgdHJlYXQgdGhlIGxhY2sgb2YNCj4gICAgICAgICByZXNw
b25zZSB0byBiZSBhIGZhaWx1cmUsIGJ1dCB3aWxsIHdhaXQgdGhlIGR1cmF0aW9uIG9mIHRoZSAN
Cj4NCj4gV2h5IGFyZSB5b3UgY2FuY2VsbGluZyBJbi1Qcm9ncmVzcyBjaGVja3Mgd2hlbiB5b3Ug
cmVjZWl2ZSBhIHBlZXItcmVmbGVjdGl2ZSBjaGVjaz8gDQo+IElmIHlvdSByZWNlaXZlIHR3byBp
biBhIHJvdywgdGhlbiBpdCBzZWVtcyBsaWtlIHRoaXMgZGVsYXlzIGEgc3VjY2Vzc2Z1bCBjaGVj
ay4gDQoNClRydWUuDQoNClNvLCBJIHdpbGwgcmVtb3ZlIHRoZSBjYW5jZWwgcGFydC4NCg0KRG8g
eW91IHN0aWxsIHRoaW5rIGl0IHNob3VsZCBjcmVhdGUgYSBuZXcgYmluZGluZyByZXF1ZXN0LCBv
ciBpcyB0aGUgb25nb2luZyBJbi1Qcm9ncmVzcyBjaGVjayBlbm91Z2ggdG8gY2hlY2sgdGhlIHBh
aXI/DQoNCi0tLQ0KDQo+IE1vcmUgZ2VuZXJhbGx5LCB0aGlzIGRvY3VtZW50IHNob3VsZCBleHBs
YWluIGhvdyB5b3UgZW5kIHVwIGluIHRoaXMNCj4gc2l0dWF0aW9uOiB5b3Ugb25seSBnZXQgaGVy
ZSB3aGVuICJ0aGUgc291cmNlIHRyYW5zcG9ydCBhZGRyZXNzIG9mIHRoZSByZXF1ZXN0IA0KPiBk
b2VzIG5vdCBtYXRjaCBhbnkgZXhpc3RpbmcgcmVtb3RlIGNhbmRpZGF0ZSIsIHNvIGhvdyBjYW4g
aXQgYmUgb24gYSBjaGVjayBsaXN0IA0KPiB1bmxlc3MgdGhpcyBpcyB0aGUgc2Vjb25kIG9ic2Vy
dmF0aW9uIG9mIGEgcGVlciByZWZsZXhpdmUuDQoNCkkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5k
LiBUaGUgc291cmNlIHRyYW5zcG9ydCBzZW50ZW5jZSB5b3UgcmVmZXIgdG8gaXMgcmVsYXRlZCB0
byBkZXRlY3Rpb24gb2YgcGVlciByZWZsZXhpdmUgY2FuZGlkYXRlcy4NCg0KLS0tDQoNCj4gICBQ
cmlvciB0byBub21pbmF0aW5nLCB0aGUgY29udHJvbGxpbmcgYWdlbnQgbGV0IGNvbm5lY3Rpdml0
eSBjaGVja3MNCj4gICBjb250aW51ZSB1bnRpbCBzb21lIHN0b3BwaW5nIGNyaXRlcmlvbiBpcyBt
ZXQuICBBZnRlciB0aGF0LCBiYXNlZCBvbiBsZXRzLg0KPiAgIFRoZSBjcml0ZXJpb24gZGV0YWls
cyBmb3Igc3RvcHBpbmcgdGhlIGNvbm5lY3Rpdml0eSBjaGVja3MgYW5kIGZvcg0KPiAgIHNlbGVj
dGluZyBhIHBhaXIgZm9yIG5vbWluYXRpb24sIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlz
ICJjcml0ZXJpb24gZGV0YWlscyIgc2VlbXMgdW5ncmFtbWF0aWNhbC4gDQo+DQo+ICAgNTI0NSBo
YWQgImNyaXRlcmlhIi4gV2hhdCdzIHdyb25nIHdpdGggdGhhdD8NCg0KSSBoYXZlIG5vIGlkZWEu
IEF0IHNvbWUgcG9pbnQgc29tZW9uZSBoYXMgbW9zdCBsaWtlbHkgcmVxdWVzdGVkIHRoYXQgImNy
aXRlcmlhIiBpcyByZXBsYWNlZCB3aXRoICJjcml0ZXJpb24gZGV0YWlscyIuIEkgY2FuIGNoYW5n
ZSBiYWNrIHRvICJjcml0ZXJpYSIuDQoNCi0tLQ0KDQo+ICAgaGF2ZSBjZWFzZWQgdXNpbmcgYSBn
aXZlbiBsb2NhbCBjYW5kaWRhdGUgKGEgY2FuZGlkYXRlIG1heSBiZSB1c2VkIGJ5DQo+ICAgbXVs
dGlwbGUgSUNFIHNlc3Npb25zLCBlLmcuIGluIGZvcmtpbmcgc2NlbmFyaW9zKSwgdGhlIGFnZW50
IGNhbiBmcmVlDQo+ICAgdGhhdCBjYW5kaWRhdGUuICBUaGUgdGhyZWUtc2Vjb25kIGRlbGF5IGhh
bmRsZXMgY2FzZXMgd2hlbiBhZ2dyZXNzaXZlDQo+IE5pdDogImUuZy4sIg0KDQpJIHdpbGwgZml4
IGFzIHN1Z2dlc3RlZC4NCg0KLS0tDQoNCj4gICBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29s
IChTRFApIFtSRkM0NTY2XSBpcyBkZWZpbmVkIGluDQo+ICAgW0ktRC5pZXRmLW1tdXNpYy1pY2Ut
c2lwLXNkcF0uDQo+IFByZXN1bWFibHkgeW91IHdhbnQgdG8gY2l0ZSA1MjQ1IFMgMTQsIHdoaWNo
IHN0YXRlczoNCj4NCj5Db25zZXF1ZW50bHksIHdoZW4gYSBjb250cm9sbGluZyBhZ2VudCBpcyBj
b21tdW5pY2F0aW5nIHdpdGggYSBwZWVyIHRoYXQgc3VwcG9ydHMgb3B0aW9ucyBpdCBkb2Vzbid0
IGtub3cgYWJvdXQsIHRoZSBhZ2VudCBNVVNUIHJ1biBhIHJlZ3VsYXIgbm9taW5hdGlvbiBhbGdv
cml0aG0uICBXaGVuIHJlZ3VsYXIgbm9taW5hdGlvbiBpcyB1c2VkLCBJQ0Ugd2lsbCBjb252ZXJn
ZSBwZXJmZWN0bHkgZXZlbiB3aGVuIGJvdGggYWdlbnRzIHVzZSBkaWZmZXJlbnQgcGFpciBwcmlv
cml0aXphdGlvbiBhbGdvcml0aG1zLg0KDQpJIGFtIG5vdCBzdXJlIGl0IGlzIHJlbGF0ZWQgdG8g
U0RQLg0KDQpJIHN1Z2dlc3QgdG8gbW9kaWZ5IHRoZSBmaXJzdCBwYXJhZ3JhcGg6DQoNCk9MRDoN
Cg0KICJGb3IgZXhhbXBsZSwgdGhlIGFnZW50IHdpbGwgbm90IHVzZSB0aGUgYWdncmVzc2l2ZSBu
b21pbmF0aW9uIHByb2NlZHVyZSBkZWZpbmVkIGluIFJGQyA1MjQ1LiINCg0KTkVXOg0KDQogIkZv
ciBleGFtcGxlLCB0aGUgYWdlbnQgd2lsbCBub3QgdXNlIHRoZSBhZ2dyZXNzaXZlIG5vbWluYXRp
b24gcHJvY2VkdXJlIGRlZmluZWQgaW4gUkZDIDUyNDUuIEluIGFkZGl0aW9uLA0KICAgSXQgd2ls
bCBlbnN1cmUgdGhhdCBhbiBSRkMgNTI0NS1jb21wbGlhbnQgcGVlciBkb2VzIG5vdCB1c2UgYWdn
cmVzc2l2ZSBub21pbmF0aW9uIGVpdGhlciwgYXMgZGVzY3JpYmVkIGluDQogICBTZWN0aW9uIDE0
IG9mIFJGQyA1MjQ1LiINCg0KLS0tDQoNCj4gICAxNSBzZWNvbmRzLiAgQWdlbnRzIE1BWSB1c2Ug
YSBiaWdnZXIgdmFsdWUsIGJ1dCBNVVNUIE5PVCB1c2UgYSB2YWx1ZQ0KPiAgIHNtYWxsZXIgdGhh
biAxNSBzZWNvbmRzLg0KPiBUaGlzIGlzIGEgdmVyeSBvbGQgbnVtYmVyLiBJcyBpdCBzdXBwb3J0
ZWQgYnkgYW4gbW9kZXJuIG1lYXN1cmVtZW50Pw0KDQpJIGRvbid0IGtub3cuIFRoZSBudW1iZXIg
aXMgdXNlZCBpbiA1MjQ1LCBhbmQgdGhlcmUgd2VyZSBuZXZlciBhbnkgc3VnZ2VzdGlvbnMgdG8g
Y2hhbmdlIGl0Lg0KDQotLS0NCg0KPiAgIHdpbGwgY29udmVyZ2UgcGVyZmVjdGx5IGV2ZW4gd2hl
biBib3RoIGFnZW50cyB1c2UgZGlmZmVyZW50IHBhaXINCj4gICBwcmlvcml0aXphdGlvbiBhbGdv
cml0aG1zLiAgT25lIG9mIHRoZSBrZXlzIHRvIHN1Y2ggY29udmVyZ2VuY2UgaXMNCj4gICB0cmln
Z2VyZWQgY2hlY2tzLCB3aGljaCBlbnN1cmUgdGhhdCB0aGUgbm9taW5hdGVkIHBhaXIgaXMgdmFs
aWRhdGVkIA0KPg0KPiBHaXZlbiB0aGF0IHlvdSBoYXZlIHJlbW92ZXMgYWdncmVzc2l2ZSwgeW91
IHByZXN1bWFibHkgd2FudCB0byByZXZpc2UgdGhpcyBzZWN0aW9uDQoNCkkgc3VnZ2VzdCB0aGUg
Zm9sbG93aW5nIG1vZGlmaWNhdGlvbjoNCg0KT0xEOg0KDQogICAiT25lIG9mIHRoZSBjb21wbGlj
YXRpb25zIGluIGFjaGlldmluZyBpbnRlcm9wZXJhYmlsaXR5IGlzIHRoYXQgSUNFDQogICByZWxp
ZXMgb24gYSBkaXN0cmlidXRlZCBhbGdvcml0aG0gcnVubmluZyBvbiBib3RoIGFnZW50cyB0byBj
b252ZXJnZQ0KICAgb24gYW4gYWdyZWVkIHNldCBvZiBjYW5kaWRhdGUgcGFpcnMuICBJZiB0aGUg
dHdvIGFnZW50cyBydW4gZGlmZmVyZW50DQogICBhbGdvcml0aG1zLCBpdCBjYW4gYmUgZGlmZmlj
dWx0IHRvIGd1YXJhbnRlZSBjb252ZXJnZW5jZSBvbiB0aGUgc2FtZQ0KICAgY2FuZGlkYXRlIHBh
aXJzLiAgVGhlIHJlZ3VsYXIgbm9taW5hdGlvbiBwcm9jZWR1cmUgZGVzY3JpYmVkIGluDQogICBT
ZWN0aW9uIDggZWxpbWluYXRlcyBzb21lIG9mIHRoZSB0aWdodCBjb29yZGluYXRpb24gYnkgZGVs
ZWdhdGluZyB0aGUNCiAgIHNlbGVjdGlvbiBhbGdvcml0aG0gY29tcGxldGVseSB0byB0aGUgY29u
dHJvbGxpbmcgYWdlbnQuDQogICBDb25zZXF1ZW50bHksIHdoZW4gYSBjb250cm9sbGluZyBhZ2Vu
dCBpcyBjb21tdW5pY2F0aW5nIHdpdGggYSBwZWVyDQogICB0aGF0IHN1cHBvcnRzIG9wdGlvbnMg
aXQgZG9lc24ndCBrbm93IGFib3V0LCB0aGUgYWdlbnQgTVVTVCBydW4gYQ0KICAgcmVndWxhciBu
b21pbmF0aW9uIGFsZ29yaXRobS4gIFdoZW4gcmVndWxhciBub21pbmF0aW9uIGlzIHVzZWQsIElD
RQ0KICAgd2lsbCBjb252ZXJnZSBwZXJmZWN0bHkgZXZlbiB3aGVuIGJvdGggYWdlbnRzIHVzZSBk
aWZmZXJlbnQgcGFpcg0KICAgcHJpb3JpdGl6YXRpb24gYWxnb3JpdGhtcy4gIE9uZSBvZiB0aGUg
a2V5cyB0byBzdWNoIGNvbnZlcmdlbmNlIGlzDQogICB0cmlnZ2VyZWQgY2hlY2tzLCB3aGljaCBl
bnN1cmUgdGhhdCB0aGUgbm9taW5hdGVkIHBhaXIgaXMgdmFsaWRhdGVkDQogICBieSBib3RoIGFn
ZW50cy4gIENvbnNlcXVlbnRseSwgYW55IGZ1dHVyZSBJQ0UgZW5oYW5jZW1lbnRzIE1VU1QNCiAg
IHByZXNlcnZlIHRyaWdnZXJlZCBjaGVja3MuIg0KDQoNCk5FVzoNCg0KICAgT25lIG9mIHRoZSBj
b21wbGljYXRpb25zIGluIGFjaGlldmluZyBpbnRlcm9wZXJhYmlsaXR5IGlzIHRoYXQgSUNFDQog
ICByZWxpZXMgb24gYSBkaXN0cmlidXRlZCBhbGdvcml0aG0gcnVubmluZyBvbiBib3RoIGFnZW50
cyB0byBjb252ZXJnZQ0KICAgb24gYW4gYWdyZWVkIHNldCBvZiBjYW5kaWRhdGUgcGFpcnMuICBJ
ZiB0aGUgdHdvIGFnZW50cyBydW4gZGlmZmVyZW50DQogICBhbGdvcml0aG1zLCBpdCBjYW4gYmUg
ZGlmZmljdWx0IHRvIGd1YXJhbnRlZSBjb252ZXJnZW5jZSBvbiB0aGUgc2FtZQ0KICAgY2FuZGlk
YXRlIHBhaXJzLiAgVGhlIG5vbWluYXRpb24gcHJvY2VkdXJlIGRlc2NyaWJlZCBpbg0KICAgU2Vj
dGlvbiA4IGVsaW1pbmF0ZXMgc29tZSBvZiB0aGUgdGlnaHQgY29vcmRpbmF0aW9uIGJ5IGRlbGVn
YXRpbmcgdGhlDQogICBzZWxlY3Rpb24gYWxnb3JpdGhtIGNvbXBsZXRlbHkgdG8gdGhlIGNvbnRy
b2xsaW5nIGFnZW50LCBhbmQgSUNFDQogICB3aWxsIGNvbnZlcmdlIHBlcmZlY3RseSBldmVuIHdo
ZW4gYm90aCBhZ2VudHMgdXNlIGRpZmZlcmVudCBwYWlyDQogICBwcmlvcml0aXphdGlvbiBhbGdv
cml0aG1zLiBPbmUgb2YgdGhlIGtleXMgdG8gc3VjaCBjb252ZXJnZW5jZSBpcw0KICAgdHJpZ2dl
cmVkIGNoZWNrcywgd2hpY2ggZW5zdXJlIHRoYXQgdGhlIG5vbWluYXRlZCBwYWlyIGlzIHZhbGlk
YXRlZA0KICAgYnkgYm90aCBhZ2VudHMuICBDb25zZXF1ZW50bHksIGFueSBmdXR1cmUgSUNFIGVu
aGFuY2VtZW50cyBNVVNUDQogICBwcmVzZXJ2ZSB0cmlnZ2VyZWQgY2hlY2tzLiINCg0KLS0tDQoN
Cj4xNi4gIFNUVU4gRXh0ZW5zaW9ucw0KPk5vbmUgb2YgdGhlIHN0dWZmIGhlcmUgaXMgIk5ldyIg
YW55IGxvbmdlciwgYXMgaXQgd2FzIGFsbG9jYXRlZCBpbiBSRkMgNTI0NS4NCg0KSSdsbCBjaGFu
Z2UgaXQgdG8gIlNUVU4gQXR0cmlidXRlcyIuDQoNCi0tLQ0KDQo+ICAgRmlyc3QgYW5kIGZvcmVt
b3N0LCBJQ0UgbWFrZXMgdXNlIG9mIFRVUk4gYW5kIFNUVU4gc2VydmVycywgd2hpY2gNCj4gICB3
b3VsZCB0eXBpY2FsbHkgYmUgbG9jYXRlZCBpbiB0aGUgZGF0YSBjZW50ZXJzLiAgVGhlIFNUVU4g
c2VydmVycw0KPiAgIHJlcXVpcmUgcmVsYXRpdmVseSBsaXR0bGUgYmFuZHdpZHRoLiAgRm9yIGVh
Y2ggY29tcG9uZW50IG9mIGVhY2ggZGF0YQ0KPiBOaXQ6IHRoaXMgdXNlZCB0byByZWFkICJ0aGUg
bmV0d29yayBvcGVyYXRvcnMgZGF0YSBjZW50ZXJzIiBhbmQgd2hlbiB5b3UgcmVtb3ZlZCAibmV0
d29yayBvcGVyYXRvcnMiIHRoaXMgYmVjYW1lIHVuZ3JhbW1hdGljYWwNCg0KSSB3aWxsIHJlbW92
ZSAidGhlIiBhbmQgc2F5ICJpbiBkYXRhIGNlbnRlcnMiLg0KDQotLS0NCg0KPiAgIHRoZXJlIHdp
bGwgYmUgZm91ciB0cmFuc2FjdGlvbnMgcGVyIGNhbGwgKG9uZSBmb3IgUlRQIGFuZCBvbmUgZm9y
DQo+ICAgUlRDUCwgZm9yIGJvdGggY2FsbGVyIGFuZCBjYWxsZWUpLiAgRWFjaCB0cmFuc2FjdGlv
biBpcyBhIHNpbmdsZQ0KPiAgIHJlcXVlc3QgYW5kIGEgc2luZ2xlIHJlc3BvbnNlLCB0aGUgZm9y
bWVyIGJlaW5nIDIwIGJ5dGVzIGxvbmcsIGFuZCBJcyB0aGlzIGN1cnJlbnRseSB0cnVlPyANCj4N
Cj4gSG93IG1hbnkgcGVvcGxlIHN0aWxsIGRvbid0IHN1cHBvcnQgUlRQLU1VWD8NCg0KSSBkb24n
dCBrbm93LiBCdXQsIHVubGVzcyB5b3UgdXNlIG11eCBleGNsdXNpdmUgdGhlIG9mZmVyZXIgc3Rp
bGwgaGFzIHRvIGdhdGhlciBhbmQgcHJvdmlkZSBSVENQIGNhbmRpZGF0ZXMuDQoNCk1heWJlIHdl
IGNvdWxkIGFkZCB0aGUgZm9sbG93aW5nIG5ldyBwYXJhZ3JhcGggdG8gdGhlIGVuZCBvZiB0aGUg
c2VjdGlvbjoNCg0KIk5PVEU6IEFzIHRoZSB1c2FnZSBvZiBSVFAvUlRDUCBtdWx0aXBsZXhpbmcg
aXMgYmVjb21pbmcgbW9yZSBjb21tb24gaW4gVm9JUCBkZXBsb3ltZW50cywgaXQgd2lsbCByZWR1
Y2UgdGhlIG5lZWQgZm9yIHNlcGFyYXRlIFNUVU4gdHJhbnNhY3Rpb24gZm9yIFJUUCBhbmQgUlRD
UC4iDQoNCi0tLQ0KDQo+ICAgY2FuIGFuZCB3aWxsIHZhcnkgb3ZlciB0aW1lLiAgSW4gYSBuZXR3
b3JrIHdpdGggMTAwJSBiZWhhdmUtY29tcGxpYW50DQo+ICAgTkFULCBpdCBpcyBleGFjdGx5IHpl
cm8uICBBdCB0aW1lIG9mIHdyaXRpbmcsIGxhcmdlLXNjYWxlIGNvbnN1bWVyDQo+ICAgZGVwbG95
bWVudHMgd2VyZSBzZWVpbmcgYmV0d2VlbiA1IGFuZCAxMCBwZXJjZW50IG9mIGNhbGxzIHJlcXVp
cmluZyANCj4NCj4gVGhpcyB0ZXh0IGRhdGVzIHRvIDUyNDUuIElzIHRoYXQgc3RpbGwgdHJ1ZT8N
Cg0KSSBoYXZlIG5vIGlkZWEuIEkgc3VnZ2VzdCB0byByZW1vdmUgdGhlIHNlbnRlbmNlLg0KDQot
LS0NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg==


From nobody Mon Feb 19 06:43:14 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FB0120724 for ; Mon, 19 Feb 2018 06:43:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=rtfm-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 XFqtoj8FQJLB for ; Mon, 19 Feb 2018 06:43:10 -0800 (PST)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 CEA461276AF for ; Mon, 19 Feb 2018 06:43:09 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id z197so12446073qkb.6 for ; Mon, 19 Feb 2018 06:43:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OngBwo81lRpPk+d7kJ+KIvfjW7md5ZnxRFvhGG0tq8I=; b=lvi3WyxSZLwnzMZIDa//tafMBYvOF1zfB20aRM9EZvOEAWs7MhSW2Gl7L8dFpF/vik 3exAr0mUePxy3gcYYvMj4hpdey+baNjChKpW+BxHcA9QXo7ie/pDJw81WPvUNLNvKdiw 2D1+55RuHKYQbFbhzaypCWQ64dbPnrgMaiPWhglsaN31thgQE0dtCnVDwVTnVkVNG8wl P1Twv8Jcx5e6FkuobZMNdbPGErrM54lYwhXwaHIvXQPSuW9EbInB1KnzFtNucIXalqVF Xnned2VuwnsYEvs0kTxfwVk8k56VSfHKwkMvsqs61kpQ7/14WPIKAIh3HkSakpZXa5zl aCjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OngBwo81lRpPk+d7kJ+KIvfjW7md5ZnxRFvhGG0tq8I=; b=BMtLfTRYrWaj9zmqybWhUcdA7X4BdaZvnsK7fgcqz9t00sTDFPeHyRGzFKwrYXOqFh 1atzArED0MLKA2yF2KgJz3cngFozxIn3C5ibOYWPCDB/ugGRTIobh4B9iv79yOAOSvu1 8753M3s0thigjFX2LSuuAi3STRy33D3lJr569SzzgZfbhUtrlP4f68P//BDtU25EJ9oy ikszv3/TwYdhVIajdwHX4/0OfaWzx2JqYLjKhfIj5oKcEcZ69lfYcnzxQtjdFy/XpIZZ AY2glz1oeOFJFrwfGmSK0UfQgZyPukxzsmI2quQGSST3X9osMLryr9BLtVhcFNBqZS0B h1GQ==
X-Gm-Message-State: APf1xPAQmg5eCosc1OI9gPxxRF3NTss8DVMK5zKCpZJfUQ6dCvTFWkTD fC9dWbCZM654zRaluK39V2Smhk6JC3Ao9OGjK6xWtg==
X-Google-Smtp-Source: AH8x226jT8S2Ec+9ufJZ58b9Or3ITmUUwKl3Om4WjUMY6mvyih23NUQlRLek6b1tdA7hMTm8GSUvqvSwYI/3Oh4spww=
X-Received: by 10.55.221.198 with SMTP id u67mr24269138qku.91.1519051388790; Mon, 19 Feb 2018 06:43:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Mon, 19 Feb 2018 06:42:28 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se>
From: Eric Rescorla 
Date: Mon, 19 Feb 2018 06:42:28 -0800
Message-ID: 
To: Christer Holmberg 
Cc: The IESG ,  "draft-ietf-ice-rfc5245bis@ietf.org" ,  "ice-chairs@ietf.org" , "pthatcher@google.com" ,  "ice@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114992e06cca0f056591b6c9"
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Feb 2018 14:43:13 -0000

--001a114992e06cca0f056591b6c9
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 19, 2018 at 6:18 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi Ekr,
>
> Thank You for the review and comments! Please see inline.
>
> Note that I will address your comments on the Security Considerations in a
> separate reply.
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Review in context at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3312
>
> > IMPORTANT:
> >
> > *  If the agent's tie-breaker value is larger than or equal to the
> contents of the ICE-CONTROLLING attribute, the agent generates
> > IMPORTANT: This algorithm seems like it's not going to work properly.
> > Consider the case where A and B happen to have the same tie-breaker and
> both think they are controlling, and the
> > Binding Requests cross. Each now sends a 487 and then they switch to
> controlled. Ugh. Unless I'm missing something,
> > if the tie-breakers match, you are stuck. Given that the chance is
> 2^{-64} this seems to not be a critical failing, but the algorithm
> > still seems wrong.
>
> The algorithm hasn't changed since RFC 5245, and nobody indicated that it
> doesn't work.


I just explained why it doesn't work. Do you think this analysis is wrong?


I guess people assume that due to the random characteristics, the chance of
> both agents using the same value is extremely small.


Yes, I agree that the chance of experiencing the problem in the field is
very low. But that doesn't make the algorithm right, and it's not sensible
to (a) specify the edge case behavior (b) specify it so that it doesn't
work correctly. Better would be to return a *different* error that says you
have unresolvable role conflict.




> >   Nomination, Regular Nomination:  The process of the controlling agent
> >      indicating to the controlled agent which candidate pair the ICE
> Given that you have
> >      removed Aggressive Nomination, do you still need to refer to
> "Regular Nomination"
>
> People asked to keep it in the Terminology section, to make it clear that
> "nomination" is 5245bis refers to what was called "regular nomination" in
> RFC 5245.
>

OK, but then you should explain why you are using "regular" here.


>   candidate gathering, (2) candidate prioritization, (3) redundant
> >  candidate elimination, and (4) sending of the candidates to the peer.
> > This is an odd diagram. There's no reason why these have to happen in
> sequence and in fact in Trickle ICE, they don't, so
> > this diagram seems misleading., as well as potentially contradicting the
> beginning of S 5.1.1.
> >
> > "An ICE agent gathers candidates when it believes that communication is
> imminent. "
>
> I think the sequence applies to core ICE, and is also how it's done in
> 5245.
>
> The fact that trickle ICE does it differently I think shall be described
> in the trickle spec.
>
> However, it if helps, I could add the following note:
>
> "NOTE: This specification assumes that all candidates are gathered before
> they are sent to the peer. The trickle ICE extensions define procedures
> where gathered candidates can be sent to the peer as soon as they have
> been gathered, while additional candidates are still gathered."
>

The issue here isn't that all candidates are gathered before they are sent
to the peer but rather  that the diagram implies that no gathering happens
before the peer's candidates are received. That's not a requirement of
5245, and, as I said, contradicts the beginning of S 5.1.1.



> >   The agent will receive a Binding or Allocate response.  A successful
> >   Allocate response will provide the agent with a server reflexive Or
> nothing or an error.
> >
> >              (2^8)*(IP precedence) +
> >              (2^0)*(256 - component ID)
> >
> > Isn't this the same formula as in S 5.1.2.1.
>
> Section 5.1.2.1 defines the generic formula. This instance is when it is
> used by a Lite implementation.
>

Of course, in order to align, I could replace "IP precedence" with "local
> preference".
>

My suggestion is to have one copy.


> >      Foundation:  A sequence of up to 32 characters.
> >
> > The Foundation is never transmitted, AFAIK. So why does it have to be up
> to 32 characters? It certainly wasn't exchanged in 5245.
>
> It is included in the candidate attribute defined in 5245 (Section 15.1):
>
>     candidate-attribute   = "candidate" ":" foundation SP component-id SP
>                                transport SP
>                                priority SP
>                                connection-address SP     ;from RFC 4566
>
>     foundation            = 1*32ice-char


My mistake.




> >   data stream, and for updating the peer with the ICE's selection, when
> >   needed.  The controlled agent is told which candidate pairs to use
> >   for each data stream, and does not require updating the peer to
> >
> > Told by who?
>
> The text seems to be a leftover.
>
> In fact, my suggestion would be to only keep the following:
>
>    "For each session, each ICE agent (Initiating and Responding) takes on
>    a role.  There are two roles -- controlling and controlled.  The
>    controlling agent is responsible for the choice of the final
>    candidate pairs used for communications. The sections below
>    describe in detail the  actual procedures followed by controlling and
>    controlled agents."
>
> What a full and lite implementation do is described in the text below.
>

Fine.



>      pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
> >
> > This was kinda terrible in 5245. Given that you use it once, maybe just
> have + GT(G, D)
> >
> > And then say GT(G, D) == 1 if G>D and 0 otherwise.
>
> I probably just don't see it, but what is the difference?
>

It has the same semantics but it's easier to read. I mean, either you think
the C syntax is self-explanatory or you
don't. If you do, then you don't need to explain it. If you don't, it's
opaque in the expression,



> >   pair to the remote candidate of the pair, as described in
> >   Section 7.2.4.
> > IMPORTANT: You don't just send a STUN request, you start a STUN
> transaction,
>
> There are multiple instances in the spec where it talks about sending STUN
> requests or Binding requests.


I agree, but this statement is still confusing. Is there a reason not to
change it?




> >   The ICE agent constructs a candidate pair whose local candidate
> >   equals the mapped address of the response, and whose remote candidate
> >
> > IMPORTANT: When does this happen?
>
> The last sentence of the parent section (7.2.5.3)  says:
>
> "If a check is considered a success, the ICE agent performs (in order) the
> actions described in the following sections."
>

Please add a reverse reference.


>   a different check list than the one to which the pair that generated
> >   the connectivity checks), or it may be a pair not currently in any
> >   check list.
> > IMPORTANT: How would a valid pair be on some other check list?
>
> That seems like an error, but I will think a little more about it.
>

Thanks.



>
> ---
>
> >      this specification.  There may be a conflict, but it cannot be
> >      detected.
> > What previous version? This was required in 5245. Maybe at this point we
> can just deprecate this?
>
> I suggest to remove the whole bullet.
>
> ---
>
> > 7.3.1.3.  Learning Peer Reflexive Candidates
> >
> >This entire section seems to duplicate 7.2.5.3.1
>
> Section 7.2.5.3.1 describes how a STUN client detects a peer reflexive
> candidate then it receives a STUN response.
>
> Section 7.3.1.3 describes how a STUN server detects a peer reflexive
> candidate when it receives a STUN request.
>
> Sure, the text is similar, but separate procedures.
>

This would benefit from consolidation.



>
> >         in-progress transaction.  Cancellation means that the agent
> >         will not retransmit the request, will not treat the lack of
> >         response to be a failure, but will wait the duration of the
> >
> > Why are you cancelling In-Progress checks when you receive a
> peer-reflective check?
> > If you receive two in a row, then it seems like this delays a successful
> check.
>
> True.
>
> So, I will remove the cancel part.
>
> Do you still think it should create a new binding request, or is the
> ongoing In-Progress check enough to check the pair?
>

My initial reaction is you don't need to do anything extra, but I could
easily be wrong here.


> More generally, this document should explain how you end up in this
> > situation: you only get here when "the source transport address of the
> request
> > does not match any existing remote candidate", so how can it be on a
> check list
> > unless this is the second observation of a peer reflexive.
>
> I am not sure I understand. The source transport sentence you refer to is
> related to detection of peer reflexive candidates.
>

My question is what sequence of events can lead to this situation, as it is
surprising to the readers.



> >   have ceased using a given local candidate (a candidate may be used by
> >   multiple ICE sessions, e.g. in forking scenarios), the agent can free
> >   that candidate.  The three-second delay handles cases when aggressive
> > Nit: "e.g.,"
>
> I will fix as suggested.
>
> ---
>
> >   Session Description Protocol (SDP) [RFC4566] is defined in
> >   [I-D.ietf-mmusic-ice-sip-sdp].
> > Presumably you want to cite 5245 S 14, which states:
> >
> >Consequently, when a controlling agent is communicating with a peer that
> supports options it doesn't know about, the agent MUST run a regular
> nomination algorithm.  When regular nomination is used, ICE will converge
> perfectly even when both agents use different pair prioritization
> algorithms.
>
> I am not sure it is related to SDP.
>
> I suggest to modify the first paragraph:
>
> OLD:
>
>  "For example, the agent will not use the aggressive nomination procedure
> defined in RFC 5245."
>
> NEW:
>
>  "For example, the agent will not use the aggressive nomination procedure
> defined in RFC 5245. In addition,
>    It will ensure that an RFC 5245-compliant peer does not use aggressive
> nomination either, as described in
>    Section 14 of RFC 5245."
>

Perhaps:
"as required by Section 14 of RFC 5245 for peers which receive unknown ICE
options"



>
> >   15 seconds.  Agents MAY use a bigger value, but MUST NOT use a value
> >   smaller than 15 seconds.
> > This is a very old number. Is it supported by an modern measurement?
>
> I don't know. The number is used in 5245,


Right, that's my point.


and there were never any suggestions to change it.
>

OK.


> NEW:
>
>    One of the complications in achieving interoperability is that ICE
>    relies on a distributed algorithm running on both agents to converge
>    on an agreed set of candidate pairs.  If the two agents run different
>    algorithms, it can be difficult to guarantee convergence on the same
>    candidate pairs.  The nomination procedure described in
>    Section 8 eliminates some of the tight coordination by delegating the
>

some of the need for tight



>    selection algorithm completely to the controlling agent, and ICE
>    will converge perfectly even when both agents use different pair
>    prioritization algorithms. One of the keys to such convergence is
>    triggered checks, which ensure that the nominated pair is validated
>    by both agents.  Consequently, any future ICE enhancements MUST
>    preserve triggered checks."
>
>


> >   there will be four transactions per call (one for RTP and one for
> >   RTCP, for both caller and callee).  Each transaction is a single
> >   request and a single response, the former being 20 bytes long, and Is
> this currently true?
> >
> > How many people still don't support RTP-MUX?
>
> I don't know. But, unless you use mux exclusive the offerer still has to
> gather and provide RTCP candidates.
>

Right, but then there will be three transactions per call in the common
case.



> >   can and will vary over time.  In a network with 100% behave-compliant
> >   NAT, it is exactly zero.  At time of writing, large-scale consumer
> >   deployments were seeing between 5 and 10 percent of calls requiring
> >
> > This text dates to 5245. Is that still true?
>
> I have no idea. I suggest to remove the sentence.
>

WFM.

-Ekr


>
> ---
>
> Regards,
>
> Christer
>

--001a114992e06cca0f056591b6c9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Feb 19, 2018 at 6:18 AM, Christer Holmberg &l=
t;chris=
ter.holmberg@ericsson.com> wrote:
Hi Ekr,



Thank You for the review and comments! Please see inline.



Note that I will address your comments on the Security Considerations in a =
separate reply.



-----------------------------------------------------------------=
-----

COMMENT:

-----------------------------------------------------------------=
-----



Review in context at:

https://mozphab-ietf.devsvcdev.mozaws.net/D3312<=
/a>



> IMPORTANT:

>

> *=C2=A0 If the agent's tie-breaker value is larger than or equal t=
o the contents of the ICE-CONTROLLING attribute, the agent generates

> IMPORTANT: This algorithm seems like it's not going to work proper=
ly.

> Consider the case where A and B happen to have the same tie-breaker an=
d both think they are controlling, and the

> Binding Requests cross. Each now sends a 487 and then they switch to c=
ontrolled. Ugh. Unless I'm missing something,

> if the tie-breakers match, you are stuck. Given that the chance is 2^{=
-64} this seems to not be a critical failing, but the algorithm

> still seems wrong.



The algorithm hasn't changed since RFC 5245, and nobody indicated that =
it doesn't work.



I guess people assume that =
due to the random characteristics, the chance of both agents using the same=
 value is extremely small.

Yes, I agree tha=
t the chance of experiencing the problem in the field is very low. But that=
 doesn't make the algorithm right, and it's not sensible to (a) spe=
cify the edge case behavior (b) specify it so that it doesn't work corr=
ectly. Better would be to return a *different* error that says you have unr=
esolvable role conflict.


=C2=A0

>=C2=A0 =C2=A0Nomination, Regular Nomination:=C2=A0 The process of the c=
ontrolling agent

>=C2=A0 =C2=A0 =C2=A0 indicating to the controlled agent which candidate=
 pair the ICE Given that you have

>=C2=A0 =C2=A0 =C2=A0 removed Aggressive Nomination, do you still need t=
o refer to "Regular Nomination"



People asked to keep it in the Terminology section, to make it clear that &=
quot;nomination" is 5245bis refers to what was called "regular no=
mination" in RFC 5245.

OK, but the=
n you should explain why you are using "regular" here.
=



>=C2=A0 =C2=A0candidate gathering, (2) candidate prioritization, (3) red=
undant

>=C2=A0 candidate elimination, and (4) sending of the candidates to the =
peer.

> This is an odd diagram. There's no reason why these have to happen=
 in sequence and in fact in Trickle ICE, they don't, so

> this diagram seems misleading., as well as potentially contradicting t=
he beginning of S 5.1.1.

>

> "An ICE agent gathers candidates when it believes that communicat=
ion is imminent. "



I think the sequence applies to core ICE, and is also how it's done in =
5245.



The fact that trickle ICE does it differently I think shall be described in=
 the trickle spec.



However, it if helps, I could add the following note:



"NOTE: This specification assumes that all candidates are gathered bef=
ore they are sent to the peer. The trickle ICE extensions define procedures=


where gathered candidates can be sent to the peer as soon as they have been=
 gathered, while additional candidates are still gathered."

The issue here isn't that all candidates are =
gathered before they are sent to the peer but rather=C2=A0 that the diagram=
 implies that no gathering happens before the peer's candidates are rec=
eived. That's not a requirement of 5245, and, as I said, contradicts th=
e beginning of S 5.1.1.





>=C2=A0 =C2=A0The agent will receive a Binding or Allocate response.=C2=
=A0 A successful

>=C2=A0 =C2=A0Allocate response will provide the agent with a server ref=
lexive Or nothing or an error.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (2^8)*(IP precedence) =
+

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (2^0)*(256 - component=
 ID)

>

> Isn't this the same formula as in S 5.1.2.1.



Section 5.1.2.1 defines the generic formula. This instance is when it is us=
ed by a Lite implementation.

Of course, in order to align, I could replace "IP prec=
edence" with "local preference".

My suggestion is to have one copy.
=C2=A0

>=C2=A0 =C2=A0 =C2=A0 Foundation:=C2=A0 A sequence of up to 32 character=
s.

>

> The Foundation is never transmitted, AFAIK. So why does it have to be =
up to 32 characters? It certainly wasn't exchanged in 5245.



It is included in the candidate attribute defined in 5245 (Section 15.1):


=C2=A0 =C2=A0 candidate-attribute=C2=A0 =C2=A0=3D "candidate" &qu=
ot;:" foundation SP component-id SP

=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 =C2=A0 =C2=A0 =C2=A0transport SP

=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 =C2=A0 =C2=A0 =C2=A0priority SP

=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 =C2=A0 =C2=A0 =C2=A0connection-address SP=C2=A0 =C2=A0 =
=C2=A0;from RFC 4566



=C2=A0 =C2=A0 foundation=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 1*32i=
ce-char

My mistake.
=C2=A0

=C2=A0

>=C2=A0 =C2=A0data stream, and for updating the peer with the ICE's =
selection, when

>=C2=A0 =C2=A0needed.=C2=A0 The controlled agent is told which candidate=
 pairs to use

>=C2=A0 =C2=A0for each data stream, and does not require updating the pe=
er to

>

> Told by who?



The text seems to be a leftover.



In fact, my suggestion would be to only keep the following:



=C2=A0 =C2=A0"For each session, each ICE agent (Initiating and Respond=
ing) takes on

=C2=A0 =C2=A0a role.=C2=A0 There are two roles -- controlling and controlle=
d.=C2=A0 The

=C2=A0 =C2=A0controlling agent is responsible for the choice of the final
=C2=A0 =C2=A0candidate pairs used for communications. The sections below
=C2=A0 =C2=A0describe in detail the=C2=A0 actual procedures followed by con=
trolling and

=C2=A0 =C2=A0controlled agents."



What a full and lite implementation do is described in the text below.
<=
/blockquote>

Fine.
=C2=A0

=



>=C2=A0 =C2=A0 =C2=A0 pair priority =3D 2^32*MIN(G,D) + 2*MAX(G,D) + (G&=
gt;D?1:0)

>

> This was kinda terrible in 5245. Given that you use it once, maybe jus=
t have + GT(G, D)

>

> And then say GT(G, D) =3D=3D 1 if G>D and 0 otherwise.



I probably just don't see it, but what is the difference?

It has the same semantics but it's easier to rea=
d. I mean, either you think the C syntax is self-explanatory or you
don't. If you do, then you don't need to explain it. If you don&=
#39;t, it's opaque in the expression,





>=C2=A0 =C2=A0pair to the remote candidate of the pair, as described in<=
br>
>=C2=A0 =C2=A0Section 7.2.4.

> IMPORTANT: You don't just send a STUN request, you start a STUN tr=
ansaction,



There are multiple instances in the spec where it talks about sending STUN =
requests or Binding requests.

I agree, but =
this statement is still confusing. Is there a reason not to change it?


=C2=A0

>=C2=A0 =C2=A0The ICE agent constructs a candidate pair whose local cand=
idate

>=C2=A0 =C2=A0equals the mapped address of the response, and whose remot=
e candidate

>

> IMPORTANT: When does this happen?



The last sentence of the parent section (7.2.5.3)=C2=A0 says:



"If a check is considered a success, the ICE agent performs (in order)=
 the actions described in the following sections."

Please add a reverse reference.

<=
br>

>=C2=A0 =C2=A0a different check list than the one to which the pair that=
 generated

>=C2=A0 =C2=A0the connectivity checks), or it may be a pair not currentl=
y in any

>=C2=A0 =C2=A0check list.

> IMPORTANT: How would a valid pair be on some other check list?



That seems like an error, but I will think a little more about it.

Thanks.

=C2=A0



---



>=C2=A0 =C2=A0 =C2=A0 this specification.=C2=A0 There may be a conflict,=
 but it cannot be

>=C2=A0 =C2=A0 =C2=A0 detected.

> What previous version? This was required in 5245. Maybe at this point =
we can just deprecate this?



I suggest to remove the whole bullet.



---



> 7.3.1.3.=C2=A0 Learning Peer Reflexive Candidates

>

>This entire section seems to duplicate 7.2.5.3.1



Section 7.2.5.3.1 describes how a STUN client detects a peer reflexive cand=
idate then it receives a STUN response.



Section 7.3.1.3 describes how a STUN server detects a peer reflexive candid=
ate when it receives a STUN request.



Sure, the text is similar, but separate procedures.
This would benefit from consolidation.

=C2=A0



>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in-progress transaction.=C2=A0 Cancel=
lation means that the agent

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0will not retransmit the request, will=
 not treat the lack of

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0response to be a failure, but will wa=
it the duration of the

>

> Why are you cancelling In-Progress checks when you receive a peer-refl=
ective check?

> If you receive two in a row, then it seems like this delays a successf=
ul check.



True.



So, I will remove the cancel part.



Do you still think it should create a new binding request, or is the ongoin=
g In-Progress check enough to check the pair?

My initial reaction is you don't need to do anything extra, but =
I could easily be wrong here.



> More generally, this document should explain how you end up in this
> situation: you only get here when "the source transport address o=
f the request

> does not match any existing remote candidate", so how can it be o=
n a check list

> unless this is the second observation of a peer reflexive.



I am not sure I understand. The source transport sentence you refer to is r=
elated to detection of peer reflexive candidates.

=

My question is what sequence of events can lead to this situatio=
n, as it is surprising to the readers.


<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">


>=C2=A0 =C2=A0have ceased using a given local candidate (a candidate may=
 be used by

>=C2=A0 =C2=A0multiple ICE sessions, e.g. in forking scenarios), the age=
nt can free

>=C2=A0 =C2=A0that candidate.=C2=A0 The three-second delay handles cases=
 when aggressive

> Nit: "e.g.,"



I will fix as suggested.



---



>=C2=A0 =C2=A0Session Description Protocol (SDP) [RFC4566] is defined in=


>=C2=A0 =C2=A0[I-D.ietf-mmusic-ice-sip-sdp].

> Presumably you want to cite 5245 S 14, which states:

>

>Consequently, when a controlling agent is communicating with a peer tha=
t supports options it doesn't know about, the agent MUST run a regular =
nomination algorithm.=C2=A0 When regular nomination is used, ICE will conve=
rge perfectly even when both agents use different pair prioritization algor=
ithms.



I am not sure it is related to SDP.



I suggest to modify the first paragraph:



OLD:



=C2=A0"For example, the agent will not use the aggressive nomination p=
rocedure defined in RFC 5245."



NEW:



=C2=A0"For example, the agent will not use the aggressive nomination p=
rocedure defined in RFC 5245. In addition,

=C2=A0 =C2=A0It will ensure that an RFC 5245-compliant peer does not use ag=
gressive nomination either, as described in

=C2=A0 =C2=A0Section 14 of RFC 5245."

<=
div>Perhaps:
"as required by Section 14 of RFC 5245 for peer=
s which receive unknown ICE options"

=C2=A0


>=C2=A0 =C2=A015 seconds.=C2=A0 Agents MAY use a bigger value, but MUST =
NOT use a value

>=C2=A0 =C2=A0smaller than 15 seconds.

> This is a very old number. Is it supported by an modern measurement?


I don't know. The number is used in 5245,

Right, that's my point.


 and there were never any suggestions to change it.

OK.
=C2=A0

NEW:



=C2=A0 =C2=A0One of the complications in achieving interoperability is that=
 ICE

=C2=A0 =C2=A0relies on a distributed algorithm running on both agents to co=
nverge

=C2=A0 =C2=A0on an agreed set of candidate pairs.=C2=A0 If the two agents r=
un different

=C2=A0 =C2=A0algorithms, it can be difficult to guarantee convergence on th=
e same

=C2=A0 =C2=A0candidate pairs.=C2=A0 The nomination procedure described in
=C2=A0 =C2=A0Section 8 eliminates some of the tight coordination by delegat=
ing the

some of the need for tight

=C2=A0

=C2=A0 =C2=A0selection algorithm completely to the controlling agent, and I=
CE

=C2=A0 =C2=A0will converge perfectly even when both agents use different pa=
ir

=C2=A0 =C2=A0prioritization algorithms. One of the keys to such convergence=
 is

=C2=A0 =C2=A0triggered checks, which ensure that the nominated pair is vali=
dated

=C2=A0 =C2=A0by both agents.=C2=A0 Consequently, any future ICE enhancement=
s MUST

=C2=A0 =C2=A0preserve triggered checks."


=

=C2=A0

>=C2=A0 =C2=A0there will be four transactions per call (one for RTP and =
one for

>=C2=A0 =C2=A0RTCP, for both caller and callee).=C2=A0 Each transaction =
is a single

>=C2=A0 =C2=A0request and a single response, the former being 20 bytes l=
ong, and Is this currently true?

>

> How many people still don't support RTP-MUX?



I don't know. But, unless you use mux exclusive the offerer still has t=
o gather and provide RTCP candidates.

R=
ight, but then there will be three transactions per call in the common case=
.

=C2=A0

>=C2=A0 =C2=A0can and will vary over time.=C2=A0 In a network with 100% =
behave-compliant

>=C2=A0 =C2=A0NAT, it is exactly zero.=C2=A0 At time of writing, large-s=
cale consumer

>=C2=A0 =C2=A0deployments were seeing between 5 and 10 percent of calls =
requiring

>

> This text dates to 5245. Is that still true?



I have no idea. I suggest to remove the sentence.

=

WFM.

-Ekr
=C2=A0



---



Regards,



Christer





--001a114992e06cca0f056591b6c9--


From nobody Mon Feb 19 09:19:21 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1188412946D for ; Mon, 19 Feb 2018 09:19:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 212OViaD-PBX for ; Mon, 19 Feb 2018 09:19:17 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E294C126CD8 for ; Mon, 19 Feb 2018 09:19:17 -0800 (PST)
Received: from [10.0.1.105] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w1JHJDI3003097 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 19 Feb 2018 11:19:14 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.105]
From: Ben Campbell 
Message-Id: <1504CC1C-C872-4AC5-9003-E28488FE9B99@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_0D79DB3E-67FF-4907-ABCC-F2280A0DEA61"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 19 Feb 2018 11:19:12 -0600
In-Reply-To: 
Cc: "ice@ietf.org" , "ice-chairs@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , The IESG , "pthatcher@google.com" 
To: Eric Rescorla , Christer Holmberg 
References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se> 
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Feb 2018 17:19:19 -0000

--Apple-Mail=_0D79DB3E-67FF-4907-ABCC-F2280A0DEA61
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Feb 19, 2018, at 8:42 AM, Eric Rescorla  wrote:
>=20
>>> > IMPORTANT:
>>> >
>>> > *  If the agent's tie-breaker value is larger than or equal to the =
contents of the ICE-CONTROLLING attribute, the agent generates
>>> > IMPORTANT: This algorithm seems like it's not going to work =
properly.
>>> > Consider the case where A and B happen to have the same =
tie-breaker and both think they are controlling, and the
>>> > Binding Requests cross. Each now sends a 487 and then they switch =
to controlled. Ugh. Unless I'm missing something,
>>> > if the tie-breakers match, you are stuck. Given that the chance is =
2^{-64} this seems to not be a critical failing, but the algorithm
>>> > still seems wrong.
>>>=20
>> The algorithm hasn't changed since RFC 5245, and nobody indicated =
that it doesn't work.
>>=20
> I just explained why it doesn't work. Do you think this analysis is =
wrong?
>=20
>=20
>> I guess people assume that due to the random characteristics, the =
chance of both agents using the same value is extremely small.
>>=20
> Yes, I agree that the chance of experiencing the problem in the field =
is very low. But that doesn't make the algorithm right, and it's not =
sensible to (a) specify the edge case behavior (b) specify it so that it =
doesn't work correctly. Better would be to return a *different* error =
that says you have unresolvable role conflict.
>=20
>=20

This was a fix that the WG did not choose to pursue in this particular =
bis draft. That may very well be because no one noticed it before. =
Unless one of you sees an obvious fix, this will probably need some WG =
discussion.

Given that this problem 1) only matters for certain 3PCC like scenarios, =
2) only has (as Ekr mentions) a 2^-64 chance of happening does anyone =
think it is worth delaying this draft to fix it? Would it be acceptable =
to note the potential problem and move on?

Thanks!

Ben.

--Apple-Mail=_0D79DB3E-67FF-4907-ABCC-F2280A0DEA61
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

iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlqLBxAACgkQgFZKbJXz
1A2iOxAAxSrPBsEuhxyhrll+E7dqQRURl/tzcqlYLPx67sY8PAv8k9xgzaT5ZVhV
iyirPp9pUUqrHmbU7VbstAm/dFMZ2CkHUqzBWh0MJkR4jsP1AYSZyZkn+pqZy4P2
Fr3BSzbeIqRaE3wx3vv1qe8BxDy518Aiz5y3M2XdDuqeWskVng2F+5von/NSrpyF
XzcLR1N3eUg2ok9Ao6rBsma2i7W/ctf1at2N6OqOg2S82OGFSO0/MAelKaNCogLo
hB0kzndwOZxZL33NPT/gNIZTsvJhBdYX+XxqP3zaer/OVW/oz0fL8vHguP6wB6WB
uwQtKNKJioCdZohHHbhGeEhD2bmerdrDtn0jAhmOOG94BQJiZdkRaPRJ6ro1vdSf
eXdOMKHfKGPLjwYrMask0r18GFjHaSGrzlrfjI8pgD9RTqg/BDICF5W8PE6+miB1
WbsTT415tO9HcgOWjK70i8ZCAkDtkxqROvfQBr32zWAw9MqG7OV+K4rs6vYNRAeQ
4iRAJIlFzWoYUSJFpXHs35HRRQvqiNjwZw32Oj7XOrjY6HrGMvLPzQELlFO2BFxA
VqC+ZUt9drPK70mXG6/IbNestFkobV8KRxvFbHs5dYE1ronxtg6UXvRCdokaz/jC
bM4qu6A4eyL3fxpa23/X6+zRcoi33mogxAKcVYz3jZQZGQHFgpQ=
=NB1r
-----END PGP SIGNATURE-----

--Apple-Mail=_0D79DB3E-67FF-4907-ABCC-F2280A0DEA61--


From nobody Mon Feb 19 09:58:38 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677F11243F6 for ; Mon, 19 Feb 2018 09:58:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPc12-BqcLHz for ; Mon, 19 Feb 2018 09:58:30 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508B712420B for ; Mon, 19 Feb 2018 09:58:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519063108; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=g5u8VLTxs6WacToTggUc2vGu/JoUJ69nYtX/i0mMsgQ=; b=PBb+eJj92g7AJDRAPRnaDTms4FgWMqBc4OAiQzaa4pDgSur1KSclxDIq+NVjojK3 xNbkE/fh3Q00BeO+aVRBuMs6bfhN8VJ99MaWQF+eF20FgbMmPCOgww5TzhBfPax8 KU2p8KsTVasQUJ5kIK/Ml0Hi3tUVau9g6ejvjcFnYcg=;
X-AuditID: c1b4fb25-c03dc9c0000038f0-b9-5a8b1044635f
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B6.D2.14576.4401B8A5; Mon, 19 Feb 2018 18:58:28 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Mon, 19 Feb 2018 18:58:17 +0100
From: Christer Holmberg 
To: Ben Campbell , Eric Rescorla 
CC: "ice@ietf.org" , "ice-chairs@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , The IESG , "pthatcher@google.com" 
Thread-Topic: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
Thread-Index: AdOpa677O8VqdAW5ThyXNM/NhWOUGQAG8xsAAAV5TgAAAvBG4A==
Date: Mon, 19 Feb 2018 17:58:17 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C177D2D@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se>  <1504CC1C-C872-4AC5-9003-E28488FE9B99@nostrum.com>
In-Reply-To: <1504CC1C-C872-4AC5-9003-E28488FE9B99@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.164]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM2K7ga6LQHeUwaPpahbzO0+zW8w/eZ3Z YsXrc+wWF2dNZrP4dqHWYsaficwW15a/ZnVg91iwqdRjyZKfTB6zdj5h8Zj8uI05gCWKyyYl NSezLLVI3y6BK+Nv/yvmgqPCFXf/T2JuYDzO38XIySEhYCLxdfkZ1i5GLg4hgcOMEv82f2MB SQgJLGGUuLlTs4uRg4NNwEKi+582SFhEwEFi0vcLYPXMAi8YJY7+e8gKkhAWqJd4tKqfDSQh ItDAKPHl0hRWiA4niRUfp4LZLAKqEl+vrmECsXkFfCUuXFjEDLH5JKPEjok/wDZzCthLTF40 gx3EZhQQk/h+CqKBWUBc4taT+UwQZwtILNlznhnCFpV4+fgfK4StJHH2yxQ2iHodiQW7P0HZ 2hLLFr5mhlgsKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFC1OLU7KTTcy1kstykwuLs7P 08tLLdnECIy2g1t+q+5gvPzG8RCjAAejEg/vtN9dUUKsiWXFlbmHGCU4mJVEeH1uAIV4UxIr q1KL8uOLSnNSiw8xSnOwKInzzhFujxISSE8sSc1OTS1ILYLJMnFwSjUwFqZ0N33afSgk2v3i /Yk3FeOuCHlkC778dWON/l6DdKFz/0MW9e6Vd1wTE+m/4dhH5u+Wm3dOalSZMbf0kZ/Wwi9p hU3CZobOTzt4/xd8ySyZenG37rGW1JOvYh6XtEZwneRz1DCrZ9e95SL3QW3OxqNvDX648j9Z GazlsuWXyZR6e63rPJ+1lFiKMxINtZiLihMBlo98v7ICAAA=
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Feb 2018 17:58:32 -0000

Hi,

>>>>> IMPORTANT:
>>>>>
>>>>> *  If the agent's tie-breaker value is larger than or equal to the=20
>>>>> contents of the ICE-CONTROLLING attribute, the agent generates
>>>>> IMPORTANT: This algorithm seems like it's not going to work properly.
>>>>> Consider the case where A and B happen to have the same=20
>>>>> tie-breaker and both think they are controlling, and the Binding=20
>>>>> Requests cross. Each now sends a 487 and then they switch to=20
>>>>> controlled. Ugh. Unless I'm missing something, if the tie-breakers ma=
tch, you are stuck.=20
>>>>> Given that the chance is 2^{-64} this seems to not be a critical fail=
ing, but the algorithm still seems wrong.
>>>>=20
>>> The algorithm hasn't changed since RFC 5245, and nobody indicated that =
it doesn't work.
>>>=20
>> I just explained why it doesn't work. Do you think this analysis is wron=
g?
>>=20
>>=20
>>> I guess people assume that due to the random characteristics, the chanc=
e of both agents using the same value is extremely small.
>>>=20
>> Yes, I agree that the chance of experiencing the problem in the field is=
 very low. But that doesn't make the algorithm right,=20
>> and it's not sensible to (a) specify the edge case behavior (b) specify =
it so that it doesn't work correctly. Better would be to=20
>> return a *different* error that says you have unresolvable role conflict=
.
>=20
> This was a fix that the WG did not choose to pursue in this particular bi=
s draft. That may very well be because no one noticed
> it before. Unless one of you sees an obvious fix, this will probably need=
 some WG discussion.
>
> Given that this problem 1) only matters for certain 3PCC like scenarios, =
2) only has (as Ekr mentions) a 2^-64 chance of happening
> does anyone think it is worth delaying this draft to fix it? Would it be =
acceptable to note the potential problem and move on?

I don't see how a new error code would help. The agents know that both use =
the same value. The question is what they do after that.

IF we really want to solve this, one simple solution be to say that, if thi=
s happens, and endpoint simply calculates a new tie-breaker value, and trie=
s again? BUT, then we would have to change section 16.1, which says that a =
new value can only be calculated at an ICE restart.

So, could we simply say that, if this happens, the agent MUST do an ICE res=
tart, and it MUST calculate a new tie-breaker value?=20

Regards,

Christer


From nobody Mon Feb 19 10:02:44 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073881241F5 for ; Mon, 19 Feb 2018 10:02:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 R8VK6iKy0D2M for ; Mon, 19 Feb 2018 10:02:37 -0800 (PST)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 641B71243F6 for ; Mon, 19 Feb 2018 10:02:35 -0800 (PST)
Received: by mail-qt0-x233.google.com with SMTP id k13so13250470qtg.5 for ; Mon, 19 Feb 2018 10:02:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Es3xZTUn3CSsdltR1K9jzU95cgub/PKffQBp+8TPTx8=; b=cis/gKQTJd/Hz9v01mDe6phsnFGU681EHvQa+27YHC61ELzjmLdfs23n8Pm7tuplQE yi+1lYZQCkKcMaVsj546IBuVmW5C4QSYHgP7Cn67/WNyjkJVRYfMwOGlKNet2Pwyy4HN sJmLZBB+0cDC17BhtjSk1IwALWZFDcGJ0vPFfaUfDZ9ipX/P6dCXk6hPtQA65vKOFFdh qfevEp3skvIOWoG9khcxCGQjWH9VMWnj872BqqCVSn/NrYdTxSoGAlDRrRb6z8aGEPZW diL2XWsm4qRHUh1OIuzp8hdFxAQWsPXHSFy69kY6qh26IE+Jz2T5quc8yQ4h/ef3Xup+ fWDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Es3xZTUn3CSsdltR1K9jzU95cgub/PKffQBp+8TPTx8=; b=hrJHjAGuQJaD+g2Hir/FaEy+yQIXEIAsXg7K69ZT0MgUfxvIExKoq6m9U+qEB4G0hR ldnJOj0yFTnHmHMvFEeEiTboHEfJ/TdcQyvQUPTi1uWMb86Yqv3z8EnlZ5kZTYBVAC+c 8OP8KKoJUIOAWIyFgofnkMrGstITn9sqqyoSCcY+0dQ1i5KCtolW6Rbh1/l3mllVSVv0 POdx6FzaI79TgzjgBo6lCGAgafa5m0tFTGQ53reo7oKJmPfw2lOLLMYbpGGWrHe02Wzc KdaJO9wA6ePkWGDHutZ+RNzTnqoXHswvosjWryiHL/LAt8L/C9DITiL79fI9ODQTE9Hq jmpQ==
X-Gm-Message-State: APf1xPBUARRGwoYr91zZFU7UNmPs1a9eYo7SakEJtz0HcT1+LI3WNxrv 4cDqvu29U+vO7ITHd1qKyMEJiXG2jCu9wQYcNm2FyA==
X-Google-Smtp-Source: AH8x2251TBO62mpCZxvcv1l0sjGUAulWN0dLjH/FlSPCIVLkjYO0UaESqJw0DKytTYqdJyz/rgitmziC60eAdUn5/BQ=
X-Received: by 10.237.56.34 with SMTP id j31mr26373943qte.208.1519063354361; Mon, 19 Feb 2018 10:02:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Mon, 19 Feb 2018 10:01:53 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C177D2D@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se>  <1504CC1C-C872-4AC5-9003-E28488FE9B99@nostrum.com> <7594FB04B1934943A5C02806D1A2204B6C177D2D@ESESSMB109.ericsson.se>
From: Eric Rescorla 
Date: Mon, 19 Feb 2018 10:01:53 -0800
Message-ID: 
To: Christer Holmberg 
Cc: Ben Campbell , "ice@ietf.org" ,  "ice-chairs@ietf.org" ,  "draft-ietf-ice-rfc5245bis@ietf.org" , The IESG , "pthatcher@google.com" 
Content-Type: multipart/alternative; boundary="001a113b7f18a0e34c0565947f62"
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Feb 2018 18:02:39 -0000

--001a113b7f18a0e34c0565947f62
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 19, 2018 at 9:58 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> >>>>> IMPORTANT:
> >>>>>
> >>>>> *  If the agent's tie-breaker value is larger than or equal to the
> >>>>> contents of the ICE-CONTROLLING attribute, the agent generates
> >>>>> IMPORTANT: This algorithm seems like it's not going to work properly.
> >>>>> Consider the case where A and B happen to have the same
> >>>>> tie-breaker and both think they are controlling, and the Binding
> >>>>> Requests cross. Each now sends a 487 and then they switch to
> >>>>> controlled. Ugh. Unless I'm missing something, if the tie-breakers
> match, you are stuck.
> >>>>> Given that the chance is 2^{-64} this seems to not be a critical
> failing, but the algorithm still seems wrong.
> >>>>
> >>> The algorithm hasn't changed since RFC 5245, and nobody indicated that
> it doesn't work.
> >>>
> >> I just explained why it doesn't work. Do you think this analysis is
> wrong?
> >>
> >>
> >>> I guess people assume that due to the random characteristics, the
> chance of both agents using the same value is extremely small.
> >>>
> >> Yes, I agree that the chance of experiencing the problem in the field
> is very low. But that doesn't make the algorithm right,
> >> and it's not sensible to (a) specify the edge case behavior (b) specify
> it so that it doesn't work correctly. Better would be to
> >> return a *different* error that says you have unresolvable role
> conflict.
> >
> > This was a fix that the WG did not choose to pursue in this particular
> bis draft. That may very well be because no one noticed
> > it before. Unless one of you sees an obvious fix, this will probably
> need some WG discussion.
> >
> > Given that this problem 1) only matters for certain 3PCC like scenarios,
> 2) only has (as Ekr mentions) a 2^-64 chance of happening
> > does anyone think it is worth delaying this draft to fix it? Would it be
> acceptable to note the potential problem and move on?
>
> I don't see how a new error code would help. The agents know that both use
> the same value.


This is not necessarily correct. Consider what happens in the case where A
has sent a check but has not yet received any checks, but B has received
A's check. Then B knows but A does not. Presumably this is why the spec
uses an error for this. What I'm talking about here is just using an error
to indicate "this is broken"




The question is what they do after that.


I agree that that's a new question.



> IF we really want to solve this, one simple solution be to say that, if
> this happens, and endpoint simply calculates a new tie-breaker value, and
> tries again? BUT, then we would have to change section 16.1, which says
> that a new value can only be calculated at an ICE restart.
>
> So, could we simply say that, if this happens, the agent MUST do an ICE
> restart, and it MUST calculate a new tie-breaker value?
>

Now both sides might do a simultaneous restart. Is that going to work?

-Ekr


>
> Regards,
>
> Christer
>

--001a113b7f18a0e34c0565947f62
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Feb 19, 2018 at 9:58 AM, Christer Holmberg &l=
t;chris=
ter.holmberg@ericsson.com> wrote:
Hi,



>>>>> IMPORTANT:

>>>>>

>>>>> *=C2=A0 If the agent's tie-breaker value is larger=
 than or equal to the

>>>>> contents of the ICE-CONTROLLING attribute, the agent g=
enerates

>>>>> IMPORTANT: This algorithm seems like it's not goin=
g to work properly.

>>>>> Consider the case where A and B happen to have the sam=
e

>>>>> tie-breaker and both think they are controlling, and t=
he Binding

>>>>> Requests cross. Each now sends a 487 and then they swi=
tch to

>>>>> controlled. Ugh. Unless I'm missing something, if =
the tie-breakers match, you are stuck.

>>>>> Given that the chance is 2^{-64} this seems to not be =
a critical failing, but the algorithm still seems wrong.

>>>>

>>> The algorithm hasn't changed since RFC 5245, and nobody in=
dicated that it doesn't work.

>>>

>> I just explained why it doesn't work. Do you think this analys=
is is wrong?

>>

>>

>>> I guess people assume that due to the random characteristics, =
the chance of both agents using the same value is extremely small.

>>>

>> Yes, I agree that the chance of experiencing the problem in the fi=
eld is very low. But that doesn't make the algorithm right,

>> and it's not sensible to (a) specify the edge case behavior (b=
) specify it so that it doesn't work correctly. Better would be to

>> return a *different* error that says you have unresolvable role co=
nflict.

>

> This was a fix that the WG did not choose to pursue in this particular=
 bis draft. That may very well be because no one noticed

> it before. Unless one of you sees an obvious fix, this will probably n=
eed some WG discussion.

>

> Given that this problem 1) only matters for certain 3PCC like scenario=
s, 2) only has (as Ekr mentions) a 2^-64 chance of happening

> does anyone think it is worth delaying this draft to fix it? Would it =
be acceptable to note the potential problem and move on?



I don't see how a new error code would help. The agents know tha=
t both use the same value. 

This is not nec=
essarily correct. Consider what happens in the case where A has sent a chec=
k but has not yet received any checks, but B has received A's check. Th=
en B knows but A does not. Presumably this is why the spec uses an error fo=
r this. What I'm talking about here is just using an error to indicate =
"this is broken"




The question is what they d=
o after that.

I agree that that's a new=
 question.
=C2=A0



IF we really want to solve this, one simple solution be to say that, if thi=
s happens, and endpoint simply calculates a new tie-breaker value, and trie=
s again? BUT, then we would have to change section 16.1, which says that a =
new value can only be calculated at an ICE restart.



So, could we simply say that, if this happens, the agent MUST do an ICE res=
tart, and it MUST calculate a new tie-breaker value?
<=
br>
Now both sides might do a simultaneous restart. Is that going=
 to work?

-Ekr
=C2=A0



Regards,



Christer





--001a113b7f18a0e34c0565947f62--


From nobody Mon Feb 19 10:03:36 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F2C124319 for ; Mon, 19 Feb 2018 10:03:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 rxItOa3A7Ij0 for ; Mon, 19 Feb 2018 10:03:31 -0800 (PST)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 A59D712420B for ; Mon, 19 Feb 2018 10:03:28 -0800 (PST)
Received: by mail-qk0-x232.google.com with SMTP id o7so13300757qkc.1 for ; Mon, 19 Feb 2018 10:03:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1mjZSouzy8wIJh4xGIdxmclybLfVbuJ7EKyizflcn40=; b=Q4IGmxizGuU0be55h0Y5QTBlWV15rqkuUzdwEcYa2acK77z2ZCjcdlw+CTHg0K6//m WLNqaP2OZ4fuBbhRXvPGX9f66vOz5xqYDmsNTuoBefBWO/13JPUooQj99YidJJHtGNFN EZfGB945Usd38wcR+bgIbH7gvVbA8mKRr3E5AQ1CKLBpzQREPhcGzaumruq3DZDIH0Su a7V4TlNpkJYNEoJjsI3HObJxK0tMgmMfLjuz7v79Z3nejgrxrrJw4Jot8HlqHJTL7meG yyFDPI8+rCaj8HdfMax1+I41rHxd1BNapv+lvbzGUN7IXI5oaOY4VKNW+4STDfVP2JUa LynQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1mjZSouzy8wIJh4xGIdxmclybLfVbuJ7EKyizflcn40=; b=UESkqVrCBOs0gzBgPyyoNRIClXV6qYPOX33rXeM7chOYgzG1DavVjQBOW81BWXFteE Xgx/Zo/IQL+Wn+SixbfEJc5ArhjfjY+3sHMzA05jEI2xWTSuUWZUiWcKS6BqpFvRdB6t GYooDLSuvS1HKsa4ULpDaWnmVeSBlbN0DYKgPblK2CeUWU9S+ovcD+1CRYPdNfYzrQNE iYJfXxM6tskVAXhjcVQQqlxAmjFm40BG+K66hQOmon1CQ2OrH/JlGRQ2A3xpoHEpyuZa thDTfs/jux589hCRTlkIl55TKCldApPs3YVafMS/meb1KXMIOkFKw0ajYC+zDMGLM4bj rihA==
X-Gm-Message-State: APf1xPB04lDa2+/1XeU19sPYRBmxVMwkcw4Q+S4/LV/ey/TnK8ov8COm s8dbyiigK3bFlAE79N5hMA/hUrdGgrwVny9kjuMWHw==
X-Google-Smtp-Source: AH8x224Dx1IZYGglgPllL7+RdvaeVGoJAMU6uXDFllI2aRIRHHZjcxP8Wx8wZV5oft3TsfpLHzV7LATk4d9VlnMtTsg=
X-Received: by 10.55.195.145 with SMTP id r17mr1010499qkl.83.1519063407688; Mon, 19 Feb 2018 10:03:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Mon, 19 Feb 2018 10:02:47 -0800 (PST)
In-Reply-To: <1504CC1C-C872-4AC5-9003-E28488FE9B99@nostrum.com>
References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se>  <1504CC1C-C872-4AC5-9003-E28488FE9B99@nostrum.com>
From: Eric Rescorla 
Date: Mon, 19 Feb 2018 10:02:47 -0800
Message-ID: 
To: Ben Campbell 
Cc: Christer Holmberg , "ice@ietf.org" ,  "ice-chairs@ietf.org" ,  "draft-ietf-ice-rfc5245bis@ietf.org" , The IESG , "pthatcher@google.com" 
Content-Type: multipart/alternative; boundary="001a1147a324ce985705659482b5"
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Feb 2018 18:03:32 -0000

--001a1147a324ce985705659482b5
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 19, 2018 at 9:19 AM, Ben Campbell  wrote:

> On Feb 19, 2018, at 8:42 AM, Eric Rescorla  wrote:
> >
> >>> > IMPORTANT:
> >>> >
> >>> > *  If the agent's tie-breaker value is larger than or equal to the
> contents of the ICE-CONTROLLING attribute, the agent generates
> >>> > IMPORTANT: This algorithm seems like it's not going to work properly.
> >>> > Consider the case where A and B happen to have the same tie-breaker
> and both think they are controlling, and the
> >>> > Binding Requests cross. Each now sends a 487 and then they switch to
> controlled. Ugh. Unless I'm missing something,
> >>> > if the tie-breakers match, you are stuck. Given that the chance is
> 2^{-64} this seems to not be a critical failing, but the algorithm
> >>> > still seems wrong.
> >>>
> >> The algorithm hasn't changed since RFC 5245, and nobody indicated that
> it doesn't work.
> >>
> > I just explained why it doesn't work. Do you think this analysis is
> wrong?
> >
> >
> >> I guess people assume that due to the random characteristics, the
> chance of both agents using the same value is extremely small.
> >>
> > Yes, I agree that the chance of experiencing the problem in the field is
> very low. But that doesn't make the algorithm right, and it's not sensible
> to (a) specify the edge case behavior (b) specify it so that it doesn't
> work correctly. Better would be to return a *different* error that says you
> have unresolvable role conflict.
> >
> >
>
> This was a fix that the WG did not choose to pursue in this particular bis
> draft. That may very well be because no one noticed it before. Unless one
> of you sees an obvious fix, this will probably need some WG discussion.
>

Yes, probably.



> Given that this problem 1) only matters for certain 3PCC like scenarios,
> 2) only has (as Ekr mentions) a 2^-64 chance of happening does anyone think
> it is worth delaying this draft to fix it? Would it be acceptable to note
> the potential problem and move on?
>

Given that this probably creates failure, I'd rather have an explicit
failure than an algorithm which is supposed to fix it, but does not.

-Ekr


> Thanks!
>
> Ben.
>

--001a1147a324ce985705659482b5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Feb 19, 2018 at 9:19 AM, Ben Campbell <ben@nostrum.com> wrote:
On Feb 19, =
2018, at 8:42 AM, Eric Rescorla <ekr@rtf=
m.com> wrote:

>

>>> > IMPORTANT:

>>> >

>>> > *=C2=A0 If the agent's tie-breaker value is larger th=
an or equal to the contents of the ICE-CONTROLLING attribute, the agent gen=
erates

>>> > IMPORTANT: This algorithm seems like it's not going t=
o work properly.

>>> > Consider the case where A and B happen to have the same t=
ie-breaker and both think they are controlling, and the

>>> > Binding Requests cross. Each now sends a 487 and then the=
y switch to controlled. Ugh. Unless I'm missing something,

>>> > if the tie-breakers match, you are stuck. Given that the =
chance is 2^{-64} this seems to not be a critical failing, but the algorith=
m

>>> > still seems wrong.

>>>

>> The algorithm hasn't changed since RFC 5245, and nobody indica=
ted that it doesn't work.

>>

> I just explained why it doesn't work. Do you think this analysis i=
s wrong?

>

>

>> I guess people assume that due to the random characteristics, the =
chance of both agents using the same value is extremely small.

>>

> Yes, I agree that the chance of experiencing the problem in the field =
is very low. But that doesn't make the algorithm right, and it's no=
t sensible to (a) specify the edge case behavior (b) specify it so that it =
doesn't work correctly. Better would be to return a *different* error t=
hat says you have unresolvable role conflict.

>

>



This was a fix that the WG did not choose to pursue in this particul=
ar bis draft. That may very well be because no one noticed it before. Unles=
s one of you sees an obvious fix, this will probably need some WG discussio=
n.

Yes, probably.

<=
div>=C2=A0
Given that this problem =
1) only matters for certain 3PCC like scenarios, 2) only has (as Ekr mentio=
ns) a 2^-64 chance of happening does anyone think it is worth delaying this=
 draft to fix it? Would it be acceptable to note the potential problem and =
move on?

Given that this probably creat=
es failure, I'd rather have an explicit failure than an algorithm which=
 is supposed to fix it, but does not.

-Ekr




Thanks!



Ben.





--001a1147a324ce985705659482b5--


From nobody Mon Feb 19 10:12:07 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A2C124319 for ; Mon, 19 Feb 2018 10:12:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fgy3zqmEbaDa for ; Mon, 19 Feb 2018 10:12:04 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A0E1241F5 for ; Mon, 19 Feb 2018 10:12:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519063922; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Wf6wTpOO62FbLrQ7eivzDH+E9vSkljmmgb0bVhPK+c8=; b=c7j3PUzrJGVGqMaeywyYLpG4/89CX5lnwJjMlYAcgfSvORvdiiYVcGAIzX1Yp7As izXfeyZBZ+kiAvmWGBBaQ0yBwdRXcQxlJQFNRS4qc1gRGJApAoK0fxkMLV3NMbdX u32qZiifBP4LhXqoGfIwIy/tb3QopWNheOZs4Sh5dr8=;
X-AuditID: c1b4fb25-823ff700000038f0-86-5a8b13724dc8
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6D.84.14576.2731B8A5; Mon, 19 Feb 2018 19:12:02 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0352.000; Mon, 19 Feb 2018 19:12:01 +0100
From: Christer Holmberg 
To: Eric Rescorla 
CC: Ben Campbell , "ice@ietf.org" , "ice-chairs@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , The IESG , "pthatcher@google.com" 
Thread-Topic: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
Thread-Index: AdOpa677O8VqdAW5ThyXNM/NhWOUGQAG8xsAAAV5TgAAAvBG4P//9GqA///syNA=
Date: Mon, 19 Feb 2018 18:12:01 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C177D9D@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se>  <1504CC1C-C872-4AC5-9003-E28488FE9B99@nostrum.com> <7594FB04B1934943A5C02806D1A2204B6C177D2D@ESESSMB109.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.164]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2J7uG6RcHeUwYzJChbzO0+zW8w/eZ3Z YsXrc+wWF2dNZrP4dqHWYsaficwW15a/ZnVg91iwqdRjyZKfTB6zdj5h8Zj8uI05gCWKyyYl NSezLLVI3y6BK+PltsNsBfvYKj7vfc/ewLiCrYuRk0NCwETi6cPHrF2MXBxCAocZJZZcv8wM khASWMIosX5jbRcjBwebgIVE9z9tkLCIgILErz8nWEDqmQU6mCTeXzgLNkhYoF7i0ap+NpCE iEADo8SXS1NYITr8JJpXXGACsVkEVCUm33gNFucV8JVYcPoZI8TmK0wSM9bMYgRJcAoESrz+ 1A1WxCggJvH91BqwZmYBcYlbT+YzQZwtILFkz3lmCFtU4uXjf6wQtpLE2S9T2ECuZhbQlFi/ Sx+iVVFiSvdDdoi9ghInZz5hmcAoOgvJ1FkIHbOQdMxC0rGAkWUVo2hxanFSbrqRsV5qUWZy cXF+nl5easkmRmCkHdzyW3UH4+U3jocYBTgYlXh4+YERKMSaWFZcmXuIUYKDWUmE1+dGV5QQ b0piZVVqUX58UWlOavEhRmkOFiVx3jnC7VFCAumJJanZqakFqUUwWSYOTqkGxpoPVeVSbe8b 7r580mCy68fWQ5uWFfBtv/SjujPtfKL0DCOVTNfcrVt2LHlQ/CZ/c2CqqBnvpp8zFJ4osP/i V+hg5RWrsNB2fx1qsV1ti8sepW7/tc7l0y3UlGZXLdX6ZPn3xP55DZPnzODiXCEQu6mUQc6s 9mDlq7UMLOb3dxj0aeovZCxfqMRSnJFoqMVcVJwIAOSwLc+wAgAA
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Feb 2018 18:12:06 -0000

SGksDQoNCi4uLg0KDQo+PiBJRiB3ZSByZWFsbHkgd2FudCB0byBzb2x2ZSB0aGlzLCBvbmUgc2lt
cGxlIHNvbHV0aW9uIGJlIHRvIHNheSB0aGF0LCBpZiB0aGlzIGhhcHBlbnMsIGFuZCBlbmRwb2lu
dCBzaW1wbHkgY2FsY3VsYXRlcyBhIA0KPj4gbmV3IHRpZS1icmVha2VyIHZhbHVlLCBhbmQgdHJp
ZXMgYWdhaW4/IEJVVCwgdGhlbiB3ZSB3b3VsZCBoYXZlIHRvIGNoYW5nZSBzZWN0aW9uIDE2LjEs
IHdoaWNoIHNheXMgdGhhdCBhIG5ldyB2YWx1ZSBjYW4gb25seSBiZSBjYWxjdWxhdGVkIGF0IGFu
IElDRSByZXN0YXJ0Lg0KPj4NCj4+IFNvLCBjb3VsZCB3ZSBzaW1wbHkgc2F5IHRoYXQsIGlmIHRo
aXMgaGFwcGVucywgdGhlIGFnZW50IE1VU1QgZG8gYW4gSUNFIHJlc3RhcnQsIGFuZCBpdCBNVVNU
IGNhbGN1bGF0ZSBhIG5ldyB0aWUtYnJlYWtlciB2YWx1ZT8NCj4NCj4gTm93IGJvdGggc2lkZXMg
bWlnaHQgZG8gYSBzaW11bHRhbmVvdXMgcmVzdGFydC4gSXMgdGhhdCBnb2luZyB0byB3b3JrPw0K
DQpXZSBjb3VsZCBzYXkgdGhhdCB0aGUgaW5pdGlhdGluZyBhZ2VudCBNVVNUIGRvIHRoZSByZXN0
YXJ0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg==


From nobody Mon Feb 19 10:25:18 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECA2127873 for ; Mon, 19 Feb 2018 10:25:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 7Y5onNbuULnD for ; Mon, 19 Feb 2018 10:25:15 -0800 (PST)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 9679212420B for ; Mon, 19 Feb 2018 10:25:15 -0800 (PST)
Received: by mail-qt0-x231.google.com with SMTP id d26so13326377qtk.10 for ; Mon, 19 Feb 2018 10:25:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GLQNrgxMjK2yJ/hc1bPMxbdFUPL2+aIaVUr5Qs4AyV4=; b=YDXS4QEjw9seC0sqvtMOIWfTCeVZn/mpBlnavoC3HEu+GR/rFBhrvuzyjHKsTktoY/ WGzETA3R++15FUQNTL7DyhlrQXdLhm/utJnV2FVLyhgoZQP9V27UImqrO4vyGTp3B8cU CZUXPNHtQjcqrksK6lxV+NSylM/co52cZJrWbA3j2B/7HYCD+MhNNUsLH6NCP7rK+fFQ akJqo6diW5ND/BFF+ms/UaL/yX4GdT2Ei9TfWodF3yiq1hEloisWo3qL6pl9qjfJaVNV 4DGEf5+edKDcIUB1a+nNRCYUTMuIGGnhPWACf82+hSLGBxeDCZbXleTzkWlfMAK1UUr4 4K+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GLQNrgxMjK2yJ/hc1bPMxbdFUPL2+aIaVUr5Qs4AyV4=; b=q1c8P2b7NOgm5/zGsVGbQvGfrc3ubJvMtaP6KsfJyGIb2FFBhg7vYakRctd36YQhs9 T85nfzNY59MmWP7PX0WFCHUdUd+eL3oIPhrX/czIWqtjDX5vw4F3sC6dhIF+pvKdwOOm 209p1ydUOCDFBuxZaznRlGG2wMRPKP3/QLa/NVTM8k+cqMPZlCgBi6PEXHqCoAV1+yiw g5pt2iTh+2a/6l7tLZqFMhfuZtZ/qa7spwBsd32nW7p/OMURGtQO9UpXYesLOtuEh6Yi yemqgex7OnsAz0dnpu+j8qtcJfZePAtMcV/VH5WHwUEikLyrmbKKE79iLeQass8aAhP2 pXDQ==
X-Gm-Message-State: APf1xPDUJXw7HLDTdPNz3TvYoy/UHVxZUEXufdSD+HPj+nlw/19mFGvp SHaDSqYOhMdZV4EhZQeyUUz+Z6v1t1p56oOIk+i47g==
X-Google-Smtp-Source: AH8x227LyZ+SH2+AOTU/mtGYVPoTFEWP4DBdhwf3qTWgcQcJWpEYjDgnhmgN24vpzlnfgGpz9tTwHiqGMhcT1vlPl7Q=
X-Received: by 10.200.7.77 with SMTP id k13mr6890601qth.165.1519064714635; Mon, 19 Feb 2018 10:25:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Mon, 19 Feb 2018 10:24:34 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C177D9D@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se>  <1504CC1C-C872-4AC5-9003-E28488FE9B99@nostrum.com> <7594FB04B1934943A5C02806D1A2204B6C177D2D@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C177D9D@ESESSMB109.ericsson.se>
From: Eric Rescorla 
Date: Mon, 19 Feb 2018 10:24:34 -0800
Message-ID: 
To: Christer Holmberg 
Cc: Ben Campbell , "ice@ietf.org" ,  "ice-chairs@ietf.org" ,  "draft-ietf-ice-rfc5245bis@ietf.org" , The IESG , "pthatcher@google.com" 
Content-Type: multipart/alternative; boundary="f403043a8c74b4ff76056594d073"
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Feb 2018 18:25:17 -0000

--f403043a8c74b4ff76056594d073
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 19, 2018 at 10:12 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> ...
>
> >> IF we really want to solve this, one simple solution be to say that, if
> this happens, and endpoint simply calculates a
> >> new tie-breaker value, and tries again? BUT, then we would have to
> change section 16.1, which says that a new value can only be calculated at
> an ICE restart.
> >>
> >> So, could we simply say that, if this happens, the agent MUST do an ICE
> restart, and it MUST calculate a new tie-breaker value?
> >
> > Now both sides might do a simultaneous restart. Is that going to work?
>
> We could say that the initiating agent MUST do the restart.
>

In this scenario, don't both sides believe they are the initiating peer,
hence the need for the tiebreaker?

-Ekr


> Regards,
>
> Christer
>
>
>

--f403043a8c74b4ff76056594d073
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Feb 19, 2018 at 10:12 AM, Christer Holmberg &=
lt;chri=
ster.holmberg@ericsson.com> wrote:
Hi,



...



>> IF we really want to solve this, one simple solution be to say tha=
t, if this happens, and endpoint simply calculates a

>> new tie-breaker value, and tries again? BUT, then we would have to=
 change section 16.1, which says that a new value can only be calculated at=
 an ICE restart.

>>

>> So, could we simply say that, if this happens, the agent MUST do a=
n ICE restart, and it MUST calculate a new tie-breaker value?

>

> Now both sides might do a simultaneous restart. Is that going to work?=




We could say that the initiating agent MUST do the restart.

In this scenario, don't both sides believe =
they are the initiating peer, hence the need for the tiebreaker?
=

-Ekr




Regards,



Christer









--f403043a8c74b4ff76056594d073--


From nobody Mon Feb 19 10:29:58 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6B41243F6 for ; Mon, 19 Feb 2018 10:29:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiBiulx-_CoS for ; Mon, 19 Feb 2018 10:29:55 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F217B1204DA for ; Mon, 19 Feb 2018 10:29:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519064993; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qRan0SQPjXhSyOWZ3IbwTTzC4Rfr9DNzbEYgow0WCMk=; b=KujF1n230SOKyZo3Q3vM7LAUd/tIwlFov1wQ3dXdmYJnXyAdOjDrOwumH9G6UTN/ Xu1UpUE8H6il0OSTfhnZ62okDGaMH3moTcUqbOlsIXVQJK4LS9JmdIsHq5s1zXgw eNSBCPhou83zd014WqgtKO9l7L9RhCjbb+TJqDZHEFc=;
X-AuditID: c1b4fb25-83bff700000038f0-d4-5a8b17a1777c
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C0.96.14576.1A71B8A5; Mon, 19 Feb 2018 19:29:53 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Mon, 19 Feb 2018 19:29:52 +0100
From: Christer Holmberg 
To: Eric Rescorla 
CC: Ben Campbell , "ice@ietf.org" , "ice-chairs@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , The IESG , "pthatcher@google.com" 
Thread-Topic: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
Thread-Index: AdOpa677O8VqdAW5ThyXNM/NhWOUGQAG8xsAAAV5TgAAAvBG4P//9GqA///syNCAABmPAP//7rFg
Date: Mon, 19 Feb 2018 18:29:51 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C177EC7@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se>  <1504CC1C-C872-4AC5-9003-E28488FE9B99@nostrum.com> <7594FB04B1934943A5C02806D1A2204B6C177D2D@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C177D9D@ESESSMB109.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.164]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2J7oO5C8e4og8PPBS3md55mt5h/8jqz xYrX59gtLs6azGbx7UKtxYw/E5ktri1/zerA7rFgU6nHkiU/mTxm7XzC4jH5cRtzAEsUl01K ak5mWWqRvl0CV8adf5/ZCtq4KzZs+crWwPiAq4uRk0NCwETi2ped7F2MXBxCAocZJXYu2M0G 4SxhlPi56y9rFyMHB5uAhUT3P22QBhEBBYlff06wgNQwC3QwSby/cJYNJCEsUC/xaFU/WLOI QAOjxJdLU1ghOqIk3iz/zwhiswioSsy5/4sdxOYV8JX4Pvkq1Lb7zBK9J9cwgSQ4BQIlOpu+ gTUzCohJfD8FEWcWEJe49WQ+E8TdAhJL9pxnhrBFJV4+/scKYStJnP0yhQ3kamYBTYn1u/Qh WhUlpnQ/hNorKHFy5hOWCYyis5BMnYXQMQtJxywkHQsYWVYxihanFiflphsZ66UWZSYXF+fn 6eWllmxiBMbawS2/VXcwXn7jeIhRgINRiYeXX7g7Sog1say4MvcQowQHs5IIb44IUIg3JbGy KrUoP76oNCe1+BCjNAeLkjjvHOH2KCGB9MSS1OzU1ILUIpgsEwenVANjfN+7u1J5G/Zl7pt5 2u+ItLKH5gtmx4czTILNzrsXGjCv9eV1k1tzO74lfl5C39Vvrx9wMiseXrGB1XalyQ3/tw46 ++YpHfD2qKpdsbT0ssCHJ4wrj5/2/Wm7ZPHNIOm5ohI7OJi//Tm8/4DRS+G/KReis/6VbUnc 2v0idc4m/uOm+qL2wdaLlViKMxINtZiLihMB3lf8arECAAA=
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Feb 2018 18:29:57 -0000

SGksDQoNCi4uLg0KDQo+Pj4+IElGIHdlIHJlYWxseSB3YW50IHRvIHNvbHZlIHRoaXMsIG9uZSBz
aW1wbGUgc29sdXRpb24gYmUgdG8gc2F5IHRoYXQsIGlmIHRoaXMgaGFwcGVucywgYW5kIGVuZHBv
aW50IHNpbXBseSBjYWxjdWxhdGVzIGENCj4+Pj4gbmV3IHRpZS1icmVha2VyIHZhbHVlLCBhbmQg
dHJpZXMgYWdhaW4/IEJVVCwgdGhlbiB3ZSB3b3VsZCBoYXZlIHRvIGNoYW5nZSBzZWN0aW9uIDE2
LjEsIHdoaWNoIHNheXMgdGhhdCBhIG5ldyB2YWx1ZSBjYW4gb25seSBiZSBjYWxjdWxhdGVkIGF0
IGFuIElDRSByZXN0YXJ0Lg0KPj4+Pg0KPj4+PiBTbywgY291bGQgd2Ugc2ltcGx5IHNheSB0aGF0
LCBpZiB0aGlzIGhhcHBlbnMsIHRoZSBhZ2VudCBNVVNUIGRvIGFuIElDRSByZXN0YXJ0LCBhbmQg
aXQgTVVTVCBjYWxjdWxhdGUgYSBuZXcgdGllLWJyZWFrZXIgdmFsdWU/DQo+Pj4NCj4+PiBOb3cg
Ym90aCBzaWRlcyBtaWdodCBkbyBhIHNpbXVsdGFuZW91cyByZXN0YXJ0LiBJcyB0aGF0IGdvaW5n
IHRvIHdvcms/DQo+Pg0KPj4gV2UgY291bGQgc2F5IHRoYXQgdGhlIGluaXRpYXRpbmcgYWdlbnQg
TVVTVCBkbyB0aGUgcmVzdGFydC4NCj4NCj4gSW4gdGhpcyBzY2VuYXJpbywgZG9uJ3QgYm90aCBz
aWRlcyBiZWxpZXZlIHRoZXkgYXJlIHRoZSBpbml0aWF0aW5nIHBlZXIsIGhlbmNlIHRoZSBuZWVk
IGZvciB0aGUgdGllYnJlYWtlcj8NCg0KUHJvYmFibHkuLi4NCg0KQnV0LCB0aGVuIEkgZG9uJ3Qg
c2VlIHdoYXQgd2UgY291bGQgZG8uIElmIGJvdGggYWdlbnRzIHNlbmQgYSBjaGVjaywgYW5kIHJl
Y2VpdmUgNDg3LCB3ZSBjYW4ndCBkZWZpbmUgYSBwcm9jZWR1cmUgZm9yIG9uZSBvZiB0aGUgYWdl
bnRzLg0KDQpQZXJoYXBzIHdlIHNob3VsZCB0aGVuIGNoYW5nZSB0aGUgbXVzdC1ub3QtY2hhbmdl
LXRoZS12YWx1ZS11bmxlc3MtcmVzdGFydCBhbmQgc2F5IHRoYXQgYW4gYWdlbnQgY2hhbmdlcyB0
aGUgdGllLWJyZWFrZXIgdmFsdWUgYW5kIHRyeSBhZ2Fpbi4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0
ZXINCg0K


From nobody Mon Feb 19 10:33:51 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B3712420B for ; Mon, 19 Feb 2018 10:33:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 iONEUsxy0jSS for ; Mon, 19 Feb 2018 10:33:47 -0800 (PST)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 F1FAC126C3D for ; Mon, 19 Feb 2018 10:33:46 -0800 (PST)
Received: by mail-qt0-x229.google.com with SMTP id d14so13400007qtg.1 for ; Mon, 19 Feb 2018 10:33:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/Evr1rjOMOVzJuC0w9bDJZ3hWRI5zQfkSaNjNzsMhS8=; b=hgbCxL5nbfwWtz+/h8TQQfjT6Z7h9slxTMNbOUi9Ym0EY/qIH7afXkeDnSdxb0GHUY NCrpS+w1UKdkoa8PMlg5tlonXHYginCGUzsHt6oq/0dufD7stq+IN+A7Z9/H15PH37Md 3CF+etO6c+2OLOuJBjBbRy7ROu/WuChJPFC1Mgh5Z39fD5QKOv8CjobfayMTavIvoRKB c2HtytH8Yl2GhhBrwFGXOpyIpSHvGIHpdxYFYFa7q62kbmB5iA7LO2OYFarHAkuWZWN6 4WWsZdBKXo55gHV+iFDxtJ0SC3hwdZFbSrQDesnrY4CJHRoUVDoP6VWqBfEL2bNtxLWp qPzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/Evr1rjOMOVzJuC0w9bDJZ3hWRI5zQfkSaNjNzsMhS8=; b=hlZfgz7VvkmL+u1pk4QOouroEE+bYOn3hZdPxX27GypOdU8fhDYyAN9jOAJ4mdXq8m +IjbHpIUwTmHtWZvfM8Sr9WDIviWvEGwHyMR24ZUs1cpG8ha9SXArnAztv79mju3tL+K LQqyZYDXPbwSvelVJc0SfxiE1g+PAH/ARNVhQj7C3cC7pBzIGZW/OpamFApTB7/DRPNc E37LAJoHfuL4m1kzfv2E0FvcYyRk+nf3uBAf+IhLWpJr3yIFn8LRTeJye7vkP5+doXMV AEFXK5eMSwHzIWqzbdYZLa/GSWL66MscwvuaTObgGtTHSVcAxyhr618GVKikGbR+4C1b 1q0A==
X-Gm-Message-State: APf1xPCO1FpUA5bmMBFYUWl/No180bAvOHdzrzymxBPhPK/VgHIhaYoB UCntsUCLp//03Ij7YDkcbBYOsQgFito7mbiMj4m9mWAw
X-Google-Smtp-Source: AH8x224/kbLbmPS86xu5flJ0MwOy0ZffS6erWYF0x6qUFwGESolCm9ZHiGBKraGXukgwhQNpG6nSwE6lJgYym7+f6/M=
X-Received: by 10.237.44.99 with SMTP id f90mr26400709qtd.80.1519065226052; Mon, 19 Feb 2018 10:33:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Mon, 19 Feb 2018 10:33:05 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C177EC7@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se>  <1504CC1C-C872-4AC5-9003-E28488FE9B99@nostrum.com> <7594FB04B1934943A5C02806D1A2204B6C177D2D@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C177D9D@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C177EC7@ESESSMB109.ericsson.se>
From: Eric Rescorla 
Date: Mon, 19 Feb 2018 10:33:05 -0800
Message-ID: 
To: Christer Holmberg 
Cc: Ben Campbell , "ice@ietf.org" ,  "ice-chairs@ietf.org" ,  "draft-ietf-ice-rfc5245bis@ietf.org" , The IESG , "pthatcher@google.com" 
Content-Type: multipart/alternative; boundary="94eb2c06375a3099d3056594efdc"
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Feb 2018 18:33:49 -0000

--94eb2c06375a3099d3056594efdc
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 19, 2018 at 10:29 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> ...
>
> >>>> IF we really want to solve this, one simple solution be to say that,
> if this happens, and endpoint simply calculates a
> >>>> new tie-breaker value, and tries again? BUT, then we would have to
> change section 16.1, which says that a new value can only be calculated at
> an ICE restart.
> >>>>
> >>>> So, could we simply say that, if this happens, the agent MUST do an
> ICE restart, and it MUST calculate a new tie-breaker value?
> >>>
> >>> Now both sides might do a simultaneous restart. Is that going to work?
> >>
> >> We could say that the initiating agent MUST do the restart.
> >
> > In this scenario, don't both sides believe they are the initiating peer,
> hence the need for the tiebreaker?
>
> Probably...
>
> But, then I don't see what we could do. If both agents send a check, and
> receive 487, we can't define a procedure for one of the agents.
>
> Perhaps we should then change the must-not-change-the-value-unless-restart
> and say that an agent changes the tie-breaker value and try again.
>

As you say, the problem is inherently that the situation is symmetrical.

At this point in the design process, I don't think it's worth trying to
actually make the call succeed; a 2^{-64} failure rate is much lower than
organic call failure rates from other causes, even in non-3PCC scenarios.
Rather, I think the spec should just prescribe a clean failure mode via a
new error code, rather than having both sides wildly oscillate between
controlled and controlling

-Ekr


>
> Regards,
>
> Christer
>
>

--94eb2c06375a3099d3056594efdc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Feb 19, 2018 at 10:29 AM, Christer Holmberg &=
lt;chri=
ster.holmberg@ericsson.com> wrote:
Hi,



...



>>>> IF we really want to solve this, one simple solution be to=
 say that, if this happens, and endpoint simply calculates a

>>>> new tie-breaker value, and tries again? BUT, then we would=
 have to change section 16.1, which says that a new value can only be calcu=
lated at an ICE restart.

>>>>

>>>> So, could we simply say that, if this happens, the agent M=
UST do an ICE restart, and it MUST calculate a new tie-breaker value?

>>>

>>> Now both sides might do a simultaneous restart. Is that going =
to work?

>>

>> We could say that the initiating agent MUST do the restart.

>

> In this scenario, don't both sides believe they are the initiating=
 peer, hence the need for the tiebreaker?



Probably...



But, then I don't see what we could do. If both agents send a check, an=
d receive 487, we can't define a procedure for one of the agents.



Perhaps we should then change the must-not-change-the-value-unless-res=
tart and say that an agent changes the tie-breaker value and try again.
=


As you say, the problem is inherently that=
 the situation is symmetrical.

At this point in th=
e design process, I don't think it's worth trying to actually make =
the call succeed; a 2^{-64} failure rate is much lower than organic call fa=
ilure rates from other causes, even in non-3PCC scenarios. Rather, I think =
the spec should just prescribe a clean failure mode via a new error code, r=
ather than having both sides wildly oscillate between controlled and contro=
lling

-Ekr
=C2=A0



Regards,



Christer







--94eb2c06375a3099d3056594efdc--


From nobody Mon Feb 19 11:20:12 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719501204DA for ; Mon, 19 Feb 2018 11:20:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QH9OWUqT4nnZ for ; Mon, 19 Feb 2018 11:20:05 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 1FC8F126CD8 for ; Mon, 19 Feb 2018 11:20:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519068000; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WH6oJ7HvyujZ8hdUVu3zlq8svhq5qF3OuL5ApaYe2BI=; b=STIbiXoxjlkgdA2qX1RWTUdjq3CNgNRYVpbRRPHDODyZiR061VgcxoBsh2Q01BcX R5dNrRFeOIlApwDNy64J2pWEIowwPLGYi2Wu3tX6qXKQYSkUNtpnWWZ6TnkQHrKr YxQXUvcA5rmefZceMnEkoeCaAthRMG8N07J0bGVSoHE=;
X-AuditID: c1b4fb30-799639c000004778-14-5a8b2360baa0
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1E.27.18296.0632B8A5; Mon, 19 Feb 2018 20:20:00 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Mon, 19 Feb 2018 20:19:35 +0100
From: Christer Holmberg 
To: Eric Rescorla 
CC: The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , "pthatcher@google.com" , "ice@ietf.org" 
Thread-Topic: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
Thread-Index: AdOpa677O8VqdAW5ThyXNM/NhWOUGQAG8xsAAApmZdA=
Date: Mon, 19 Feb 2018 19:19:35 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C17801A@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.164]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7gW6CcneUwZRFqhbzT15ntljx+hy7 xcVZk9ksvl2otZjxZyKzxbXlr1kd2DwWbCr1WLLkJ5PH5MdtzAHMUVw2Kak5mWWpRfp2CVwZ 11/OYSpYlV1x/uQctgbGExldjJwcEgImEut/z2EFsYUEDjNKnNrhC2EvYZQ48Le2i5GDg03A QqL7nzZIWERAQeLXnxMsXYxcHMwCLxglzs18xQSSEBaol3i0qp8NJCEi0MAo8eXSFFaQZhEB K4mO89UgJouAqsSnvWog5bwCvhLnVixhBykXEpjCKLFvRSszSIJTIFDixedeNhCbUUBM4vup NWDzmQXEJW49mc8EcbOAxJI955khbFGJl4//sULYShJnv0xhA9nFLKApsX6XPkSrosSU7ofs EHsFJU7OfMIygVF0FpKpsxA6ZiHpmIWkYwEjyypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2M wHg6uOW3wQ7Gl88dDzEKcDAq8fAyi3RHCbEmlhVX5h5ilOBgVhLhzQEJ8aYkVlalFuXHF5Xm pBYfYpTmYFES5z3pyRslJJCeWJKanZpakFoEk2Xi4JRqYExuuNq3zrBmw8ba3woLHpZ8u6n7 weV64Qshhzent+5snPqon0Vz7reHl/1rZ6t+/9S6i+f6zpikzdKeBe1SBjwLEmXfmfbkhUt4 /p7y+Zxgj0p2aPvXqR9VBP9NtV4fNb3oaVKx8JVL/7zCprjcik4OPbbjxqLCN7favhxU28JX kPJeSXtZ6SclluKMREMt5qLiRACrSgTqowIAAA==
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Feb 2018 19:20:07 -0000

SGksDQoNCihJIGhhdmUgcmVtb3ZlZCB0aGUgdGllLWJyZWFrZXIgY29tbWVudCwgc2luY2UgaXQg
aXMgY292ZXJlZCBpbiBhIHNlcGFyYXRlIHRocmVhZCkNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVO
VDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NCg0KUmV2aWV3IGluIGNvbnRleHQgYXQ6DQpodHRwczovL21venBo
YWItaWV0Zi5kZXZzdmNkZXYubW96YXdzLm5ldC9EMzMxMg0KDQo+PsKgIMKgTm9taW5hdGlvbiwg
UmVndWxhciBOb21pbmF0aW9uOsKgIFRoZSBwcm9jZXNzIG9mIHRoZSBjb250cm9sbGluZyBhZ2Vu
dA0KPj7CoCDCoGluZGljYXRpbmcgdG8gdGhlIGNvbnRyb2xsZWQgYWdlbnQgd2hpY2ggY2FuZGlk
YXRlIHBhaXIgdGhlIElDRSBHaXZlbiB0aGF0IHlvdSBoYXZlDQo+PsKgIMKgcmVtb3ZlZCBBZ2dy
ZXNzaXZlIE5vbWluYXRpb24sIGRvIHlvdSBzdGlsbCBuZWVkIHRvIHJlZmVyIHRvICJSZWd1bGFy
IE5vbWluYXRpb24iDQo+DQo+IFBlb3BsZSBhc2tlZCB0byBrZWVwIGl0IGluIHRoZSBUZXJtaW5v
bG9neSBzZWN0aW9uLCB0byBtYWtlIGl0IGNsZWFyIHRoYXQgIm5vbWluYXRpb24iIGlzIDUyNDVi
aXMgcmVmZXJzIHRvIHdoYXQgd2FzIGNhbGxlZCAicmVndWxhciBub21pbmF0aW9uIiBpbiBSRkMg
NTI0NS4NCj4NCj4gT0ssIGJ1dCB0aGVuIHlvdSBzaG91bGQgZXhwbGFpbiB3aHkgeW91IGFyZSB1
c2luZyAicmVndWxhciIgaGVyZS4NCg0KTkVXOg0KDQpOb21pbmF0aW9uOiAgVGhlIHByb2Nlc3Mg
b2YgdGhlIGNvbnRyb2xsaW5nIGFnZW50DQogICAgICBpbmRpY2F0aW5nIHRvIHRoZSBjb250cm9s
bGVkIGFnZW50IHdoaWNoIGNhbmRpZGF0ZSBwYWlyIHRoZSBJQ0UNCiAgICAgIGFnZW50cyB3aWxs
IHVzZSBmb3Igc2VuZGluZyBhbmQgcmVjZWl2aW5nIGRhdGEuIFRoZSBub21pbmF0aW9uDQogICAg
ICBwcm9jZXNzIGRlZmluZWQgaW4gdGhpcyBzcGVjaWZpY2F0aW9uIHdhcyByZWZlcnJlZCB0byAi
cmVndWxhciBub21pbmF0aW9uIg0KICAgICAgaW4gUkZDIDUyNDUuDQoNCi0tLQ0KDQo+Pj7CoCDC
oGNhbmRpZGF0ZSBnYXRoZXJpbmcsICgyKSBjYW5kaWRhdGUgcHJpb3JpdGl6YXRpb24sICgzKSBy
ZWR1bmRhbnQNCj4+PsKgIGNhbmRpZGF0ZSBlbGltaW5hdGlvbiwgYW5kICg0KSBzZW5kaW5nIG9m
IHRoZSBjYW5kaWRhdGVzIHRvIHRoZSBwZWVyLg0KPj4+IFRoaXMgaXMgYW4gb2RkIGRpYWdyYW0u
IFRoZXJlJ3Mgbm8gcmVhc29uIHdoeSB0aGVzZSBoYXZlIHRvIGhhcHBlbiBpbiBzZXF1ZW5jZSBh
bmQgaW4gZmFjdCBpbiBUcmlja2xlIElDRSwgdGhleSBkb24ndCwgc28NCj4+PiB0aGlzIGRpYWdy
YW0gc2VlbXMgbWlzbGVhZGluZy4sIGFzIHdlbGwgYXMgcG90ZW50aWFsbHkgY29udHJhZGljdGlu
ZyB0aGUgYmVnaW5uaW5nIG9mIFMgNS4xLjEuDQo+Pj4NCj4+PiAiQW4gSUNFIGFnZW50IGdhdGhl
cnMgY2FuZGlkYXRlcyB3aGVuIGl0IGJlbGlldmVzIHRoYXQgY29tbXVuaWNhdGlvbiBpcyBpbW1p
bmVudC4gIg0KPj4NCj4+IEkgdGhpbmsgdGhlIHNlcXVlbmNlIGFwcGxpZXMgdG8gY29yZSBJQ0Us
IGFuZCBpcyBhbHNvIGhvdyBpdCdzIGRvbmUgaW4gNTI0NS4NCj4+DQo+PiBUaGUgZmFjdCB0aGF0
IHRyaWNrbGUgSUNFIGRvZXMgaXQgZGlmZmVyZW50bHkgSSB0aGluayBzaGFsbCBiZSBkZXNjcmli
ZWQgaW4gdGhlIHRyaWNrbGUgc3BlYy4NCj4+DQo+PiBIb3dldmVyLCBpdCBpZiBoZWxwcywgSSBj
b3VsZCBhZGQgdGhlIGZvbGxvd2luZyBub3RlOg0KPj4NCj4+ICJOT1RFOiBUaGlzIHNwZWNpZmlj
YXRpb24gYXNzdW1lcyB0aGF0IGFsbCBjYW5kaWRhdGVzIGFyZSBnYXRoZXJlZCBiZWZvcmUgdGhl
eSBhcmUgc2VudCB0byB0aGUgcGVlci4gVGhlIHRyaWNrbGUgSUNFIGV4dGVuc2lvbnMgZGVmaW5l
IHByb2NlZHVyZXMNCj4+IHdoZXJlIGdhdGhlcmVkIGNhbmRpZGF0ZXMgY2FuIGJlIHNlbnQgdG8g
dGhlIHBlZXIgYXMgc29vbiBhcyB0aGV5IGhhdmUgYmVlbiBnYXRoZXJlZCwgd2hpbGUgYWRkaXRp
b25hbCBjYW5kaWRhdGVzIGFyZSBzdGlsbCBnYXRoZXJlZC4iDQo+DQo+IFRoZSBpc3N1ZSBoZXJl
IGlzbid0IHRoYXQgYWxsIGNhbmRpZGF0ZXMgYXJlIGdhdGhlcmVkIGJlZm9yZSB0aGV5IGFyZSBz
ZW50IHRvIHRoZSBwZWVyIGJ1dCByYXRoZXLCoCB0aGF0IHRoZSBkaWFncmFtIGltcGxpZXMgdGhh
dCBubyBnYXRoZXJpbmcgaGFwcGVucyBiZWZvcmUgdGhlIHBlZXIncyANCj4gY2FuZGlkYXRlcyBh
cmUgcmVjZWl2ZWQuIFRoYXQncyBub3QgYSByZXF1aXJlbWVudCBvZiA1MjQ1LCBhbmQsIGFzIEkg
c2FpZCwgY29udHJhZGljdHMgdGhlIGJlZ2lubmluZyBvZiBTIDUuMS4xLg0KDQpJIGNvdWxkIGFk
ZCB0aGUgZm9sbG93aW5nIHNlbnRlbmNlOiAiTm90ZSB0aGF0IGFuIGFnZW50IGNhbiBiZWdpbiBn
YXRoZXJpbmcgY2FuZGlkYXRlcyBhdCBhbnkgcG9pbnQsIGV2ZW4gaWYgaXQgaGFzIG5vdCByZWNl
aXZlZCBhbnkgY2FuZGlkYXRlcyAob3IgZXZlbiBiZWVuIGNvbnRhY3RlZCkgYnkgaXRzIHBlZXIu
Ig0KDQotLS0NCg0KPj4+wqAgwqBUaGUgYWdlbnQgd2lsbCByZWNlaXZlIGEgQmluZGluZyBvciBB
bGxvY2F0ZSByZXNwb25zZS7CoCBBIHN1Y2Nlc3NmdWwNCj4+PsKgIMKgQWxsb2NhdGUgcmVzcG9u
c2Ugd2lsbCBwcm92aWRlIHRoZSBhZ2VudCB3aXRoIGEgc2VydmVyIHJlZmxleGl2ZSBPciBub3Ro
aW5nIG9yIGFuIGVycm9yLg0KPj4+DQo+Pj7CoCDCoCDCoCDCoCDCoCDCoCDCoCAoMl44KSooSVAg
cHJlY2VkZW5jZSkgKw0KPj4+wqAgwqAgwqAgwqAgwqAgwqAgwqAgKDJeMCkqKDI1NiAtIGNvbXBv
bmVudCBJRCkNCj4+Pg0KPj4+IElzbid0IHRoaXMgdGhlIHNhbWUgZm9ybXVsYSBhcyBpbiBTIDUu
MS4yLjEuDQo+Pg0KPj4gU2VjdGlvbiA1LjEuMi4xIGRlZmluZXMgdGhlIGdlbmVyaWMgZm9ybXVs
YS4gVGhpcyBpbnN0YW5jZSBpcyB3aGVuIGl0IGlzIHVzZWQgYnkgYSBMaXRlIGltcGxlbWVudGF0
aW9uLg0KPj4NCj4+IE9mIGNvdXJzZSwgaW4gb3JkZXIgdG8gYWxpZ24sIEkgY291bGQgcmVwbGFj
ZSAiSVAgcHJlY2VkZW5jZSIgd2l0aCAibG9jYWwgcHJlZmVyZW5jZSIuDQo+DQo+IE15IHN1Z2dl
c3Rpb24gaXMgdG8gaGF2ZSBvbmUgY29weS4NCsKgDQpJIGNhbiBrZWVwIHRoZSBmb3JtdWxhIGlu
IHNlY3Rpb24gNS4xLjIuMS4NCg0KQnV0LCBpbiB0aGUgY2FzZSBvZiBMaXRlLCB3ZSBzdGlsbCBu
ZWVkIHRvIHNheSB3aGF0IHZhbHVlcyBhcmUgdXNlZCBmb3IgdGhlIGRpZmZlcmVudCBmb3JtdWxh
IHBhcnRzIC0gZXZlbiBpZiB3ZSBkb24ndCBzaG93IHRoZSBmb3JtdWxhLg0KDQotLS0NCsKgDQo+
PsKgIMKgIMKgIHBhaXIgcHJpb3JpdHkgPSAyXjMyKk1JTihHLEQpICsgMipNQVgoRyxEKSArIChH
PkQ/MTowKQ0KPj4NCj4+IFRoaXMgd2FzIGtpbmRhIHRlcnJpYmxlIGluIDUyNDUuIEdpdmVuIHRo
YXQgeW91IHVzZSBpdCBvbmNlLCBtYXliZSBqdXN0IGhhdmUgKyBHVChHLCBEKQ0KPj4NCj4+IEFu
ZCB0aGVuIHNheSBHVChHLCBEKSA9PSAxIGlmIEc+RCBhbmQgMCBvdGhlcndpc2UuDQo+DQo+IEkg
cHJvYmFibHkganVzdCBkb24ndCBzZWUgaXQsIGJ1dCB3aGF0IGlzIHRoZSBkaWZmZXJlbmNlPw0K
Pg0KPiBJdCBoYXMgdGhlIHNhbWUgc2VtYW50aWNzIGJ1dCBpdCdzIGVhc2llciB0byByZWFkLiBJ
IG1lYW4sIGVpdGhlciB5b3UgdGhpbmsgdGhlIEMgc3ludGF4IGlzIHNlbGYtZXhwbGFuYXRvcnkg
b3IgeW91DQo+IGRvbid0LiBJZiB5b3UgZG8sIHRoZW4geW91IGRvbid0IG5lZWQgdG8gZXhwbGFp
biBpdC4gSWYgeW91IGRvbid0LCBpdCdzIG9wYXF1ZSBpbiB0aGUgZXhwcmVzc2lvbiwNCg0KUGVy
c29uYWxseSBJIHRoaW5rIHRoZSBmb3JtdWxhIGlzIGNsZWFyLCBhbmQgd2UgY291bGQgcmVtb3Zl
IHRoZSBmb2xsb3dpbmcgc2VudGVuY2U6DQoNCiJ3aGVyZSBHPkQ/MTowIGlzIGFuIGV4cHJlc3Np
b24gd2hvc2UgdmFsdWUgaXMgMSBpZiBHIGlzIGdyZWF0ZXIgdGhhbiBELCBhbmQgMCBvdGhlcndp
c2UuIg0KDQotLS0NCg0KPj4+wqAgwqBwYWlyIHRvIHRoZSByZW1vdGUgY2FuZGlkYXRlIG9mIHRo
ZSBwYWlyLCBhcyBkZXNjcmliZWQgaW4NCj4+PsKgIMKgU2VjdGlvbiA3LjIuNC4NCj4+PiAgIElN
UE9SVEFOVDogWW91IGRvbid0IGp1c3Qgc2VuZCBhIFNUVU4gcmVxdWVzdCwgeW91IHN0YXJ0IGEg
U1RVTiB0cmFuc2FjdGlvbiwNCj4+Pg0KPj4gVGhlcmUgYXJlIG11bHRpcGxlIGluc3RhbmNlcyBp
biB0aGUgc3BlYyB3aGVyZSBpdCB0YWxrcyBhYm91dCBzZW5kaW5nIFNUVU4gcmVxdWVzdHMgb3Ig
QmluZGluZyByZXF1ZXN0cy4NCj4NCj4gSSBhZ3JlZSwgYnV0IHRoaXMgc3RhdGVtZW50IGlzIHN0
aWxsIGNvbmZ1c2luZy4gSXMgdGhlcmUgYSByZWFzb24gbm90IHRvIGNoYW5nZSBpdD8NCg0KSSBj
b3VsZCBzYXkgImJ5IGluaXRpYXRpbmcgYSBTVFVOIHRyYW5zYWN0aW9uIiwgYnV0IEknZCBwcmVm
ZXIgdG8gaGF2ZSBjb21tb24gdGVybWlub2xvZ3kuDQoNCi0tLQ0KDQo+Pj7CoCDCoFRoZSBJQ0Ug
YWdlbnQgY29uc3RydWN0cyBhIGNhbmRpZGF0ZSBwYWlyIHdob3NlIGxvY2FsIGNhbmRpZGF0ZQ0K
Pj4+wqAgwqBlcXVhbHMgdGhlIG1hcHBlZCBhZGRyZXNzIG9mIHRoZSByZXNwb25zZSwgYW5kIHdo
b3NlIHJlbW90ZSBjYW5kaWRhdGUNCj4+Pg0KPj4+IElNUE9SVEFOVDogV2hlbiBkb2VzIHRoaXMg
aGFwcGVuPw0KPj4NCj4+IFRoZSBsYXN0IHNlbnRlbmNlIG9mIHRoZSBwYXJlbnQgc2VjdGlvbiAo
Ny4yLjUuMynCoCBzYXlzOg0KPj4NCj4+ICJJZiBhIGNoZWNrIGlzIGNvbnNpZGVyZWQgYSBzdWNj
ZXNzLCB0aGUgSUNFIGFnZW50IHBlcmZvcm1zIChpbiBvcmRlcikgdGhlIGFjdGlvbnMgZGVzY3Jp
YmVkIGluIHRoZSBmb2xsb3dpbmcgc2VjdGlvbnMuIg0KPg0KPiBQbGVhc2UgYWRkIGEgcmV2ZXJz
ZSByZWZlcmVuY2UuDQoNCkFsbCA3LjIuNS4zLlguIHNlY3Rpb25zIGhhcHBlbnMgYWZ0ZXIgdGhl
IGNoZWNrIGhhcyBiZWVuIGNvbnNpZGVyZWQgYSBzdWNjZXNzLCBzbyBleGFjdGx5IHdoZXJlIGRv
IHlvdSB3YW50IGEgcmVmZXJlbmNlPw0KDQotLS0NCg0KPj4+IDcuMy4xLjMuwqAgTGVhcm5pbmcg
UGVlciBSZWZsZXhpdmUgQ2FuZGlkYXRlcw0KPj4+DQo+Pj5UaGlzIGVudGlyZSBzZWN0aW9uIHNl
ZW1zIHRvIGR1cGxpY2F0ZSA3LjIuNS4zLjENCj4+DQo+PiBTZWN0aW9uIDcuMi41LjMuMSBkZXNj
cmliZXMgaG93IGEgU1RVTiBjbGllbnQgZGV0ZWN0cyBhIHBlZXIgcmVmbGV4aXZlIGNhbmRpZGF0
ZSB0aGVuIGl0IHJlY2VpdmVzIGEgU1RVTiByZXNwb25zZS4NCj4+DQo+PiBTZWN0aW9uIDcuMy4x
LjMgZGVzY3JpYmVzIGhvdyBhIFNUVU4gc2VydmVyIGRldGVjdHMgYSBwZWVyIHJlZmxleGl2ZSBj
YW5kaWRhdGUgd2hlbiBpdCByZWNlaXZlcyBhIFNUVU4gcmVxdWVzdC4NCj4+DQo+PiBTdXJlLCB0
aGUgdGV4dCBpcyBzaW1pbGFyLCBidXQgc2VwYXJhdGUgcHJvY2VkdXJlcy4NCj4NCj4gVGhpcyB3
b3VsZCBiZW5lZml0IGZyb20gY29uc29saWRhdGlvbi4NCg0KV2UgZGlkIGEgY2hvaWNlIHRvIGtl
ZXAgdGhlIGNsaWVudCBhbmQgc2VydmVyIHByb2NlZHVyZXMgc2VwYXJhdGVkLCBzbyBJJ2QgbGlr
ZSB0byBrZWVwIGl0LiANCg0KQWxzbywgdGhlcmUgQVJFIGRpZmZlcmVuY2VzIGluIHRoZSBwcm9j
ZWR1cmVzLCBzbyB3ZSBzdGlsbCBuZWVkIHRvIGNvdmVyIHRoZSBjbGllbnQtIGFuZCB0aGUgc2Vy
dmVyIGNhc2VzIHNlcGFyYXRlbHkuDQogDQotLS0NCg0KPj4+wqAgwqAgwqAgwqAgwqBpbi1wcm9n
cmVzcyB0cmFuc2FjdGlvbi7CoCBDYW5jZWxsYXRpb24gbWVhbnMgdGhhdCB0aGUgYWdlbnQNCj4+
PsKgIMKgIMKgIMKgIMKgd2lsbCBub3QgcmV0cmFuc21pdCB0aGUgcmVxdWVzdCwgd2lsbCBub3Qg
dHJlYXQgdGhlIGxhY2sgb2YNCj4+PsKgIMKgIMKgIMKgIMKgcmVzcG9uc2UgdG8gYmUgYSBmYWls
dXJlLCBidXQgd2lsbCB3YWl0IHRoZSBkdXJhdGlvbiBvZiB0aGUNCj4+Pg0KPj4+IFdoeSBhcmUg
eW91IGNhbmNlbGxpbmcgSW4tUHJvZ3Jlc3MgY2hlY2tzIHdoZW4geW91IHJlY2VpdmUgYSBwZWVy
LXJlZmxlY3RpdmUgY2hlY2s/DQo+Pj4gSWYgeW91IHJlY2VpdmUgdHdvIGluIGEgcm93LCB0aGVu
IGl0IHNlZW1zIGxpa2UgdGhpcyBkZWxheXMgYSBzdWNjZXNzZnVsIGNoZWNrLg0KPj4NCj4+IFRy
dWUuDQo+Pg0KPj4gU28sIEkgd2lsbCByZW1vdmUgdGhlIGNhbmNlbCBwYXJ0Lg0KPj4NCj4+IERv
IHlvdSBzdGlsbCB0aGluayBpdCBzaG91bGQgY3JlYXRlIGEgbmV3IGJpbmRpbmcgcmVxdWVzdCwg
b3IgaXMgdGhlIG9uZ29pbmcgSW4tUHJvZ3Jlc3MgY2hlY2sgZW5vdWdoIHRvIGNoZWNrIHRoZSBw
YWlyPw0KPg0KPiBNeSBpbml0aWFsIHJlYWN0aW9uIGlzIHlvdSBkb24ndCBuZWVkIHRvIGRvIGFu
eXRoaW5nIGV4dHJhLCBidXQgSSBjb3VsZCBlYXNpbHkgYmUgd3JvbmcgaGVyZS4NCg0KSSBoYWQg
dGhlIHNhbWUgcmVhY3Rpb24sIGJ1dCBJJ3ZlIGFza2VkIEFyaSB0byB0aGluayBhYm91dCB0aGlz
IHRvby4NCg0KLS0tDQoNCj4+PiBNb3JlIGdlbmVyYWxseSwgdGhpcyBkb2N1bWVudCBzaG91bGQg
ZXhwbGFpbiBob3cgeW91IGVuZCB1cCBpbiB0aGlzDQo+Pj4gc2l0dWF0aW9uOiB5b3Ugb25seSBn
ZXQgaGVyZSB3aGVuICJ0aGUgc291cmNlIHRyYW5zcG9ydCBhZGRyZXNzIG9mIHRoZSByZXF1ZXN0
DQo+Pj4gZG9lcyBub3QgbWF0Y2ggYW55IGV4aXN0aW5nIHJlbW90ZSBjYW5kaWRhdGUiLCBzbyBo
b3cgY2FuIGl0IGJlIG9uIGEgY2hlY2sgbGlzdA0KPj4+IHVubGVzcyB0aGlzIGlzIHRoZSBzZWNv
bmQgb2JzZXJ2YXRpb24gb2YgYSBwZWVyIHJlZmxleGl2ZS4NCj4+DQo+PiBJIGFtIG5vdCBzdXJl
IEkgdW5kZXJzdGFuZC4gVGhlIHNvdXJjZSB0cmFuc3BvcnQgc2VudGVuY2UgeW91IHJlZmVyIHRv
IGlzIHJlbGF0ZWQgdG8gZGV0ZWN0aW9uIG9mIHBlZXIgcmVmbGV4aXZlIGNhbmRpZGF0ZXMuDQo+
DQo+IE15IHF1ZXN0aW9uIGlzIHdoYXQgc2VxdWVuY2Ugb2YgZXZlbnRzIGNhbiBsZWFkIHRvIHRo
aXMgc2l0dWF0aW9uLCBhcyBpdCBpcyBzdXJwcmlzaW5nIHRvIHRoZSByZWFkZXJzLg0KDQpBcmUg
eW91IGFza2luZyB3aGF0IGV2ZW50cyBjYW4gbGVhZCB0byBhIHRyaWdnZXJlZCByZXF1ZXN0Pw0K
DQotLS0NCg0KPj4+wqAgwqBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApIFtSRkM0
NTY2XSBpcyBkZWZpbmVkIGluDQo+Pj7CoCDCoFtJLUQuaWV0Zi1tbXVzaWMtaWNlLXNpcC1zZHBd
Lg0KPj4+IFByZXN1bWFibHkgeW91IHdhbnQgdG8gY2l0ZSA1MjQ1IFMgMTQsIHdoaWNoIHN0YXRl
czoNCj4+Pg0KPj4+IENvbnNlcXVlbnRseSwgd2hlbiBhIGNvbnRyb2xsaW5nIGFnZW50IGlzIGNv
bW11bmljYXRpbmcgd2l0aCBhIHBlZXIgdGhhdCBzdXBwb3J0cyBvcHRpb25zIGl0IGRvZXNuJ3Qg
a25vdyBhYm91dCwgDQo+Pj4gdGhlIGFnZW50IE1VU1QgcnVuIGEgcmVndWxhciBub21pbmF0aW9u
IGFsZ29yaXRobS7CoCBXaGVuIHJlZ3VsYXIgbm9taW5hdGlvbiBpcyB1c2VkLCBJQ0Ugd2lsbCBj
b252ZXJnZSBwZXJmZWN0bHkgDQo+Pj4gZXZlbiB3aGVuIGJvdGggYWdlbnRzIHVzZSBkaWZmZXJl
bnQgcGFpciBwcmlvcml0aXphdGlvbiBhbGdvcml0aG1zLg0KPj4NCj4+IEkgYW0gbm90IHN1cmUg
aXQgaXMgcmVsYXRlZCB0byBTRFAuDQo+Pg0KPj4gSSBzdWdnZXN0IHRvIG1vZGlmeSB0aGUgZmly
c3QgcGFyYWdyYXBoOg0KPg0KPiBPTEQ6DQo+DQo+ICJGb3IgZXhhbXBsZSwgdGhlIGFnZW50IHdp
bGwgbm90IHVzZSB0aGUgYWdncmVzc2l2ZSBub21pbmF0aW9uIHByb2NlZHVyZSBkZWZpbmVkIGlu
IFJGQyA1MjQ1LiINCj4NCj4gTkVXOg0KPg0KPsKgIkZvciBleGFtcGxlLCB0aGUgYWdlbnQgd2ls
bCBub3QgdXNlIHRoZSBhZ2dyZXNzaXZlIG5vbWluYXRpb24gcHJvY2VkdXJlIGRlZmluZWQgaW4g
UkZDIDUyNDUuIEluIGFkZGl0aW9uLA0KPsKgIMKgSXQgd2lsbCBlbnN1cmUgdGhhdCBhbiBSRkMg
NTI0NS1jb21wbGlhbnQgcGVlciBkb2VzIG5vdCB1c2UgYWdncmVzc2l2ZSBub21pbmF0aW9uIGVp
dGhlciwgYXMgZGVzY3JpYmVkIGluDQo+wqAgwqBTZWN0aW9uIDE0IG9mIFJGQyA1MjQ1LiINCj4N
Cj4gUGVyaGFwczoNCj4gImFzIHJlcXVpcmVkIGJ5IFNlY3Rpb24gMTQgb2YgUkZDIDUyNDUgZm9y
IHBlZXJzIHdoaWNoIHJlY2VpdmUgdW5rbm93biBJQ0Ugb3B0aW9ucyINCg0KTG9va3MgZ29vZC4N
Cg0KLS0tDQoNCj4+IE5FVzoNCj4+DQo+PsKgIMKgT25lIG9mIHRoZSBjb21wbGljYXRpb25zIGlu
IGFjaGlldmluZyBpbnRlcm9wZXJhYmlsaXR5IGlzIHRoYXQgSUNFDQo+PsKgIMKgcmVsaWVzIG9u
IGEgZGlzdHJpYnV0ZWQgYWxnb3JpdGhtIHJ1bm5pbmcgb24gYm90aCBhZ2VudHMgdG8gY29udmVy
Z2UNCj4+wqAgwqBvbiBhbiBhZ3JlZWQgc2V0IG9mIGNhbmRpZGF0ZSBwYWlycy7CoCBJZiB0aGUg
dHdvIGFnZW50cyBydW4gZGlmZmVyZW50DQo+PsKgIMKgYWxnb3JpdGhtcywgaXQgY2FuIGJlIGRp
ZmZpY3VsdCB0byBndWFyYW50ZWUgY29udmVyZ2VuY2Ugb24gdGhlIHNhbWUNCj4+wqAgwqBjYW5k
aWRhdGUgcGFpcnMuwqAgVGhlIG5vbWluYXRpb24gcHJvY2VkdXJlIGRlc2NyaWJlZCBpbg0KPj7C
oCDCoFNlY3Rpb24gOCBlbGltaW5hdGVzIHNvbWUgb2YgdGhlIHRpZ2h0IGNvb3JkaW5hdGlvbiBi
eSBkZWxlZ2F0aW5nIHRoZQ0KPg0KPiBzb21lIG9mIHRoZSBuZWVkIGZvciB0aWdodA0KDQpMb29r
cyBnb29kLg0KwqANCj7CoCDCoHNlbGVjdGlvbiBhbGdvcml0aG0gY29tcGxldGVseSB0byB0aGUg
Y29udHJvbGxpbmcgYWdlbnQsIGFuZCBJQ0UNCj7CoCDCoHdpbGwgY29udmVyZ2UgcGVyZmVjdGx5
IGV2ZW4gd2hlbiBib3RoIGFnZW50cyB1c2UgZGlmZmVyZW50IHBhaXINCj7CoCDCoHByaW9yaXRp
emF0aW9uIGFsZ29yaXRobXMuIE9uZSBvZiB0aGUga2V5cyB0byBzdWNoIGNvbnZlcmdlbmNlIGlz
DQo+wqAgwqB0cmlnZ2VyZWQgY2hlY2tzLCB3aGljaCBlbnN1cmUgdGhhdCB0aGUgbm9taW5hdGVk
IHBhaXIgaXMgdmFsaWRhdGVkDQo+wqAgwqBieSBib3RoIGFnZW50cy7CoCBDb25zZXF1ZW50bHks
IGFueSBmdXR1cmUgSUNFIGVuaGFuY2VtZW50cyBNVVNUDQo+wqAgwqBwcmVzZXJ2ZSB0cmlnZ2Vy
ZWQgY2hlY2tzLiINCg0KLS0twqANCg0KPj4+wqAgwqB0aGVyZSB3aWxsIGJlIGZvdXIgdHJhbnNh
Y3Rpb25zIHBlciBjYWxsIChvbmUgZm9yIFJUUCBhbmQgb25lIGZvcg0KPj4+wqAgwqBSVENQLCBm
b3IgYm90aCBjYWxsZXIgYW5kIGNhbGxlZSkuwqAgRWFjaCB0cmFuc2FjdGlvbiBpcyBhIHNpbmds
ZQ0KPj4+wqAgwqByZXF1ZXN0IGFuZCBhIHNpbmdsZSByZXNwb25zZSwgdGhlIGZvcm1lciBiZWlu
ZyAyMCBieXRlcyBsb25nLCBhbmQgSXMgdGhpcyBjdXJyZW50bHkgdHJ1ZT8NCj4+Pg0KPj4+IEhv
dyBtYW55IHBlb3BsZSBzdGlsbCBkb24ndCBzdXBwb3J0IFJUUC1NVVg/DQo+Pg0KPj4gSSBkb24n
dCBrbm93LiBCdXQsIHVubGVzcyB5b3UgdXNlIG11eCBleGNsdXNpdmUgdGhlIG9mZmVyZXIgc3Rp
bGwgaGFzIHRvIGdhdGhlciBhbmQgcHJvdmlkZSBSVENQIGNhbmRpZGF0ZXMuDQo+DQo+IFJpZ2h0
LCBidXQgdGhlbiB0aGVyZSB3aWxsIGJlIHRocmVlIHRyYW5zYWN0aW9ucyBwZXIgY2FsbCBpbiB0
aGUgY29tbW9uIGNhc2UuDQoNCkFzc3VtaW5nIHlvdSBhcmUgdXNpbmcgb2ZmZXIvYW5zd2VyLCB5
ZXMuIA0KDQpNYXliZSBzb21ldGhpbmcgbGlrZToNCg0KIkluIGEgdHlwaWNhbCBWb0lQIGRlcGxv
eW1lbnQsIHdoZXJlIFJUUC9SVENQIG11bHRpcGxleGluZyBpcyB1c2VkLCB0aGVyZSB3aWxsIGJl
IDItMyB0cmFuc2FjdGlvbnMgDQpwZXIgY2FsbCwgZGVwZW5kaW5nIG9uIHdoZXRoZXIgZmFsbGJh
Y2sgdG8gbm9uLW11bHRpcGxleGluZyBpcyBzdXBwb3J0ZWQuIg0KDQpSZWdhcmRzLA0KDQpDaHJp
c3Rlcg0K


From nobody Mon Feb 19 11:30:26 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CBF128959 for ; Mon, 19 Feb 2018 11:30:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 jY1CMht_LEMA for ; Mon, 19 Feb 2018 11:30:21 -0800 (PST)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 6BD46126CE8 for ; Mon, 19 Feb 2018 11:30:21 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id t13so10262079qkj.13 for ; Mon, 19 Feb 2018 11:30:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vvxs4x2MaylqcdD5LT+of/T5w3dYwq8x8fuhKK/RMxc=; b=Ihky+g+pkw8GbD3qj2J1jWBE7LsWIw3CBS5pK7nN5lq3qgJtDjHvSauQEwPofFgWAy BZGlNsivKP70TXuI/SEAXz0/8CP6Z6u+NkCQAky1Lezg43o+k1gJ/hCYBfbGrzX2CNqH GXmy7gox3VJk4OCqBIgJj0wLgqiPhZ+/pKqv6JJ0JraPgMagYKsD5Hwy1ZQmRQ/KRrJU x9oxbNC0EJXro39vv6denuXVcFY3u+adzt1FK3Ks/sTB1cEtYxx2Mm/fvWO99n/Xwsiu fsuPx3n8hbsoY51KBiD2fHjlpgRHsQH4XZ4asrx/73b5WEcCatJjXu8EazMBqvNm898H 91gA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vvxs4x2MaylqcdD5LT+of/T5w3dYwq8x8fuhKK/RMxc=; b=cysBbfU/ivqXfU/434dN9ib/COrAm34xJ2c3pe0Kcq8xey3IG8KRIb1Kq++z9awyFR Qvef999LoglsZIFnKpbDDBQwHh8fj9Y6g+tukxJrcQOcSznVK8J9R6FhIlVsXgc30v/P oGALxHvNN2feYi+cxZ2mzpow3x3ULbYAMt2iBuiVnK7o/2/N4Sz8udmsKDzMC9mqYUf/ BvOxFYEuuvRNsITPXD0AlR4Yh9qgIScXG5Or4TtO+/My5CcVLkou/BIersSR+qoYFhRC BJSzeisUOcdnH9wLmlaNwUhl0CWB4oXl44EnzlNgBdP2wHl6TyYg+ag0X70rys0hSnLx X9dA==
X-Gm-Message-State: APf1xPB9GBfcDbBC+WLcr3RvZDXKHZeYWcT64JyZxKJjRls4YOKvqqAv 8oQsLmEuzazWVO+H9zdwQBDwAu5wed3Bpit/x6Rn5g==
X-Google-Smtp-Source: AH8x227EpvKqR3V/pjlNbHxzu0epOColpTHyzevVLlq4utUovWTHtSwexqubxuWqKOSjO+9DyOrG/llFqzULsA/iWpE=
X-Received: by 10.55.118.6 with SMTP id r6mr14012922qkc.211.1519068620358; Mon, 19 Feb 2018 11:30:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Mon, 19 Feb 2018 11:29:39 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C17801A@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C17801A@ESESSMB109.ericsson.se>
From: Eric Rescorla 
Date: Mon, 19 Feb 2018 11:29:39 -0800
Message-ID: 
To: Christer Holmberg 
Cc: The IESG ,  "draft-ietf-ice-rfc5245bis@ietf.org" ,  "ice-chairs@ietf.org" , "pthatcher@google.com" ,  "ice@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c06273882065b056595b93a"
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Feb 2018 19:30:24 -0000

--94eb2c06273882065b056595b93a
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 19, 2018 at 11:19 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> (I have removed the tie-breaker comment, since it is covered in a separate
> thread)
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Review in context at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3312
>
> >>   Nomination, Regular Nomination:  The process of the controlling agent
> >>   indicating to the controlled agent which candidate pair the ICE Given
> that you have
> >>   removed Aggressive Nomination, do you still need to refer to "Regular
> Nomination"
> >
> > People asked to keep it in the Terminology section, to make it clear
> that "nomination" is 5245bis refers to what was called "regular nomination"
> in RFC 5245.
> >
> > OK, but then you should explain why you are using "regular" here.
>
> NEW:
>
> Nomination:  The process of the controlling agent
>       indicating to the controlled agent which candidate pair the ICE
>       agents will use for sending and receiving data. The nomination
>       process defined in this specification was referred to "regular
> nomination"
>       in RFC 5245.
>

Perfect.


>
> ---
>
> >>>   candidate gathering, (2) candidate prioritization, (3) redundant
> >>>  candidate elimination, and (4) sending of the candidates to the peer.
> >>> This is an odd diagram. There's no reason why these have to happen in
> sequence and in fact in Trickle ICE, they don't, so
> >>> this diagram seems misleading., as well as potentially contradicting
> the beginning of S 5.1.1.
> >>>
> >>> "An ICE agent gathers candidates when it believes that communication
> is imminent. "
> >>
> >> I think the sequence applies to core ICE, and is also how it's done in
> 5245.
> >>
> >> The fact that trickle ICE does it differently I think shall be
> described in the trickle spec.
> >>
> >> However, it if helps, I could add the following note:
> >>
> >> "NOTE: This specification assumes that all candidates are gathered
> before they are sent to the peer. The trickle ICE extensions define
> procedures
> >> where gathered candidates can be sent to the peer as soon as they have
> been gathered, while additional candidates are still gathered."
> >
> > The issue here isn't that all candidates are gathered before they are
> sent to the peer but rather  that the diagram implies that no gathering
> happens before the peer's
> > candidates are received. That's not a requirement of 5245, and, as I
> said, contradicts the beginning of S 5.1.1.
>
> I could add the following sentence: "Note that an agent can begin
> gathering candidates at any point, even if it has not received any
> candidates (or even been contacted) by its peer."
>

My point is that the diagram just doesn't help.



> >>>   The agent will receive a Binding or Allocate response.  A successful
> >>>   Allocate response will provide the agent with a server reflexive Or
> nothing or an error.
> >>>
> >>>              (2^8)*(IP precedence) +
> >>>              (2^0)*(256 - component ID)
> >>>
> >>> Isn't this the same formula as in S 5.1.2.1.
> >>
> >> Section 5.1.2.1 defines the generic formula. This instance is when it
> is used by a Lite implementation.
> >>
> >> Of course, in order to align, I could replace "IP precedence" with
> "local preference".
> >
> > My suggestion is to have one copy.
>
> I can keep the formula in section 5.1.2.1.
>
> But, in the case of Lite, we still need to say what values are used for
> the different formula parts - even if we don't show the formula.
>

I agree.


>
> ---
>
> >>      pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)
> >>
> >> This was kinda terrible in 5245. Given that you use it once, maybe just
> have + GT(G, D)
> >>
> >> And then say GT(G, D) == 1 if G>D and 0 otherwise.
> >
> > I probably just don't see it, but what is the difference?
> >
> > It has the same semantics but it's easier to read. I mean, either you
> think the C syntax is self-explanatory or you
> > don't. If you do, then you don't need to explain it. If you don't, it's
> opaque in the expression,
>
> Personally I think the formula is clear,


I do too, but I note that a number of modern C-like languages don't have
this (e.g., neither Go nor Rust does)


and we could remove the following sentence:
>
> "where G>D?1:0 is an expression whose value is 1 if G is greater than D,
> and 0 otherwise."
>

I think that would probably be fine.


>
> ---
>
> >>>   pair to the remote candidate of the pair, as described in
> >>>   Section 7.2.4.
> >>>   IMPORTANT: You don't just send a STUN request, you start a STUN
> transaction,
> >>>
> >> There are multiple instances in the spec where it talks about sending
> STUN requests or Binding requests.
> >
> > I agree, but this statement is still confusing. Is there a reason not to
> change it?
>
> I could say "by initiating a STUN transaction", but I'd prefer to have
> common terminology.
>

"starting a check"


>>>   The ICE agent constructs a candidate pair whose local candidate

> >>>   equals the mapped address of the response, and whose remote candidate
> >>>
> >>> IMPORTANT: When does this happen?
> >>
> >> The last sentence of the parent section (7.2.5.3)  says:
> >>
> >> "If a check is considered a success, the ICE agent performs (in order)
> the actions described in the following sections."
> >
> > Please add a reverse reference.
>
> All 7.2.5.3.X. sections happens after the check has been considered a
> success, so exactly where do you want a reference?
>

At the beginning of the section that describes how to form a success.


>>> 7.3.1.3.  Learning Peer Reflexive Candidates
> >>>
> >>>This entire section seems to duplicate 7.2.5.3.1
> >>
> >> Section 7.2.5.3.1 describes how a STUN client detects a peer reflexive
> candidate then it receives a STUN response.
> >>
> >> Section 7.3.1.3 describes how a STUN server detects a peer reflexive
> candidate when it receives a STUN request.
> >>
> >> Sure, the text is similar, but separate procedures.
> >
> > This would benefit from consolidation.
>
> We did a choice to keep the client and server procedures separated, so I'd
> like to keep it.
>
> Also, there ARE differences in the procedures, so we still need to cover
> the client- and the server cases separately.
>

I agree it's a WG decision.


>
> >>> More generally, this document should explain how you end up in this
> >>> situation: you only get here when "the source transport address of the
> request
> >>> does not match any existing remote candidate", so how can it be on a
> check list
> >>> unless this is the second observation of a peer reflexive.
> >>
> >> I am not sure I understand. The source transport sentence you refer to
> is related to detection of peer reflexive candidates.
> >
> > My question is what sequence of events can lead to this situation, as it
> is surprising to the readers.
>
> Are you asking what events can lead to a triggered request?
>

No. What sequence of events can lead to a valid pair being on some other
check list.




>
> >>>   there will be four transactions per call (one for RTP and one for
> >>>   RTCP, for both caller and callee).  Each transaction is a single
> >>>   request and a single response, the former being 20 bytes long, and
> Is this currently true?
> >>>
> >>> How many people still don't support RTP-MUX?
> >>
> >> I don't know. But, unless you use mux exclusive the offerer still has
> to gather and provide RTCP candidates.
> >
> > Right, but then there will be three transactions per call in the common
> case.
>
> Assuming you are using offer/answer, yes.
>
> Maybe something like:
>
> "In a typical VoIP deployment, where RTP/RTCP multiplexing is used, there
> will be 2-3 transactions
> per call, depending on whether fallback to non-multiplexing is supported."
>

SGTM

-Ekr


>
> Regards,
>
> Christer
>

--94eb2c06273882065b056595b93a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Feb 19, 2018 at 11:19 AM, Christer Holmberg &=
lt;chri=
ster.holmberg@ericsson.com> wrote:
Hi,



(I have removed the tie-breaker comment, since it is covered in a separate =
thread)



-----------------------------------------------------------------=
-----

COMMENT:

-----------------------------------------------------------------=
-----



Review in context at:

https://mozphab-ietf.devsvcdev.mozaws.net/D3312<=
/a>



>>=C2=A0 =C2=A0Nomination, Regular Nomination=
:=C2=A0 The process of the controlling agent

>>=C2=A0 =C2=A0indicating to the controlled agent which candidate pai=
r the ICE Given that you have

>>=C2=A0 =C2=A0removed Aggressive Nomination, do you still need to re=
fer to "Regular Nomination"

>

> People asked to keep it in the Terminology section, to make it clear t=
hat "nomination" is 5245bis refers to what was called "regul=
ar nomination" in RFC 5245.

>

> OK, but then you should explain why you are using "regular" =
here.



NEW:



Nomination:=C2=A0 The process of the controlling agent

=C2=A0 =C2=A0 =C2=A0 indicating to the controlled agent which candidate pai=
r the ICE

=C2=A0 =C2=A0 =C2=A0 agents will use for sending and receiving data.=
 The nomination

=C2=A0 =C2=A0 =C2=A0 process defined in this specification was referred to =
"regular nomination"

=C2=A0 =C2=A0 =C2=A0 in RFC 5245.




---



>>>=C2=A0 =C2=A0candidate gathering, (2) candidate prioritization,=
 (3) redundant

>>>=C2=A0 candidate elimination, and (4) sending of the candidates=
 to the peer.

>>> This is an odd diagram. There's no reason why these have t=
o happen in sequence and in fact in Trickle ICE, they don't, so

>>> this diagram seems misleading., as well as potentially contrad=
icting the beginning of S 5.1.1.

>>>

>>> "An ICE agent gathers candidates when it believes that co=
mmunication is imminent. "

>>

>> I think the sequence applies to core ICE, and is also how it's=
 done in 5245.

>>

>> The fact that trickle ICE does it differently I think shall be des=
cribed in the trickle spec.

>>

>> However, it if helps, I could add the following note:

>>

>> "NOTE: This specification assumes that all candidates are gat=
hered before they are sent to the peer. The trickle ICE extensions define p=
rocedures

>> where gathered candidates can be sent to the peer as soon as they =
have been gathered, while additional candidates are still gathered."
>

> The issue here isn't that all candidates are gathered before they =
are sent to the peer but rather=C2=A0 that the diagram implies that no gath=
ering happens before the peer's

> candidates are received. That's not a requirement of 5245, and, as=
 I said, contradicts the beginning of S 5.1.1.



I could add the following sentence: "Note that an agent can beg=
in gathering candidates at any point, even if it has not received any candi=
dates (or even been contacted) by its peer."

>>>=C2=A0 =C2=A0The agent will receive a Binding or Allocate respo=
nse.=C2=A0 A successful

>>>=C2=A0 =C2=A0Allocate response will provide the agent with a se=
rver reflexive Or nothing or an error.

>>>

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (2^8)*(IP prec=
edence) +

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (2^0)*(256 - c=
omponent ID)

>>>

>>> Isn't this the same formula as in S 5.1.2.1.

>>

>> Section 5.1.2.1 defines the generic formula. This instance is when=
 it is used by a Lite implementation.

>>

>> Of course, in order to align, I could replace "IP precedence&=
quot; with "local preference".

>

> My suggestion is to have one copy.

=C2=A0

I can keep the formula in section 5.1.2.1.



But, in the case of Lite, we still need to say what values are used for the=
 different formula parts - even if we don't show the formula.

I agree.
=C2=A0



---

=C2=A0

>>=C2=A0 =C2=A0 =C2=A0 pair priority =3D 2^32*MIN(G,D) + 2*MAX(G,D) +=
 (G>D?1:0)

>>

>> This was kinda terrible in 5245. Given that you use it once, maybe=
 just have + GT(G, D)

>>

>> And then say GT(G, D) =3D=3D 1 if G>D and 0 otherwise.

>

> I probably just don't see it, but what is the difference?

>

> It has the same semantics but it's easier to read. I mean, either =
you think the C syntax is self-explanatory or you

> don't. If you do, then you don't need to explain it. If you do=
n't, it's opaque in the expression,



Personally I think the formula is clear,

=

I do too, but I note that a number of modern C-like languages don'=
t have this (e.g., neither Go nor Rust does)


<=
/div>
 and we could remove the following sent=
ence:



"where G>D?1:0 is an expression whose value is 1 if G is greater th=
an D, and 0 otherwise."

I think th=
at would probably be fine.
=C2=A0



---



>>>=C2=A0 =C2=A0pair to the remote candidate of the pair, as descr=
ibed in

>>>=C2=A0 =C2=A0Section 7.2.4.

>>>=C2=A0 =C2=A0IMPORTANT: You don't just send a STUN request,=
 you start a STUN transaction,

>>>

>> There are multiple instances in the spec where it talks about send=
ing STUN requests or Binding requests.

>

> I agree, but this statement is still confusing. Is there a reason not =
to change it?



I could say "by initiating a STUN transaction", but I'=
d prefer to have common terminology.

&q=
uot;starting a check"


>>=
>=C2=A0 =C2=A0The ICE agent constructs a candidate pair whose local cand=
idate

>>>=C2=A0 =C2=A0equals the mapped address of the response, and who=
se remote candidate

>>>

>>> IMPORTANT: When does this happen?

>>

>> The last sentence of the parent section (7.2.5.3)=C2=A0 says:

>>

>> "If a check is considered a success, the ICE agent performs (=
in order) the actions described in the following sections."

>

> Please add a reverse reference.



All 7.2.5.3.X. sections happens after the check has been considered =
a success, so exactly where do you want a reference?
<=
br>
At the beginning of the section that describes how to form a =
success.


=
>>> 7.3.1.3.=C2=A0 Learning Peer Reflexive Candid=
ates

>>>

>>>This entire section seems to duplicate 7.2.5.3.1

>>

>> Section 7.2.5.3.1 describes how a STUN client detects a peer refle=
xive candidate then it receives a STUN response.

>>

>> Section 7.3.1.3 describes how a STUN server detects a peer reflexi=
ve candidate when it receives a STUN request.

>>

>> Sure, the text is similar, but separate procedures.

>

> This would benefit from consolidation.



We did a choice to keep the client and server procedures separated, =
so I'd like to keep it.



Also, there ARE differences in the procedures, so we still need to cover th=
e client- and the server cases separately.

<=
div>I agree it's a WG decision.
=C2=A0


>>> More generally, this document should explain how you end up in=
 this

>>> situation: you only get here when "the source transport a=
ddress of the request

>>> does not match any existing remote candidate", so how can=
 it be on a check list

>>> unless this is the second observation of a peer reflexive.

>>

>> I am not sure I understand. The source transport sentence you refe=
r to is related to detection of peer reflexive candidates.

>

> My question is what sequence of events can lead to this situation, as =
it is surprising to the readers.



Are you asking what events can lead to a triggered request?

No. What sequence of events can lead to a valid=
 pair being on some other check list.






>>>=C2=A0 =C2=A0there will be four transactions per call (one for =
RTP and one for

>>>=C2=A0 =C2=A0RTCP, for both caller and callee).=C2=A0 Each tran=
saction is a single

>>>=C2=A0 =C2=A0request and a single response, the former being 20=
 bytes long, and Is this currently true?

>>>

>>> How many people still don't support RTP-MUX?

>>

>> I don't know. But, unless you use mux exclusive the offerer st=
ill has to gather and provide RTCP candidates.

>

> Right, but then there will be three transactions per call in the commo=
n case.



Assuming you are using offer/answer, yes.



Maybe something like:



"In a typical VoIP deployment, where RTP/RTCP multiplexing is used, th=
ere will be 2-3 transactions

per call, depending on whether fallback to non-multiplexing is supported.&q=
uot;





Regards,



Christer





--94eb2c06273882065b056595b93a--


From nobody Mon Feb 19 13:38:04 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D9D128959 for ; Mon, 19 Feb 2018 13:38:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKRpQfbcLvhU for ; Mon, 19 Feb 2018 13:38:00 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 5AA941277BB for ; Mon, 19 Feb 2018 13:38:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519076278; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Y8PduFnM4pXZceOiWY9jDN2q8tLrzJrwSovKBmKHCf4=; b=Ec1c0y3E+822jttQkClURpsl6RG36OfGmKybsfaw3MdVl3w1G+bW7R4XlE0brEdS XVcTHQfAJtUt+sGlXqHtbcAIKWNN+AcykML3Jp6vubZKSJIzHcNCHjje0k4lr+ON 91YH5sYMxIoQAzDd1PgYSHRfjL3X8XPga+mQHKTfCC8=;
X-AuditID: c1b4fb2d-4b1ff70000005540-e3-5a8b43b53df1
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E0.E2.21824.5B34B8A5; Mon, 19 Feb 2018 22:37:58 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0352.000; Mon, 19 Feb 2018 22:37:57 +0100
From: Christer Holmberg 
To: Eric Rescorla 
CC: The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , "pthatcher@google.com" , "ice@ietf.org" 
Thread-Topic: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
Thread-Index: AdOpa677O8VqdAW5ThyXNM/NhWOUGQAG8xsAAApmZdD///0JgP//0MkQ
Date: Mon, 19 Feb 2018 21:37:56 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1781B1@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C17801A@ESESSMB109.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.171]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7h+425+4og62PuCzmn7zObLHi9Tl2 i4uzJrNZfLtQazHjz0Rmi2vLX7M6sHks2FTqsWTJTyaPyY/bmAOYo7hsUlJzMstSi/TtErgy lq38yFiwyahi3akzbA2MPYZdjBwcEgImEie+RHUxcnEICRxmlHj6di8zhLOEUWLG81/MIEVs AhYS3f+0uxg5OUQEFCR+/TnBAlLDLPCCUeLczFdMIAlhgXqJR6v62UASIgINjBJfLk1hhehw k3jdeZkFxGYRUJXoPP6EHWQor4CvxMyluhDL5jNJzHy0CqyeUyBQomvPLLB6RgExie+n1oAt YBYQl7j1ZD6YLSEgILFkz3lmCFtU4uXjf6wQtpLEiYeNYEczC2hKrN+lD9GqKDGl+yE7iM0r IChxcuYTlgmMorOQTJ2F0DELSccsJB0LGFlWMYoWpxYX56YbGeulFmUmFxfn5+nlpZZsYgTG 1MEtv3V3MK5+7XiIUYCDUYmH11a3O0qINbGsuDL3EKMEB7OSCG+OCFCINyWxsiq1KD++qDQn tfgQozQHi5I470lP3ighgfTEktTs1NSC1CKYLBMHp1QDY+WpO5JRtxQfiK1zXBGUZvs3X/B9 9/vnq5ofBi5qFLo7Z77pV4tthtsXJ7jsubmq8g7nCYMPIRv7b7FN3L1Bb33rn0NAF9/t575w SOGogP6tOK84JuEI0yD1PXtXbmnc8it9mugtv/JnfZkzr56Ywx/m275T5ukUroBnBZrRxb+9 Hv6SZazhUWIpzkg01GIuKk4EAHXFhKylAgAA
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Feb 2018 21:38:03 -0000

SGksDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClJldmlldyBp
biBjb250ZXh0IGF0Og0KaHR0cHM6Ly9tb3pwaGFiLWlldGYuZGV2c3ZjZGV2Lm1vemF3cy5uZXQv
RDMzMTINCg0KLS0tDQoNCj4+Pj7CoCDCoGNhbmRpZGF0ZSBnYXRoZXJpbmcsICgyKSBjYW5kaWRh
dGUgcHJpb3JpdGl6YXRpb24sICgzKSByZWR1bmRhbnQNCj4+Pj7CoCBjYW5kaWRhdGUgZWxpbWlu
YXRpb24sIGFuZCAoNCkgc2VuZGluZyBvZiB0aGUgY2FuZGlkYXRlcyB0byB0aGUgcGVlci4NCj4+
Pj4gVGhpcyBpcyBhbiBvZGQgZGlhZ3JhbS4gVGhlcmUncyBubyByZWFzb24gd2h5IHRoZXNlIGhh
dmUgdG8gaGFwcGVuIGluIHNlcXVlbmNlIGFuZCBpbiBmYWN0IGluIFRyaWNrbGUgSUNFLCB0aGV5
IGRvbid0LCBzbw0KPj4+PiB0aGlzIGRpYWdyYW0gc2VlbXMgbWlzbGVhZGluZy4sIGFzIHdlbGwg
YXMgcG90ZW50aWFsbHkgY29udHJhZGljdGluZyB0aGUgYmVnaW5uaW5nIG9mIFMgNS4xLjEuDQo+
Pj4+DQo+Pj4+ICJBbiBJQ0UgYWdlbnQgZ2F0aGVycyBjYW5kaWRhdGVzIHdoZW4gaXQgYmVsaWV2
ZXMgdGhhdCBjb21tdW5pY2F0aW9uIGlzIGltbWluZW50LiAiDQo+Pj4NCj4+PiBJIHRoaW5rIHRo
ZSBzZXF1ZW5jZSBhcHBsaWVzIHRvIGNvcmUgSUNFLCBhbmQgaXMgYWxzbyBob3cgaXQncyBkb25l
IGluIDUyNDUuDQo+Pj4NCj4+PiBUaGUgZmFjdCB0aGF0IHRyaWNrbGUgSUNFIGRvZXMgaXQgZGlm
ZmVyZW50bHkgSSB0aGluayBzaGFsbCBiZSBkZXNjcmliZWQgaW4gdGhlIHRyaWNrbGUgc3BlYy4N
Cj4+Pg0KPj4+IEhvd2V2ZXIsIGl0IGlmIGhlbHBzLCBJIGNvdWxkIGFkZCB0aGUgZm9sbG93aW5n
IG5vdGU6DQo+Pj4NCj4+PiAiTk9URTogVGhpcyBzcGVjaWZpY2F0aW9uIGFzc3VtZXMgdGhhdCBh
bGwgY2FuZGlkYXRlcyBhcmUgZ2F0aGVyZWQgYmVmb3JlIHRoZXkgYXJlIHNlbnQgdG8gdGhlIHBl
ZXIuIA0KPj4+IFRoZSB0cmlja2xlIElDRSBleHRlbnNpb25zIGRlZmluZSBwcm9jZWR1cmVzIHdo
ZXJlIGdhdGhlcmVkIGNhbmRpZGF0ZXMgY2FuIGJlIHNlbnQgdG8gdGhlIHBlZXIgYXMgDQo+Pj4g
c29vbiBhcyB0aGV5IGhhdmUgYmVlbiBnYXRoZXJlZCwgd2hpbGUgYWRkaXRpb25hbCBjYW5kaWRh
dGVzIGFyZSBzdGlsbCBnYXRoZXJlZC4iDQo+Pj4NCj4+PiBUaGUgaXNzdWUgaGVyZSBpc24ndCB0
aGF0IGFsbCBjYW5kaWRhdGVzIGFyZSBnYXRoZXJlZCBiZWZvcmUgdGhleSBhcmUgc2VudCB0byB0
aGUgcGVlciBidXQgcmF0aGVywqAgdGhhdCANCj4+PiB0aGUgZGlhZ3JhbSBpbXBsaWVzIHRoYXQg
bm8gZ2F0aGVyaW5nIGhhcHBlbnMgYmVmb3JlIHRoZSBwZWVyJ3MgY2FuZGlkYXRlcyBhcmUgcmVj
ZWl2ZWQuIFRoYXQncyBub3QgYSANCj4+PiByZXF1aXJlbWVudCBvZiA1MjQ1LCBhbmQsIGFzIEkg
c2FpZCwgY29udHJhZGljdHMgdGhlIGJlZ2lubmluZyBvZiBTIDUuMS4xLg0KPj4NCj4+IEkgY291
bGQgYWRkIHRoZSBmb2xsb3dpbmcgc2VudGVuY2U6ICJOb3RlIHRoYXQgYW4gYWdlbnQgY2FuIGJl
Z2luIGdhdGhlcmluZyBjYW5kaWRhdGVzIGF0IGFueSBwb2ludCwgZXZlbiANCj4+IGlmIGl0IGhh
cyBub3QgcmVjZWl2ZWQgYW55IGNhbmRpZGF0ZXMgKG9yIGV2ZW4gYmVlbiBjb250YWN0ZWQpIGJ5
IGl0cyBwZWVyLiINCj4NCj4gTXkgcG9pbnQgaXMgdGhhdCB0aGUgZGlhZ3JhbSBqdXN0IGRvZXNu
J3QgaGVscC4NCg0KT2suIFNvLCBJJ2xsIHJlbW92ZSB0aGUgZGlhZ3JhbSwgYW5kIG9ubHkga2Vl
cCB0aGUgZm9sbG93aW5nIHRleHQ6DQoNCjUuICBJQ0UgQ2FuZGlkYXRlIEdhdGhlcmluZyBhbmQg
RXhjaGFuZ2UNCg0KICAgQXMgcGFydCBvZiBJQ0UgcHJvY2Vzc2luZywgYm90aCB0aGUgaW5pdGlh
dGluZyBhbmQgcmVzcG9uZGluZyBhZ2VudHMNCiAgIGdhdGhlciBjYW5kaWRhdGVzLCBwcmlvcml0
aXplIGFuZCBlbGltaW5hdGUgcmVkdW5kYW50IGNhbmRpZGF0ZXMsICANCiAgIGFuZCBleGNoYW5n
ZSBjYW5kaWRhdGUgaW5mb3JtYXRpb24gd2l0aCB0aGUgcGVlciBhcyBkZWZpbmVkIGJ5IHRoZSAN
CiAgIFVzYWdlIFByb3RvY29sIChJQ0UgVXNhZ2UpLiAgU3BlY2lmaWNzIG9mIHRoZSBjYW5kaWRh
dGUgZW5jb2RpbmcgDQogICBtZWNoYW5pc20gYW5kIHRoZSBzZW1hbnRpY3Mgb2YgY2FuZGlkYXRl
IGluZm9ybWF0aW9uIGV4Y2hhbmdlIGlzIG91dCANCiAgIG9mIHNjb3BlIG9mIHRoaXMgc3BlY2lm
aWNhdGlvbi4NCg0KLS0tDQrCoA0KPj4+PsKgIMKgcGFpciB0byB0aGUgcmVtb3RlIGNhbmRpZGF0
ZSBvZiB0aGUgcGFpciwgYXMgZGVzY3JpYmVkIGluDQo+Pj4+wqAgwqBTZWN0aW9uIDcuMi40Lg0K
Pj4+PsKgIMKgSU1QT1JUQU5UOiBZb3UgZG9uJ3QganVzdCBzZW5kIGEgU1RVTiByZXF1ZXN0LCB5
b3Ugc3RhcnQgYSBTVFVOIHRyYW5zYWN0aW9uLA0KPj4+Pg0KPj4+IFRoZXJlIGFyZSBtdWx0aXBs
ZSBpbnN0YW5jZXMgaW4gdGhlIHNwZWMgd2hlcmUgaXQgdGFsa3MgYWJvdXQgc2VuZGluZyBTVFVO
IHJlcXVlc3RzIG9yIEJpbmRpbmcgcmVxdWVzdHMuDQo+Pg0KPj4gSSBhZ3JlZSwgYnV0IHRoaXMg
c3RhdGVtZW50IGlzIHN0aWxsIGNvbmZ1c2luZy4gSXMgdGhlcmUgYSByZWFzb24gbm90IHRvIGNo
YW5nZSBpdD8NCj4NCj4+IEkgY291bGQgc2F5ICJieSBpbml0aWF0aW5nIGEgU1RVTiB0cmFuc2Fj
dGlvbiIsIGJ1dCBJJ2QgcHJlZmVyIHRvIGhhdmUgY29tbW9uIHRlcm1pbm9sb2d5Lg0KPg0KPiAi
c3RhcnRpbmcgYSBjaGVjayINCg0KT2suDQoNCi0tLQ0KDQo+Pj4+wqAgwqBUaGUgSUNFIGFnZW50
IGNvbnN0cnVjdHMgYSBjYW5kaWRhdGUgcGFpciB3aG9zZSBsb2NhbCBjYW5kaWRhdGUNCj4+Pj7C
oCDCoGVxdWFscyB0aGUgbWFwcGVkIGFkZHJlc3Mgb2YgdGhlIHJlc3BvbnNlLCBhbmQgd2hvc2Ug
cmVtb3RlIGNhbmRpZGF0ZQ0KPj4+Pg0KPj4+PiBJTVBPUlRBTlQ6IFdoZW4gZG9lcyB0aGlzIGhh
cHBlbj8NCj4+Pg0KPj4+IFRoZSBsYXN0IHNlbnRlbmNlIG9mIHRoZSBwYXJlbnQgc2VjdGlvbiAo
Ny4yLjUuMynCoCBzYXlzOg0KPj4+DQo+Pj4gIklmIGEgY2hlY2sgaXMgY29uc2lkZXJlZCBhIHN1
Y2Nlc3MsIHRoZSBJQ0UgYWdlbnQgcGVyZm9ybXMgKGluIG9yZGVyKSB0aGUgYWN0aW9ucyBkZXNj
cmliZWQgaW4gdGhlIGZvbGxvd2luZyBzZWN0aW9ucy4iDQo+Pg0KPj4gUGxlYXNlIGFkZCBhIHJl
dmVyc2UgcmVmZXJlbmNlLg0KPj4NCj4+IEFsbCA3LjIuNS4zLlguIHNlY3Rpb25zIGhhcHBlbnMg
YWZ0ZXIgdGhlIGNoZWNrIGhhcyBiZWVuIGNvbnNpZGVyZWQgYSBzdWNjZXNzLCBzbyBleGFjdGx5
IHdoZXJlIGRvIHlvdSB3YW50IGEgcmVmZXJlbmNlPw0KPg0KPiBBdCB0aGUgYmVnaW5uaW5nIG9m
IHRoZSBzZWN0aW9uIHRoYXQgZGVzY3JpYmVzIGhvdyB0byBmb3JtIGEgc3VjY2Vzcy4NCg0KU2Vj
dGlvbiA3LjIuNS4zIGRlZmluZXMgaG93IGEgc3VjY2VzcyBpcyBmb3JtZWQsIGFuZCB0aGVuIHN0
YXRlcyB0aGF0IHRoZSBwcm9jZWR1cmVzIGluIHRoZSBmb2xsb3dpbmcgc3ViIHNlY3Rpb25zIGFy
ZSBwZXJmb3JtZWQuIERvIHlvdSB3YW50IHRvIGFkZCBleHBsaWNpdCByZWZlcmVuY2VzIHRvIHRo
b3NlIHN1YiBzZWN0aW9ucz8NCg0KTWF5YmUgSSdtIHRvbyB0aXJlZCwgYnV0IEknbSBnb2luZyB0
byBoYXZlIHRvIGFzayB5b3UgdG8gcHJvdmlkZSB0ZXh0LCBiZWNhdXNlIEkgc3RpbGwgZG9uJ3Qg
dW5kZXJzdGFuZCBleGFjdGx5IHdoYXQgeW91IHdhbnQuDQoNCi0tLQ0KDQo+Pj4+IE1vcmUgZ2Vu
ZXJhbGx5LCB0aGlzIGRvY3VtZW50IHNob3VsZCBleHBsYWluIGhvdyB5b3UgZW5kIHVwIGluIHRo
aXMNCj4+Pj4gc2l0dWF0aW9uOiB5b3Ugb25seSBnZXQgaGVyZSB3aGVuICJ0aGUgc291cmNlIHRy
YW5zcG9ydCBhZGRyZXNzIG9mIHRoZSByZXF1ZXN0DQo+Pj4+IGRvZXMgbm90IG1hdGNoIGFueSBl
eGlzdGluZyByZW1vdGUgY2FuZGlkYXRlIiwgc28gaG93IGNhbiBpdCBiZSBvbiBhIGNoZWNrIGxp
c3QNCj4+Pj4gdW5sZXNzIHRoaXMgaXMgdGhlIHNlY29uZCBvYnNlcnZhdGlvbiBvZiBhIHBlZXIg
cmVmbGV4aXZlLg0KPj4+DQo+Pj4gSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQuIFRoZSBzb3Vy
Y2UgdHJhbnNwb3J0IHNlbnRlbmNlIHlvdSByZWZlciB0byBpcyByZWxhdGVkIHRvIGRldGVjdGlv
biBvZiBwZWVyIHJlZmxleGl2ZSBjYW5kaWRhdGVzLg0KPj4NCj4+IE15IHF1ZXN0aW9uIGlzIHdo
YXQgc2VxdWVuY2Ugb2YgZXZlbnRzIGNhbiBsZWFkIHRvIHRoaXMgc2l0dWF0aW9uLCBhcyBpdCBp
cyBzdXJwcmlzaW5nIHRvIHRoZSByZWFkZXJzLg0KPg0KPj4gQXJlIHlvdSBhc2tpbmcgd2hhdCBl
dmVudHMgY2FuIGxlYWQgdG8gYSB0cmlnZ2VyZWQgcmVxdWVzdD8NCj4NCj4gTm8uIFdoYXQgc2Vx
dWVuY2Ugb2YgZXZlbnRzIGNhbiBsZWFkIHRvIGEgdmFsaWQgcGFpciBiZWluZyBvbiBzb21lIG90
aGVyIGNoZWNrIGxpc3QuDQoNCkFhaCwgZ290Y2hhLiBNb3N0IGxpa2VseSBpdCBjYW4ndCwgYW5k
IHVubGVzcyBJIGZpZ3VyZSBvdXQgaG93IEkgd2lsbCByZW1vdmUgdGhlIGFzc29jaWF0ZWQgdGV4
dC4NCg0KLS0tDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg==


From nobody Tue Feb 20 11:06:00 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057DD12DA00; Tue, 20 Feb 2018 11:05:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=Pu5uN9vw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HQxIs4Vm
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 uut-6rrvfsGl; Tue, 20 Feb 2018 11:05:57 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942D712D96D; Tue, 20 Feb 2018 11:05:57 -0800 (PST)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D0BC420D1E; Tue, 20 Feb 2018 14:05:56 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 20 Feb 2018 14:05:56 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=5C8mcH0lZ/hWJTc+pqACRVTK4CWfs AHweNPjzSv0UG4=; b=Pu5uN9vwwXSIt7cagm7RpzjQSNYyzOaY4b9WsVTZkjM+F /12lDkGfH6uXGzjEg/l1x3dtHAM3fHq1oSKMefiNVrZeS2YuFXJIG32PLcZNm5me ysjz6X/pPLn2WE1nmK/p/NpaiVoJYR+EIluXOcCQbSDYzUR4tuBNOn595j9a1VTC rIptqtqKs2DhilJhbuNmsF3yLmxdAdiBTgl/fr5UP6c1E75/hvywgz6xSVXYI5hZ Dp0SzxazdYlKEDKxAhGfrrTm/A/lfULo2T5ag7hc7lfrV5Lzk5scu3xD3ogvgQWO 36zW/G3vhS7vfzGefo3AfVjAsoDChZni9rIH4Vr9A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=5C8mcH 0lZ/hWJTc+pqACRVTK4CWfsAHweNPjzSv0UG4=; b=HQxIs4Vm6myW6snStn/9yD sqD712dOQqXmJGVWpeUvgi3SKm5wnt/OVKa09zPxVlcBSTqnIQxNU6Gr9E7QT2Kl b1g6KPSBtiz7bAinQkbyFuc8i3u71Akpxp1/TioAt6ER83b5r1mg16/5PBLpxlTK eqNG8+IooFOEHQNaC86BLL5UFjQfcqytajzqAsN4/3qduth5AryEU/MhuxcCmwU5 qaPySzqcQgPUoXD0Con+9I8UL4M+TRPgS1XV+K7MMXOWHybRGRuFyJR3J2HjrYaf PcsJ6MXH7ou38/2Rrep7ubAX4R8AQfL6Xhw9ylnX89UNMc+kJDnab5maE+wJ/bhA ==
X-ME-Sender: 
Received: from dhcp-10-155-36-58.cisco.com (unknown [128.107.241.167]) by mail.messagingengine.com (Postfix) with ESMTPA id 4A0A97E0ED; Tue, 20 Feb 2018 14:05:56 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper 
In-Reply-To: <151878874692.4869.5442673693779488735@ietfa.amsl.com>
Date: Tue, 20 Feb 2018 11:05:54 -0800
Cc: "gen-art@ietf.org Review Team" , draft-ietf-ice-rfc5245bis.all@ietf.org, ice@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <151878874692.4869.5442673693779488735@ietfa.amsl.com>
To: Stewart Bryant 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [Ice] [Gen-art] Genart telechat review of draft-ietf-ice-rfc5245bis-17
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Feb 2018 19:05:59 -0000

Stewart, thanks for your review. I have entered a No Objection ballot.

Alissa


> On Feb 16, 2018, at 5:45 AM, Stewart Bryant  =
wrote:
>=20
> Reviewer: Stewart Bryant
> Review result: Ready
>=20
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please wait for direction from your
> document shepherd or AD before posting a new version of the draft.
>=20
> For more information, please see the FAQ at
>=20
> .
>=20
> Document: draft-ietf-ice-rfc5245bis-17
> Reviewer: Stewart Bryant
> Review Date: 2018-02-16
> IETF LC End Date: 2018-01-26
> IESG Telechat date: 2018-02-22
>=20
> Summary: A well written document ready for publication.
>=20
> Major issues: None
>=20
> Minor issues: None
>=20
> Nits/editorial comments: None
>=20
>=20
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art


From nobody Tue Feb 20 14:00:21 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F9F12E037; Tue, 20 Feb 2018 14:00:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.231
X-Spam-Level: 
X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 T1NhRJHJCo5n; Tue, 20 Feb 2018 14:00:15 -0800 (PST)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 5240212D959; Tue, 20 Feb 2018 14:00:14 -0800 (PST)
X-AuditID: 12074422-ef7ff70000002e48-4b-5a8c9a6abf3f
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id EE.8F.11848.B6A9C8A5; Tue, 20 Feb 2018 17:00:12 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w1KM068a005479; Tue, 20 Feb 2018 17:00:08 -0500
Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w1KM02o8022493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Feb 2018 17:00:05 -0500
Date: Tue, 20 Feb 2018 16:00:03 -0600
From: Benjamin Kaduk 
To: IESG 
Cc: draft-ietf-ice-rfc5245bis@ietf.org, ice-chairs@ietf.org, pthatcher@google.com, ice@ietf.org
Message-ID: <20180220220002.GS54688@mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixG6nrpszqyfKYP10JYv5J68zW1ycNZnN 4tuFWosZfyYyW1xb/prVgdVjwaZSjyVLfjIFMEVx2aSk5mSWpRbp2yVwZXw/eJalYLdWxeRr u9gbGBcrdjFyckgImEi0zGxg7WLk4hASWMwksXfrF0YIZyOjxIfH+1kgnLNMErPXrWcGaWER UJXY2/qXFcRmE1CRaOi+DBYXEZCQWPdgCVicWSBDYurs/0wgtrBAtMTOA3vA4rwCOhInv11j gbAFJU7OfMICUa8lcePfS6B6DiBbWmL5Pw6QsKiAssTevkPsExj5ZiHpmIWkYxZCxwJG5lWM sim5Vbq5iZk5xanJusXJiXl5qUW6pnq5mSV6qSmlmxjBAemitINx4j+vQ4wCHIxKPLwPNHui hFgTy4orcw8xSnIwKYnypqh0RwnxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4b38HSjHm5JYWZVa lA+TkuZgURLn9TDRjhISSE8sSc1OTS1ILYLJynBwKEnwTpoJtEewKDU9tSItM6cEIc3EwQky nAdoeD9IDW9xQWJucWY6RP4Uoy7HjRev25iFWPLy81KlxHn/zAAqEgApyijNg5sDSiQS2ftr XjGKA70lzLsGZBQPMAnBTXoFtIQJaMlqkU6QJSWJCCmpBkbnjiX6l4KaWpoP9IitPbGLmcXt 66GFl17eD63YYDg1eO/68LLw6kge9V6BRVuLE/6xSSe8+Gy+u7aTMaTQM5fX+sOHIyfCLdK+ Z3LtqSp56+XcdDMxr6rwtuQdPb28ggaXU/cZF+VGSC6+f3HCK9ZPcxefYVS2tTy4JOXQzNsp TztnSkQ3vFZiKc5INNRiLipOBADiwqBW/wIAAA==
Archived-At: 
Subject: [Ice] Benjamin Kaduk's practice ballot on draft-ietf-ice-rfc5245bis-17: (with COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Feb 2018 22:00:16 -0000

[resending with fixed Subject and recipients list]

[incoming AD ramping up on pre-telechat document review]

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Given that this is a -bis document, there are some areas that may
have aged poorly and could benefit from reconsideration:

In Section 5.2, we say that for the Lite implementation, preferring
IPv4 is RECOMMENDED for dual-stack hosts.  Is that still the advice
we want to give?

Section 17 is very focused on voice traffic; is that still the main
use of ICE?

Appendix B.8 has:

   Additionally, using a Binding Indication allows integrity to be
   disabled, allowing for better performance.  This is useful for large-
   scale endpoints, such as PSTN gateways and SBCs.

which talks of disabling STUN's MESSAGE-INTEGRITY as a potential
benefit.  Do we really want to advocate for increased levels of
unauthenticated plaintext on the internet?

Appendix C has a table of bandwidth consumption in various
scenarios, most of which are measured in kilobits per second.  Is
this still relevant to modern deployments?

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Some other general comments/questions.


I was also a little confused in Section 6.1.2.2, where we say

   for each interface.  To keep the amount of resulting candidate pairs
   reasonable and to avoid candidate pairs that are highly unlikely to
   work, IPv6 link-local addresses [RFC4291] MUST NOT be paired with
   other than link-local addresses.

but in section 5.1.1.1 we say that IPv6 link-local addresses MUST
NOT be gathered.  Is this just to handle the chance that we might
get a reflexive candiate for a link-local address?


Section 13 has:

   Consequently, any future ICE enhancements MUST
   preserve triggered checks.

which does not seem like an enforceable requirement, given that
future updates to this document could just remove it.  Perhaps it
should be worded differently to give the motivation for the need to
keep triggered checks.


In section 14.3:

   For connectivity checks, agents SHOULD calculate the RTO value using
   the following formula:

     RTO = MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress))

What is 'N'?


In Section 15:

   will succeed.  Consequently, agent R constructs a new candidate pair
   using the mapped address from the response as the local candidate (R-
   PUB-1) and the destination of the request (NAT-PUB-1) as the remote
   candidate.  This pair is added to the valid list for that data
   stream.

which leaves me confused, perhaps just about which response is "the
response" that we're taking the mapped address from.  The previous
text is about a STUN Binding request from L to R that causes R to
generate a triggered check, so is this the response that R generates
to the Binding request from L?  IIUC the mapped address therein
would be where R sees traffic from L as originating from, and would
not be appropriate to use as a local address for R, etc..  So
presumably I am picking the wrong response to use as the source of
data.


In Section 18.3:

   [...] The process of determining
   connectivity is very robust.

This seems to contrast with section 14.1, where

   The loss of the first single packet for any
   connectivity check is likely to cause that pair to take a long time
   to be validated, and instead, a lower-priority check (but one for
   which there was no packet loss) is much more likely to complete
   first.


Something of a side note, but is HMAC-SHA1 still the state of the
art for STUN MESSAGE-INTEGRITY?  I know that there are no known
breaks against HMAC-SHA1, but I would be a little surprised if no
one was interested in producing an update.


In Section 19.3:

   However, TURN servers are susceptible to DNS attacks for purposes of
   turning it into a zombie or rogue server.  These attacks can be
   mitigated by DNS-SEC and through good box and software security on
   TURN servers.

I don't understand this.  Is the ICE agent or the TURN server
"turned into" a zombie or rogue server by DNS attacks?  If the TURN
server, how would a bogus DNS response turn it into a rogue server?

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

On an editorial note, there is a general feel to the document that
it started off life as only covering ICE for RTP and the application
profiling was later split off into separtae documents.  I don't know
that it's worth the effort to try to change that, though.  I might
give some thought to factoring out some of the duplicated content,
though, such as discussion of how RTP gets component ID 1 and RTCP
id 2, and I think Ekr noted some other areas of duplication.

Other purely editorial nits follow (IESG feel free to ignore).

Section 18.2:

   Therefore, the servers get used less and
   less, and can eventually be remove when their usage goes to zero.

*removed


Section 19.4:

   In addition to attacks where the attacker is a third party trying to
   insert fake candidate information or stun messages,

s/stun/STUN/


Section 21:

   o  Make technical changes, due to discovered flows in RFC 5245 and
      based on feedback from the community that has implemented and
      deployed ICE applications based on RFC 5245.

flows or flaws?


-Benjamin


From nobody Tue Feb 20 14:51:38 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FDC126DFF for ; Tue, 20 Feb 2018 14:51:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 hzsmUED_1TDX for ; Tue, 20 Feb 2018 14:51:35 -0800 (PST)
Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (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 C2070120724 for ; Tue, 20 Feb 2018 14:51:32 -0800 (PST)
Received: by mail-ua0-x22d.google.com with SMTP id n1so9475741uaa.2 for ; Tue, 20 Feb 2018 14:51:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6AgOPVnhKjSzXElDeJ3vDAjZNf1XgrtDnxqyPWwXEpU=; b=gFfXzlZ9rWThso+F8K5ZEQC6VW2jCx/tN/HtV66aIZh7QXvxJzFzijNCrl6djFQ12c m5ELiynCK5Q8MzaYmGHLAcdiBU+fLQES5tRg1LMvbJ7G5tD2I9cvbdWsCStq7OAhPU6r KMvqqQAtRPrc2kSB1efDXQUy7YdVTRMBe2eSWyY3sbXbVAfVQRMV/tmfRntHBy012C9p JIq2yZkBLP3dkTRP1bXlBrUl/nzI+b2z9hrS9s3H323IM6QHY9Sggb8nAQNMWdEHjGu2 c+1BYrqqDfRnvMIW8kfb3xmK9OBaQTYIpaFMk/knT3nNy882l5sMw2d9rhDqpC2qVlY0 VyhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6AgOPVnhKjSzXElDeJ3vDAjZNf1XgrtDnxqyPWwXEpU=; b=Po0IU23pqv0HT9H8DufHK88S06ZbCs45ugVIG+wmTR39vnGWnvWyK4Q0cipHef3PZF FOqgGjrizeCNalijLOk9EyYYRQ3/xJe9rpa+hnU5banQ24TE4Aw7pN2TDdDPCsNi+oYq e5fBxUrPT2yFnsUoi7Xprc76o0oP3yAmTjLYW4X3IR5Lnhbe1lbKOjk3nSNerWMx2YXT /qBN6SkMPu9Z/eLeurBgjCaWeKYaoBJvq//Lt297XKbcJTLfhFUjjh4smZKPWm87gmSJ V4t0s77sknB5ql1vC6hJ09H8JwIpv0Wjh5HOrQxHQpdmP8KqHdbbhHvh40xDXh0y4BEb 663Q==
X-Gm-Message-State: APf1xPA/7DW7qxxOBBC2WIwPqUGJx42gVw9cuYbPrfDo+PKrJqIwasXX kEhgrSVRx/qiUS5DPDSy8MUKZF+5zPSbL1Wh8DObJQ==
X-Google-Smtp-Source: AH8x225SwtUdem6GGiL341b7WNGMclWjBcc64ZAITR0ZoLM6/K1OSBLFr60EhLkOr10xbQAklnZ9CnvVawREQJG8tD8=
X-Received: by 10.176.82.26 with SMTP id i26mr1001560uaa.107.1519167091236; Tue, 20 Feb 2018 14:51:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.114.66 with HTTP; Tue, 20 Feb 2018 14:51:30 -0800 (PST)
In-Reply-To: 
References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se>  <1504CC1C-C872-4AC5-9003-E28488FE9B99@nostrum.com> <7594FB04B1934943A5C02806D1A2204B6C177D2D@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C177D9D@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C177EC7@ESESSMB109.ericsson.se> 
From: Taylor Brandstetter 
Date: Tue, 20 Feb 2018 14:51:30 -0800
Message-ID: 
To: Eric Rescorla 
Cc: Christer Holmberg , Ben Campbell ,  "ice-chairs@ietf.org" , "ice@ietf.org" ,  "draft-ietf-ice-rfc5245bis@ietf.org" ,  "pthatcher@google.com" , The IESG 
Content-Type: multipart/alternative; boundary="94eb2c18ff88d475420565aca6f1"
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Feb 2018 22:51:37 -0000

--94eb2c18ff88d475420565aca6f1
Content-Type: text/plain; charset="UTF-8"

The tie-breaker collision problem has come up a few times before, actually.
As I've said, I believe it could be fixed very easily by saying "pick a new
tie-breaker if this happens."

As for the "MUST not change tie-breaker" rule in section 16.1, requiring an
ICE restart is overkill. We can just change it to "MUST not change
tie-breaker* unless there's a collision*."

On Mon, Feb 19, 2018 at 10:33 AM, Eric Rescorla  wrote:

>
>
> On Mon, Feb 19, 2018 at 10:29 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
>> Hi,
>>
>> ...
>>
>> >>>> IF we really want to solve this, one simple solution be to say that,
>> if this happens, and endpoint simply calculates a
>> >>>> new tie-breaker value, and tries again? BUT, then we would have to
>> change section 16.1, which says that a new value can only be calculated at
>> an ICE restart.
>> >>>>
>> >>>> So, could we simply say that, if this happens, the agent MUST do an
>> ICE restart, and it MUST calculate a new tie-breaker value?
>> >>>
>> >>> Now both sides might do a simultaneous restart. Is that going to work?
>> >>
>> >> We could say that the initiating agent MUST do the restart.
>> >
>> > In this scenario, don't both sides believe they are the initiating
>> peer, hence the need for the tiebreaker?
>>
>> Probably...
>>
>> But, then I don't see what we could do. If both agents send a check, and
>> receive 487, we can't define a procedure for one of the agents.
>>
>> Perhaps we should then change the must-not-change-the-value-unless-restart
>> and say that an agent changes the tie-breaker value and try again.
>>
>
> As you say, the problem is inherently that the situation is symmetrical.
>
> At this point in the design process, I don't think it's worth trying to
> actually make the call succeed; a 2^{-64} failure rate is much lower than
> organic call failure rates from other causes, even in non-3PCC scenarios.
> Rather, I think the spec should just prescribe a clean failure mode via a
> new error code, rather than having both sides wildly oscillate between
> controlled and controlling
>
> -Ekr
>
>
>>
>> Regards,
>>
>> Christer
>>
>>
>
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice
>
>

--94eb2c18ff88d475420565aca6f1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


The tie-breaker collision proble=
m has come up a few times before, actually. As I've said, I believe=C2=
=A0it could be fixed very easily by saying "pick a new tie-brea=
ker if this happens."

As for the "MUST not cha=
nge tie-breaker" rule in section 16.1, requiring an ICE restart is ove=
rkill. We can just change it to "MUST not change tie-breaker unless=
 there's a collision."

On Mon, Feb 19, 2018 at 10:33 AM, Eric Re=
scorla <ekr@rtfm.com> wrote:


On Mon, Feb 19, 2018 at 10:29 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,



...



>>>> IF we really want to solve this, one simple solution be to=
 say that, if this happens, and endpoint simply calculates a

>>>> new tie-breaker value, and tries again? BUT, then we would=
 have to change section 16.1, which says that a new value can only be calcu=
lated at an ICE restart.

>>>>

>>>> So, could we simply say that, if this happens, the agent M=
UST do an ICE restart, and it MUST calculate a new tie-breaker value?

>>>

>>> Now both sides might do a simultaneous restart. Is that going =
to work?

>>

>> We could say that the initiating agent MUST do the restart.

>

> In this scenario, don't both sides believe they are the initiating=
 peer, hence the need for the tiebreaker?



Probably...



But, then I don't see what we could do. If both agents send a check, an=
d receive 487, we can't define a procedure for one of the agents.



Perhaps we should then change the must-not-change-the-value-unless-res=
tart and say that an agent changes the tie-breaker value and try again.
=


As you say, the problem is inherent=
ly that the situation is symmetrical.

At this poin=
t in the design process, I don't think it's worth trying to actuall=
y make the call succeed; a 2^{-64} failure rate is much lower than organic =
call failure rates from other causes, even in non-3PCC scenarios. Rather, I=
 think the spec should just prescribe a clean failure mode via a new error =
code, rather than having both sides wildly oscillate between controlled and=
 controlling

-Ekr
=C2=A0



Regards,



Christer







_______________________________________________

Ice mailing list

Ice@ietf.org

https://www.ietf.org/mailman/listinfo/ice





--94eb2c18ff88d475420565aca6f1--


From nobody Tue Feb 20 15:07:46 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56D5126DFF for ; Tue, 20 Feb 2018 15:07:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 EeHZFjygq-Ib for ; Tue, 20 Feb 2018 15:07:39 -0800 (PST)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 11B8712E042 for ; Tue, 20 Feb 2018 15:07:37 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id n198so18692552qke.7 for ; Tue, 20 Feb 2018 15:07:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PhCS97ofDuVlSmaDij9JHwzF06+CCx9YkQbPVbo0830=; b=OEQDXNf6h8IqXExW1r3pHvjCsPjI8LVDh0B1seWBkA4U3JezKi2zs67KqxVVF5QKEw 8VGOmO/wCLwk0/WWLGfKoQGGOfe7ckk4qs91NR173sgqDWUGfaM0Bk4ags79gJTUlosq IQ3bdDHOtOLtRaT8/9zpewrw/SVNM0aD4aqPUwU7D/Yo+/vNzW10gl/9tJ2rP3kzyn+I Ddi6IXugwLcNjDq47X/ARJ8zCBKpgrKDJRyeKESifLUbXVwryd4N1LSAZT04MU0vjPBp ARFHe73nYlXujOWDgjwpKSomdvzjlkBQ8sMX1bPlHGDx/WZblNZnEWIF8/+pLGHwcMnM iCtg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PhCS97ofDuVlSmaDij9JHwzF06+CCx9YkQbPVbo0830=; b=Lx+ERhHQTKVk+kyg2aeWHHGbWP1Ms3E/dQbGHxq4Ra4zGHQVxlfwMmCLshoYy81zP8 4BKPRsFDMrvJb/15WLZD6kKVnLP+dJZ2zzHIkvXcoTm4aFh+nm1lXH2s8zItMmVOSc1X rhsMuboksb00lNKTO2w3UdiKnSNomA03CD7PEdDyAFxMe5k1ImhV9eGN3JGSPa7d3GX+ q3mIe2bLPOWRl9MakJ2sbClxM6zKpJ/Zm1kePV48sVPVAM+SyHDlzmocHh3x4Jadk2Ov yriuEYurPepXZC65geWB33aVUjQrPQ/81SLXeX1e0LaxSvDCXowz7yKpHYJzfO7zGvBr 97NQ==
X-Gm-Message-State: APf1xPCC67dcA3NFc4z/d9sXVOakUZnb9eX9HjJIEgygLmihHX32ES/H aILypd6TlLrlQLF5Hlfohghea98lB/EwcyCrRp+hcQ==
X-Google-Smtp-Source: AH8x224lxSf7uESn6vMQW4O4iIL+RkQoAogN8Fs6pVJdXxOuGgdrXsncrkGRO0HG/ORQJcQTQmylVxvRqkC/jXEer2k=
X-Received: by 10.55.118.6 with SMTP id r6mr2193728qkc.211.1519168056088; Tue, 20 Feb 2018 15:07:36 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Tue, 20 Feb 2018 15:06:55 -0800 (PST)
In-Reply-To: 
References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se>  <1504CC1C-C872-4AC5-9003-E28488FE9B99@nostrum.com> <7594FB04B1934943A5C02806D1A2204B6C177D2D@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C177D9D@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C177EC7@ESESSMB109.ericsson.se>  
From: Eric Rescorla 
Date: Tue, 20 Feb 2018 15:06:55 -0800
Message-ID: 
To: Taylor Brandstetter 
Cc: Christer Holmberg , Ben Campbell ,  "ice-chairs@ietf.org" , "ice@ietf.org" ,  "draft-ietf-ice-rfc5245bis@ietf.org" ,  "pthatcher@google.com" , The IESG 
Content-Type: multipart/alternative; boundary="94eb2c062738567cb30565ace002"
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Feb 2018 23:07:41 -0000

--94eb2c062738567cb30565ace002
Content-Type: text/plain; charset="UTF-8"

I wouldn't object if someone produced a principled fix. I just don't want
to create a lot of work for people


On Tue, Feb 20, 2018 at 2:51 PM, Taylor Brandstetter 
wrote:

> The tie-breaker collision problem has come up a few times before,
> actually. As I've said, I believe it could be fixed very easily by saying
> "pick a new tie-breaker if this happens."
>
> As for the "MUST not change tie-breaker" rule in section 16.1, requiring
> an ICE restart is overkill. We can just change it to "MUST not change
> tie-breaker* unless there's a collision*."
>
> On Mon, Feb 19, 2018 at 10:33 AM, Eric Rescorla  wrote:
>
>>
>>
>> On Mon, Feb 19, 2018 at 10:29 AM, Christer Holmberg <
>> christer.holmberg@ericsson.com> wrote:
>>
>>> Hi,
>>>
>>> ...
>>>
>>> >>>> IF we really want to solve this, one simple solution be to say
>>> that, if this happens, and endpoint simply calculates a
>>> >>>> new tie-breaker value, and tries again? BUT, then we would have to
>>> change section 16.1, which says that a new value can only be calculated at
>>> an ICE restart.
>>> >>>>
>>> >>>> So, could we simply say that, if this happens, the agent MUST do an
>>> ICE restart, and it MUST calculate a new tie-breaker value?
>>> >>>
>>> >>> Now both sides might do a simultaneous restart. Is that going to
>>> work?
>>> >>
>>> >> We could say that the initiating agent MUST do the restart.
>>> >
>>> > In this scenario, don't both sides believe they are the initiating
>>> peer, hence the need for the tiebreaker?
>>>
>>> Probably...
>>>
>>> But, then I don't see what we could do. If both agents send a check, and
>>> receive 487, we can't define a procedure for one of the agents.
>>>
>>> Perhaps we should then change the must-not-change-the-value-unless-restart
>>> and say that an agent changes the tie-breaker value and try again.
>>>
>>
>> As you say, the problem is inherently that the situation is symmetrical.
>>
>> At this point in the design process, I don't think it's worth trying to
>> actually make the call succeed; a 2^{-64} failure rate is much lower than
>> organic call failure rates from other causes, even in non-3PCC scenarios.
>> Rather, I think the spec should just prescribe a clean failure mode via a
>> new error code, rather than having both sides wildly oscillate between
>> controlled and controlling
>>
>> -Ekr
>>
>>
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>
>> _______________________________________________
>> Ice mailing list
>> Ice@ietf.org
>> https://www.ietf.org/mailman/listinfo/ice
>>
>>
>

--94eb2c062738567cb30565ace002
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I wouldn't object if someone produced a principled fix=
. I just don't want to create a lot of work for people
=C2=A0=C2=A0=


On Tue, Feb 2=
0, 2018 at 2:51 PM, Taylor Brandstetter <deadbeef@google.com> wrote:
The tie-breaker collision problem has come up a few times be=
fore, actually. As I've said, I believe=C2=A0it could be fixed v=
ery easily by saying "pick a new tie-breaker if this happens."
As for the "MUST not change tie-breaker" rule in=
 section 16.1, requiring an ICE restart is overkill. We can just change it =
to "MUST not change tie-breaker unless there's a collision.=
"

On Mon, Feb 19, 2018 at 10:33 AM, Eric Rescorla=
 <ek=
r@rtfm.com> wrote:

=

On Mon, Feb 19, 2018 at 10:29 AM, Chri=
ster Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,



...



>>>> IF we really want to solve this, one simple solution be to=
 say that, if this happens, and endpoint simply calculates a

>>>> new tie-breaker value, and tries again? BUT, then we would=
 have to change section 16.1, which says that a new value can only be calcu=
lated at an ICE restart.

>>>>

>>>> So, could we simply say that, if this happens, the agent M=
UST do an ICE restart, and it MUST calculate a new tie-breaker value?

>>>

>>> Now both sides might do a simultaneous restart. Is that going =
to work?

>>

>> We could say that the initiating agent MUST do the restart.

>

> In this scenario, don't both sides believe they are the initiating=
 peer, hence the need for the tiebreaker?



Probably...



But, then I don't see what we could do. If both agents send a check, an=
d receive 487, we can't define a procedure for one of the agents.



Perhaps we should then change the must-not-change-the-value-unless-res=
tart and say that an agent changes the tie-breaker value and try again.
=


As you say, the problem is inherent=
ly that the situation is symmetrical.

At this poin=
t in the design process, I don't think it's worth trying to actuall=
y make the call succeed; a 2^{-64} failure rate is much lower than organic =
call failure rates from other causes, even in non-3PCC scenarios. Rather, I=
 think the spec should just prescribe a clean failure mode via a new error =
code, rather than having both sides wildly oscillate between controlled and=
 controlling

-Ekr
=C2=A0



Regards,



Christer







_______________________________________________

Ice mailing list

Ice@ietf.org

https://www.ietf.org/mailman/listinfo/ice







--94eb2c062738567cb30565ace002--


From nobody Tue Feb 20 15:42:58 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8C812E04A for ; Tue, 20 Feb 2018 15:42:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 zdRalOJeRgrI for ; Tue, 20 Feb 2018 15:42:52 -0800 (PST)
Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (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 B4A941250B8 for ; Tue, 20 Feb 2018 15:42:52 -0800 (PST)
Received: by mail-pl0-x22c.google.com with SMTP id u13so4759127plq.1 for ; Tue, 20 Feb 2018 15:42:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=UxF2/q9I7ufysXkqAICQFNwnqxXi0jF345FtKcNkk4g=; b=FRhP79gpeTx4EuCi5QCE4dzvf6yJ+AfY8ve99CfFghQNykHZtW9qIEwf5I3w/vskGF GMD7+U8TNpe1/K73x4L3lapFDK847rPTrTPAwlJBSv1mGQmLNtPsT6aNucGchn1NzKw5 2F364zhGz1BAcAzu4rgAPSlyhhr9SUxsWPkoo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=UxF2/q9I7ufysXkqAICQFNwnqxXi0jF345FtKcNkk4g=; b=hG3utJ14XlBuJWREGdM8KWGHrgRQ3NqATRdGopCyql3e19QcEJ0M5MFaecpFKPTNtM cr2Q3gOfyqj9k/pE4lubvls6oFA+WSFufCVtbtZavHzQuovPVdBcC+vvNyWpeFA/VVZW 1fLlk845rVqpjk7QennjArAsI1S65ZBkEHNlH7RocJHFc0BGA7xAhwxSLA6GZh/K55yF o07/dZ6aUQ/TvXD9qaz8emP48UqDXFVPKqeVKnpNmOAKIxAEi/CXTYtGKPSWm5beY0eo h09ywT8ZAv4qSs4npNDiuL6UHhZ4VPRLNRkOaxyCFv5w9TL+QasBjiEBZvEIbV8Qqe3c B22Q==
X-Gm-Message-State: APf1xPC14jQyl3BeySwmEW/VabFCn9Qysqht6NS3XahB4r9OqAm959fP B8ZfOMgP49dE+MD/EvyABu2RuUTkWP8=
X-Google-Smtp-Source: AH8x226T3OMzXlnF3cIcU4VvcXhWPu6bOBzVusL3bTi151YnndOydO3T8EvDaFdC4zkAEcsZtE4xUQ==
X-Received: by 2002:a17:902:8c95:: with SMTP id t21-v6mr1226177plo.36.1519170172161;  Tue, 20 Feb 2018 15:42:52 -0800 (PST)
Received: from dragon.local ([2620:101:80f4:224:70fd:35f:11fe:f8e0]) by smtp.gmail.com with ESMTPSA id o12sm27218572pfj.86.2018.02.20.15.42.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Feb 2018 15:42:50 -0800 (PST)
To: ice@ietf.org
References: <20180220220002.GS54688@mit.edu>
From: Peter Saint-Andre 
Message-ID: <1165172a-6474-628b-33ca-001624409ae7@mozilla.com>
Date: Tue, 20 Feb 2018 15:42:49 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180220220002.GS54688@mit.edu>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mPc3UgUk9zmExGpk8DLUZAzPe8g6uyBnk"
Archived-At: 
Subject: Re: [Ice] Benjamin Kaduk's practice ballot on draft-ietf-ice-rfc5245bis-17: (with COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Feb 2018 23:42:56 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--mPc3UgUk9zmExGpk8DLUZAzPe8g6uyBnk
Content-Type: multipart/mixed; boundary="8L6QPnAzTNNEeEUa5Y8gmMaFOHejfS08Z";
 protected-headers="v1"
From: Peter Saint-Andre 
To: ice@ietf.org
Message-ID: <1165172a-6474-628b-33ca-001624409ae7@mozilla.com>
Subject: Re: [Ice] Benjamin Kaduk's practice ballot on
 draft-ietf-ice-rfc5245bis-17: (with COMMENT)
References: <20180220220002.GS54688@mit.edu>
In-Reply-To: <20180220220002.GS54688@mit.edu>

--8L6QPnAzTNNEeEUa5Y8gmMaFOHejfS08Z
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2/20/18 2:00 PM, Benjamin Kaduk wrote:

> [incoming AD=20

Welcome, and good luck! :-)

> ramping up on pre-telechat document review]

The status of a "practice ballot" is unclear in IETF process. Is this
feedback that the authors and WG need to address?

Peter


--8L6QPnAzTNNEeEUa5Y8gmMaFOHejfS08Z--

--mPc3UgUk9zmExGpk8DLUZAzPe8g6uyBnk
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqMsnkACgkQZWGMGH9o
FKnmPw//U5u+UfFvqQ9Ino+WXroH22QkZv8AOgjnTmX65q44VUPozvOPcuZytqHf
E6yJRjLk9YgybhBuSY3+9VmcykJVCE3SklPsT328lAiQrtmULjaIku2nsNMvW8qs
KlO4EFTWM1xvpTTMQdlQXDVxwqrCsc1u/RXDcUBpQiewjmD6Czrow7C3nQwWN70z
4fGnternpTvlX6kYS1q9ZEfGvgny8FgvcSjx3tI/YxtzUu8f3k0/mjClPnGCKRk9
Jg67z1LCgnPAaN32JnZDOnuPszlLvEdU7Obv5MhiZXro8T3CJ1dDchdyza2x3scz
7dSjCbtK/JKDWfb0Pzqr8FIAMyWtciYEAHuoGNWkp0Z3tirewwWZ2IjZMhB5pwN2
dhk83B2gFotM89+p0jx4sJJ+8j26vsxiel48AHYGzrGpFTUPvsLlbJrp9/LHbb2N
3AdoW7yb4OqmYCrfcW4bT5wSucQzX8UisX4LyhaSTom1Vg2WUi/WU7qWZoKqMIiK
TaWJiwhFEhxQSaUut6ovuokhVO1g3TWFqjCfN+a74PBHTDaI5BDqvWdmtrjkFNac
nBD6knCDfmXjCddrR+NEd1bzA2sUQudyxdiZtvlo8Yh2pBqt28XChU18Q79RHh9q
syEu0zaTNtQpvsZRY2IZeWjSae56HjPEdTClm/h5V2KrRdUpgzU=
=WBHl
-----END PGP SIGNATURE-----

--mPc3UgUk9zmExGpk8DLUZAzPe8g6uyBnk--


From nobody Tue Feb 20 15:46:11 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA2B12E042 for ; Tue, 20 Feb 2018 15:46:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 0htMAS2VwrZw for ; Tue, 20 Feb 2018 15:46:05 -0800 (PST)
Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (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 0783812E044 for ; Tue, 20 Feb 2018 15:46:03 -0800 (PST)
Received: by mail-pl0-x232.google.com with SMTP id x18so2800284pln.0 for ; Tue, 20 Feb 2018 15:46:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=aFO+Z9ZOoZsnQPatjUnft+tEfa7P3LRvjFudbYiEVyA=; b=YxgGwqmIA5sj+Syf6tQKq/qX9NJeoKQNwYIDx8kkLJX33pQuKps7maggLfOBds+WKc LsKqdgVw86teG9iIpr8CMxHBbDuGhIGb0qfGePLmde+0XFK+sLqK6N2iV8ZfOnayTlrF 2vUkA15DU9f5rs53IX3Qog381qEXMVKtc4W0Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=aFO+Z9ZOoZsnQPatjUnft+tEfa7P3LRvjFudbYiEVyA=; b=cyyus5d0mX+iu8bENJeLQSAsMiSMHsQYnB/0cc/UK1muBy/YD3wzqYvAx5yJnQEQJr eRlVAXouzlZie0vAiE6pUepQTFMBDxycsnKvbBC7uy+EFPO6Jpv7VQud4hdB6urNGZEx 728fDWW6Jd0YcGa2TSh2EUDtI7s6EgDGzox0jTey+KGyZfmZXJPUUFmYgf8yA6C1r1vO IZZWNNF6cP7gqZlg4SwiShX2f7oiSYHlCQ5rAmZbMV5d/USi8F1SwVPb35s0MamEqxzO 4YgP5yTMPWs9KBUSQeOzMuTPyRBNkChlK58jlsPOQ8j8Id3HH7mIMPm10xIa6boG/S+c CH4Q==
X-Gm-Message-State: APf1xPAxsiSQOP17lSTCDSe+1F4HJy4+Q4ok/AGXgWZH8VEvUTW0TCIw 7W2lyW+F87UYPw1FbpzkcqUcgQ==
X-Google-Smtp-Source: AH8x225Esbzr6+1fiHuM+UxuxDiKEP6sW7UeSE7l7yI7XuJHiyqFC642kwqOoN3GmW7zTcfowFolRA==
X-Received: by 2002:a17:902:b215:: with SMTP id t21-v6mr1238750plr.414.1519170362558;  Tue, 20 Feb 2018 15:46:02 -0800 (PST)
Received: from dragon.local ([2620:101:80f4:224:70fd:35f:11fe:f8e0]) by smtp.gmail.com with ESMTPSA id x86sm69457819pfa.164.2018.02.20.15.46.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Feb 2018 15:46:01 -0800 (PST)
To: Benjamin Kaduk , IESG 
Cc: ice-chairs@ietf.org, draft-ietf-ice-rfc5245bis@ietf.org, pthatcher@google.com, ice@ietf.org
References: <20180220220002.GS54688@mit.edu>
From: Peter Saint-Andre 
Message-ID: <18b9ce0f-acdc-4fa7-055c-3ba75d1e2e98@mozilla.com>
Date: Tue, 20 Feb 2018 15:46:00 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180220220002.GS54688@mit.edu>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VnunRObW2FQdxDaNuyoRsyBghb7Knt6UM"
Archived-At: 
Subject: Re: [Ice] Benjamin Kaduk's practice ballot on draft-ietf-ice-rfc5245bis-17: (with COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Feb 2018 23:46:06 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--VnunRObW2FQdxDaNuyoRsyBghb7Knt6UM
Content-Type: multipart/mixed; boundary="HOrdHqiUpKnALtwZIvy5UR3QUcbZ8ozCt";
 protected-headers="v1"
From: Peter Saint-Andre 
To: Benjamin Kaduk , IESG 
Cc: ice-chairs@ietf.org, draft-ietf-ice-rfc5245bis@ietf.org,
 pthatcher@google.com, ice@ietf.org
Message-ID: <18b9ce0f-acdc-4fa7-055c-3ba75d1e2e98@mozilla.com>
Subject: Re: [Ice] Benjamin Kaduk's practice ballot on
 draft-ietf-ice-rfc5245bis-17: (with COMMENT)
References: <20180220220002.GS54688@mit.edu>
In-Reply-To: <20180220220002.GS54688@mit.edu>

--HOrdHqiUpKnALtwZIvy5UR3QUcbZ8ozCt
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2/20/18 2:00 PM, Benjamin Kaduk wrote:
>=20
> [resending with fixed Subject and recipients list]

[same]

> [incoming AD=20

Welcome, and good luck! :-)

> ramping up on pre-telechat document review]

The status of a "practice ballot" is unclear in IETF process. Is this
feedback that the authors and WG need to address?

Peter


--HOrdHqiUpKnALtwZIvy5UR3QUcbZ8ozCt--

--VnunRObW2FQdxDaNuyoRsyBghb7Knt6UM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqMszgACgkQZWGMGH9o
FKmy2g//UzTROUoTlbGu4Bkp9vfUHZc++K1UH+WzLWDC3kLTUWsy0PU4kdwchtkZ
oXQMJBGOmcm/gx2RM2aVTjKwwjzfGMY58rupE+EJZWiGyxJyIy9OAZsHNbnQ5YJj
BYVm0VRLPNU/9dGSuZkNfoWVhXhOJf0OSMtTqkpOLKYXzrdCye8MM7cBH1xbrXYV
T+UJbw4ogzni8vNh9h7gFnlmVSV1H5koPpMGa6+5QqPskWa4cEvR7mBTuCjDjQvP
Xl0Yk12lKcpuCNwLgouj1Jmt/WGdESr9YN22u65zgdlzqbHxsOVtmNx6OE/G26R6
YELZwfLYu1k0ERA1j7WckKd5EyhCW9bm8htzODTwSsGlbRK+3q4720lnFw56SDHf
0yrUFTTtsuzRNH9OwMiy/NlXmlY6onc/zURpHbLG0b7lruNP1UR/HbWHxrBh3anP
MbG1pUcfbJYGUdzhOeN0SfzujAzl7+tu6LJqNSpnW7AyMTMycUyxkueu12sh5q67
sgrXVNDQeYCnLbeWS1GoQzJOKWwKqhbiC34C8QFpLhCelraG6lhYepG+0R0ujllq
t1YBpG02L0htq0MposmXG02b68bysE3YZfWCXZIzPa4Vm9JsxU9L0WhlbNUblwxZ
GpRR4S1KjxWrNsUfF2Rb2Xa5qVmatRukkJd+g2RJF1T2uh3W3IU=
=19JC
-----END PGP SIGNATURE-----

--VnunRObW2FQdxDaNuyoRsyBghb7Knt6UM--


From nobody Tue Feb 20 15:48:05 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF6812E04A for ; Tue, 20 Feb 2018 15:48:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=rtfm-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 Ouya3Xz76SFU for ; Tue, 20 Feb 2018 15:48:02 -0800 (PST)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 C3AC2126BF6 for ; Tue, 20 Feb 2018 15:48:01 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id t13so15459401qkj.13 for ; Tue, 20 Feb 2018 15:48:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=djnqcBirodYDu8heRj/rGhkjAJh7ubA1MFy6zLjUmCc=; b=voVt2IZOa4qkzrDagIrZhGhHjVSxzsOHowwKpS01RZD03weaozbLvtriWdYIVVq+gN ykAE5JIKlp3peT5D+UT20pR2Cp9PTiKyu6x2rYu3e9LoiTPT00V0d+O9f/Nc5hfJE2W2 W0vt82I7I7k3MDDZlIAPqnfgqxsuNwS0mzscNFWs7XCigXZ0+ot3S6zZgbW99gRsI1FC +X7bSqaDqUOsdiIOBIFK4EMsT5URipL1SJUxz6tRBJYwdJlUFgQ0WMleyV2NN2xXpOPg JG3zmEM3+7MkkPWujBTTyKUWcItR+w8twcn1by4gMpm+sSmAp6nFrjSq/jamAaOVSheb lu8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=djnqcBirodYDu8heRj/rGhkjAJh7ubA1MFy6zLjUmCc=; b=kNCrOexiRTkzwIQGFRiKBrlsTpYS4At++snsgf0TJcJYL2oeXW7NmaSlzJEQSQVnYy f//K8MRPWi1M0ia9BJTVXbhc7XLKzYtYsBMw6D8k+OYe/+csmDmnnzSeuZsDVI9+sRZg CvMzsV0BA/V/gp2jQfjli0LaxpZQz302auHHAIvlQ7cgRkWIJwEOdJH7ebqeSwFxcCAB d/IvI0/QfHljS2wD5v1vaaCLGVUYMuKwjeh6gC9SCcby88YpITJuGRm9g0U8useVKV9F kKCajfPyW1Oyl3JFeO4hX4dNBgBZydXudg8KxqKSaQMGBjSblU3/Zezb5bXt8UhctGo5 tz4A==
X-Gm-Message-State: APf1xPCu1mF9mdInMHUtkSOTI2AOPBYrcbs1uGzFiiGkVhlYVs83xNDV 3a7CID6cDPNbHViqWMuJ7LttSVWjxMShqyX88A5hww==
X-Google-Smtp-Source: AH8x224yFYw/VeGB46QC02Xe4ZHxZnW8IA2UVy9Olj3SGJBakoekJ83nO7b9iIFIH75qow1V3OckKQym2Bm95C25w6k=
X-Received: by 10.55.43.220 with SMTP id r89mr2286381qkr.152.1519170480908; Tue, 20 Feb 2018 15:48:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Tue, 20 Feb 2018 15:47:20 -0800 (PST)
In-Reply-To: <18b9ce0f-acdc-4fa7-055c-3ba75d1e2e98@mozilla.com>
References: <20180220220002.GS54688@mit.edu> <18b9ce0f-acdc-4fa7-055c-3ba75d1e2e98@mozilla.com>
From: Eric Rescorla 
Date: Tue, 20 Feb 2018 15:47:20 -0800
Message-ID: 
To: Peter Saint-Andre 
Cc: Benjamin Kaduk , IESG , ice-chairs@ietf.org,  draft-ietf-ice-rfc5245bis@ietf.org, Peter Thatcher ,  ice@ietf.org
Content-Type: multipart/alternative; boundary="001a1149442cde38af0565ad7094"
Archived-At: 
Subject: Re: [Ice] Benjamin Kaduk's practice ballot on draft-ietf-ice-rfc5245bis-17: (with COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Feb 2018 23:48:03 -0000

--001a1149442cde38af0565ad7094
Content-Type: text/plain; charset="UTF-8"

I would suggest treating it as a Comment.

Ben, if there is anything you think is DISCUSS-worthy, please call it to my
attention and we can talk

-Ekr


On Tue, Feb 20, 2018 at 3:46 PM, Peter Saint-Andre 
wrote:

> On 2/20/18 2:00 PM, Benjamin Kaduk wrote:
> >
> > [resending with fixed Subject and recipients list]
>
> [same]
>
> > [incoming AD
>
> Welcome, and good luck! :-)
>
> > ramping up on pre-telechat document review]
>
> The status of a "practice ballot" is unclear in IETF process. Is this
> feedback that the authors and WG need to address?
>
> Peter
>
>

--001a1149442cde38af0565ad7094
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I would suggest treating it as a Comment.

Ben, if there is anything you think is DISCUSS-worthy, please call it to=
 my attention and we can talk

-Ekr

<=
/div>

On Tue=
, Feb 20, 2018 at 3:46 PM, Peter Saint-Andre <stpeter@mozilla.com&g=
t; wrote:
On 2/20=
/18 2:00 PM, Benjamin Kaduk wrote:

>

> [resending with fixed Subject and recipients list]



[same]



> [incoming AD



Welcome, and good luck! :-)



> ramping up on pre-telechat document review]



The status of a "practice ballot" is unclear in IETF proce=
ss. Is this

feedback that the authors and WG need to address?



Peter







--001a1149442cde38af0565ad7094--


From nobody Tue Feb 20 15:54:56 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15D512E042 for ; Tue, 20 Feb 2018 15:54:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 D9IY_QEI9WBP for ; Tue, 20 Feb 2018 15:54:47 -0800 (PST)
Received: from mail-pl0-x234.google.com (mail-pl0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (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 7BCE812E044 for ; Tue, 20 Feb 2018 15:54:47 -0800 (PST)
Received: by mail-pl0-x234.google.com with SMTP id 31so8351375ple.9 for ; Tue, 20 Feb 2018 15:54:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=oz08aHwE0iaWep2Szw+pYWsLeB3GDiwQvqNfjOLyPME=; b=IxJMO20crBU5J/wme/Jr6qgPEOSmEesXz1807dl6VC1nouB7JbrypfRRrWV8InBbW3 tlPSDi2RvaqHUx+SNnUfk8p4IOWVx5QCFyelRArt0021uRT04KvuU4UnxxChmPp9zyrs F1bTDtV5cDRyR483G5p8/H38nAqaJDxaXt+WM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=oz08aHwE0iaWep2Szw+pYWsLeB3GDiwQvqNfjOLyPME=; b=IA8QtkDrOqDGfBEtMuz128cJSI/cbb6V8IbIym7VWR3OKVsY7bDuNf/lEN+wE1aC1Z nSOY7GdW36/6ms3UR7JutObZONvZDZbkMnZx2TQyyXZvT4QiVX8PAMgEUxsJJIbcEOqY bfaMBIWB6kfpwQtKl4zh5JpuYK1gh/JYTNdiC97Cv32VYNn/iAL+JDb/niVrU3OpzIGi tJrFc5qsctnHyB0s26Gmikx0Dpk2GR014xp6xhDBidwBsg9Mf/jnb5Hb+d0q3yQKjEs2 SmiXlkPp6Bfit53HtKNJXJ8IBhsUEXhVVYjMkYuRFAy0Z54+oAKlHHGtr7C4tZtkhU0g I4+g==
X-Gm-Message-State: APf1xPAZHQc5ysdE9aA6eZiMiNENx8B62K0nCSJBNgVYm0qZmynok0TE /Ms9G40bMeoHm1oFg2N16WvD5A==
X-Google-Smtp-Source: AH8x227o7GL/Fz4Cwh/298Y1RHzRNO93get8Y+p/VXS+EV1av1CjsCtK6UjRBSfRUE3PHT/K7zvpSQ==
X-Received: by 2002:a17:902:51ee:: with SMTP id y101-v6mr1252285plh.157.1519170887049;  Tue, 20 Feb 2018 15:54:47 -0800 (PST)
Received: from dragon.local ([2620:101:80f4:224:70fd:35f:11fe:f8e0]) by smtp.gmail.com with ESMTPSA id s89sm64868872pfk.35.2018.02.20.15.54.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Feb 2018 15:54:46 -0800 (PST)
To: Eric Rescorla 
Cc: Benjamin Kaduk , IESG , ice-chairs@ietf.org, draft-ietf-ice-rfc5245bis@ietf.org, Peter Thatcher , ice@ietf.org
References: <20180220220002.GS54688@mit.edu> <18b9ce0f-acdc-4fa7-055c-3ba75d1e2e98@mozilla.com> 
From: Peter Saint-Andre 
Message-ID: <65920fe2-9411-ed27-c496-bc3c1c848fc1@mozilla.com>
Date: Tue, 20 Feb 2018 15:54:44 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="crY2AwbqEnerIrouOec2OU6JWZcCiQw4B"
Archived-At: 
Subject: Re: [Ice] Benjamin Kaduk's practice ballot on draft-ietf-ice-rfc5245bis-17: (with COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Feb 2018 23:54:50 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--crY2AwbqEnerIrouOec2OU6JWZcCiQw4B
Content-Type: multipart/mixed; boundary="FwYLbif00keirBqVqG3yViXTzHzHxElYR";
 protected-headers="v1"
From: Peter Saint-Andre 
To: Eric Rescorla 
Cc: Benjamin Kaduk , IESG ,
 ice-chairs@ietf.org, draft-ietf-ice-rfc5245bis@ietf.org,
 Peter Thatcher , ice@ietf.org
Message-ID: <65920fe2-9411-ed27-c496-bc3c1c848fc1@mozilla.com>
Subject: Re: [Ice] Benjamin Kaduk's practice ballot on
 draft-ietf-ice-rfc5245bis-17: (with COMMENT)
References: <20180220220002.GS54688@mit.edu>
 <18b9ce0f-acdc-4fa7-055c-3ba75d1e2e98@mozilla.com>
 
In-Reply-To: 

--FwYLbif00keirBqVqG3yViXTzHzHxElYR
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

That seems like a fine approach!

On 2/20/18 3:47 PM, Eric Rescorla wrote:
> I would suggest treating it as a Comment.
>=20
> Ben, if there is anything you think is DISCUSS-worthy, please call it t=
o
> my attention and we can talk
>=20
> -Ekr
>=20
>=20
> On Tue, Feb 20, 2018 at 3:46 PM, Peter Saint-Andre  > wrote:
>=20
>     On 2/20/18 2:00 PM, Benjamin Kaduk wrote:
>     >
>     > [resending with fixed Subject and recipients list]
>=20
>     [same]
>=20
>     > [incoming AD
>=20
>     Welcome, and good luck! :-)
>=20
>     > ramping up on pre-telechat document review]
>=20
>     The status of a "practice ballot" is unclear in IETF process. Is th=
is
>     feedback that the authors and WG need to address?
>=20
>     Peter
>=20
>=20


--FwYLbif00keirBqVqG3yViXTzHzHxElYR--

--crY2AwbqEnerIrouOec2OU6JWZcCiQw4B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqMtUUACgkQZWGMGH9o
FKnuRA//YS68Memhhimk6wYRDpbbeh6+wwskIgOsisO3RFli9K8uPwMtRtFpgqR/
hZbbezwEuGRnU6r61Wm57HQwX4Qpn0WbuNWd+dXpAFgIBGhEMKupU0Zsvh/Kk/5o
G4xevf4X8HofkV2MuNW2StHopVHU689XWDDNTa51+HSUs+Cpj+sJn3X4LEFt58Uy
iUaucSz+uqjhexgTHkc0qdox3sZluQPIkDTnc77E43oDJ2/6ya9cSNk0Q+qVl5tf
9o6z5X8BzBk9iAZ77KpHSqV7JEUPaCnUchMwVCL7g5HgBH3pjcHQU3t1W97yQaCh
3ykoPPrIdKsB/QyLdHlEIITmQRHkNgOl4yHdmV6wb2tD8G5gle1BBR4lPR+3KeXp
WJwE497Jr8fIkGgcoBi0U2mKcmloH+1R0VktJ+tni1q7vEyArGzs+J4aYH6q07xB
msqyazz0PqdrqFhm84q56IGBJRb7FeFB7yLSik+UDOjn7nUvPj8/CJX7ZylQmMtm
XMrLVl9Lq6EUIpwH44GY7nlA0iCr+HDzctZ/Pf63+H4myR+RMFYbCSfJapNhOFG1
ofVKYjJysfHFSov8AKfrn5u7/OWTciol4EW/4dXSFI28/7HwBMq4Z9WdK/zR/Wvq
NrOZ6PLBJvpjaumhw+kYCJ8cdabo3uv2wDW8rkaNW4g9EROZpGo=
=feAu
-----END PGP SIGNATURE-----

--crY2AwbqEnerIrouOec2OU6JWZcCiQw4B--


From nobody Tue Feb 20 21:03:33 2018
Return-Path: 
X-Original-To: ice@ietf.org
Delivered-To: ice@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA35129C6D; Tue, 20 Feb 2018 21:03:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Suresh Krishnan 
To: "The IESG" 
Cc: draft-ietf-ice-rfc5245bis@ietf.org, Peter Thatcher ,  ice-chairs@ietf.org, pthatcher@google.com, ice@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151918940727.9623.17348873149297319051.idtracker@ietfa.amsl.com>
Date: Tue, 20 Feb 2018 21:03:27 -0800
Archived-At: 
Subject: [Ice] Suresh Krishnan's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Feb 2018 05:03:27 -0000

Suresh Krishnan has entered the following ballot position for
draft-ietf-ice-rfc5245bis-17: Discuss

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


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

* Section 5.2.  Lite Implementation Procedures

"For dual-stack hosts, the IPv4 address is RECOMMENDED."

I am trying to understand the reasoning behind this unequivocal choice (which
probably might have made sense in 2010). At least, there is some explanatory
text required to justify this.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* Section 15

It would have been good to have an example with IPv6 addresses (from the
2001:db8::/32 space) as well.



From nobody Wed Feb 21 01:23:08 2018
Return-Path: 
X-Original-To: ice@ietf.org
Delivered-To: ice@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E20B6120047; Wed, 21 Feb 2018 01:23:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach 
To: "The IESG" 
Cc: draft-ietf-ice-rfc5245bis@ietf.org, Peter Thatcher ,  ice-chairs@ietf.org, pthatcher@google.com, ice@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151920498287.9799.11602055137725027840.idtracker@ietfa.amsl.com>
Date: Wed, 21 Feb 2018 01:23:02 -0800
Archived-At: 
Subject: [Ice] Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Feb 2018 09:23:03 -0000

Adam Roach has entered the following ballot position for
draft-ietf-ice-rfc5245bis-17: Discuss

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


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to everyone who has contributed to this document over the many years of
its development.

The document currently appears to contain normative statements that, while not
literally contradictory, certainly point implementors in conflicting directions.
§5.1.1.1 says:

>  o  Host candidates corresponding to IPv6 link-local addresses MUST
>     NOT be gathered.

Further down, §6.1.2.2 says:

>  To keep the amount of resulting candidate pairs
>  reasonable and to avoid candidate pairs that are highly unlikely to
>  work, IPv6 link-local addresses [RFC4291] MUST NOT be paired with
>  other than link-local addresses.

This second passage is nonsensical if IPv6 link local addresses MUST NOT be
gathered. Please remove or amend one of these normative statements. If the first
statement is retained, please add rationale.

(As an aside, it makes more sense to cite 4291 the first time you mention IPv6
link local address rather than the second)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have a number of comments on technical content, followed by some editorial
nits.

---------------------------------------------------------------------------

§5.1.1.3:

>  o  For reflexive and relayed candidates, the STUN or TURN servers
>     used to obtain them have the same IP address.

This is ambiguous: it is unclear whether "the same IP address" refers to the
address that the ICE agent used to reach the TURN server, or whether the IP
address allocated by the TURN server on the client's behalf. In large-scale
TURN deployments, these addresses will frequently differ, since one IP address
can only support ~64k ports at once (and therefore TURN servers may need to
make use of multiple at once). Please clarify which IP address is to be used for
this comparison.

>  Similarly, two candidates have different foundations if their types
>  are different, their bases have different IP addresses, the STUN or
>  TURN servers used to obtain them have different IP addresses, or
>  their transport protocols are different.

The same clarification is required to this paragraph as well.

---------------------------------------------------------------------------

§5.2:

>  This default
>  SHOULD be chosen such that it is the candidate most likely to be used
>  with a peer.  For IPv6-only hosts, this would typically be a globally
>  scoped IPv6 address.  For dual-stack hosts, the IPv4 address is
>  RECOMMENDED.


I support Suresh's DISCUSS. I would propose that you recommend that dual-stack
hosts SHOULD allow configuration of whether IPv4 or IPv6 is used for the
default, and that the configuration needs to be based on which one its
administrator believes has a higher chance of success in the current network
environment. I am of the understanding, for example, that in certain Japanese
carriers, the selection of IPv6 as the default would maximize the chance of
success, even today.

---------------------------------------------------------------------------

§5.3:

>     Related Address and Port:  The related IP address and port of the
>        candidate.  These MAY be omitted or set to invalid values if
>        the agent does not want to reveal them, e.g., for privacy
>        reasons.

The term "Related Address and Port" is not defined anywhere. Is it the same as
the base address? Something else? Please add a definition to §4. (I'll note that
this term is also used in Figure 6.) It may also be useful to call forward to
§B.3 here, so that implementors aren't confused by the apparent uselessness of
including this information.

---------------------------------------------------------------------------

§8.1.1:

>  NOTE: A controlling agent that does not support this specification
>  (i.e. it is implemented according to RFC 5245) might nominate more
>  than one candidate pair.  This was referred to as aggressive
>  nomination in RFC 5245.

Please here or elsewhere (probably Appendix B) indicate why aggressive
nomination was removed (i.e., it's redundant with the ability to send data on
any valid pair even prior to nomination).

Also (editorial nit) please put quotation marks around the term "aggressive
nomination."

---------------------------------------------------------------------------

§8.1.2:

>     *  The agent MAY begin transmitting data for this data stream as
>        described in Section 12.1.

This seems redundant with the fact that the data could be sent even before
nomination, and runs the risk that implementors might interpret it to mean that
they must not send data *prior* to nomination. I think it would be safest to
remove this, and possibly reiterate right here that sending data is not blocked
on successful pair nomination.

---------------------------------------------------------------------------

§9:

>  To restart ICE, an agent MUST change both the password and the
>  username fragment for the data stream(s) being restarted.  The agent
>  MUST verify that it has not used the new values in recent ICE
>  sessions, as packets from those sessions might still be present in
>  the network.

To be clear: the password and ufrag, taken together, provide 152 bits of
randomness, and need to be selected randomly on restart. This passage appears to
be guarding against random collisions between 152-bit values in a small set.
Do I have that correct?

If so: I couldn't find a birthday paradox calculator that could deal with
5,708,990,770,823,839,524,233,143,877,797,980,545,530,986,496 potential values.
The only one that didn't generate an error outright gave a probability of 0,
which is as close as correct as to make no difference.

Unless I'm misunderstanding what is being asked of implementors, this second
MUST is superfluous and should be removed.

---------------------------------------------------------------------------

§15:

Please either update the example to use IPv6 in addition to IPv4, or provide
an additional example that uses IPv6 addresses.  See
https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for guidance on the use of
IPv6 in IETF specifications, including their examples.

---------------------------------------------------------------------------

§15:

>            |              |(9) Bind Req  |              |Begin
>            |              |S=$R-PUB-1    |              |Connectivity
>            |              |D=L-PRIV-1    |              |Checks
>            |              |<----------------------------|
>            |              |Dropped       |              |

This is quite misleading. If a host on the public Internet (as R is in this
example) sent a Binding Request to $L-PRIV-1 (10.0.1.1 in this example), it
would *not* be routed to the NAT, as is shown in this example. If it didn't get
blocked before reaching the default free zone, I believe it would be blackholed
once it did so. I would propose keeping the arrow, but having it end prior to
reaching the NAT line.

(Minor nit: please replace "L-PRIV-1" with "$L-PRIV-1")

---------------------------------------------------------------------------

§15:

>  Since the check was generated in the reverse direction of a
>  check that contained the USE-CANDIDATE attribute...

It was? I don't see that in the ladder, can't find it in the prose, and believe
it to be actually incorrect. By my understanding, the example would need an
additional messages 18 through 21, originating from L (as the controlling agent)
that nominates this pair.

I believe what you've shown is an aggressive nomination call flow, but this
document no longer supports aggressive nomination.

If I'm simply confused here, then please add the "USE-CANDIDATE" attribute to
the ladder diagram and to the corresponding text where it belongs.

---------------------------------------------------------------------------

§20.1 and §20.2:

Please add instructions to IANA to update the registry to point to this document
instead of RFC 5245.


===========================================================================

All of the following are editorial nits.

> J. Rosenberg
> jdrosen.net

You might want to double-check with the author that this is the intended
affiliation for this document.

---------------------------------------------------------------------------

§1:
>  sinks.  However this poses challenges when operated through Network

"However, this..."

>  (RTCP) [RFC3605].  Unfortunately, these techniques all have pros and
>  cons which, make each one optimal in some network topologies, but a

"...cons that make..."

>  to-peer connectivity checks.  The IP addresses and ports are
>  exchanged exchanged using ICE usage-specific mechanisms (for example,

Remove duplicate "exchanged"

>  including in a offer/answer exchange) and the connectivity checks are
>  performed using Session Traversal Utilities for NAT (STUN)

"STUN" has already been expanded in this section.

>  specification [RFC5389].  ICE also makes use of Traversal Using
>  Relays around NAT (TURN) [RFC5766], an extension to STUN.  Because
>  ICE exchanges a multiplicity of IP addresses and ports for each media
>  stream, it also allows for address selection for multihomed and dual-
>  stack hosts.  For this reason RFC 5245 [RFC5245] deprecated RFC 4091

"For this reaason, RFC..."

"...deprecated the solutions previously defined in..."

---------------------------------------------------------------------------

§2:

>  Figure 1 shows a typical ICE deployment.  The agents are labelled L
>  and R.  Both L and R are behind their own respective NATs though they
>  may not be aware of it.  The type of NAT and its properties are also
>  unknown.  L and R are capable of engaging in an candidate exchange

"...in a candidate..."

>  In addition to the agents, a signaling server and NATs, ICE is

"...signaling server, and NATs,..."

---------------------------------------------------------------------------

§2.4:

>  Once ICE is concluded, it can be restarted at any time for one or all
>  of the data streams by either ICE agent.  This is done by sending an
>  updated candidate information indicating a restart.

"...sending updated..."

---------------------------------------------------------------------------

§3:

>  This document specifies generic use of ICE with protocols that
>  provide means to exchange candidate information between the ICE
>  agents.  The specific details of (i.e how to encode candidate

"...specific details (i.e., how.."

(remove "of", include period and comma after "i.e")

>  information and the actual candidate exchange process) for different
>  protocols using ICE (referred to as using protocol) are described in

'...(referred to as "using protocol")...'

>  separate usage documents.
>
>  One mechanism for agents to exchange the candidate information by
>  using [RFC3264] based Offer/Answer semantics as part of the SIP

"...information is using..."

---------------------------------------------------------------------------

§4:

>  Responding Peer, Responding Agent, Responder:  A receiving agent is

"A responding agent..."

>  Component:  A component is a piece of a data stream.  A data stream
>     may require multiple components, each of which has to work in
>     order for the data stream as a whole to work.  For RTP/RTCP data
>     streams, unless RTP and RTCP are multiplexed in the same port,
>     there are two components per data stream -- one for RTP, and one
>     for RTCP.  A component has a candidate pair, which cannot be used
>     by other components

Add a period to the end of this sentence.

>   Default Destination/Candidate:  The default destination for a
>     component of a data stream is the transport address that would be
>     used by an ICE agent that is not ICE-aware.

Users are likely to be confused by the phrase "ICE agent that is not ICE-aware."
It certainly threw me for a loop. Perhaps "...used by a peer that is not
ICE-aware" or something like that.

>  Nomination, Regular Nomination:  The process of the controlling agent
>     indicating to the controlled agent which candidate pair the ICE
>     agents will use for sending and receiving data.

With the exception of its use in §13 (which I think should be removed), the term
"Regular Nomination" (which was used to distinguish from the now-removed
aggressive nomination) does not appear in this document. I suggest it be removed
from this definition.

>  Timer HTO:  The timeout timer for a given STUN or TURN transaction.

It would be nice if the document indicated some mnemonic for "HTO" (that is:
expand or explain this acronym, please).

---------------------------------------------------------------------------

§5.1.1.1:

>  For other than RTP/RTCP streams, use of multiple components is

"For uses other than..."

>  discouraged since using them increases the complexity of ICE

"...discouraged, since..."

---------------------------------------------------------------------------

§5.3:

>  The using protocol may (or may not) need to deal with backwards
>  compatibility with older implementations that do not support ICE.  If
>  the fallback mechanism is being used...

It's not clear what "the fallback mechanism" refers to in this sentence.

---------------------------------------------------------------------------

§5.4:

>   Certain middleboxes, such as ALGs, can alter signaling information in
>   ways that break ICE.

"...break ICE (for example, by rewriting IP addresses in SDP)."

---------------------------------------------------------------------------

§6.1.1:

>  Both agents are full:  The initiating agent which started the ICE

"...agent that started..."

>  Both lite:  The initiating agent which started the ICE processing

"...agent that started..."

>  NOTE: There are certain 3PCC (third party call control) scenarios
>  where an ICE restart might cause a role conflict.

Please add an informative citation to RFC 3725.

---------------------------------------------------------------------------

§6.1.2:

>  There is one check list for each data stream.  To form a check list,
>  initiating and responding ICE agents form candidate pairs, computes
>  pair priorities, orders pairs by priority, prunes pairs, removes
>  lower-priority pairs, and sets check list states.

Please match up your number tense here. Either:

   There is one check list for each data stream.  To form a check list,
   initiating and responding ICE agents form candidate pairs, compute
   pair priorities, order pairs by priority, prune pairs, remove
   lower-priority pairs, and set check list states.

...or...

   There is one check list for each data stream.  To form a check list,
   each initiating and responding ICE agent forms candidate pairs, computes
   pair priorities, orders pairs by priority, prunes pairs, removes
   lower-priority pairs, and sets check list states.

---------------------------------------------------------------------------

§6.1.2.6:

>                      Figure 8: Initial Pair State

I think calling this a figure is quite a stretch. I was really thrown for a loop
after reading four paragraphs to find this non-sequitur label just hanging out
at the end of the section.

---------------------------------------------------------------------------

§6.1.4.2:

>  Once the agent has picked a candidate pair, for which a connectivity
>  check is to be performed, the agent performs the check by sending a

"...a candidate pair for which..."

---------------------------------------------------------------------------

§6.2:

>  Lite implementations skips most of the steps in Section 6 except for

"Lite implementations skip..."

---------------------------------------------------------------------------

§7.2.5.2.2:

   An ICE agent MAY support processing of ICMP errors for connectivity
   checks.  If the agent supports processing of ICMP errors, and if a
   Binging request generates a hard ICMP error, the agent SHOULD set the

"...Binding request..."

---------------------------------------------------------------------------

§9:

>  An ICE agent MAY restart ICE for existing data streams.  An ICE
>  restart causes all previous state of the data streams, excluding the
>  roles of the agents to be flushed.

"...excluding the roles of the agents, to be flushed."

(insert comma)

---------------------------------------------------------------------------

§12.1:

>  Once selected pairs have been produced for a data stream, an agent
>  MUST send data on those pairs.

"...on those pairs only."

---------------------------------------------------------------------------

§12.2:

>  Even though ICE agents are only allowed to send data using valid
>  candidate pairs (and, once selected pairs have been produced, only on
>  the selected pairs) ICE implementations SHOULD by default be prepared
>  to receive data on any of the candidates provided in the most recent
>  candidate exchange with the peer.  ICE usages MAY define rules that
>  differs from this, e.g., by defining that data will not be sent until

"...rules that differ..."

---------------------------------------------------------------------------

§13:

>  One of the complications in achieving interoperability is that ICE
>  relies on a distributed algorithm running on both agents to converge
>  on an agreed set of candidate pairs.  If the two agents run different
>  algorithms, it can be difficult to guarantee convergence on the same
>  candidate pairs.  The regular nomination procedure described in

There is only one nomination procedure here; this makes more sense as "The
nomination procedure described in..."

>  Section 8 eliminates some of the tight coordination by delegating the
>  selection algorithm completely to the controlling agent.
>  Consequently, when a controlling agent is communicating with a peer
>  that supports options it doesn't know about, the agent MUST run a
>  regular nomination algorithm.  When regular nomination is used, ICE

"...MUST run the nomination algorithm described in Section 8. When this
algorithm is used,..."

---------------------------------------------------------------------------

§14.2:

>  ICE agents SHOULD use the default Ta value, 50 ms, but MAY use

"ICE agents SHOULD use a default Ta value of 50 ms, but MAY use..."
                       ^                  ^^

>     1.  Let MaxBytes be the maximum number of bytes allowed to be
>         outstanding in the network at start-up, which SHOULD be 14600
>         bytes per RFC 6928.

Please add a citation to RFC 6928 (rather than just mentioning its RFC number).

---------------------------------------------------------------------------

§14.3:

>    RTO = MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress))

I can't tell whether the "*N" in "Ta*N" is a typo, or if the document simply
doesn't define the meaning of "N" anywhere. Please either fix the formula, or
add a description of the meaning of "N."

---------------------------------------------------------------------------

§16.1:

>  This specification defines four new STUN attributes, PRIORITY, USE-
>  CANDIDATE, ICE-CONTROLLED, and ICE-CONTROLLING.

"...new STUN attributes: PRIORITY, ..."

---------------------------------------------------------------------------

§17.1:

>  Consequently, it is not necessary to replace or reconfigure existing
>  firewall and NAT equipment in order to facilitate deployment of ICE.
>  Indeed, ICE was developed to be deployed in environments where the
>  Voice over IP (VoIP) operator has no control over the IP network
>  infrastructure, including firewalls and NAT.

"...and NATs."

>  That said, ICE works best in environments where the NAT devices are
>  "behave" compliant, meeting the recommendations defined in [RFC4787]
>  and [RFC5382].  In networks with behave-compliant NAT, ICE will work

"...behave-compliant NATs, ..."

---------------------------------------------------------------------------

§17.2.1:

>  First and foremost, ICE makes use of TURN and STUN servers, which
>  would typically be located in the data centers.

"...in data centers."


---------------------------------------------------------------------------

§17.3:

>  Deployments utilizing a mix of ICE and ICE-lite interoperate
>  perfectly.  They have been explicitly designed to do so.

"Perfectly" seems a bit hubristic. Perhaps "...interoperate with each other."


---------------------------------------------------------------------------

§18:

>  The IAB has studied the problem of "Unilateral Self-Address Fixing",

Since you use the "UNSAF" acronym further down, please use this opportunity to
expand it.

>  and the difference has a significant impact on the issues raised by
>  IAB.  Indeed, ICE can be considered a B-SAF (Bilateral Self-Address

"...raised by the IAB."

---------------------------------------------------------------------------

§18.2

>  less, and can eventually be remove when their usage goes to zero.

"...be removed..."

---------------------------------------------------------------------------

§19:

The text in the top-level "Security Considerations" section is its own topic,
similar to those found in Section 19's subsections. Please give it its own title
(e.g., "19.1.   IP Address Privacy")

---------------------------------------------------------------------------

§19.1:

>  UDP header of the message triggering the error.  These fields also
>  needs to be validated.  The IP destination and UDP destination port

"...need..."

>  needs to match either the targeted candidate address and port, or the

"...need..."

>  candidates base address.  The source IP address and port can be any

"...candidate's..."

---------------------------------------------------------------------------

§19.4:

>  In addition to attacks where the attacker is a third party trying to
>  insert fake candidate information or stun messages, there are attacks

"...STUN..."

---------------------------------------------------------------------------

§20.3:

>       The ICE option indicates that the ICE agent using the ICE option
>       is compliant and implemented according to RFC XXXX.

Suggest removing "compliant and" from this.

---------------------------------------------------------------------------

§21:

>  o  Make technical changes, due to discovered flows in RFC 5245 and

"...discovered flaws..."

---------------------------------------------------------------------------

§22

>  Harald Alvestrand and Roman Shpount.  Ben Campbill did the AD review.

"Ben Campbell"

---------------------------------------------------------------------------

§B.1:

>  rate at which they will create new bindings.  Experiments have shown

I agree with EKR that a citation to these experiments is called for.

>  that once every 5 ms is well supported.  This is why Ta has a lower

"...well-supported..."

---------------------------------------------------------------------------

§B.8:

>  Additionally, using a Binding Indication allows integrity to be
>  disabled, allowing for better performance.  This is useful for large-
>  scale endpoints, such as PSTN gateways and SBCs.

Expand "PSTN" and "SBC".



From nobody Wed Feb 21 08:52:19 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50245127010 for ; Wed, 21 Feb 2018 08:52:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 8tbWwH_kggyD for ; Wed, 21 Feb 2018 08:52:16 -0800 (PST)
Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 92A61127867 for ; Wed, 21 Feb 2018 08:52:16 -0800 (PST)
Received: by mail-wr0-x22e.google.com with SMTP id s5so6401914wra.0 for ; Wed, 21 Feb 2018 08:52:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=mf3xKmqWKfZ+YTSirSwo/NGjI/5zjKrnQUEH1Nr5kGg=; b=UPMwnX19b7YUyj13nuvuFUJ8CrO0EMD9w5M/8OUWbE/RtlxjVsiapSo6j1mwecyjEV /I7a6RPsPj3RSKHTuMiUdGCvPnePI7EDSfF5A7ZAwBuUec9zjoyb55wQCSxKdtLhbC4U rW4p+LIBnylEUBGCm6G2hznvXNGaTdRxU5b+qlxz4GWyxzhNtS+y6pknN3do+rB78UoH jfsZEr1wsce5ljNIxO8PiUwT9FWJoDMfoJvMAsplyN7o1Xd19zLqgdorCidNKa7k4ZK6 ieCH36YvF/U/dzUy5Bnwa+bYPBKQcUzdbwzX0zK9C7XTyDH/4I/w+tHLkH4ghf2ngdI7 YlgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mf3xKmqWKfZ+YTSirSwo/NGjI/5zjKrnQUEH1Nr5kGg=; b=pfUHuMtzLS1KHCj4lAUJODp0BV//ePe1drisg1ZjejWZFJsAQdvw0Zetn+naD9fIi1 kcJhWbhBhdJz/9a3jsPGntVlQYn/exavF0OnhjbeCYUjyCDnoepIFyJWM4q5+NjTz9a7 iZJQDAegBa9So2ntaHYDIz7lOBlp37UAGieG5MnbA2AnnPupYj8IwHLjLDLCJJyWwuES p+zp7RaTx32/PF2/luc38CjdUMPkJCVuWLnllQZau1WhZ9aUjo+wnq+HOpTGELToqQIN V4hRF9ze1TJLNDfKTmR2l05Mao554Ko790yt8Wq3ommtTy4zGeLozp+Afzs1+kB2VLAX GXpg==
X-Gm-Message-State: APf1xPClOu+p1h3FDHivhW1PtktWvR+UUzr+5Te5flRhIY58RSKbfCKc FCVSgEs3DQEfsOBrsprhOeKbFmYZBICcen3OXLiOVB3g
X-Google-Smtp-Source: AH8x225PjOTX+aloMeHPrwI8p8ZQNn1ymyWJRhRvydVNZ6+eDc144cWC6LVxLdRL+FbEmAM+SvvWeTdJSwnHQlULNYQ=
X-Received: by 10.28.139.66 with SMTP id n63mr2536463wmd.101.1519231934589; Wed, 21 Feb 2018 08:52:14 -0800 (PST)
MIME-Version: 1.0
From: Peter Thatcher 
Date: Wed, 21 Feb 2018 16:52:03 +0000
Message-ID: 
To: ice@ietf.org
Content-Type: multipart/alternative; boundary="001a11442166cbb9cf0565bbbf0e"
Archived-At: 
Subject: [Ice] Changes to draft-ietf-ice-rfc5245bis-17 (from -16)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Feb 2018 16:52:18 -0000

--001a11442166cbb9cf0565bbbf0e
Content-Type: text/plain; charset="UTF-8"

ICEbis has been making steady progress through IESG review.  Christer has
been doing a great job responding to all the comments there, mostly
editorial ones.  If you'd like to keep up on the changes to ICEbis, here's
a diff from -16 to -17:

https://www.ietf.org/rfcdiff?url1=draft-ietf-ice-rfc5245bis-16&url2=draft-ietf-ice-rfc5245bis-17&difftype=--html


The biggest changes are (in the order they appear in the diff):


- For ICE lite, there is 0 or 1 candidate per IP for both IPv4 and IPv6
(previously IPv4 could only have 0 or 1, not 0 or 1 per IP; this makes IPv4
and IPv6 the same).

- Multihomed agents are recommended to run full ICE implementations.

- When restarting ICE, the agent must verify that the new local ufrag/pwd
were not used previously.

- "Num-Of-Pairs" in gathering phase changed to "Num-Of-Cands" (seems like
an error in 5245)

- The text around hard ICMP errors is more specific, especially around and
the security implications related to them.


These are all non-editorial changes and so we would like to to verify WG
consensus for them, in particular around ICMP hard errors.  Please let us
know by 28th of February if you have any concerns about these changes.


Thanks,

ICE WG Chairs

--001a11442166cbb9cf0565bbbf0e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


ICEbis has been making steady progress through IESG r=
eview.=C2=A0 Christer has been doing a great job responding to all the comm=
ents there, mostly editorial ones.=C2=A0 If you'd like to keep up on th=
e changes to ICEbis, here's a diff from -16 to -17:
The biggest changes are (in the order they appear in the diff):

- For ICE lite, there is 0 or 1 candidate per I=
P for both IPv4 and IPv6 (previously IPv4 could only have 0 or 1, not 0 or =
1 per IP; this makes IPv4 and IPv6 the same).

- Mu=
ltihomed agents are recommended to run full ICE implementations.
=

- When restarting ICE, the agent must verify that the new lo=
cal ufrag/pwd were not used previously.

- "Nu=
m-Of-Pairs" in gathering phase changed to "Num-Of-Cands" (se=
ems like an error in 5245)

- The text around hard =
ICMP errors is more specific, especially around and the security implicatio=
ns related to them.


These are all n=
on-editorial changes and so we would like to=C2=A0to verify WG consensus fo=
r them, in particular around ICMP hard errors.=C2=A0 Please let us know by =
28th of February if you have any concerns about these changes.

Thanks,

ICE WG Chairs<=
/div>



--001a11442166cbb9cf0565bbbf0e--


From nobody Wed Feb 21 09:49:52 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE0A12D956 for ; Wed, 21 Feb 2018 09:49:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvPiWCxzCpIA for ; Wed, 21 Feb 2018 09:49:49 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 F34A512783A for ; Wed, 21 Feb 2018 09:49:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519235387; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=QPclZflzvIjbtxPHuLoG4Eqpau50LBtIKgNG/IrHx40=; b=NU6duObGkQji0JHSYTBzdiWotrk9/schnnCL5ZZjZCeGXDqopXXDaqwRpbdc4VtY toUjIMYF599BQLxmlJQt6JxU9PbM5I6jzjFpl7sT7Z64d4GBxlIrNLOhnbhU/SpN UiMTSZBgP0YQOa2H0G7TlAZqMaSTwx3D8hkCz33Ouzg=;
X-AuditID: c1b4fb30-3b1ff70000004778-af-5a8db13a790b
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CC.5D.18296.A31BD8A5; Wed, 21 Feb 2018 18:49:47 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Wed, 21 Feb 2018 18:49:46 +0100
From: Christer Holmberg 
To: Suresh Krishnan , The IESG 
CC: "draft-ietf-ice-rfc5245bis@ietf.org" ,  Peter Thatcher , "ice-chairs@ietf.org" , "pthatcher@google.com" , "ice@ietf.org" 
Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
Thread-Index: AQHTqtFQPV6g3lZs5kCk61sA9woFcKOu9Tzw
Date: Wed, 21 Feb 2018 17:49:46 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C17AFDF@ESESSMB109.ericsson.se>
References: <151918940727.9623.17348873149297319051.idtracker@ietfa.amsl.com>
In-Reply-To: <151918940727.9623.17348873149297319051.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.172]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7n671xt4ogy8POSzmn7zObHFx1mQ2 i28Xai1m/JnIbHFt+WtWi21dp1gc2DwWbCr1WLLkJ5PH+Ssz2AOYo7hsUlJzMstSi/TtErgy /r0rKbjFU9E8aTJbA+MGni5GTg4JAROJ1X3HGLsYuTiEBA4zSqydO5MJwlnCKLH1ZjdbFyMH B5uAhUT3P22QBhEBR4k5c2aDNTALfGWUWLFxJxNIQlggRWL3xlYmiKJUif4JB9ggbCOJzi3P wGwWAVWJ+VfvsYLYvAK+Em2P94PZQkD2xX+bWUBsTgE/iekPX4LVMwqISXw/tQZsJrOAuMSt J/OZIK4WkFiy5zwzhC0q8fLxP1aQOyUElCQaZrKAmMwCmhLrd+lDdCpKTOl+yA6xVVDi5Mwn LBMYRWchGToLoWMWko5ZSDoWMLKsYhQtTi1Oyk03MtJLLcpMLi7Oz9PLSy3ZxAiMp4Nbfhvs YHz53PEQowAHoxIPr8qa3igh1sSy4srcQ4wSHMxKIrwnEoBCvCmJlVWpRfnxRaU5qcWHGKU5 WJTEeU968kYJCaQnlqRmp6YWpBbBZJk4OKUaGDUZL8irLHJ6/3PewqnNnBuuRn3zCTWxn77G 6tw0u4p1CUJ1bafPWhTfmxJqeudC+xVttvwnIrYvJ/1NeJEmUB3o08UWdOfQusn/H0Sbn2dL Omnz3//29k6hqPyQnccYp8zrWrhsmtac9bJad5cFH7tc/+da7Kalf1J60r9orZumsE08tZuH x1GJpTgj0VCLuag4EQCYceUbowIAAA==
Archived-At: 
Subject: Re: [Ice] Suresh Krishnan's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Feb 2018 17:49:50 -0000

SGkgU3VyZXNoLA0KDQpUaGFuayBZb3UgZm9yIHRoZSByZXZpZXcgYW5kIGNvbW1lbnRzISBQbGVh
c2Ugc2VlIGlubGluZS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRElTQ1VTUzoNCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N
Cg0KPiAqIFNlY3Rpb24gNS4yLiAgTGl0ZSBJbXBsZW1lbnRhdGlvbiBQcm9jZWR1cmVzDQo+DQo+
ICJGb3IgZHVhbC1zdGFjayBob3N0cywgdGhlIElQdjQgYWRkcmVzcyBpcyBSRUNPTU1FTkRFRC4i
DQo+DQo+IEkgYW0gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIHJlYXNvbmluZyBiZWhpbmQgdGhp
cyB1bmVxdWl2b2NhbCBjaG9pY2UgKHdoaWNoIHByb2JhYmx5IG1pZ2h0IGhhdmUgbWFkZSANCj4g
c2Vuc2UgaW4gMjAxMCkuIEF0IGxlYXN0LCB0aGVyZSBpcyBzb21lIGV4cGxhbmF0b3J5IHRleHQg
cmVxdWlyZWQgdG8ganVzdGlmeSB0aGlzLg0KDQpUaGUgdGV4dCBjYW1lIGZyb20gUkZDIDUyNDUu
IEFzIGZhciBhcyBJIHJlbWVtYmVyLCBpdCB3YXMgbmV2ZXIgZGlzY3Vzc2VkIGluIHRoZSBiaXMg
d29yay4NCg0KSSBkb24ndCBoYXZlIGFueSBqdXN0aWZpY2F0aW9uIHRvIGtlZXAgdGhlIHRleHQs
IHNvIEkgc3VnZ2VzdCB0byByZW1vdmUgaXQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQot
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQoNCj4qIFNlY3Rpb24gMTUNCj4NCj5JdCB3b3VsZCBoYXZlIGJlZW4gZ29v
ZCB0byBoYXZlIGFuIGV4YW1wbGUgd2l0aCBJUHY2IGFkZHJlc3NlcyAoZnJvbSB0aGUNCj4yMDAx
OmRiODo6LzMyIHNwYWNlKSBhcyB3ZWxsLg0KDQpJIGNhbiBtb2RpZnkgdGhlIGV4aXN0aW5nIGV4
YW1wbGUgdG8gdXNlIElQdjYgYWRkcmVzc2VzLiBJIHNlZSBubyByZWFzb24gdG8gaGF2ZSB0byBj
b3BpZXMgb2YgdGhlIHNhbWUgZXhhbXBsZSwgd2l0aCB0aGUgSVAgdmVyc2lvbiBiZWluZyB0aGUg
b25seSBkaWZmZXJlbmNlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg==


From nobody Wed Feb 21 09:54:09 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8977112D945 for ; Wed, 21 Feb 2018 09:54:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 qPSvICoLoBkG for ; Wed, 21 Feb 2018 09:54:05 -0800 (PST)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 823D612783A for ; Wed, 21 Feb 2018 09:54:05 -0800 (PST)
Received: by mail-qt0-x231.google.com with SMTP id d26so2978933qtk.10 for ; Wed, 21 Feb 2018 09:54:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jLMy3TzRQ5qpW0/kYiPUCTXvzONZAQjLoc5/8h9HTWg=; b=fGK6squt6Ga8al0tL4byKSA7yFgovitNt45lmBRs6QdXG0pPs4avtpJTIYz/j2tLHK ojRZUql2WPk78FgsZCet3pTvlnWd3g949vHeKOOr4BDMZ9Aa6uUWtZ3YMbjaxE20wdUy c1RPUddbBiqdJM9dckQ7VPqRTcZIL3kMwwBaOUFIfq85jQbklg8W330TK2veyUaHTd3Q bNz9qafNu0qg7VIcBcKdKB2+TJYN2EDpqDKnFEGQZocTSG1T2Af2umdHSwmQhToJFi0d WYrVFgADYOSLWStCDDNqUE27kad9UatLcdo9JWRdAqKScuLYxcg1tCmaiG3P7qc27Pha gcdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jLMy3TzRQ5qpW0/kYiPUCTXvzONZAQjLoc5/8h9HTWg=; b=VLB1SuRNIeJOw0Ry4OHFkWLweb8TW42eMXQyJPLAfYB5LsBHiWhpBewHIwY/IWQYgn Su5ItV8BNk/+BN25buKSxlP5DOJJnajeAuP1cRWO3pyOGsk+G8gPVUK1yaewCmbAXmmm NCEPHtKQvV5S6OdTLjcT9ZLfsndiG3TJjZsYvq4xGMfbZ1TIAxlsLhPTU/JnAS4eTq18 7tuIW32HmBmMAnip6XB0kQVFy+9+8TRSud8eSqDN3ExCUCY5PQ6LA8sp3ROodhOPlJFe lyv5eg9jEOV/0fxTOcqs1V9g0Y8pesg4YSB4HQ/v2l9BqYLs/h8TaDmN34hpu5tjCInh we/Q==
X-Gm-Message-State: APf1xPDy64hd5IoWksJVv3Zpy7GvcEBJlyVka+oU3a/De2IkqgMYdzbP ZXO6KAVdyF9+eWMh2D+UW7RsgCdhGW+AWWI+b37sceSk
X-Google-Smtp-Source: AH8x227fnyKGI4lP1kQkzHqi4nANFUJLMHg8nGYBemGIl7P6vcmhzgTvkYNNK7OQZPf7ISGnCDa+qQOGn4jTCWFvyKM=
X-Received: by 10.237.56.34 with SMTP id j31mr6692414qte.208.1519235644528; Wed, 21 Feb 2018 09:54:04 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Wed, 21 Feb 2018 09:53:24 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C17AFDF@ESESSMB109.ericsson.se>
References: <151918940727.9623.17348873149297319051.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C17AFDF@ESESSMB109.ericsson.se>
From: Eric Rescorla 
Date: Wed, 21 Feb 2018 09:53:24 -0800
Message-ID: 
To: Christer Holmberg 
Cc: Suresh Krishnan , The IESG ,  "ice-chairs@ietf.org" ,  "draft-ietf-ice-rfc5245bis@ietf.org" ,  "pthatcher@google.com" , "ice@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113b7f18ec4a130565bc9c2e"
Archived-At: 
Subject: Re: [Ice] Suresh Krishnan's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Feb 2018 17:54:07 -0000

--001a113b7f18ec4a130565bc9c2e
Content-Type: text/plain; charset="UTF-8"

I would actually prefer multiple examples to ones with just IPv6. Like it
or not, there is a huge amount of IPv4 ICE and it would be good for the
examples to match reality

On Wed, Feb 21, 2018 at 9:49 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi Suresh,
>
> Thank You for the review and comments! Please see inline.
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> > * Section 5.2.  Lite Implementation Procedures
> >
> > "For dual-stack hosts, the IPv4 address is RECOMMENDED."
> >
> > I am trying to understand the reasoning behind this unequivocal choice
> (which probably might have made
> > sense in 2010). At least, there is some explanatory text required to
> justify this.
>
> The text came from RFC 5245. As far as I remember, it was never discussed
> in the bis work.
>
> I don't have any justification to keep the text, so I suggest to remove it.
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> >* Section 15
> >
> >It would have been good to have an example with IPv6 addresses (from the
> >2001:db8::/32 space) as well.
>
> I can modify the existing example to use IPv6 addresses. I see no reason
> to have to copies of the same example, with the IP version being the only
> difference.
>
> Regards,
>
> Christer
>
>
>

--001a113b7f18ec4a130565bc9c2e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


I would actually prefer multiple examples to ones with jus=
t IPv6. Like it or not, there is a huge amount of IPv4 ICE and it would be =
good for the examples to match reality

=

On Wed, Feb 21, 2018 at 9:49 AM, Christer Holmbe=
rg <christer.holmberg@ericsson.com> wrote:
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">Hi Suresh,



Thank You for the review and comments! Please see inline.



-----------------------------------------------------------------=
-----

DISCUSS:

-----------------------------------------------------------------=
-----



> * Section 5.2.=C2=A0 Lite Implementation Procedures

>

> "For dual-stack hosts, the IPv4 address is RECOMMENDED."

>

> I am trying to understand the reasoning behind this unequivocal choice=
 (which probably might have made

> sense in 2010). At least, there is some explanatory text required to j=
ustify this.



The text came from RFC 5245. As far as I remember, it was never disc=
ussed in the bis work.



I don't have any justification to keep the text, so I suggest to remove=
 it.



-----------------------------------------------------------------=
-----

COMMENT:

-----------------------------------------------------------------=
-----



>* Section 15

>

>It would have been good to have an example with IPv6 addresses (from th=
e

>2001:db8::/32 space) as well.



I can modify the existing example to use IPv6 addresses. I see no re=
ason to have to copies of the same example, with the IP version being the o=
nly difference.



Regards,



Christer









--001a113b7f18ec4a130565bc9c2e--


From nobody Wed Feb 21 10:04:51 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC544126B7E for ; Wed, 21 Feb 2018 10:04:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnTnuoVqt8Ks for ; Wed, 21 Feb 2018 10:04:43 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77037120713 for ; Wed, 21 Feb 2018 10:04:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519236281; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=M1TtOgN2EAJerr6VoWFgJa4+/vBMAX4ufht6wY7Zaq8=; b=ZLPCA8J535oojtFlU6Nva4Y3hftAXDg8BQdrgBOmWUrAw4z/CukqXlIiX+c8GP+q KDm34qusRP8MPQdv0O+NZ500G8PQazznjK8DXFmFEbeB+yNwwo3XRaX3Ha/CSE8K J8lRowCnlR2u+cwCn8h/dF+VYTpXfAEQWXnHI/EB7m8=;
X-AuditID: c1b4fb25-083ff70000002d5f-86-5a8db4b98298
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 97.4D.11615.9B4BD8A5; Wed, 21 Feb 2018 19:04:41 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Wed, 21 Feb 2018 19:04:41 +0100
From: Christer Holmberg 
To: Eric Rescorla 
CC: Suresh Krishnan , The IESG , "ice-chairs@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , "pthatcher@google.com" , "ice@ietf.org" 
Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
Thread-Index: AQHTqtFQPV6g3lZs5kCk61sA9woFcKOu9TzwgAAeGgCAABMgUA==
Date: Wed, 21 Feb 2018 18:04:40 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C17B031@ESESSMB109.ericsson.se>
References: <151918940727.9623.17348873149297319051.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C17AFDF@ESESSMB109.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.172]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C17B031ESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM2K7n+7OLb1RBnvOKFjMP3md2WLF63Ps FhdnTWaz+Hah1mLGn4nMFteWv2a12NZ1isWB3WPBplKPJUt+MnmcvzKD3WPy4zbmAJYoLpuU 1JzMstQifbsErozti1czFuwLq7j7Q6SBsSeki5GTQ0LARKJ94xvmLkYuDiGBw4wSxybvY4Fw ljBKbJi3krGLkYODTcBCovufNkiDiICCxK8/J1hAbGaBXiaJFZeyQGxhgRSJ3RtbmSBqUiX6 Jxxgg7CdJJ4fnccMYrMIqEocnHkDrIZXwFdi9b0D7BC7bjACzX/JCJLgFAiUWLplDlgRo4CY xPdTa5gglolL3HoynwniagGJJXvOM0PYohIvH/9jBblTQkBJomEmC4jJLJAvMe+cCsQqQYmT M5+wTGAUmYVk0CyEqllIqiDCmhLrd+lDVCtKTOl+yA5ha0i0zpnLjiy+gJF9FaNocWpxUm66 kbFealFmcnFxfp5eXmrJJkZgRB7c8lt1B+PlN46HGAU4GJV4eINW90YJsSaWFVfmHmKU4GBW EuE9kQAU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzjtHuD1KSCA9sSQ1OzW1ILUIJsvEwSnVwBg+ d9GizIY/+yax688Wvr7FZPt+joxPWt3cf+qPxh3LeljgtE8sV18lPPWJ3aS9uyryt62PSVu7 enHjltXnp26OFg00ntzeWHOqo7zy6cOlvkybEt4zsL1tOMmTYJRsNd2g2ncpN/vFLSdaFdYH sTn90bhz2jFDTGKj3prPuZ7tUuJZU9YuuqPEUpyRaKjFXFScCACbSmAVxAIAAA==
Archived-At: 
Subject: Re: [Ice] Suresh Krishnan's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Feb 2018 18:04:49 -0000

--_000_7594FB04B1934943A5C02806D1A2204B6C17B031ESESSMB109erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U28sIHlvdSB3YW50IG1lIHRvIGNvcHkgcGFzdGUgc2VjdGlvbiAxNSAod2hpY2ggaXMgNCw1IHBh
Z2VzIGxvbmcpLCBhbmQgb25seSBjaGFuZ2UgdGhlIElQIGFkZHJlc3Nlcz8gVGhlIElQIGFkZHJl
c3NlcyBhcmUgb25seSBtZW50aW9uZWQgaW4gdGhlIGludHJvZHVjdGlvbiB0ZXh0IOKAkyBpbiB0
aGUgZmxvdyBldGMgdGhleSBhcmUgbm90IHNob3duLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K
DQpGcm9tOiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXQ0KU2VudDogMjEgRmVi
cnVhcnkgMjAxOCAxOTo1Mw0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVy
Z0Blcmljc3Nvbi5jb20+DQpDYzogU3VyZXNoIEtyaXNobmFuIDxzdXJlc2hAa2Fsb29tLmNvbT47
IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPjsgaWNlLWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0
Zi1pY2UtcmZjNTI0NWJpc0BpZXRmLm9yZzsgcHRoYXRjaGVyQGdvb2dsZS5jb207IGljZUBpZXRm
Lm9yZw0KU3ViamVjdDogUmU6IFN1cmVzaCBLcmlzaG5hbidzIERpc2N1c3Mgb24gZHJhZnQtaWV0
Zi1pY2UtcmZjNTI0NWJpcy0xNzogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCg0KSSB3b3Vs
ZCBhY3R1YWxseSBwcmVmZXIgbXVsdGlwbGUgZXhhbXBsZXMgdG8gb25lcyB3aXRoIGp1c3QgSVB2
Ni4gTGlrZSBpdCBvciBub3QsIHRoZXJlIGlzIGEgaHVnZSBhbW91bnQgb2YgSVB2NCBJQ0UgYW5k
IGl0IHdvdWxkIGJlIGdvb2QgZm9yIHRoZSBleGFtcGxlcyB0byBtYXRjaCByZWFsaXR5DQoNCk9u
IFdlZCwgRmViIDIxLCAyMDE4IGF0IDk6NDkgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rl
ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u
LmNvbT4+IHdyb3RlOg0KSGkgU3VyZXNoLA0KDQpUaGFuayBZb3UgZm9yIHRoZSByZXZpZXcgYW5k
IGNvbW1lbnRzISBQbGVhc2Ugc2VlIGlubGluZS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRElTQ1VTUzoN
Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCg0KPiAqIFNlY3Rpb24gNS4yLiAgTGl0ZSBJbXBsZW1lbnRhdGlvbiBQ
cm9jZWR1cmVzDQo+DQo+ICJGb3IgZHVhbC1zdGFjayBob3N0cywgdGhlIElQdjQgYWRkcmVzcyBp
cyBSRUNPTU1FTkRFRC4iDQo+DQo+IEkgYW0gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIHJlYXNv
bmluZyBiZWhpbmQgdGhpcyB1bmVxdWl2b2NhbCBjaG9pY2UgKHdoaWNoIHByb2JhYmx5IG1pZ2h0
IGhhdmUgbWFkZQ0KPiBzZW5zZSBpbiAyMDEwKS4gQXQgbGVhc3QsIHRoZXJlIGlzIHNvbWUgZXhw
bGFuYXRvcnkgdGV4dCByZXF1aXJlZCB0byBqdXN0aWZ5IHRoaXMuDQoNClRoZSB0ZXh0IGNhbWUg
ZnJvbSBSRkMgNTI0NS4gQXMgZmFyIGFzIEkgcmVtZW1iZXIsIGl0IHdhcyBuZXZlciBkaXNjdXNz
ZWQgaW4gdGhlIGJpcyB3b3JrLg0KDQpJIGRvbid0IGhhdmUgYW55IGp1c3RpZmljYXRpb24gdG8g
a2VlcCB0aGUgdGV4dCwgc28gSSBzdWdnZXN0IHRvIHJlbW92ZSBpdC4NCg0KLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KPiogU2VjdGlvbiAxNQ0KPg0KPkl0IHdvdWxk
IGhhdmUgYmVlbiBnb29kIHRvIGhhdmUgYW4gZXhhbXBsZSB3aXRoIElQdjYgYWRkcmVzc2VzIChm
cm9tIHRoZQ0KPjIwMDE6ZGI4OjovMzIgc3BhY2UpIGFzIHdlbGwuDQoNCkkgY2FuIG1vZGlmeSB0
aGUgZXhpc3RpbmcgZXhhbXBsZSB0byB1c2UgSVB2NiBhZGRyZXNzZXMuIEkgc2VlIG5vIHJlYXNv
biB0byBoYXZlIHRvIGNvcGllcyBvZiB0aGUgc2FtZSBleGFtcGxlLCB3aXRoIHRoZSBJUCB2ZXJz
aW9uIGJlaW5nIHRoZSBvbmx5IGRpZmZlcmVuY2UuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN
Cg0K

--_000_7594FB04B1934943A5C02806D1A2204B6C17B031ESESSMB109erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl
OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N
CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t
W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt
YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N
CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh
PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv
ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5TbywgeW91IHdhbnQgbWUgdG8g
Y29weSBwYXN0ZSBzZWN0aW9uIDE1ICh3aGljaCBpcyA0LDUgcGFnZXMgbG9uZyksIGFuZCBvbmx5
IGNoYW5nZSB0aGUgSVAgYWRkcmVzc2VzPyBUaGUgSVAgYWRkcmVzc2VzIGFyZSBvbmx5IG1lbnRp
b25lZA0KIGluIHRoZSBpbnRyb2R1Y3Rpb24gdGV4dCDigJMgaW4gdGhlIGZsb3cgZXRjIHRoZXkg
YXJlIG5vdCBzaG93bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V
UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJl
Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3Rlcjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWls
RW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48
L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEVyaWMgUmVzY29ybGEgW21haWx0bzpl
a3JAcnRmbS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjEgRmVicnVhcnkgMjAxOCAxOTo1Mzxi
cj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVy
aWNzc29uLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFN1cmVzaCBLcmlzaG5hbiAmbHQ7c3VyZXNo
QGthbG9vbS5jb20mZ3Q7OyBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDs7IGljZS1jaGFp
cnNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXNAaWV0Zi5vcmc7IHB0aGF0Y2hl
ckBnb29nbGUuY29tOyBpY2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFN1cmVz
aCBLcmlzaG5hbidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpcy0xNzogKHdp
dGggRElTQ1VTUyBhbmQgQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5JIHdvdWxkIGFjdHVhbGx5IHByZWZlciBtdWx0aXBsZSBleGFtcGxlcyB0byBvbmVzIHdp
dGgganVzdCBJUHY2LiBMaWtlIGl0IG9yIG5vdCwgdGhlcmUgaXMgYSBodWdlIGFtb3VudCBvZiBJ
UHY0IElDRSBhbmQgaXQgd291bGQgYmUgZ29vZCBmb3IgdGhlIGV4YW1wbGVzIHRvIG1hdGNoIHJl
YWxpdHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdl
ZCwgRmViIDIxLCAyMDE4IGF0IDk6NDkgQU0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVm
PSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+
Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48
L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND
Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h
cmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0
b206MTIuMHB0Ij5IaSBTdXJlc2gsPGJyPg0KPGJyPg0KVGhhbmsgWW91IGZvciB0aGUgcmV2aWV3
IGFuZCBjb21tZW50cyEgUGxlYXNlIHNlZSBpbmxpbmUuPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LTxicj4NCkRJU0NVU1M6PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCiZndDsgKiBTZWN0
aW9uIDUuMi4mbmJzcDsgTGl0ZSBJbXBsZW1lbnRhdGlvbiBQcm9jZWR1cmVzPGJyPg0KJmd0Ozxi
cj4NCiZndDsgJnF1b3Q7Rm9yIGR1YWwtc3RhY2sgaG9zdHMsIHRoZSBJUHY0IGFkZHJlc3MgaXMg
UkVDT01NRU5ERUQuJnF1b3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSSBhbSB0cnlpbmcgdG8gdW5k
ZXJzdGFuZCB0aGUgcmVhc29uaW5nIGJlaGluZCB0aGlzIHVuZXF1aXZvY2FsIGNob2ljZSAod2hp
Y2ggcHJvYmFibHkgbWlnaHQgaGF2ZSBtYWRlPGJyPg0KJmd0OyBzZW5zZSBpbiAyMDEwKS4gQXQg
bGVhc3QsIHRoZXJlIGlzIHNvbWUgZXhwbGFuYXRvcnkgdGV4dCByZXF1aXJlZCB0byBqdXN0aWZ5
IHRoaXMuPGJyPg0KPGJyPg0KVGhlIHRleHQgY2FtZSBmcm9tIFJGQyA1MjQ1LiBBcyBmYXIgYXMg
SSByZW1lbWJlciwgaXQgd2FzIG5ldmVyIGRpc2N1c3NlZCBpbiB0aGUgYmlzIHdvcmsuPGJyPg0K
PGJyPg0KSSBkb24ndCBoYXZlIGFueSBqdXN0aWZpY2F0aW9uIHRvIGtlZXAgdGhlIHRleHQsIHNv
IEkgc3VnZ2VzdCB0byByZW1vdmUgaXQuPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCkNP
TU1FTlQ6PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCiZndDsqIFNlY3Rpb24gMTU8YnI+
DQomZ3Q7PGJyPg0KJmd0O0l0IHdvdWxkIGhhdmUgYmVlbiBnb29kIHRvIGhhdmUgYW4gZXhhbXBs
ZSB3aXRoIElQdjYgYWRkcmVzc2VzIChmcm9tIHRoZTxicj4NCiZndDsyMDAxOmRiODo6LzMyIHNw
YWNlKSBhcyB3ZWxsLjxicj4NCjxicj4NCkkgY2FuIG1vZGlmeSB0aGUgZXhpc3RpbmcgZXhhbXBs
ZSB0byB1c2UgSVB2NiBhZGRyZXNzZXMuIEkgc2VlIG5vIHJlYXNvbiB0byBoYXZlIHRvIGNvcGll
cyBvZiB0aGUgc2FtZSBleGFtcGxlLCB3aXRoIHRoZSBJUCB2ZXJzaW9uIGJlaW5nIHRoZSBvbmx5
IGRpZmZlcmVuY2UuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpDaHJpc3Rlcjxicj4N
Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+
DQo8L2h0bWw+DQo=

--_000_7594FB04B1934943A5C02806D1A2204B6C17B031ESESSMB109erics_--


From nobody Wed Feb 21 10:17:35 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C57129C59 for ; Wed, 21 Feb 2018 10:17:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSX1aikl_5mo for ; Wed, 21 Feb 2018 10:17:28 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 9F62912D949 for ; Wed, 21 Feb 2018 10:17:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519237043; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fMFzvCNYKrhNa2uKBWbZUuAUrAmtIUSy65WqG4M5TsI=; b=VWdtYYvYPaC0U57AhR3011WwXQ4Y8mHvi9rv9kTFKSp8a2JTF6mHMyEeOAjzvT5w /VqT7yIipWQVl8QRabPb6jmOoqBqoxYqtp0keFLAZbqSOlHBU1fc+AlGhO6Ff46o LLPVqX6kuWR19ofdLcGDK9s4PJSQE4M1YsuSfkdGOhQ=;
X-AuditID: c1b4fb3a-35fff700000067b4-57-5a8db7b232a8
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3F.41.26548.2B7BD8A5; Wed, 21 Feb 2018 19:17:23 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Wed, 21 Feb 2018 19:17:22 +0100
From: Christer Holmberg 
To: Eric Rescorla 
CC: Suresh Krishnan , The IESG , "ice-chairs@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , "pthatcher@google.com" , "ice@ietf.org" 
Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
Thread-Index: AQHTqtFQPV6g3lZs5kCk61sA9woFcKOu9TzwgAAeGgCAABMgUP//8vAAgAAROXA=
Date: Wed, 21 Feb 2018 18:17:22 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C17B0A5@ESESSMB109.ericsson.se>
References: <151918940727.9623.17348873149297319051.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C17AFDF@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C17B031@ESESSMB109.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.172]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C17B0A5ESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyM2K7qO7m7b1RBj3L2Szmn7zObLHi9Tl2 i4uzJrNZfLtQazHjz0Rmi2vLX7NabOs6xeLA7rFgU6nHkiU/mTzOX5nB7jH5cRtzAEsUl01K ak5mWWqRvl0CV0bX1RusBRe6GCsmTi1sYPzSxtjFyMkhIWAi0fpkI0sXIxeHkMBhRok7244w QjhLGCUOXT7D3MXIwcEmYCHR/U8bpEFEQEHi158TLCA2s0Avk8SKS1kgtrBAisTuja1MEDWp Ev0TDrBB2H4Sczt+MoPYLAKqEtdefAZbzCvgK/H1y0N2iF2PmSS+3l0BNpRTIFBi6eI+dhCb UUBM4vupNUwQy8Qlbj2ZzwRxtYDEkj3nmSFsUYmXj/+xgtwpIaAk0TAT6rZ8iWmda6B2CUqc nPmEZQKjyCwkk2YhKZuFpGwW0CRmAU2J9bv0IUoUJaZ0P2SHsDUkWufMZUcWX8DIvopRtDi1 uDg33chIL7UoM7m4OD9PLy+1ZBMjMDIPbvlttYPx4HPHQ4wCHIxKPLz71/RGCbEmlhVX5h5i lOBgVhLhPZEAFOJNSaysSi3Kjy8qzUktPsQozcGiJM7rlGYRJSSQnliSmp2aWpBaBJNl4uCU amB0X7JYLvaWwelXq6bdsp/1Oa8lKqzqUHvVzh81s4JrFR1rIvO9BOxz4+dv5a0LX3/Me0Xp c6WqZWxyZ8rvFk4xEy3w1/39zXqlTtj6bfHRyVmvDL9yeTGcc+s+z7TEc2uzcnbP860RC4/+ /ah0/XHrutKkzllVJxavzXrlo84knFMuGxIe7afEUpyRaKjFXFScCADzLLmjyAIAAA==
Archived-At: 
Subject: Re: [Ice] Suresh Krishnan's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Feb 2018 18:17:31 -0000

--_000_7594FB04B1934943A5C02806D1A2204B6C17B0A5ESESSMB109erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

T2ssIEnigJlsbCBsb29rIGludG8gaXQsIGlmIEkgY2FuIHVzZSBib3RoIElQdjQgYW5kIElQdjYg
YWRkcmVzc2VzIGluIHRoZSBzYW1lIGV4YW1wbGUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN
CkZyb206IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dDQpTZW50OiAyMSBGZWJy
dWFyeSAyMDE4IDIwOjE1DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJn
QGVyaWNzc29uLmNvbT4NCkNjOiBTdXJlc2ggS3Jpc2huYW4gPHN1cmVzaEBrYWxvb20uY29tPjsg
VGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBpY2UtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRm
LWljZS1yZmM1MjQ1YmlzQGlldGYub3JnOyBwdGhhdGNoZXJAZ29vZ2xlLmNvbTsgaWNlQGlldGYu
b3JnDQpTdWJqZWN0OiBSZTogU3VyZXNoIEtyaXNobmFuJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRm
LWljZS1yZmM1MjQ1YmlzLTE3OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQpObywgSSdk
IHByZWZlciB5b3UgbGVhdmUgaXQgYXMtaXMsIG9yLCBhbHRlcm5hdGVseSwgYWRkIHNvbWUgdGV4
dCBzYXlpbmcgIm9yIHRoZXNlIGNvdWxkIGJlIHY2IGFkZHJlc3NlcyIuIEJ1dCBoYXZpbmcgdGhl
IG9ubHkgZXhhbXBsZSBiZSB2NiBpcyBtaXNsZWFkaW5nLg0KDQotRWtyDQoNCg0KT24gV2VkLCBG
ZWIgMjEsIDIwMTggYXQgMTA6MDQgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xt
YmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+
IHdyb3RlOg0KU28sIHlvdSB3YW50IG1lIHRvIGNvcHkgcGFzdGUgc2VjdGlvbiAxNSAod2hpY2gg
aXMgNCw1IHBhZ2VzIGxvbmcpLCBhbmQgb25seSBjaGFuZ2UgdGhlIElQIGFkZHJlc3Nlcz8gVGhl
IElQIGFkZHJlc3NlcyBhcmUgb25seSBtZW50aW9uZWQgaW4gdGhlIGludHJvZHVjdGlvbiB0ZXh0
IOKAkyBpbiB0aGUgZmxvdyBldGMgdGhleSBhcmUgbm90IHNob3duLg0KDQpSZWdhcmRzLA0KDQpD
aHJpc3Rlcg0KDQpGcm9tOiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tPG1haWx0
bzpla3JAcnRmbS5jb20+XQ0KU2VudDogMjEgRmVicnVhcnkgMjAxOCAxOTo1Mw0KVG86IENocmlz
dGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlz
dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+DQpDYzogU3VyZXNoIEtyaXNobmFuIDxzdXJlc2hA
a2Fsb29tLmNvbTxtYWlsdG86c3VyZXNoQGthbG9vbS5jb20+PjsgVGhlIElFU0cgPGllc2dAaWV0
Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+PjsgaWNlLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86
aWNlLWNoYWlyc0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXNAaWV0Zi5vcmc8
bWFpbHRvOmRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXNAaWV0Zi5vcmc+OyBwdGhhdGNoZXJAZ29v
Z2xlLmNvbTxtYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5jb20+OyBpY2VAaWV0Zi5vcmc8bWFpbHRv
OmljZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBTdXJlc2ggS3Jpc2huYW4ncyBEaXNjdXNzIG9u
IGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXMtMTc6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQp
DQoNCkkgd291bGQgYWN0dWFsbHkgcHJlZmVyIG11bHRpcGxlIGV4YW1wbGVzIHRvIG9uZXMgd2l0
aCBqdXN0IElQdjYuIExpa2UgaXQgb3Igbm90LCB0aGVyZSBpcyBhIGh1Z2UgYW1vdW50IG9mIElQ
djQgSUNFIGFuZCBpdCB3b3VsZCBiZSBnb29kIGZvciB0aGUgZXhhbXBsZXMgdG8gbWF0Y2ggcmVh
bGl0eQ0KDQpPbiBXZWQsIEZlYiAyMSwgMjAxOCBhdCA5OjQ5IEFNLCBDaHJpc3RlciBIb2xtYmVy
ZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVy
Z0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpIFN1cmVzaCwNCg0KVGhhbmsgWW91IGZvciB0aGUg
cmV2aWV3IGFuZCBjb21tZW50cyEgUGxlYXNlIHNlZSBpbmxpbmUuDQoNCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N
CkRJU0NVU1M6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCj4gKiBTZWN0aW9uIDUuMi4gIExpdGUgSW1wbGVt
ZW50YXRpb24gUHJvY2VkdXJlcw0KPg0KPiAiRm9yIGR1YWwtc3RhY2sgaG9zdHMsIHRoZSBJUHY0
IGFkZHJlc3MgaXMgUkVDT01NRU5ERUQuIg0KPg0KPiBJIGFtIHRyeWluZyB0byB1bmRlcnN0YW5k
IHRoZSByZWFzb25pbmcgYmVoaW5kIHRoaXMgdW5lcXVpdm9jYWwgY2hvaWNlICh3aGljaCBwcm9i
YWJseSBtaWdodCBoYXZlIG1hZGUNCj4gc2Vuc2UgaW4gMjAxMCkuIEF0IGxlYXN0LCB0aGVyZSBp
cyBzb21lIGV4cGxhbmF0b3J5IHRleHQgcmVxdWlyZWQgdG8ganVzdGlmeSB0aGlzLg0KDQpUaGUg
dGV4dCBjYW1lIGZyb20gUkZDIDUyNDUuIEFzIGZhciBhcyBJIHJlbWVtYmVyLCBpdCB3YXMgbmV2
ZXIgZGlzY3Vzc2VkIGluIHRoZSBiaXMgd29yay4NCg0KSSBkb24ndCBoYXZlIGFueSBqdXN0aWZp
Y2F0aW9uIHRvIGtlZXAgdGhlIHRleHQsIHNvIEkgc3VnZ2VzdCB0byByZW1vdmUgaXQuDQoNCi0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCj4qIFNlY3Rpb24gMTUNCj4N
Cj5JdCB3b3VsZCBoYXZlIGJlZW4gZ29vZCB0byBoYXZlIGFuIGV4YW1wbGUgd2l0aCBJUHY2IGFk
ZHJlc3NlcyAoZnJvbSB0aGUNCj4yMDAxOmRiODo6LzMyIHNwYWNlKSBhcyB3ZWxsLg0KDQpJIGNh
biBtb2RpZnkgdGhlIGV4aXN0aW5nIGV4YW1wbGUgdG8gdXNlIElQdjYgYWRkcmVzc2VzLiBJIHNl
ZSBubyByZWFzb24gdG8gaGF2ZSB0byBjb3BpZXMgb2YgdGhlIHNhbWUgZXhhbXBsZSwgd2l0aCB0
aGUgSVAgdmVyc2lvbiBiZWluZyB0aGUgb25seSBkaWZmZXJlbmNlLg0KDQpSZWdhcmRzLA0KDQpD
aHJpc3Rlcg0KDQoNCg==

--_000_7594FB04B1934943A5C02806D1A2204B6C17B0A5ESESSMB109erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl
OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N
CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t
W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt
YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N
CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh
PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv
ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5PaywgSeKAmWxsIGxvb2sgaW50
byBpdCwgaWYgSSBjYW4gdXNlIGJvdGggSVB2NCBhbmQgSVB2NiBhZGRyZXNzZXMgaW4gdGhlIHNh
bWUgZXhhbXBsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2Fy
ZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5k
Q29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh
Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+
PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JA
cnRmbS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjEgRmVicnVhcnkgMjAxOCAyMDoxNTxicj4N
CjxiPlRvOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNz
c29uLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFN1cmVzaCBLcmlzaG5hbiAmbHQ7c3VyZXNoQGth
bG9vbS5jb20mZ3Q7OyBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDs7IGljZS1jaGFpcnNA
aWV0Zi5vcmc7IGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXNAaWV0Zi5vcmc7IHB0aGF0Y2hlckBn
b29nbGUuY29tOyBpY2VAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFN1cmVzaCBL
cmlzaG5hbidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpcy0xNzogKHdpdGgg
RElTQ1VTUyBhbmQgQ09NTUVOVCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5ObywgSSdkIHByZWZlciB5b3UgbGVhdmUgaXQgYXMtaXMsIG9yLCBhbHRlcm5hdGVseSwgYWRk
IHNvbWUgdGV4dCBzYXlpbmcgJnF1b3Q7b3IgdGhlc2UgY291bGQgYmUgdjYgYWRkcmVzc2VzJnF1
b3Q7LiBCdXQgaGF2aW5nIHRoZSBvbmx5IGV4YW1wbGUgYmUgdjYgaXMgbWlzbGVhZGluZy48bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZl
YiAyMSwgMjAxOCBhdCAxMDowNCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1h
aWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJp
c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N
CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND
IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu
LXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvLCB5b3Ugd2FudCBtZSB0byBjb3B5IHBhc3RlIHNl
Y3Rpb24gMTUgKHdoaWNoIGlzIDQsNSBwYWdlcyBsb25nKSwgYW5kIG9ubHkgY2hhbmdlIHRoZSBJ
UCBhZGRyZXNzZXM/DQogVGhlIElQIGFkZHJlc3NlcyBhcmUgb25seSBtZW50aW9uZWQgaW4gdGhl
IGludHJvZHVjdGlvbiB0ZXh0IOKAkyBpbiB0aGUgZmxvdyBldGMgdGhleSBhcmUgbm90IHNob3du
Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMs
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1f
LTgwNTE3NDg0NzgzMzY3NzcyNDJfX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+
PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBFcmljDQogUmVzY29ybGEgW21haWx0
bzo8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0u
Y29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyMSBGZWJydWFyeSAyMDE4IDE5OjUzPGJyPg0K
PGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVy
LmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJn
QGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBTdXJlc2ggS3Jpc2huYW4gJmx0
OzxhIGhyZWY9Im1haWx0bzpzdXJlc2hAa2Fsb29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN1cmVz
aEBrYWxvb20uY29tPC9hPiZndDs7IFRoZSBJRVNHICZsdDs8YSBocmVmPSJtYWlsdG86aWVzZ0Bp
ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmllc2dAaWV0Zi5vcmc8L2E+Jmd0OzsNCjxhIGhyZWY9
Im1haWx0bzppY2UtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWNlLWNoYWlyc0Bp
ZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzQGll
dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYu
b3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tIiB0YXJnZXQ9Il9i
bGFuayI+DQpwdGhhdGNoZXJAZ29vZ2xlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzppY2VAaWV0
Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8
L2I+IFJlOiBTdXJlc2ggS3Jpc2huYW4ncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtaWNlLXJmYzUy
NDViaXMtMTc6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB3b3VsZCBhY3R1YWxseSBwcmVm
ZXIgbXVsdGlwbGUgZXhhbXBsZXMgdG8gb25lcyB3aXRoIGp1c3QgSVB2Ni4gTGlrZSBpdCBvciBu
b3QsIHRoZXJlIGlzIGEgaHVnZSBhbW91bnQgb2YgSVB2NCBJQ0UgYW5kIGl0IHdvdWxkIGJlIGdv
b2QgZm9yIHRoZSBleGFtcGxlcyB0byBtYXRjaCByZWFsaXR5PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBGZWIgMjEsIDIwMTggYXQgOTo0
OSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xt
YmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmlj
c3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt
IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t
cmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBTdXJl
c2gsPGJyPg0KPGJyPg0KVGhhbmsgWW91IGZvciB0aGUgcmV2aWV3IGFuZCBjb21tZW50cyEgUGxl
YXNlIHNlZSBpbmxpbmUuPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCkRJU0NVU1M6PGJy
Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCiZndDsgKiBTZWN0aW9uIDUuMi4mbmJzcDsgTGl0
ZSBJbXBsZW1lbnRhdGlvbiBQcm9jZWR1cmVzPGJyPg0KJmd0Ozxicj4NCiZndDsgJnF1b3Q7Rm9y
IGR1YWwtc3RhY2sgaG9zdHMsIHRoZSBJUHY0IGFkZHJlc3MgaXMgUkVDT01NRU5ERUQuJnF1b3Q7
PGJyPg0KJmd0Ozxicj4NCiZndDsgSSBhbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUgcmVhc29u
aW5nIGJlaGluZCB0aGlzIHVuZXF1aXZvY2FsIGNob2ljZSAod2hpY2ggcHJvYmFibHkgbWlnaHQg
aGF2ZSBtYWRlPGJyPg0KJmd0OyBzZW5zZSBpbiAyMDEwKS4gQXQgbGVhc3QsIHRoZXJlIGlzIHNv
bWUgZXhwbGFuYXRvcnkgdGV4dCByZXF1aXJlZCB0byBqdXN0aWZ5IHRoaXMuPGJyPg0KPGJyPg0K
VGhlIHRleHQgY2FtZSBmcm9tIFJGQyA1MjQ1LiBBcyBmYXIgYXMgSSByZW1lbWJlciwgaXQgd2Fz
IG5ldmVyIGRpc2N1c3NlZCBpbiB0aGUgYmlzIHdvcmsuPGJyPg0KPGJyPg0KSSBkb24ndCBoYXZl
IGFueSBqdXN0aWZpY2F0aW9uIHRvIGtlZXAgdGhlIHRleHQsIHNvIEkgc3VnZ2VzdCB0byByZW1v
dmUgaXQuPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCkNPTU1FTlQ6PGJyPg0KLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLTxicj4NCjxicj4NCiZndDsqIFNlY3Rpb24gMTU8YnI+DQomZ3Q7PGJyPg0KJmd0O0l0
IHdvdWxkIGhhdmUgYmVlbiBnb29kIHRvIGhhdmUgYW4gZXhhbXBsZSB3aXRoIElQdjYgYWRkcmVz
c2VzIChmcm9tIHRoZTxicj4NCiZndDsyMDAxOmRiODo6LzMyIHNwYWNlKSBhcyB3ZWxsLjxicj4N
Cjxicj4NCkkgY2FuIG1vZGlmeSB0aGUgZXhpc3RpbmcgZXhhbXBsZSB0byB1c2UgSVB2NiBhZGRy
ZXNzZXMuIEkgc2VlIG5vIHJlYXNvbiB0byBoYXZlIHRvIGNvcGllcyBvZiB0aGUgc2FtZSBleGFt
cGxlLCB3aXRoIHRoZSBJUCB2ZXJzaW9uIGJlaW5nIHRoZSBvbmx5IGRpZmZlcmVuY2UuPGJyPg0K
PGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpDaHJpc3RlcjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j
a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_7594FB04B1934943A5C02806D1A2204B6C17B0A5ESESSMB109erics_--


From nobody Wed Feb 21 10:21:13 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9261241F8 for ; Wed, 21 Feb 2018 10:21:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 V2tvuP926VuW for ; Wed, 21 Feb 2018 10:21:09 -0800 (PST)
Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 019A61201F8 for ; Wed, 21 Feb 2018 10:21:09 -0800 (PST)
Received: by mail-qt0-x22b.google.com with SMTP id u6so3076730qtg.13 for ; Wed, 21 Feb 2018 10:21:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WMBBhfM4TZB2qpHVcv46WcLQxXFwzBcUBIiab1R9tLI=; b=cu5sYW+0kax7pU1cFmjWepbHp1rgKz8pWPpHVAz0AuZ6Elr9U6sISsjB3o7retzKzF du6B13IqFQeo1FYQFUCeONBJgD1gFXlzrp3++Wtx0BsUWaTdZON+D3BZPm8xYhj6RGSv CGsVZhuViPZPZkHmgfmSwvs2h0GhRTiHoidT7ugbT2/Y5cjQjiXO0ialbim18NoUm+zD 9F6VcvrYP3J5LrltPC/xAbDRYspPOk2rK8gBLpD/+HM8SOoRZjTkX4I2huWcj39UHk2H leav2d/Ue2A4vUIWk6xoFbYTIDyZy0sWFJBnJ36Y5UKLFpyIumHMPkE7RcA5aWe4Phx9 b/Ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WMBBhfM4TZB2qpHVcv46WcLQxXFwzBcUBIiab1R9tLI=; b=JhhV/EzSYlQd5Px5H5f5vUXkM9J1Y3W/AlcEcNWBhTd07ZCpXo8IZORyG8ycQa1jTU QMJlJ+yQYEbhlk0gk2OfI1sEtMpt4u81KCMZHUt/7UArxW0ZtaG3Hk29nNOUod/vzU3u s0cyO+WhiGG5EX2I8ov1yxHvsk/d68ad4tEi8mVnYG0cbP5qLssHDKb6IkS8NptifZm3 xl7MtCRL0B7HeuWRmO1xYuiN32u6Lt9QGxosT/GSjuCQDtVDaSCasoCEIbaRafzCplWS PpTFgXlSrglMg0cCuZw04YHD2NTVwVoOC3BQoPNtwX6G4YgT/CoBG9PJT6WUCntlqXF+ dW/w==
X-Gm-Message-State: APf1xPAoGWmD+rlKpbA4szPSgO3h0mtuA6zTCuu3/0kwSjUPQyxJ0USg K2U5mdxlwrVdo1GTD9jicNkzKZT9o142GkwyYOB/yQ==
X-Google-Smtp-Source: AH8x224fpv6KViihu+5Wzd2ADlz1X1kzJ9LNFkDWeIbL1ea0Vms/OeH+1PwwWkTGrOp2lK/QNKLDBBK9FKy1Wu+oPms=
X-Received: by 10.237.44.99 with SMTP id f90mr6792889qtd.80.1519236947372; Wed, 21 Feb 2018 10:15:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Wed, 21 Feb 2018 10:15:06 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C17B031@ESESSMB109.ericsson.se>
References: <151918940727.9623.17348873149297319051.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C17AFDF@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C17B031@ESESSMB109.ericsson.se>
From: Eric Rescorla 
Date: Wed, 21 Feb 2018 10:15:06 -0800
Message-ID: 
To: Christer Holmberg 
Cc: Suresh Krishnan , The IESG ,  "ice-chairs@ietf.org" ,  "draft-ietf-ice-rfc5245bis@ietf.org" ,  "pthatcher@google.com" , "ice@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c06375a9401e80565bceac2"
Archived-At: 
Subject: Re: [Ice] Suresh Krishnan's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Feb 2018 18:21:11 -0000

--94eb2c06375a9401e80565bceac2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

No, I'd prefer you leave it as-is, or, alternately, add some text saying
"or these could be v6 addresses". But having the only example be v6 is
misleading.

-Ekr


On Wed, Feb 21, 2018 at 10:04 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> So, you want me to copy paste section 15 (which is 4,5 pages long), and
> only change the IP addresses? The IP addresses are only mentioned in the
> introduction text =E2=80=93 in the flow etc they are not shown.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Eric Rescorla [mailto:ekr@rtfm.com]
> *Sent:* 21 February 2018 19:53
> *To:* Christer Holmberg 
> *Cc:* Suresh Krishnan ; The IESG ;
> ice-chairs@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org;
> pthatcher@google.com; ice@ietf.org
> *Subject:* Re: Suresh Krishnan's Discuss on draft-ietf-ice-rfc5245bis-17:
> (with DISCUSS and COMMENT)
>
>
>
> I would actually prefer multiple examples to ones with just IPv6. Like it
> or not, there is a huge amount of IPv4 ICE and it would be good for the
> examples to match reality
>
>
>
> On Wed, Feb 21, 2018 at 9:49 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> Hi Suresh,
>
> Thank You for the review and comments! Please see inline.
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> > * Section 5.2.  Lite Implementation Procedures
> >
> > "For dual-stack hosts, the IPv4 address is RECOMMENDED."
> >
> > I am trying to understand the reasoning behind this unequivocal choice
> (which probably might have made
> > sense in 2010). At least, there is some explanatory text required to
> justify this.
>
> The text came from RFC 5245. As far as I remember, it was never discussed
> in the bis work.
>
> I don't have any justification to keep the text, so I suggest to remove i=
t.
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> >* Section 15
> >
> >It would have been good to have an example with IPv6 addresses (from the
> >2001:db8::/32 space) as well.
>
> I can modify the existing example to use IPv6 addresses. I see no reason
> to have to copies of the same example, with the IP version being the only
> difference.
>
> Regards,
>
> Christer
>
>
>

--94eb2c06375a9401e80565bceac2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


No, I'd prefer you leave it as-is, or, alternately, ad=
d some text saying "or these could be v6 addresses". But having t=
he only example be v6 is misleading.

-Ekr

=


On We=
d, Feb 21, 2018 at 10:04 AM, Christer Holmberg <christer.holm=
berg@ericsson.com> wrote:











So, you want me to copy paste section=
 15 (which is 4,5 pages long), and only change the IP addresses? The IP add=
resses are only mentioned
 in the introduction text =E2=80=93 in the flow etc they are not shown.<=
/u>


=C2=A0


Regards,


=C2=A0


Christer


<=
span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c=
olor:#1f497d">=C2=A0


From: =
Eric Rescorla [mailto:ekr=
@rtfm.com]


Sent: 21 February 2018 19:53

To: Christer Holmberg <christer.holmberg@ericsson.com>

Cc: Suresh Krishnan <suresh@kaloom.com>; The IESG <iesg@ietf.org>; ice-chairs@ietf.org; draft-ietf-ice-rfc52=
45bis@ietf.org; pthatcher@google.com; ice@ietf.org

Subject: Re: Suresh Krishnan's Discuss on draft-ietf-ice-rfc5245=
bis-17: (with DISCUSS and COMMENT)


=C2=A0




I would actually prefer multiple examples to ones wi=
th just IPv6. Like it or not, there is a huge amount of IPv4 ICE and it wou=
ld be good for the examples to match reality






=C2=A0




On Wed, Feb 21, 2018 at 9:49 AM, Christer Holmberg &=
lt;chri=
ster.holmberg@ericsson.com> wrote:




Hi Suresh,



Thank You for the review and comments! Please see inline.



-----------------------------------------------------------------=
-----

DISCUSS:

-----------------------------------------------------------------=
-----



> * Section 5.2.=C2=A0 Lite Implementation Procedures

>

> "For dual-stack hosts, the IPv4 address is RECOMMENDED."

>

> I am trying to understand the reasoning behind this unequivocal choice=
 (which probably might have made

> sense in 2010). At least, there is some explanatory text required to j=
ustify this.



The text came from RFC 5245. As far as I remember, it was never discussed i=
n the bis work.



I don't have any justification to keep the text, so I suggest to remove=
 it.



-----------------------------------------------------------------=
-----

COMMENT:

-----------------------------------------------------------------=
-----



>* Section 15

>

>It would have been good to have an example with IPv6 addresses (from th=
e

>2001:db8::/32 space) as well.



I can modify the existing example to use IPv6 addresses. I see no reason to=
 have to copies of the same example, with the IP version being the only dif=
ference.



Regards,



Christer










=C2=A0












--94eb2c06375a9401e80565bceac2--


From nobody Wed Feb 21 11:19:50 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655AF1289B0; Wed, 21 Feb 2018 11:19:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kaloom.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3Uci1k07u8A; Wed, 21 Feb 2018 11:19:46 -0800 (PST)
Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660090.outbound.protection.outlook.com [40.107.66.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9FF124BAC; Wed, 21 Feb 2018 11:19:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kaloom.onmicrosoft.com; s=selector1-kaloom-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=950RyqIfjEhVkDZVW8Z09lWiTaN2XeyE7VJJ8U3pBkc=; b=if+tEPuOGKFGXnv3dM5/PqniaVO6GSX8OKiXHugBdApSfy1RfW1JRt4cxfzPpaS1azFTkZqdWrOGTpA27sSuHou/NL9kAaL2L0y9NFZL2/pSsunO6o77GOm12Yh3Bv1HJuM9DzIn5MAKkX3iIlUo3ShdNLtambYd+yr16OYrwUw=
Received: from YQXPR0101MB2054.CANPRD01.PROD.OUTLOOK.COM (52.132.77.143) by YQXPR0101MB0966.CANPRD01.PROD.OUTLOOK.COM (52.132.76.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Wed, 21 Feb 2018 19:19:44 +0000
Received: from YQXPR0101MB2054.CANPRD01.PROD.OUTLOOK.COM ([fe80::2903:f315:10e0:c9c9]) by YQXPR0101MB2054.CANPRD01.PROD.OUTLOOK.COM ([fe80::2903:f315:10e0:c9c9%13]) with mapi id 15.20.0506.023; Wed, 21 Feb 2018 19:19:44 +0000
From: Suresh Krishnan 
To: Christer Holmberg 
CC: Eric Rescorla , The IESG , "ice-chairs@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , "pthatcher@google.com" , "ice@ietf.org" 
Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
Thread-Index: AQHTqtFQPV6g3lZs5kCk61sA9woFcKOu9TzwgAAu3QCAAAMmAIAAAusAgAAAogCAABFhAA==
Date: Wed, 21 Feb 2018 19:19:44 +0000
Message-ID: <4F7BA3CF-AF3D-471A-B576-FD43A737CBA2@kaloom.com>
References: <151918940727.9623.17348873149297319051.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C17AFDF@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C17B031@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C17B0A5@ESESSMB109.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C17B0A5@ESESSMB109.ericsson.se>
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=Suresh@kaloom.com; 
x-originating-ip: [45.19.110.76]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; YQXPR0101MB0966; 6:zZuhuf96RVXR+TojQ/+E4dV65imvFo/CD57bfPoD5lzLRXO+13kHjlYPYSzpfB2gYHoAy2tqeXc38HtHO2JupZjFnnzFFNmq8lMmIqUGbv5ueTZfX6eIUsOVEeLJjr7pvz6f4qz6al9VAmhp5Q+CDs9c+ZnJPDthSV1RLainzMMmmb8O0pUpDFG+P+8EpSvlv5pTv03QTWZ/dHAiT3nfPs9LC0o5qd4411JfIT/kF1FodjQ4Uxt3TgYknYPVIwQHwxaAmbwZSd81mdWyyYErESARXOuSMV3ixN0/2kEIkej+Bu+1V4Dg1wyNlbDthdR3DurYeE/Sko6KZixHD8A2fZOBrr0KC+o5apAWpyIyE/+98UZs8KDUCqPNAcR57eCx; 5:2mU+a0KkAUWZl6WO205KBQkV6Cj8+sIR9ey1n9HGlqcvCurmIRMLfCUxEdwCFGw2lZgMryS9U1tlThNrQuP96pSgFCNpdt1YvgGjqpbJd3f3TVMbdIgezp3rbu57i9OOB8oVw9zm9PgJtQ3DFEVu7idG3D4C4OQGM0QaqspkB+A=; 24:m8ttW6OAWJMjZU5BWI4nZRs/tlIUU3mpZ+yFYcAR+xsS8+PZBsJ+Et8ZmXYrjPaoZ6tyx77tXX8Y0Wx4RpJGwb92cNjQC61VLxupviqJ3rA=; 7:8KGY2OOsoDrekBeXGm0dDSReBNuy9Sf1a3dKGD8O/c/ExrYPAYhQte0y6kyjL5Cf+K7grfsX20S0WPOwD+1U2KpAUUneTCXphR+oR8ZY8cA+8svXevGSLqPdwnNWjOODIil2xnLCBCYAzUW+YpJ34Q1UPhbQdC9ErtnY5cl6Pzb5Ztqf7a0nK9QCfzIgW9g5FFau2hijiKv0lyBxv5Us/MnMkoXD96yke7Fic3G3+oGUS3SNf06MATFO7XjaVakN
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 498e729b-f9c7-4d74-7cf4-08d5796010af
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:YQXPR0101MB0966; 
x-ms-traffictypediagnostic: YQXPR0101MB0966:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(37575265505322)(211936372134217);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231101)(944501161)(93006095)(93001095)(6041288)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(2016111802025)(6043046)(6072148)(201708071742011); SRVR:YQXPR0101MB0966; BCL:0; PCL:0; RULEID:; SRVR:YQXPR0101MB0966; 
x-forefront-prvs: 0590BBCCBC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(366004)(376002)(346002)(39830400003)(189003)(199004)(6506007)(68736007)(102836004)(7736002)(53546011)(26005)(105586002)(106356001)(81156014)(8676002)(81166006)(5250100002)(8936002)(80792005)(97736004)(66066001)(99286004)(82746002)(72206003)(86362001)(83716003)(478600001)(4326008)(25786009)(186003)(54906003)(316002)(53936002)(345774005)(3846002)(6116002)(5660300001)(76176011)(6246003)(2906002)(236005)(6486002)(54896002)(6436002)(6512007)(2950100002)(229853002)(36756003)(2900100001)(14454004)(33656002)(93886005)(3280700002)(6916009)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:YQXPR0101MB0966; H:YQXPR0101MB2054.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: kaloom.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: Cdy36Wpz6dNmMoNDbPCykjY7GUdKypMjV3JEHLH8E7TXgTzuuFARsdrc2mDAMK2HNCi9QNZsP+l5uoS3qopNGyD/50BCbS0+atp7Qd4h9KNc0vYpLTxGtZtj5DstYM/wM8EVSyq7ow22zxOnIkeyBOK2Baz7GXDq+WAa29h3DcE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_4F7BA3CFAF3D471AB576FD43A737CBA2kaloomcom_"
MIME-Version: 1.0
X-OriginatorOrg: kaloom.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 498e729b-f9c7-4d74-7cf4-08d5796010af
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2018 19:19:44.5769 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 47d58e26-f796-48e8-ac40-1c365c204513
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR0101MB0966
Archived-At: 
Subject: Re: [Ice] Suresh Krishnan's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Feb 2018 19:19:48 -0000

--_000_4F7BA3CFAF3D471AB576FD43A737CBA2kaloomcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQ2hyaXN0ZXIsDQogIFllcy4gTGlrZSBla3IsIEkgd291bGQgYWxzbyBwcmVmZXIgdG8gaGF2
ZSBleGFtcGxlcyBpbiBib3RoIGFkZHJlc3MgZmFtaWxpZXMgaWYgcG9zc2libGUuIEZvciBJUHY2
LCBJIHdhcyBtYWlubHkgdGhpbmtpbmcgb2YgaGF2aW5nIGEgbm9uLU5BVCBleGFtcGxlIChhcyBO
QVRzIGFyZSBub3QgY3VycmVudGx5IGNvbW1vbiB3aXRoIElQdjYpIHdpdGggcGVyaGFwcyBhIGZp
cmV3YWxsIGluc3RlYWQgb24gYm90aCBlbmRzLg0KDQpUaGFua3MNClN1cmVzaA0KDQpPbiBGZWIg
MjEsIDIwMTgsIGF0IDE6MTcgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVy
Z0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdy
b3RlOg0KDQpPaywgSeKAmWxsIGxvb2sgaW50byBpdCwgaWYgSSBjYW4gdXNlIGJvdGggSVB2NCBh
bmQgSVB2NiBhZGRyZXNzZXMgaW4gdGhlIHNhbWUgZXhhbXBsZS4NCg0KUmVnYXJkcywNCg0KQ2hy
aXN0ZXINCg0KRnJvbTogRXJpYyBSZXNjb3JsYSBbbWFpbHRvOmVrckBydGZtLmNvbV0NClNlbnQ6
IDIxIEZlYnJ1YXJ5IDIwMTggMjA6MTUNClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIu
aG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j
b20+Pg0KQ2M6IFN1cmVzaCBLcmlzaG5hbiA8c3VyZXNoQGthbG9vbS5jb208bWFpbHRvOnN1cmVz
aEBrYWxvb20uY29tPj47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGlldGYu
b3JnPj47IGljZS1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmljZS1jaGFpcnNAaWV0Zi5vcmc+OyBk
cmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWljZS1y
ZmM1MjQ1YmlzQGlldGYub3JnPjsgcHRoYXRjaGVyQGdvb2dsZS5jb208bWFpbHRvOnB0aGF0Y2hl
ckBnb29nbGUuY29tPjsgaWNlQGlldGYub3JnPG1haWx0bzppY2VAaWV0Zi5vcmc+DQpTdWJqZWN0
OiBSZTogU3VyZXNoIEtyaXNobmFuJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1
YmlzLTE3OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQpObywgSSdkIHByZWZlciB5b3Ug
bGVhdmUgaXQgYXMtaXMsIG9yLCBhbHRlcm5hdGVseSwgYWRkIHNvbWUgdGV4dCBzYXlpbmcgIm9y
IHRoZXNlIGNvdWxkIGJlIHY2IGFkZHJlc3NlcyIuIEJ1dCBoYXZpbmcgdGhlIG9ubHkgZXhhbXBs
ZSBiZSB2NiBpcyBtaXNsZWFkaW5nLg0KDQotRWtyDQoNCg0KT24gV2VkLCBGZWIgMjEsIDIwMTgg
YXQgMTA6MDQgQU0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv
bi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KU28s
IHlvdSB3YW50IG1lIHRvIGNvcHkgcGFzdGUgc2VjdGlvbiAxNSAod2hpY2ggaXMgNCw1IHBhZ2Vz
IGxvbmcpLCBhbmQgb25seSBjaGFuZ2UgdGhlIElQIGFkZHJlc3Nlcz8gVGhlIElQIGFkZHJlc3Nl
cyBhcmUgb25seSBtZW50aW9uZWQgaW4gdGhlIGludHJvZHVjdGlvbiB0ZXh0IOKAkyBpbiB0aGUg
ZmxvdyBldGMgdGhleSBhcmUgbm90IHNob3duLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpG
cm9tOiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5j
b20+XQ0KU2VudDogMjEgRmVicnVhcnkgMjAxOCAxOTo1Mw0KVG86IENocmlzdGVyIEhvbG1iZXJn
IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJn
QGVyaWNzc29uLmNvbT4+DQpDYzogU3VyZXNoIEtyaXNobmFuIDxzdXJlc2hAa2Fsb29tLmNvbTxt
YWlsdG86c3VyZXNoQGthbG9vbS5jb20+PjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc8bWFpbHRv
Omllc2dAaWV0Zi5vcmc+PjsgaWNlLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86aWNlLWNoYWlyc0Bp
ZXRmLm9yZz47IGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXNAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0
LWlldGYtaWNlLXJmYzUyNDViaXNAaWV0Zi5vcmc+OyBwdGhhdGNoZXJAZ29vZ2xlLmNvbTxtYWls
dG86cHRoYXRjaGVyQGdvb2dsZS5jb20+OyBpY2VAaWV0Zi5vcmc8bWFpbHRvOmljZUBpZXRmLm9y
Zz4NClN1YmplY3Q6IFJlOiBTdXJlc2ggS3Jpc2huYW4ncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt
aWNlLXJmYzUyNDViaXMtMTc6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQoNCkkgd291bGQg
YWN0dWFsbHkgcHJlZmVyIG11bHRpcGxlIGV4YW1wbGVzIHRvIG9uZXMgd2l0aCBqdXN0IElQdjYu
IExpa2UgaXQgb3Igbm90LCB0aGVyZSBpcyBhIGh1Z2UgYW1vdW50IG9mIElQdjQgSUNFIGFuZCBp
dCB3b3VsZCBiZSBnb29kIGZvciB0aGUgZXhhbXBsZXMgdG8gbWF0Y2ggcmVhbGl0eQ0KDQpPbiBX
ZWQsIEZlYiAyMSwgMjAxOCBhdCA5OjQ5IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIu
aG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j
b20+PiB3cm90ZToNCkhpIFN1cmVzaCwNCg0KVGhhbmsgWW91IGZvciB0aGUgcmV2aWV3IGFuZCBj
b21tZW50cyEgUGxlYXNlIHNlZSBpbmxpbmUuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkRJU0NVU1M6DQot
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tDQoNCj4gKiBTZWN0aW9uIDUuMi4gIExpdGUgSW1wbGVtZW50YXRpb24gUHJv
Y2VkdXJlcw0KPg0KPiAiRm9yIGR1YWwtc3RhY2sgaG9zdHMsIHRoZSBJUHY0IGFkZHJlc3MgaXMg
UkVDT01NRU5ERUQuIg0KPg0KPiBJIGFtIHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSByZWFzb25p
bmcgYmVoaW5kIHRoaXMgdW5lcXVpdm9jYWwgY2hvaWNlICh3aGljaCBwcm9iYWJseSBtaWdodCBo
YXZlIG1hZGUNCj4gc2Vuc2UgaW4gMjAxMCkuIEF0IGxlYXN0LCB0aGVyZSBpcyBzb21lIGV4cGxh
bmF0b3J5IHRleHQgcmVxdWlyZWQgdG8ganVzdGlmeSB0aGlzLg0KDQpUaGUgdGV4dCBjYW1lIGZy
b20gUkZDIDUyNDUuIEFzIGZhciBhcyBJIHJlbWVtYmVyLCBpdCB3YXMgbmV2ZXIgZGlzY3Vzc2Vk
IGluIHRoZSBiaXMgd29yay4NCg0KSSBkb24ndCBoYXZlIGFueSBqdXN0aWZpY2F0aW9uIHRvIGtl
ZXAgdGhlIHRleHQsIHNvIEkgc3VnZ2VzdCB0byByZW1vdmUgaXQuDQoNCi0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N
CkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCj4qIFNlY3Rpb24gMTUNCj4NCj5JdCB3b3VsZCBo
YXZlIGJlZW4gZ29vZCB0byBoYXZlIGFuIGV4YW1wbGUgd2l0aCBJUHY2IGFkZHJlc3NlcyAoZnJv
bSB0aGUNCj4yMDAxOmRiODo6LzMyIHNwYWNlKSBhcyB3ZWxsLg0KDQpJIGNhbiBtb2RpZnkgdGhl
IGV4aXN0aW5nIGV4YW1wbGUgdG8gdXNlIElQdjYgYWRkcmVzc2VzLiBJIHNlZSBubyByZWFzb24g
dG8gaGF2ZSB0byBjb3BpZXMgb2YgdGhlIHNhbWUgZXhhbXBsZSwgd2l0aCB0aGUgSVAgdmVyc2lv
biBiZWluZyB0aGUgb25seSBkaWZmZXJlbmNlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo=

--_000_4F7BA3CFAF3D471AB576FD43A737CBA2kaloomcom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SGkgQ2hyaXN0ZXIsPC9k
aXY+DQombmJzcDsgWWVzLiBMaWtlIGVrciwgSSB3b3VsZCBhbHNvIHByZWZlciB0byBoYXZlIGV4
YW1wbGVzIGluIGJvdGggYWRkcmVzcyBmYW1pbGllcyBpZiBwb3NzaWJsZS4gRm9yIElQdjYsIEkg
d2FzIG1haW5seSB0aGlua2luZyBvZiBoYXZpbmcgYSBub24tTkFUIGV4YW1wbGUgKGFzIE5BVHMg
YXJlIG5vdCBjdXJyZW50bHkgY29tbW9uIHdpdGggSVB2Nikgd2l0aCBwZXJoYXBzIGEgZmlyZXdh
bGwgaW5zdGVhZCBvbiBib3RoIGVuZHMuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv
ZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3M8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U3VyZXNoPGJy
IGNsYXNzPSIiPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj
bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gRmViIDIxLCAyMDE4LCBhdCAxOjE3IFBNLCBDaHJp
c3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNz
c29uLmNvbSIgY2xhc3M9IiI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsg
d3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRp
diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRT
ZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0
eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt
YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu
dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z
cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHls
ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5
OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBz
dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg
Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5PaywgSeKAmWxsIGxvb2sgaW50byBp
dCwgaWYgSSBjYW4gdXNlIGJvdGggSVB2NCBhbmQgSVB2NiBhZGRyZXNzZXMgaW4gdGhlIHNhbWUg
ZXhhbXBsZS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h
cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1
b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y
OiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48
L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt
c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2Vy
aWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5
OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIi
PlJlZ2FyZHMsPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt
YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZx
dW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl
PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv
cjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250
LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNl
cmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls
eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0i
Ij5DaHJpc3RlcjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i
bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAm
cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8YSBuYW1lPSJf
TWFpbEVuZENvbXBvc2UiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv
bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi
IGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L2Rpdj4NCjxk
aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250
LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0K
PGIgY2xhc3M9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv
bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+RnJvbTo8L3NwYW4+PC9i
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog
Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5FcmljIFJlc2NvcmxhDQogWzxhIGhyZWY9Im1haWx0bzpl
a3JAcnRmbS5jb20iIGNsYXNzPSIiPm1haWx0bzpla3JAcnRmbS5jb208L2E+XTxzcGFuIGNsYXNz
PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8YiBj
bGFzcz0iIj5TZW50OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz
cDs8L3NwYW4+MjEgRmVicnVhcnkgMjAxOCAyMDoxNTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIi
PlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+
Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Bl
cmljc3Nvbi5jb20iIGNsYXNzPSIiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4m
Z3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1j
b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5TdXJlc2ggS3Jpc2huYW4gJmx0OzxhIGhyZWY9
Im1haWx0bzpzdXJlc2hAa2Fsb29tLmNvbSIgY2xhc3M9IiI+c3VyZXNoQGthbG9vbS5jb208L2E+
Jmd0OzsgVGhlIElFU0cgJmx0OzxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3JnIiBjbGFzcz0i
Ij5pZXNnQGlldGYub3JnPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86aWNlLWNoYWlyc0BpZXRm
Lm9yZyIgY2xhc3M9IiI+aWNlLWNoYWlyc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpk
cmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYub3JnIiBjbGFzcz0iIj4NCmRyYWZ0LWlldGYt
aWNlLXJmYzUyNDViaXNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86cHRoYXRjaGVyQGdv
b2dsZS5jb20iIGNsYXNzPSIiPg0KcHRoYXRjaGVyQGdvb2dsZS5jb208L2E+OyA8YSBocmVmPSJt
YWlsdG86aWNlQGlldGYub3JnIiBjbGFzcz0iIj5pY2VAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIi
Pg0KPGIgY2xhc3M9IiI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBTdXJlc2ggS3Jpc2huYW4ncyBEaXNjdXNzIG9uIGRyYWZ0
LWlldGYtaWNlLXJmYzUyNDViaXMtMTc6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpPG86cCBj
bGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g
MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBS
b21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+
PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw
MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m
cXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQpObywgSSdkIHByZWZlciB5b3UgbGVhdmUgaXQgYXMt
aXMsIG9yLCBhbHRlcm5hdGVseSwgYWRkIHNvbWUgdGV4dCBzYXlpbmcgJnF1b3Q7b3IgdGhlc2Ug
Y291bGQgYmUgdjYgYWRkcmVzc2VzJnF1b3Q7LiBCdXQgaGF2aW5nIHRoZSBvbmx5IGV4YW1wbGUg
YmUgdjYgaXMgbWlzbGVhZGluZy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFz
cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx
MnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNs
YXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj
bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl
OiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsi
IGNsYXNzPSIiPg0KLUVrcjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYg
Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6
ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7
IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw
dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1
b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4N
CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv
bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywg
c2VyaWY7IiBjbGFzcz0iIj4NCk9uIFdlZCwgRmViIDIxLCAyMDE4IGF0IDEwOjA0IEFNLCBDaHJp
c3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNz
c29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29y
YXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv
bTwvYT4mZ3Q7IHdyb3RlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8YmxvY2txdW90ZSBz
dHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtd2lk
dGg6IDFwdDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZzog
MGNtIDBjbSAwY20gNnB0OyBtYXJnaW4tbGVmdDogNC44cHQ7IG1hcmdpbi1yaWdodDogMGNtOyIg
Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h
cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1
b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9y
OiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+U28sIHlvdSB3YW50IG1lIHRvIGNvcHkgcGFz
dGUgc2VjdGlvbiAxNSAod2hpY2ggaXMgNCw1IHBhZ2VzIGxvbmcpLCBhbmQgb25seSBjaGFuZ2Ug
dGhlIElQIGFkZHJlc3Nlcz8gVGhlIElQIGFkZHJlc3NlcyBhcmUgb25seSBtZW50aW9uZWQgaW4g
dGhlIGludHJvZHVjdGlvbg0KIHRleHQg4oCTIGluIHRoZSBmbG93IGV0YyB0aGV5IGFyZSBub3Qg
c2hvd24uPC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn
aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90
O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm
b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjog
cmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwv
bzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp
emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlm
OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog
Q2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5S
ZWdhcmRzLDwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy
Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVv
dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i
Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6
IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48
L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z
aXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJp
ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6
IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+
Q2hyaXN0ZXI8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h
cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1
b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPGEgbmFtZT0ibV8t
ODA1MTc0ODQ3ODMzNjc3NzI0Ml9fTWFpbEVuZENvbXBvc2UiIGNsYXNzPSIiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv
cjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2E+PG86cCBjbGFz
cz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg
Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7
LCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh
c3M9IiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxzcGFu
IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5FcmljIFJlc2Nvcmxh
DQogW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayIg
c3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9
IiI+ZWtyQHJ0Zm0uY29tPC9hPl08c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U2VudDo8L2I+PHNwYW4gY2xh
c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjIxIEZlYnJ1YXJ5IDIwMTgg
MTk6NTM8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkNocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBo
cmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFu
ayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xh
c3M9IiI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+
DQo8YiBjbGFzcz0iIj5DYzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+
Jm5ic3A7PC9zcGFuPlN1cmVzaCBLcmlzaG5hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1cmVzaEBr
YWxvb20uY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVj
b3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+c3VyZXNoQGthbG9vbS5jb208L2E+Jmd0Ozsg
VGhlIElFU0cgJmx0OzxhIGhyZWY9Im1haWx0bzppZXNnQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu
ayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xh
c3M9IiI+aWVzZ0BpZXRmLm9yZzwvYT4mZ3Q7OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86aWNlLWNoYWlyc0BpZXRmLm9yZyIg
dGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVu
ZGVybGluZTsiIGNsYXNzPSIiPmljZS1jaGFpcnNAaWV0Zi5vcmc8L2E+OzxzcGFuIGNsYXNzPSJB
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZHJhZnQt
aWV0Zi1pY2UtcmZjNTI0NWJpc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xv
cjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmRyYWZ0LWll
dGYtaWNlLXJmYzUyNDViaXNAaWV0Zi5vcmc8L2E+OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86cHRoYXRjaGVyQGdvb2dsZS5j
b20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9u
OiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5wdGhhdGNoZXJAZ29vZ2xlLmNvbTwvYT47PHNwYW4gY2xh
c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpp
Y2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1k
ZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5pY2VAaWV0Zi5vcmc8L2E+PGJyIGNsYXNz
PSIiPg0KPGIgY2xhc3M9IiI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl
ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBTdXJlc2ggS3Jpc2huYW4ncyBEaXNjdXNzIG9uIGRy
YWZ0LWlldGYtaWNlLXJmYzUyNDViaXMtMTc6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpPC9z
cGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz
cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx
MnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNs
YXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+
DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg
Zm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0i
Ij4NCkkgd291bGQgYWN0dWFsbHkgcHJlZmVyIG11bHRpcGxlIGV4YW1wbGVzIHRvIG9uZXMgd2l0
aCBqdXN0IElQdjYuIExpa2UgaXQgb3Igbm90LCB0aGVyZSBpcyBhIGh1Z2UgYW1vdW50IG9mIElQ
djQgSUNFIGFuZCBpdCB3b3VsZCBiZSBnb29kIGZvciB0aGUgZXhhbXBsZXMgdG8gbWF0Y2ggcmVh
bGl0eTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8
ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u
dC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4N
CiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz
dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt
aWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQpPbiBX
ZWQsIEZlYiAyMSwgMjAxOCBhdCA5OjQ5IEFNLCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsi
IHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNz
PSIiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnAgY2xh
c3M9IiI+PC9vOnA+PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25l
IG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtd2lkdGg6IDFwdDsgYm9yZGVyLWxlZnQtY29s
b3I6IHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZzogMGNtIDBjbSAwY20gNnB0OyBtYXJnaW46
IDVwdCAwY20gNXB0IDQuOHB0OyIgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luOiAwY20gMGNtIDEycHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZx
dW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7Ij4NCkhpIFN1cmVzaCw8YnIgY2xhc3M9
IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGFuayBZb3UgZm9yIHRoZSByZXZpZXcgYW5kIGNvbW1lbnRz
ISBQbGVhc2Ugc2VlIGlubGluZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tPGJyIGNsYXNzPSIiPg0KRElTQ1VTUzo8YnIgY2xhc3M9IiI+DQotLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJmd0OyAqIFNlY3Rpb24gNS4yLiZuYnNwOyBM
aXRlIEltcGxlbWVudGF0aW9uIFByb2NlZHVyZXM8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNz
PSIiPg0KJmd0OyAmcXVvdDtGb3IgZHVhbC1zdGFjayBob3N0cywgdGhlIElQdjQgYWRkcmVzcyBp
cyBSRUNPTU1FTkRFRC4mcXVvdDs8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0
OyBJIGFtIHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSByZWFzb25pbmcgYmVoaW5kIHRoaXMgdW5l
cXVpdm9jYWwgY2hvaWNlICh3aGljaCBwcm9iYWJseSBtaWdodCBoYXZlIG1hZGU8YnIgY2xhc3M9
IiI+DQomZ3Q7IHNlbnNlIGluIDIwMTApLiBBdCBsZWFzdCwgdGhlcmUgaXMgc29tZSBleHBsYW5h
dG9yeSB0ZXh0IHJlcXVpcmVkIHRvIGp1c3RpZnkgdGhpcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xh
c3M9IiI+DQpUaGUgdGV4dCBjYW1lIGZyb20gUkZDIDUyNDUuIEFzIGZhciBhcyBJIHJlbWVtYmVy
LCBpdCB3YXMgbmV2ZXIgZGlzY3Vzc2VkIGluIHRoZSBiaXMgd29yay48YnIgY2xhc3M9IiI+DQo8
YnIgY2xhc3M9IiI+DQpJIGRvbid0IGhhdmUgYW55IGp1c3RpZmljYXRpb24gdG8ga2VlcCB0aGUg
dGV4dCwgc28gSSBzdWdnZXN0IHRvIHJlbW92ZSBpdC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9
IiI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tPGJyIGNsYXNzPSIiPg0KQ09NTUVOVDo8YnIgY2xhc3M9IiI+DQot
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJmd0OyogU2VjdGlvbiAx
NTxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7SXQgd291bGQgaGF2ZSBiZWVu
IGdvb2QgdG8gaGF2ZSBhbiBleGFtcGxlIHdpdGggSVB2NiBhZGRyZXNzZXMgKGZyb20gdGhlPGJy
IGNsYXNzPSIiPg0KJmd0OzIwMDE6ZGI4OjovMzIgc3BhY2UpIGFzIHdlbGwuPGJyIGNsYXNzPSIi
Pg0KPGJyIGNsYXNzPSIiPg0KSSBjYW4gbW9kaWZ5IHRoZSBleGlzdGluZyBleGFtcGxlIHRvIHVz
ZSBJUHY2IGFkZHJlc3Nlcy4gSSBzZWUgbm8gcmVhc29uIHRvIGhhdmUgdG8gY29waWVzIG9mIHRo
ZSBzYW1lIGV4YW1wbGUsIHdpdGggdGhlIElQIHZlcnNpb24gYmVpbmcgdGhlIG9ubHkgZGlmZmVy
ZW5jZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSZWdhcmRzLDxiciBjbGFzcz0iIj4N
CjxiciBjbGFzcz0iIj4NCkNocmlzdGVyPC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFz
cz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_4F7BA3CFAF3D471AB576FD43A737CBA2kaloomcom_--


From nobody Wed Feb 21 11:31:06 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7BB12DA0C for ; Wed, 21 Feb 2018 11:31:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1nr-HHCWwz1 for ; Wed, 21 Feb 2018 11:31:02 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B133212DA02 for ; Wed, 21 Feb 2018 11:30:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519241451; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=S62qvHe7mG5S7lbb0s0CY9XBph/aIEpMOF/VHJjGXXw=; b=dxefQ2Ler32oPeT2srwd/HiL4GnZyhlkbjJ+sz7gJyEhZAHkPKvo38xo5djq+evp c6yVR8QnlC2kmWXKCUwvBz1er4ZG63h7/r5uhr6/LkS7ypYC8/kEoalbzaRI8CMf hrWvC35Rokv2TGrFZZyCqYsjMdxtyUghhgffi3+XtHs=;
X-AuditID: c1b4fb25-06bff70000002d5f-0b-5a8dc8eb9c4b
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 88.27.11615.BE8CD8A5; Wed, 21 Feb 2018 20:30:51 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Wed, 21 Feb 2018 20:30:51 +0100
From: Christer Holmberg 
To: Benjamin Kaduk , IESG 
CC: "draft-ietf-ice-rfc5245bis@ietf.org" ,  "ice-chairs@ietf.org" , "pthatcher@google.com" , "ice@ietf.org" 
Thread-Topic: Benjamin Kaduk's practice ballot on draft-ietf-ice-rfc5245bis-17: (with COMMENT)
Thread-Index: AQHTqpYy9FJdDoYDFk2qXCr+ZyLyBKOvKTtA
Date: Wed, 21 Feb 2018 19:30:50 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C17B1A8@ESESSMB109.ericsson.se>
References: <20180220220002.GS54688@mit.edu>
In-Reply-To: <20180220220002.GS54688@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.172]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7je7rE71RBk/uWlvMP3md2eLirMls Ft8u1FrM+DOR2WL5xplMFteWv2Z1YPNYsKnUY8mSn0weTWeOMgcwR3HZpKTmZJalFunbJXBl 3Px/l7lgv1nFif2nGBsYe7S6GDk5JARMJB4se8bUxcjFISRwmFHiSs9+dghnCaPE9nsLGLsY OTjYBCwkuv9pgzSIAJm73l1jA6lhFjjDKDFj5g5WkISwQLzElUdrmSCKEiTO3TnJBtIrImAk sfVIIEiYRUBV4vDKPrASXgFfif5Dk5lBSoQEdCQ+nTcACXMK6Eqs+fyfBcRmFBCT+H5qDVg5 s4C4xK0n85kgbhaQWLLnPDOELSrx8vE/VpAxEgJKEg0zWSDKdSQW7P7EBmFrSyxb+JoZYqug xMmZT1gmMIrOQjJ1FpKWWUhaZiFpWcDIsopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMjMKIO bvmtuoPx8hvHQ4wCHIxKPLzKR3ujhFgTy4orcw8xSnAwK4nwnkgACvGmJFZWpRblxxeV5qQW H2KU5mBREuedI9weJSSQnliSmp2aWpBaBJNl4uCUamDMqpyzpLZLLWjqrzUpSpuKJtnNWnPT 5UXn5/1WXgHaG+737ZFxdIy9t0mk1/ioga6X6hX/ei5xw+kcJw8ErRL4Z5x2//7jNW8N056Z PdfoY2ISe8Rfkr/JPFi9TkVm6YcX3Lfe6epu51r6Y87Ku1HZpxcdjj80bWWIK+/DYL3l67Yf TYy4fyxQiaU4I9FQi7moOBEAM76Oj6QCAAA=
Archived-At: 
Subject: Re: [Ice] Benjamin Kaduk's practice ballot on draft-ietf-ice-rfc5245bis-17: (with COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Feb 2018 19:31:04 -0000

Hi Ben,

Thank You for the review and comments! Please see inline.

>Given that this is a -bis document, there are some areas that may have age=
d poorly and could benefit from reconsideration:

Yes. The focus of the bis work was to fix bugs, and clarify procedures. But=
, if outdated information is found we can of course fix that.

> In Section 5.2, we say that for the Lite implementation, preferring
> IPv4 is RECOMMENDED for dual-stack hosts.  Is that still the advice we wa=
nt to give?

Suresh had the same comment. I suggest to remove the sentence.

> Section 17 is very focused on voice traffic; is that still the main use o=
f ICE?

In my opinion it is.

---

>Appendix B.8 has:
>
>   Additionally, using a Binding Indication allows integrity to be
>   disabled, allowing for better performance.  This is useful for large-
>   scale endpoints, such as PSTN gateways and SBCs.
>
> which talks of disabling STUN's MESSAGE-INTEGRITY as a potential benefit.=
  Do we really want to advocate for=20
> increased levels of unauthenticated plaintext on the internet?

I wouldn't say that we are advocating. The truth is that people don't see i=
t feasibly to integrity protect keep-alives.

---

>Appendix C has a table of bandwidth consumption in various scenarios, most=
 of which are measured in kilobits per second.  Is this still relevant to m=
odern deployments?

Appendix C was added to the bis document, based on real measurements (broug=
ht by Google, as far as I remember), so they are relevant.

---

>Some other general comments/questions.
>
>
>I was also a little confused in Section 6.1.2.2, where we say
>
>   for each interface.  To keep the amount of resulting candidate pairs
>   reasonable and to avoid candidate pairs that are highly unlikely to
>   work, IPv6 link-local addresses [RFC4291] MUST NOT be paired with
>   other than link-local addresses.
>
> but in section 5.1.1.1 we say that IPv6 link-local addresses MUST NOT be =
gathered. =20
> Is this just to handle the chance that we might get a reflexive candiate =
for a link-local address?

Well, even if that happens, it shouldn't be used in my opinion.

I suggest to remove the text in Section 6.1.2.2, to avoid confusion.

---

>Section 13 has:
>
>   Consequently, any future ICE enhancements MUST
>   preserve triggered checks.
>
> which does not seem like an enforceable requirement, given that future up=
dates to this document could just remove it. =20
> Perhaps it should be worded differently to give the motivation for the ne=
ed to keep triggered checks.

Perhaps we could remove the sentence. There are many things that extensions=
 need to keep, and I don't see any reason to just mention one of them. And,=
 triggered checks isn't even needed for ICE to work - it's just an optimiza=
tion.

---

>In section 14.3:
>
>   For connectivity checks, agents SHOULD calculate the RTO value using
>   the following formula:
>
>     RTO =3D MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress))
>
> What is 'N'?

The number of checks to be performed. See section 14.1.

---

>In Section 15:
>
>   will succeed.  Consequently, agent R constructs a new candidate pair
>   using the mapped address from the response as the local candidate (R-
>   PUB-1) and the destination of the request (NAT-PUB-1) as the remote
>   candidate.  This pair is added to the valid list for that data
>   stream.
>
> which leaves me confused, perhaps just about which response is "the respo=
nse" that we're taking the mapped address from. =20
> The previous text is about a STUN Binding request from L to R that causes=
 R to generate a triggered check, so is this the response=20
> that R generates to the Binding request from L?

Correct.

>  IIUC the mapped address therein would be where R sees traffic from L as =
originating=20
> from, and would not be appropriate to use as a local address for R, etc..=
  So presumably I am picking the wrong response to use as the=20
> source of data.

I think you are picking the right response :)

---

> In Section 18.3:
>
>   [...] The process of determining
>   connectivity is very robust.
>
> This seems to contrast with section 14.1, where
>
>   The loss of the first single packet for any
>   connectivity check is likely to cause that pair to take a long time
>   to be validated, and instead, a lower-priority check (but one for
>   which there was no packet loss) is much more likely to complete
>   first.

What is meant in 18.3 is that ICE is very robust when it comes to finding *=
A* connectivity, as there is no single point of failure in the network (you=
 can use multiple STUN servers etc).

---

> Something of a side note, but is HMAC-SHA1 still the state of the art for=
 STUN MESSAGE-INTEGRITY? =20
> I know that there are no known breaks against HMAC-SHA1, but I would be a=
 little surprised if no one was interested in producing an update.

RFC 5389 (STUN) uses HMAC-SHA1.

Anyway, I don't think it is mentioned in the 5245bis document, is it?

---

>In Section 19.3:
>
>   However, TURN servers are susceptible to DNS attacks for purposes of
>   turning it into a zombie or rogue server.  These attacks can be
>   mitigated by DNS-SEC and through good box and software security on
>   TURN servers.
>
> I don't understand this.  Is the ICE agent or the TURN server "turned int=
o" a zombie or rogue server by DNS attacks? =20
> If the TURN server, how would a bogus DNS response turn it into a rogue s=
erver?

I will have to come back on the security related comments, because I need i=
nput from others.

---

>On an editorial note, there is a general feel to the document that it star=
ted off life as only covering ICE for RTP and the application=20
>profiling was later split off into separtae documents.  I don't know that =
it's worth the effort to try to change that, though.  I might=20
>give some thought to factoring out some of the duplicated content, though,=
 such as discussion of how RTP gets component ID 1 and=20
>RTCP id 2, and I think Ekr noted some other areas of duplication.
>
> Other purely editorial nits follow (IESG feel free to ignore).

---

>Section 18.2:
>
>   Therefore, the servers get used less and
>   less, and can eventually be remove when their usage goes to zero.
>
>*removed

I will fix as suggested.

---

>Section 19.4:
>
>   In addition to attacks where the attacker is a third party trying to
>   insert fake candidate information or stun messages,
>
> s/stun/STUN/

I will fix as suggested.

---

>Section 21:
>
>   o  Make technical changes, due to discovered flows in RFC 5245 and
>      based on feedback from the community that has implemented and
>      deployed ICE applications based on RFC 5245.
>
> flows or flaws?

Flaws :) I will fix it.

---

Regards,

Christer


From nobody Wed Feb 21 12:38:55 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAE912DA1D for ; Wed, 21 Feb 2018 12:38:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_b4-57E0-t5 for ; Wed, 21 Feb 2018 12:38:51 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 3982312D94A for ; Wed, 21 Feb 2018 12:38:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519245529; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7C1vuiAoj0kE1HDVcTrJzXmYRcRAoS1igaegVu4MZVA=; b=AjdgqTmEVLmuYBQLscZv8+NmEvjJQNsuh9A0iEAYGJNtp9jhA0ufxY3gMMtXRCcG NKLJmIeaFd3pHiMYBVIDzuZc+nAxvaGtXoZoQ7bMxZVt4tzlYnaAV70ObcN+DXct My+u+Bl3IeQKOsCHExtOf5IAudg9M+hnerdz/78ygNA=;
X-AuditID: c1b4fb2d-499ff70000005540-c5-5a8dd8d98748
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 05.44.21824.9D8DD8A5; Wed, 21 Feb 2018 21:38:49 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Wed, 21 Feb 2018 21:38:48 +0100
From: Christer Holmberg 
To: Adam Roach , The IESG 
CC: "draft-ietf-ice-rfc5245bis@ietf.org" ,  Peter Thatcher , "ice-chairs@ietf.org" , "pthatcher@google.com" , "ice@ietf.org" 
Thread-Topic: Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
Thread-Index: AQHTqvWUaf7qEwtdZ0KrkPtHSF2TaKOvQY5g
Date: Wed, 21 Feb 2018 20:38:48 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C17B247@ESESSMB109.ericsson.se>
References: <151920498287.9799.11602055137725027840.idtracker@ietfa.amsl.com>
In-Reply-To: <151920498287.9799.11602055137725027840.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.172]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7ru7NG71RBie/C1rs+buI3WL+yevM FhdnTWaz+Hah1mLGn4nMFteWv2Z1YPNYsKnUY8mSn0wes3Y+YQlgjuKySUnNySxLLdK3S+DK 6Dm9hbXgQidjRc/uC2wNjD1tjF2MnBwSAiYSN162snYxcnEICRxmlGhqnsEG4SxhlDj9djeQ w8HBJmAh0f1PG6RBRMBa4nTzSWaQGmaBr4wSKzbuZAJJCAvES7w5N58doihBoq/3KAuEbSTx +t1LVhCbRUBV4tn702AzeQV8JT416ICEhYDMm7PfsYHYnAJ+Egd3rQcrZxQQk/h+ag3YeGYB cYlbT+YzQRwtILFkz3lmCFtU4uXjf6wgIyUElCQaZrKAmMwCmhLrd+lDdCpKTOl+CHYYr4Cg xMmZT1gmMIrOQjJ0FkLHLCQds5B0LGBkWcUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGFMH t/zW3cG4+rXjIUYBDkYlHt74o71RQqyJZcWVuYcYJTiYlUR4TyQAhXhTEiurUovy44tKc1KL DzFKc7AoifOe9OSNEhJITyxJzU5NLUgtgskycXBKNTDOPiR9lGfavFaJyrmx2cYbb26LvmSz K7CgMKYv7Ndlk0PLZrW5nk+9+jLyOOP032JOylqvEkPPMRgf3P9M2vLCqT17LGXXuvc1GSct TTaaILRQbUowp+GZUOEI6fXl+1QsZO5e7WVKkLEtrpv+SvqV1rPTL3s169/dy/19ZwlLo/+8 bfH7G1WUWIozEg21mIuKEwEziu2mpQIAAA==
Archived-At: 
Subject: Re: [Ice] Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Feb 2018 20:38:54 -0000

SGkgQWRhbSwNCg0KVGhhbmsgWW91IGZvciB0aGUgcmV2aWV3IGFuZCBjb21tZW50cyEgUGxlYXNl
IHNlZSBpbmxpbmUuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkRJU0NVU1M6DQotLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN
Cj4gVGhhbmtzIHRvIGV2ZXJ5b25lIHdobyBoYXMgY29udHJpYnV0ZWQgdG8gdGhpcyBkb2N1bWVu
dCBvdmVyIHRoZSBtYW55IHllYXJzIG9mIGl0cyBkZXZlbG9wbWVudC4NCj4NCj5UaGUgZG9jdW1l
bnQgY3VycmVudGx5IGFwcGVhcnMgdG8gY29udGFpbiBub3JtYXRpdmUgc3RhdGVtZW50cyB0aGF0
LCB3aGlsZSBub3QgbGl0ZXJhbGx5IGNvbnRyYWRpY3RvcnksIGNlcnRhaW5seSBwb2ludCBpbXBs
ZW1lbnRvcnMgaW4gY29uZmxpY3RpbmcgZGlyZWN0aW9ucy4NCj7CpzUuMS4xLjEgc2F5czoNCj4N
Cj4gIG8gIEhvc3QgY2FuZGlkYXRlcyBjb3JyZXNwb25kaW5nIHRvIElQdjYgbGluay1sb2NhbCBh
ZGRyZXNzZXMgTVVTVA0KPiAgICAgTk9UIGJlIGdhdGhlcmVkLg0KPg0KPiBGdXJ0aGVyIGRvd24s
IMKnNi4xLjIuMiBzYXlzOg0KPg0KPiAgVG8ga2VlcCB0aGUgYW1vdW50IG9mIHJlc3VsdGluZyBj
YW5kaWRhdGUgcGFpcnMgIHJlYXNvbmFibGUgYW5kIHRvIA0KPiBhdm9pZCBjYW5kaWRhdGUgcGFp
cnMgdGhhdCBhcmUgaGlnaGx5IHVubGlrZWx5IHRvICB3b3JrLCBJUHY2IA0KPiBsaW5rLWxvY2Fs
IGFkZHJlc3NlcyBbUkZDNDI5MV0gTVVTVCBOT1QgYmUgcGFpcmVkIHdpdGggIG90aGVyIHRoYW4g
DQo+IGxpbmstbG9jYWwgYWRkcmVzc2VzLg0KPg0KPiBUaGlzIHNlY29uZCBwYXNzYWdlIGlzIG5v
bnNlbnNpY2FsIGlmIElQdjYgbGluayBsb2NhbCBhZGRyZXNzZXMgTVVTVCBOT1QgYmUgZ2F0aGVy
ZWQuIFBsZWFzZSByZW1vdmUgb3IgYW1lbmQgb25lIG9mIA0KPiB0aGVzZSBub3JtYXRpdmUgc3Rh
dGVtZW50cy4gSWYgdGhlIGZpcnN0IHN0YXRlbWVudCBpcyByZXRhaW5lZCwgcGxlYXNlIGFkZCBy
YXRpb25hbGUuDQoNCkJlbiBoYWQgdGhlIHNhbWUgY29tbWVudC4gTXkgc3VnZ2VzdGlvbiB3YXMg
dG8gcmVtb3ZlIHRoZSB0ZXh0IGluIDYuMS4yLjIuDQoNCkkgZ3Vlc3MgdGhlIHJhdGlvbmFsZSBp
cyBzaW5jZSBhIGxvY2FsLWxpbmsgYWRkcmVzcyBtYXkgbm90IGJlIHZhbGlkIGZvciBjb21tdW5p
Y2F0aW5nIHdpdGggdGhlIHBlZXIuDQoNCj4oQXMgYW4gYXNpZGUsIGl0IG1ha2VzIG1vcmUgc2Vu
c2UgdG8gY2l0ZSA0MjkxIHRoZSBmaXJzdCB0aW1lIHlvdSBtZW50aW9uIElQdjYgbGluayBsb2Nh
bCBhZGRyZXNzIHJhdGhlciB0aGFuIHRoZSBzZWNvbmQpDQoNCkknbGwgZml4IHRoYXQuDQoNCi0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0Kwqc1LjEuMS4zOg0K
DQo+ICBvICBGb3IgcmVmbGV4aXZlIGFuZCByZWxheWVkIGNhbmRpZGF0ZXMsIHRoZSBTVFVOIG9y
IFRVUk4gc2VydmVycw0KPiAgICAgdXNlZCB0byBvYnRhaW4gdGhlbSBoYXZlIHRoZSBzYW1lIElQ
IGFkZHJlc3MuDQo+DQo+IFRoaXMgaXMgYW1iaWd1b3VzOiBpdCBpcyB1bmNsZWFyIHdoZXRoZXIg
InRoZSBzYW1lIElQIGFkZHJlc3MiIHJlZmVycyB0byB0aGUgYWRkcmVzcyB0aGF0IHRoZSBJQ0Ug
YWdlbnQgdXNlZCB0byANCj4gcmVhY2ggdGhlIFRVUk4gc2VydmVyLCBvciB3aGV0aGVyIHRoZSBJ
UCBhZGRyZXNzIGFsbG9jYXRlZCBieSB0aGUgVFVSTiBzZXJ2ZXIgb24gdGhlIGNsaWVudCdzIGJl
aGFsZi4gSW4gDQo+IGxhcmdlLXNjYWxlIFRVUk4gZGVwbG95bWVudHMsIHRoZXNlIGFkZHJlc3Nl
cyB3aWxsIGZyZXF1ZW50bHkgZGlmZmVyLCBzaW5jZSBvbmUgSVAgYWRkcmVzcyBjYW4gb25seSBz
dXBwb3J0IH42NGsgcG9ydHMgDQo+IGF0IG9uY2UgKGFuZCB0aGVyZWZvcmUgVFVSTiBzZXJ2ZXJz
IG1heSBuZWVkIHRvIG1ha2UgdXNlIG9mIG11bHRpcGxlIGF0IG9uY2UpLiBQbGVhc2UgY2xhcmlm
eSB3aGljaCBJUCBhZGRyZXNzIGlzIHRvIGJlIA0KPiB1c2VkIGZvciB0aGlzIGNvbXBhcmlzb24u
DQoNCkl0IGlzIHRoZSBhZGRyZXNzIHRoZSBhZ2VudCB1c2VzIHRvIHJlYWNoIHRoZSBTVFVOL1RV
Uk4gc2VydmVyLg0KDQo+ICBTaW1pbGFybHksIHR3byBjYW5kaWRhdGVzIGhhdmUgZGlmZmVyZW50
IGZvdW5kYXRpb25zIGlmIHRoZWlyIHR5cGVzICANCj4gYXJlIGRpZmZlcmVudCwgdGhlaXIgYmFz
ZXMgaGF2ZSBkaWZmZXJlbnQgSVAgYWRkcmVzc2VzLCB0aGUgU1RVTiBvciAgDQo+IFRVUk4gc2Vy
dmVycyB1c2VkIHRvIG9idGFpbiB0aGVtIGhhdmUgZGlmZmVyZW50IElQIGFkZHJlc3Nlcywgb3Ig
IA0KPiB0aGVpciB0cmFuc3BvcnQgcHJvdG9jb2xzIGFyZSBkaWZmZXJlbnQuDQo+DQo+IFRoZSBz
YW1lIGNsYXJpZmljYXRpb24gaXMgcmVxdWlyZWQgdG8gdGhpcyBwYXJhZ3JhcGggYXMgd2VsbC4N
Cg0KV2lsbCBmaXggaXQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQrCpzUuMjoNCg0KPiAgVGhp
cyBkZWZhdWx0DQo+ICBTSE9VTEQgYmUgY2hvc2VuIHN1Y2ggdGhhdCBpdCBpcyB0aGUgY2FuZGlk
YXRlIG1vc3QgbGlrZWx5IHRvIGJlIHVzZWQgIA0KPiB3aXRoIGEgcGVlci4gIEZvciBJUHY2LW9u
bHkgaG9zdHMsIHRoaXMgd291bGQgdHlwaWNhbGx5IGJlIGEgZ2xvYmFsbHkgIA0KPiBzY29wZWQg
SVB2NiBhZGRyZXNzLiAgRm9yIGR1YWwtc3RhY2sgaG9zdHMsIHRoZSBJUHY0IGFkZHJlc3MgaXMg
IA0KPiBSRUNPTU1FTkRFRC4NCj4NCj4NCj4gSSBzdXBwb3J0IFN1cmVzaCdzIERJU0NVU1MuIEkg
d291bGQgcHJvcG9zZSB0aGF0IHlvdSByZWNvbW1lbmQgdGhhdCBkdWFsLXN0YWNrIGhvc3RzIFNI
T1VMRCBhbGxvdyBjb25maWd1cmF0aW9uIA0KPiBvZiB3aGV0aGVyIElQdjQgb3IgSVB2NiBpcyB1
c2VkIGZvciB0aGUgZGVmYXVsdCwgYW5kIHRoYXQgdGhlIGNvbmZpZ3VyYXRpb24gbmVlZHMgdG8g
YmUgYmFzZWQgb24gd2hpY2ggb25lIGl0cyBhZG1pbmlzdHJhdG9yIA0KPiBiZWxpZXZlcyBoYXMg
YSBoaWdoZXIgY2hhbmNlIG9mIHN1Y2Nlc3MgaW4gdGhlIGN1cnJlbnQgbmV0d29yayBlbnZpcm9u
bWVudC4gSSBhbSBvZiB0aGUgdW5kZXJzdGFuZGluZywgZm9yIGV4YW1wbGUsIHRoYXQgDQo+IGlu
IGNlcnRhaW4gSmFwYW5lc2UgY2FycmllcnMsIHRoZSBzZWxlY3Rpb24gb2YgSVB2NiBhcyB0aGUg
ZGVmYXVsdCB3b3VsZCBtYXhpbWl6ZSB0aGUgY2hhbmNlIG9mIHN1Y2Nlc3MsIGV2ZW4gdG9kYXku
DQoNCk15IHN1Z2dlc3Rpb24gdG8gU3VyZXNoIHdhcyB0byBzaW1wbHkgcmVtb3ZlIHRoZSBzdGF0
ZW1lbnQuIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0Kwqc1LjM6DQoNCj4gICAgIFJlbGF0ZWQg
QWRkcmVzcyBhbmQgUG9ydDogIFRoZSByZWxhdGVkIElQIGFkZHJlc3MgYW5kIHBvcnQgb2YgdGhl
DQo+ICAgICAgICBjYW5kaWRhdGUuICBUaGVzZSBNQVkgYmUgb21pdHRlZCBvciBzZXQgdG8gaW52
YWxpZCB2YWx1ZXMgaWYNCj4gICAgICAgIHRoZSBhZ2VudCBkb2VzIG5vdCB3YW50IHRvIHJldmVh
bCB0aGVtLCBlLmcuLCBmb3IgcHJpdmFjeQ0KPiAgICAgICAgcmVhc29ucy4NCj4NCj4gVGhlIHRl
cm0gIlJlbGF0ZWQgQWRkcmVzcyBhbmQgUG9ydCIgaXMgbm90IGRlZmluZWQgYW55d2hlcmUuIElz
IGl0IHRoZSBzYW1lIGFzIHRoZSBiYXNlIGFkZHJlc3M/IFNvbWV0aGluZyBlbHNlPyANCj4gUGxl
YXNlIGFkZCBhIGRlZmluaXRpb24gdG8gwqc0LiAoSSdsbCBub3RlIHRoYXQgdGhpcyB0ZXJtIGlz
IGFsc28gdXNlZCBpbiBGaWd1cmUgNi4pIEl0IG1heSBhbHNvIGJlIHVzZWZ1bCB0byBjYWxsIGZv
cndhcmQgdG8NCj4gwqdCLjMgaGVyZSwgc28gdGhhdCBpbXBsZW1lbnRvcnMgYXJlbid0IGNvbmZ1
c2VkIGJ5IHRoZSBhcHBhcmVudCB1c2VsZXNzbmVzcyBvZiBpbmNsdWRpbmcgdGhpcyBpbmZvcm1h
dGlvbi4NCg0KSSBoYWQgYSBsb29rIGluIFJGQyA1MjQ1LCBhbmQgdGhlIG9ubHkgcGxhY2Ugd2hl
cmUgaXQgd2FzIGV4cGxhaW5lZCB3YXMgdGhlIFNEUCBzeW50YXggKHdoaWNoIG5vIGxvbmdlciBl
eGlzdHMgaW4gNTI0NWJpcyk6DQoNCjxyZWwtYWRkcj4gYW5kIDxyZWwtcG9ydD46ICBjb252ZXkg
dHJhbnNwb3J0IGFkZHJlc3NlcyByZWxhdGVkIHRvIHRoZQ0KICAgICAgY2FuZGlkYXRlLCB1c2Vm
dWwgZm9yIGRpYWdub3N0aWNzIGFuZCBvdGhlciBwdXJwb3Nlcy4gPHJlbC1hZGRyPg0KICAgICAg
YW5kIDxyZWwtcG9ydD4gTVVTVCBiZSBwcmVzZW50IGZvciBzZXJ2ZXIgcmVmbGV4aXZlLCBwZWVy
DQogICAgICByZWZsZXhpdmUsIGFuZCByZWxheWVkIGNhbmRpZGF0ZXMuICBJZiBhIGNhbmRpZGF0
ZSBpcyBzZXJ2ZXIgb3INCiAgICAgIHBlZXIgcmVmbGV4aXZlLCA8cmVsLWFkZHI+IGFuZCA8cmVs
LXBvcnQ+IGFyZSBlcXVhbCB0byB0aGUgYmFzZQ0KICAgICAgZm9yIHRoYXQgc2VydmVyIG9yIHBl
ZXIgcmVmbGV4aXZlIGNhbmRpZGF0ZS4gIElmIHRoZSBjYW5kaWRhdGUgaXMNCiAgICAgIHJlbGF5
ZWQsIDxyZWwtYWRkcj4gYW5kIDxyZWwtcG9ydD4gaXMgZXF1YWwgdG8gdGhlIG1hcHBlZCBhZGRy
ZXNzDQogICAgICBpbiB0aGUgQWxsb2NhdGUgcmVzcG9uc2UgdGhhdCBwcm92aWRlZCB0aGUgY2xp
ZW50IHdpdGggdGhhdA0KICAgICAgcmVsYXllZCBjYW5kaWRhdGUgKHNlZSBBcHBlbmRpeCBCLjMg
Zm9yIGEgZGlzY3Vzc2lvbiBvZiBpdHMNCiAgICAgIHB1cnBvc2UpLiAgSWYgdGhlIGNhbmRpZGF0
ZSBpcyBhIGhvc3QgY2FuZGlkYXRlLCA8cmVsLWFkZHI+IGFuZA0KICAgICAgPHJlbC1wb3J0PiBN
VVNUIGJlIG9taXR0ZWQuDQoNCkkgd2lsbCB1c2UgdGhhdCB0ZXh0LCBhbmQgYWRkIGEgZGVmaW5p
dGlvbiB0byBzZWN0aW9uIDQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQrCpzguMS4xOg0KDQo+
ICBOT1RFOiBBIGNvbnRyb2xsaW5nIGFnZW50IHRoYXQgZG9lcyBub3Qgc3VwcG9ydCB0aGlzIHNw
ZWNpZmljYXRpb24gIA0KPiAoaS5lLiBpdCBpcyBpbXBsZW1lbnRlZCBhY2NvcmRpbmcgdG8gUkZD
IDUyNDUpIG1pZ2h0IG5vbWluYXRlIG1vcmUgIA0KPiB0aGFuIG9uZSBjYW5kaWRhdGUgcGFpci4g
IFRoaXMgd2FzIHJlZmVycmVkIHRvIGFzIGFnZ3Jlc3NpdmUgIA0KPiBub21pbmF0aW9uIGluIFJG
QyA1MjQ1Lg0KPg0KPiBQbGVhc2UgaGVyZSBvciBlbHNld2hlcmUgKHByb2JhYmx5IEFwcGVuZGl4
IEIpIGluZGljYXRlIHdoeSBhZ2dyZXNzaXZlIG5vbWluYXRpb24gd2FzIHJlbW92ZWQgKGkuZS4s
IGl0J3MgcmVkdW5kYW50IA0KPiB3aXRoIHRoZSBhYmlsaXR5IHRvIHNlbmQgZGF0YSBvbiBhbnkg
dmFsaWQgcGFpciBldmVuIHByaW9yIHRvIG5vbWluYXRpb24pLg0KDQpJJ2xsIGRvIHRoYXQuDQoN
Cj5BbHNvIChlZGl0b3JpYWwgbml0KSBwbGVhc2UgcHV0IHF1b3RhdGlvbiBtYXJrcyBhcm91bmQg
dGhlIHRlcm0gImFnZ3Jlc3NpdmUgbm9taW5hdGlvbi4iDQoNCldpbGwgZG8uDQoNCi0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KDQrCpzguMS4yOg0KDQo+ICAgICAqICBUaGUgYWdlbnQgTUFZIGJlZ2luIHRy
YW5zbWl0dGluZyBkYXRhIGZvciB0aGlzIGRhdGEgc3RyZWFtIGFzDQo+ICAgICAgICBkZXNjcmli
ZWQgaW4gU2VjdGlvbiAxMi4xLg0KPg0KPiBUaGlzIHNlZW1zIHJlZHVuZGFudCB3aXRoIHRoZSBm
YWN0IHRoYXQgdGhlIGRhdGEgY291bGQgYmUgc2VudCBldmVuIGJlZm9yZSBub21pbmF0aW9uLCBh
bmQgcnVucyB0aGUgcmlzayB0aGF0IA0KPiBpbXBsZW1lbnRvcnMgbWlnaHQgaW50ZXJwcmV0IGl0
IHRvIG1lYW4gdGhhdCB0aGV5IG11c3Qgbm90IHNlbmQgZGF0YSAqcHJpb3IqIHRvIG5vbWluYXRp
b24uIEkgdGhpbmsgaXQgd291bGQgYmUgDQo+IHNhZmVzdCB0byByZW1vdmUgdGhpcywgYW5kIHBv
c3NpYmx5IHJlaXRlcmF0ZSByaWdodCBoZXJlIHRoYXQgc2VuZGluZyBkYXRhIGlzIG5vdCBibG9j
a2VkIG9uIHN1Y2Nlc3NmdWwgcGFpciBub21pbmF0aW9uLg0KDQpJIHN1Z2dlc3QgdG8gc2ltcGx5
IHJlbW92ZSB0aGUgdGV4dC4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCsKnOToNCg0KPiAgVG8g
cmVzdGFydCBJQ0UsIGFuIGFnZW50IE1VU1QgY2hhbmdlIGJvdGggdGhlIHBhc3N3b3JkIGFuZCB0
aGUgIA0KPiB1c2VybmFtZSBmcmFnbWVudCBmb3IgdGhlIGRhdGEgc3RyZWFtKHMpIGJlaW5nIHJl
c3RhcnRlZC4gIFRoZSBhZ2VudCAgDQo+IE1VU1QgdmVyaWZ5IHRoYXQgaXQgaGFzIG5vdCB1c2Vk
IHRoZSBuZXcgdmFsdWVzIGluIHJlY2VudCBJQ0UgIA0KPiBzZXNzaW9ucywgYXMgcGFja2V0cyBm
cm9tIHRob3NlIHNlc3Npb25zIG1pZ2h0IHN0aWxsIGJlIHByZXNlbnQgaW4gIA0KPiB0aGUgbmV0
d29yay4NCj4NCj4gVG8gYmUgY2xlYXI6IHRoZSBwYXNzd29yZCBhbmQgdWZyYWcsIHRha2VuIHRv
Z2V0aGVyLCBwcm92aWRlIDE1MiBiaXRzIG9mIHJhbmRvbW5lc3MsIGFuZCBuZWVkIHRvIGJlIA0K
PiBzZWxlY3RlZCByYW5kb21seSBvbiByZXN0YXJ0LiBUaGlzIHBhc3NhZ2UgYXBwZWFycyB0byBi
ZSBndWFyZGluZyBhZ2FpbnN0IHJhbmRvbSBjb2xsaXNpb25zIGJldHdlZW4gMTUyLWJpdCB2YWx1
ZXMgaW4gYSBzbWFsbCBzZXQuDQo+IERvIEkgaGF2ZSB0aGF0IGNvcnJlY3Q/DQoNClllcy4NCg0K
Tm90ZSwgdGhvdWdoLCB0aGF0IGluIDNQQ0Mgc2NlbmFyaW9zIHRoZSBwZWVyIG1heSBhbHNvIGNo
YW5nZSAoZXZlbnRob3VnaCB0aGUgcmlzayBvZiBjb2xsaXNpb24gc2hvdWxkIHN0aWxsIGJlIHNt
YWxsKS4NCg0KPklmIHNvOiBJIGNvdWxkbid0IGZpbmQgYSBiaXJ0aGRheSBwYXJhZG94IGNhbGN1
bGF0b3IgdGhhdCBjb3VsZCBkZWFsIHdpdGgNCj41LDcwOCw5OTAsNzcwLDgyMyw4MzksNTI0LDIz
MywxNDMsODc3LDc5Nyw5ODAsNTQ1LDUzMCw5ODYsNDk2IHBvdGVudGlhbCB2YWx1ZXMuDQo+VGhl
IG9ubHkgb25lIHRoYXQgZGlkbid0IGdlbmVyYXRlIGFuIGVycm9yIG91dHJpZ2h0IGdhdmUgYSBw
cm9iYWJpbGl0eSBvZiAwLCB3aGljaCBpcyBhcyBjbG9zZSBhcyBjb3JyZWN0IGFzIHRvIG1ha2Ug
bm8gZGlmZmVyZW5jZS4NCj4NCj5Vbmxlc3MgSSdtIG1pc3VuZGVyc3RhbmRpbmcgd2hhdCBpcyBi
ZWluZyBhc2tlZCBvZiBpbXBsZW1lbnRvcnMsIHRoaXMgc2Vjb25kIE1VU1QgaXMgc3VwZXJmbHVv
dXMgYW5kIHNob3VsZCBiZSByZW1vdmVkLg0KDQpJIGFtIG9rIHJlbW92aW5nIGl0Lg0KDQotLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCg0KwqcxNToNCg0KPlBsZWFzZSBlaXRoZXIgdXBkYXRlIHRoZSBleGFt
cGxlIHRvIHVzZSBJUHY2IGluIGFkZGl0aW9uIHRvIElQdjQsIG9yIHByb3ZpZGUgYW4gYWRkaXRp
b25hbCBleGFtcGxlIHRoYXQgdXNlcyANCj5JUHY2IGFkZHJlc3Nlcy4gIFNlZSBodHRwczovL3d3
dy5pYWIub3JnLzIwMTYvMTEvMDcvaWFiLXN0YXRlbWVudC1vbi1pcHY2LyBmb3IgZ3VpZGFuY2Ug
b24gdGhlIHVzZSBvZg0KPklQdjYgaW4gSUVURiBzcGVjaWZpY2F0aW9ucywgaW5jbHVkaW5nIHRo
ZWlyIGV4YW1wbGVzLg0KDQpTdWhhcyBoYWQgdGhlIHNhbWUgY29tbWVudC4gSSdsbCBsb29rIGlu
dG8gaXQuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQrCpzE1Og0KDQo+ICAgICAgICAgICAgfCAg
ICAgICAgICAgICAgfCg5KSBCaW5kIFJlcSAgfCAgICAgICAgICAgICAgfEJlZ2luDQo+ICAgICAg
ICAgICAgfCAgICAgICAgICAgICAgfFM9JFItUFVCLTEgICAgfCAgICAgICAgICAgICAgfENvbm5l
Y3Rpdml0eQ0KPiAgICAgICAgICAgIHwgICAgICAgICAgICAgIHxEPUwtUFJJVi0xICAgIHwgICAg
ICAgICAgICAgIHxDaGVja3MNCj4gICAgICAgICAgICB8ICAgICAgICAgICAgICB8PC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS18DQo+ICAgICAgICAgICAgfCAgICAgICAgICAgICAgfERyb3Bw
ZWQgICAgICAgfCAgICAgICAgICAgICAgfA0KPg0KPiBUaGlzIGlzIHF1aXRlIG1pc2xlYWRpbmcu
IElmIGEgaG9zdCBvbiB0aGUgcHVibGljIEludGVybmV0IChhcyBSIGlzIGluIHRoaXMNCj4gZXhh
bXBsZSkgc2VudCBhIEJpbmRpbmcgUmVxdWVzdCB0byAkTC1QUklWLTEgKDEwLjAuMS4xIGluIHRo
aXMgZXhhbXBsZSksIGl0IA0KPiB3b3VsZCAqbm90KiBiZSByb3V0ZWQgdG8gdGhlIE5BVCwgYXMg
aXMgc2hvd24gaW4gdGhpcyBleGFtcGxlLiBJZiBpdCBkaWRuJ3QgZ2V0IGJsb2NrZWQgDQo+IGJl
Zm9yZSByZWFjaGluZyB0aGUgZGVmYXVsdCBmcmVlIHpvbmUsIEkgYmVsaWV2ZSBpdCB3b3VsZCBi
ZSBibGFja2hvbGVkIG9uY2UgaXQgZGlkIHNvLiBJIHdvdWxkIA0KPiBwcm9wb3NlIGtlZXBpbmcg
dGhlIGFycm93LCBidXQgaGF2aW5nIGl0IGVuZCBwcmlvciB0byByZWFjaGluZyB0aGUgTkFUIGxp
bmUuDQoNCj4oTWlub3Igbml0OiBwbGVhc2UgcmVwbGFjZSAiTC1QUklWLTEiIHdpdGggIiRMLVBS
SVYtMSIpDQoNCldpbGwgZml4Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KwqcxNToNCg0KPiAg
U2luY2UgdGhlIGNoZWNrIHdhcyBnZW5lcmF0ZWQgaW4gdGhlIHJldmVyc2UgZGlyZWN0aW9uIG9m
IGEgIGNoZWNrIA0KPiB0aGF0IGNvbnRhaW5lZCB0aGUgVVNFLUNBTkRJREFURSBhdHRyaWJ1dGUu
Li4NCj4NCj4gSXQgd2FzPyBJIGRvbid0IHNlZSB0aGF0IGluIHRoZSBsYWRkZXIsIGNhbid0IGZp
bmQgaXQgaW4gdGhlIHByb3NlLCBhbmQgYmVsaWV2ZSBpdCB0byBiZSBhY3R1YWxseSBpbmNvcnJl
Y3QuIA0KPiBCeSBteSB1bmRlcnN0YW5kaW5nLCB0aGUgZXhhbXBsZSB3b3VsZCBuZWVkIGFuIGFk
ZGl0aW9uYWwgbWVzc2FnZXMgMTggdGhyb3VnaCAyMSwgb3JpZ2luYXRpbmcgZnJvbSBMIA0KPiAo
YXMgdGhlIGNvbnRyb2xsaW5nIGFnZW50KSB0aGF0IG5vbWluYXRlcyB0aGlzIHBhaXIuDQo+DQo+
IEkgYmVsaWV2ZSB3aGF0IHlvdSd2ZSBzaG93biBpcyBhbiBhZ2dyZXNzaXZlIG5vbWluYXRpb24g
Y2FsbCBmbG93LCBidXQgdGhpcyBkb2N1bWVudCBubyBsb25nZXIgc3VwcG9ydHMgYWdncmVzc2l2
ZSBub21pbmF0aW9uLg0KPg0KPiBJZiBJJ20gc2ltcGx5IGNvbmZ1c2VkIGhlcmUsIHRoZW4gcGxl
YXNlIGFkZCB0aGUgIlVTRS1DQU5ESURBVEUiIGF0dHJpYnV0ZSB0byB0aGUgbGFkZGVyIGRpYWdy
YW0gYW5kIHRvIHRoZSBjb3JyZXNwb25kaW5nIHRleHQgd2hlcmUgaXQgYmVsb25ncy4NCg0KSSds
bCBkb3VibGUgY2hlY2sgdGhlIGV4YW1wbGUuIEkgZG9u4oCZdCB0aGluayB3ZSBsb29rZWQgYXQg
aXQgaW4gdGhlIFdHLCBzbyBpdCBtYXkgZS5nLiwgc2hvdyBhZ2dyZXNzaXZlIG5vbWluYXRpb24u
DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQrCpzIwLjEgYW5kIMKnMjAuMjoNCg0KPiBQbGVhc2Ug
YWRkIGluc3RydWN0aW9ucyB0byBJQU5BIHRvIHVwZGF0ZSB0aGUgcmVnaXN0cnkgdG8gcG9pbnQg
dG8gdGhpcyBkb2N1bWVudCBpbnN0ZWFkIG9mIFJGQyA1MjQ1Lg0KDQpJQU5BIGFscmVhZHkgYXNr
ZWQgbWUgYWJvdXQgdGhhdCwgYnV0IEkgY2FuIGFkZCB0ZXh0Lg0KDQo9PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT0NCg0KQWxsIG9mIHRoZSBmb2xsb3dpbmcgYXJlIGVkaXRvcmlhbCBuaXRzLg0KDQo+IEouIFJv
c2VuYmVyZw0KPiBqZHJvc2VuLm5ldA0KPg0KPiBZb3UgbWlnaHQgd2FudCB0byBkb3VibGUtY2hl
Y2sgd2l0aCB0aGUgYXV0aG9yIHRoYXQgdGhpcyBpcyB0aGUgaW50ZW5kZWQgYWZmaWxpYXRpb24g
Zm9yIHRoaXMgZG9jdW1lbnQuDQoNCkluIGdlbmVyYWwgSSB0aGluayB0aGUgYXV0aG9ycyBzaG91
bGQgY2hlY2sgdGhhdCB0aGVtc2VsdmVzLCBidXQgaW4gdGhpcyBjYXNlIEkgY2FuIGRvIHRoYXQu
DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+ICBOb21pbmF0aW9uLCBSZWd1bGFyIE5vbWluYXRp
b246ICBUaGUgcHJvY2VzcyBvZiB0aGUgY29udHJvbGxpbmcgYWdlbnQNCj4gICAgIGluZGljYXRp
bmcgdG8gdGhlIGNvbnRyb2xsZWQgYWdlbnQgd2hpY2ggY2FuZGlkYXRlIHBhaXIgdGhlIElDRQ0K
PiAgICAgYWdlbnRzIHdpbGwgdXNlIGZvciBzZW5kaW5nIGFuZCByZWNlaXZpbmcgZGF0YS4NCj4N
Cj4gV2l0aCB0aGUgZXhjZXB0aW9uIG9mIGl0cyB1c2UgaW4gwqcxMyAod2hpY2ggSSB0aGluayBz
aG91bGQgYmUgcmVtb3ZlZCksIHRoZSB0ZXJtICJSZWd1bGFyIE5vbWluYXRpb24iICh3aGljaCB3
YXMgdXNlZCB0byBkaXN0aW5ndWlzaCANCj4gZnJvbSB0aGUgbm93LXJlbW92ZWQgYWdncmVzc2l2
ZSBub21pbmF0aW9uKSBkb2VzIG5vdCBhcHBlYXIgaW4gdGhpcyBkb2N1bWVudC4gSSBzdWdnZXN0
IGl0IGJlIHJlbW92ZWQgZnJvbSB0aGlzIGRlZmluaXRpb24uDQoNCkVrciBoYWQgdGhlIHNhbWUg
Y29tbWVudC4gQXMgcGVvcGxlIGRpZCByZXF1ZXN0IHRoYXQgd2Ugc2hvdWxkIG1ha2UgY2xlYXIg
dGhhdCBub21pbmF0aW9uIGluIHRoaXMgc3BlYyBpcyB3aGF0IHdhcyBjYWxsZWQgcmVndWxhciBu
b21pbmF0aW9uIGluIFJGQyA1MjQ1LCBJIHN1Z2dlc3RlZCB0aGUgZm9sbG93aW5nIG1vZGlmaWNh
dGlvbjoNCg0KTm9taW5hdGlvbjogIFRoZSBwcm9jZXNzIG9mIHRoZSBjb250cm9sbGluZyBhZ2Vu
dA0KICAgICAgaW5kaWNhdGluZyB0byB0aGUgY29udHJvbGxlZCBhZ2VudCB3aGljaCBjYW5kaWRh
dGUgcGFpciB0aGUgSUNFDQogICAgICBhZ2VudHMgd2lsbCB1c2UgZm9yIHNlbmRpbmcgYW5kIHJl
Y2VpdmluZyBkYXRhLiBUaGUgbm9taW5hdGlvbg0KICAgICAgcHJvY2VzcyBkZWZpbmVkIGluIHRo
aXMgc3BlY2lmaWNhdGlvbiB3YXMgcmVmZXJyZWQgdG8gInJlZ3VsYXIgbm9taW5hdGlvbiINCiAg
ICAgIGluIFJGQyA1MjQ1Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0Kwqc1LjM6DQoNCj4gIFRo
ZSB1c2luZyBwcm90b2NvbCBtYXkgKG9yIG1heSBub3QpIG5lZWQgdG8gZGVhbCB3aXRoIGJhY2t3
YXJkcyAgDQo+IGNvbXBhdGliaWxpdHkgd2l0aCBvbGRlciBpbXBsZW1lbnRhdGlvbnMgdGhhdCBk
byBub3Qgc3VwcG9ydCBJQ0UuICBJZiAgDQo+IHRoZSBmYWxsYmFjayBtZWNoYW5pc20gaXMgYmVp
bmcgdXNlZC4uLg0KPg0KPkl0J3Mgbm90IGNsZWFyIHdoYXQgInRoZSBmYWxsYmFjayBtZWNoYW5p
c20iIHJlZmVycyB0byBpbiB0aGlzIHNlbnRlbmNlLg0KDQpJdCBzaG91bGQgc2F5Og0KDQoiSWYg
YSBmYWxsYmFjayBtZWNoYW5pc20gdG8gbm9uLUlDRSBpcyBzdXBwb3J0ZWQsLi4uIg0KDQotLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0NCg0Kwqc2LjEuMi42Og0KDQo+ICAgICAgICAgICAgICAgICAgICAgIEZp
Z3VyZSA4OiBJbml0aWFsIFBhaXIgU3RhdGUNCj4NCj4gSSB0aGluayBjYWxsaW5nIHRoaXMgYSBm
aWd1cmUgaXMgcXVpdGUgYSBzdHJldGNoLiBJIHdhcyByZWFsbHkgdGhyb3duIGZvciBhIGxvb3Ag
YWZ0ZXIgcmVhZGluZyBmb3VyIHBhcmFncmFwaHMgdG8gZmluZCB0aGlzIA0KPiBub24tc2VxdWl0
dXIgbGFiZWwganVzdCBoYW5naW5nIG91dCBhdCB0aGUgZW5kIG9mIHRoZSBzZWN0aW9uLg0KDQpF
a3IgaGFkIHRoZSBzYW1lIGNvbW1lbnQuIEkgc3VnZ2VzdCB0byByZW1vdmUgdGhlIEZpZ3VyZSB0
ZXh0Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KwqcxNC4zOg0KDQo+ICAgIFJUTyA9IE1BWCAo
NTAwbXMsIFRhKk4gKiAoTnVtLVdhaXRpbmcgKyBOdW0tSW4tUHJvZ3Jlc3MpKQ0KPg0KPkkgY2Fu
J3QgdGVsbCB3aGV0aGVyIHRoZSAiKk4iIGluICJUYSpOIiBpcyBhIHR5cG8sIG9yIGlmIHRoZSBk
b2N1bWVudCBzaW1wbHkgZG9lc24ndCBkZWZpbmUgdGhlIG1lYW5pbmcgb2YgIk4iIGFueXdoZXJl
LiANCj5QbGVhc2UgZWl0aGVyIGZpeCB0aGUgZm9ybXVsYSwgb3IgYWRkIGEgZGVzY3JpcHRpb24g
b2YgdGhlIG1lYW5pbmcgb2YgIk4uIg0KDQpOIGlzIGRlZmluZWQgaW4gU2VjdGlvbiAxNC4xLg0K
DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg==


From nobody Wed Feb 21 16:36:55 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE50129BBF for ; Wed, 21 Feb 2018 16:36:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 91Pzr7XSqYFm for ; Wed, 21 Feb 2018 16:36:53 -0800 (PST)
Received: from mail-pl0-x230.google.com (mail-pl0-x230.google.com [IPv6:2607:f8b0:400e:c01::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 E4B871200E5 for ; Wed, 21 Feb 2018 16:36:52 -0800 (PST)
Received: by mail-pl0-x230.google.com with SMTP id u13so1935793plq.1 for ; Wed, 21 Feb 2018 16:36:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=4BXnuiwNKtMVeArl1qrtrtM/NwvW8rpQaUb0kbrxve8=; b=VePgpDo8vIWaZ5I9DVX11rTgJUK+sS43FhHhbdBYWnb7/JS+I1QikKqaot3K5zLKEW bubXWlx9y12OS+Chz3kmWG1RPCe1F8p6xLAwzH/fYlPRHBy+gMuH58Ue3Q4tWXN0/Lwr HZKdtVdTTmmbD8/HXt53RR3aBGU+VyM/kPM0o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=4BXnuiwNKtMVeArl1qrtrtM/NwvW8rpQaUb0kbrxve8=; b=jOZonQXBlFkgvlvt8yqc1Jo39X7fg9E+5zERXL2UmfEGbfdtrCp/0OkueMgDwKVRwr FMrKeqkdTVXKfOl0+iMlJb5ii+S0t21LdZbBk5/TT6fFjfPFIC/AdaBIQfwMH2pAj8Nt 3A61PeFP0EB6tJt3LawUNYmZl2o0w2iRvI7OWR9MhbKNjCJVlUoUCDZ6HMWpRvlXMjgq pT/PBo1OSLJn31GXG1Roh/kDnItJHsrlKs+rMRGR4Y6dg+SqKwC5u0m1U2iK+jcmNorc w+ueUMf0gewA+IdkQYlzU2T41MsmUviANYvWCbgklRTuxTgaby5EiG/zEYYDnKWnzzb9 U44Q==
X-Gm-Message-State: APf1xPBXsdVSvrOUHBaDqC1t0YJSrhzQL8UOcX/FDqjnw3CCSr1ZW4lo 1dGCBhBnTBxNR8YbNKEZScV7ig==
X-Google-Smtp-Source: AH8x225lspVK3xFzRyfeELkpFtzwLw8VXwxs9VC/S1YFAV94J8b4K6allCP+Z1hJsdeAYG4dWb77tA==
X-Received: by 2002:a17:902:5a4a:: with SMTP id f10-v6mr4762766plm.308.1519259812175;  Wed, 21 Feb 2018 16:36:52 -0800 (PST)
Received: from dragon.local ([2620:101:80f4:224:38da:32b0:3821:d1f4]) by smtp.gmail.com with ESMTPSA id q76sm16257229pfj.149.2018.02.21.16.36.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Feb 2018 16:36:51 -0800 (PST)
To: ice@ietf.org
References: 
From: Peter Saint-Andre 
Message-ID: <754e7198-83c2-14d0-1983-2ed355a48ed8@mozilla.com>
Date: Wed, 21 Feb 2018 16:36:49 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Wb60PaofxumrMP2gYMkJxEUVBW9r1w0rt"
Archived-At: 
Subject: Re: [Ice] Changes to draft-ietf-ice-rfc5245bis-17 (from -16)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Feb 2018 00:36:55 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Wb60PaofxumrMP2gYMkJxEUVBW9r1w0rt
Content-Type: multipart/mixed; boundary="Nhad3FENdNH7n6EPzHxV6qzVadAtB963u";
 protected-headers="v1"
From: Peter Saint-Andre 
To: ice@ietf.org
Message-ID: <754e7198-83c2-14d0-1983-2ed355a48ed8@mozilla.com>
Subject: Re: [Ice] Changes to draft-ietf-ice-rfc5245bis-17 (from -16)
References: 
In-Reply-To: 

--Nhad3FENdNH7n6EPzHxV6qzVadAtB963u
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2/21/18 8:52 AM, Peter Thatcher wrote:
> ICEbis has been making steady progress through IESG review.=C2=A0 Chris=
ter
> has been doing a great job responding to all the comments there,=20

Big thanks to Crister for his quick and efficient processing of feedback!=


> mostly
> editorial ones.=C2=A0 If you'd like to keep up on the changes to ICEbis=
,
> here's a diff from -16 to -17:
>=20
> https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-ice-rfc5245bis-16&url2=3D=
draft-ietf-ice-rfc5245bis-17&difftype=3D--html

IMHO that all looks good.

Peter



--Nhad3FENdNH7n6EPzHxV6qzVadAtB963u--

--Wb60PaofxumrMP2gYMkJxEUVBW9r1w0rt
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqOEKEACgkQZWGMGH9o
FKlf2A//S+Ly2Xs7N1yB19L1Gv3DojbCTIQHIG4JmGbRhT8Sa8NAYw1y0p5B3Sxk
+eciuAZXIIXs57gAhzBOvNxlh6GBoVAX51J5+EHGj730OubaE/jGCOIPTCKRLzge
dTH7UJ8ZYuhaJeSy/wz4Y7Eols8LfrBYV1KSF5/DkJUWHfk4uZXfEUjxSpiUML5+
oLSXXY4fEmRq0bUNUIK/xfHuc7krqHGpKy4HD4erNEO4sM2Iz5mxGnm5+I2Za016
W+CplPq60br7y5BaktGFYsaSvMysLdB5UgFZzulMeKxjapsCehDGysmpg5KQWtD8
6CM1/bIL04xXdZ6EVoJ+zpu7jOYdVPMB1Ksd6ApyduDsHDWFUWr1k2zgl3bndR5i
/iKs0sN0oMz78+dYxAWcxYoEy71bWNjaX2SxK+5upBhY3Yd7jYiu6ay37DE5CzO0
zSgXCQc8PMixXTFp6sqtzXXZnd43Xo6luM/shLP5kPua0wdde/XB8PoIsgfa4x6F
oat8vNPLlV6zk0cbFyfl2DMkL8mlOK0S5FA7zYHWTd9tWC6vZkXvnNxkl3ZU5FnX
QLR6rkoTnNjiaTdhsBn6ZEPUluFr7DEfsNVtKsZ7kuG2HqFfF9ZJT4uHUQuTZxVp
0fIAWgKR5n3r5YknvF6+VqyUg6QjIAuY3m/0EWOnOBtTkOU6BZo=
=K9m0
-----END PGP SIGNATURE-----

--Wb60PaofxumrMP2gYMkJxEUVBW9r1w0rt--


From nobody Thu Feb 22 11:38:32 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D0712D9FF for ; Thu, 22 Feb 2018 11:38:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 ngsBhUi5d_pN for ; Thu, 22 Feb 2018 11:38:29 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 7C382129BBF for ; Thu, 22 Feb 2018 11:38:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519328307; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uCsaBDil1gOipwBf0/j48pCoe6FyJ6n9NHD5C/+97j8=; b=YmCrmqsb7PiTyZYHRpeb0ePHzvOj5ex4rvsXu3E+xnNDDnCcFJMwIxL/ynXQXR4B QOOJLo5cueS9IpWGIPwLuOIQDTGU0aPaXoGiRQJcRhaKv4YFXSAPAyH3HzK0ohQF EBjrzzj5ICcJa7ffRDB20J5IEEmGnyIEbiSo6tC3Vhk=;
X-AuditID: c1b4fb30-3b1ff70000004778-a4-5a8f1c33d3e1
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CF.92.18296.33C1F8A5; Thu, 22 Feb 2018 20:38:27 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Thu, 22 Feb 2018 20:38:27 +0100
From: Christer Holmberg 
To: Peter Saint-Andre , Ben Campbell 
CC: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "draft-ietf-ice-trickle.all@ietf.org" , "ice@ietf.org" 
Thread-Topic: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle - ice-options
Thread-Index: AdOsFMDbZWm2/HY4S0+5McSejW57Gg==
Date: Thu, 22 Feb 2018 19:38:26 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C17CCBD@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.166]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM2K7tK6xTH+UwdRthhbzO0+zWxz/8Yfd 4smHn6wW3y7UWhzb08/swOqxZMlPJo9ZO5+weMzd84I5gDmKyyYlNSezLLVI3y6BK+Piqxa2 gmsqFYePfWdvYLyj3MXIySEhYCKx5VUvWxcjF4eQwGFGiQnXtkM5SxglFh0/yNzFyMHBJmAh 0f1PG6RBRMBL4vC7W+wgNcwCxxklNp3cwQqSEBZIkziy+TcrRFG6xKmT+6FsPYnut62MIDaL gKrE+b7FYHFeAV+J3WuXgcUZBcQkvp9awwRiMwuIS9x6Mp8J4joBiSV7zjND2KISLx//Y4Ww lSSOnr7ECnIbs4CmxPpd+hCtihJTuh+yQ4wXlDg58wnLBEbhWUimzkLomIWkYxaSjgWMLKsY RYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAmPj4JbfBjsYXz53PMQowMGoxMNbw94fJcSaWFZc mXuIUYKDWUmEd48QUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvSU/eKCGB9MSS1OzU1ILUIpgs EwenVAPjnMuFRaG1ui1bDrvqHHP4snrbciHzsvVTHsbv6rDmTDz8ds6hyt/9vzMV/4rvmBc7 3aTDwqbld/bEdT+lou/8Zv394KpthVHDgtdal9tKvwTzzj9xr1pufYdL96FlDgzv+je0vuve fWFPq14J78f5W6YoLNS6/Hnus+tyijvfepjNUtidwfIkX4mlOCPRUIu5qDgRALNDOeaJAgAA
Archived-At: 
Subject: Re: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle - ice-options
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Feb 2018 19:38:31 -0000

SGksDQoNCkl0IHNlZW1zIGxpa2UgSSBtaXNzZWQgdGhpcyBjb252ZXJzYXRpb24gKHRoYW5rcyB0
byBBcmkgZm9yIHJlbWluZGluZyBtZSkuDQoNCjUyNDViaXMgZG9lcyB0YWxrIGFib3V0IGljZSBv
cHRpb25zLCBidXQgaW4gbXkgb3BpbmlvbiB0aGUgdGV4dCBpbiBTZWN0aW9uIDEzIG5lZWRzIHRv
IGJlIG1vZGlmaWVkLCB0byBiZSBtb3JlIGdlbmVyaWMuDQoNCkkgc3VnZ2VzdCB0aGUgZm9sbG93
aW5nIG1vZGlmaWNhdGlvbjoNCg0KT0xEOg0KDQogICBGaXJzdCwgSUNFIHByb3ZpZGVzIHRoZSBp
Y2Utb3B0aW9ucyBhdHRyaWJ1dGUuICBFYWNoIGV4dGVuc2lvbiBvcg0KICAgY2hhbmdlIHRvIElD
RSBpcyBhc3NvY2lhdGVkIHdpdGggYSB0b2tlbi4gIFdoZW4gYW4gYWdlbnQgc3VwcG9ydGluZw0K
ICAgc3VjaCBhbiBleHRlbnNpb24gb3IgY2hhbmdlIHRyaWdnZXJzIGNhbmRpZGF0ZSBleGNoYW5n
ZSwgaXQgTVVTVA0KICAgaW5jbHVkZSB0aGUgdG9rZW4gZm9yIHRoYXQgZXh0ZW5zaW9uIGluIHRo
aXMgYXR0cmlidXRlLiAgVGhpcyBhbGxvd3MNCiAgIGVhY2ggc2lkZSB0byBrbm93IHdoYXQgdGhl
IG90aGVyIHNpZGUgaXMgZG9pbmcuICBUaGlzIGF0dHJpYnV0ZSBNVVNUDQogICBOT1QgYmUgcHJl
c2VudCBpZiB0aGUgYWdlbnQgZG9lc24ndCBzdXBwb3J0IGFueSBJQ0UgZXh0ZW5zaW9ucyBvcg0K
ICAgY2hhbmdlcy4NCg0KTkVXOg0KDQogICBGaXJzdCwgSUNFIHByb3ZpZGVzIHRoZSBJQ0Ugb3B0
aW9uIGNvbmNlcHQuICBFYWNoIGV4dGVuc2lvbiBvcg0KICAgY2hhbmdlIHRvIElDRSBpcyBhc3Nv
Y2lhdGVkIHdpdGggYW4gSUNFIG9wdGlvbi4gIFdoZW4gYW4gYWdlbnQgc3VwcG9ydHMNCiAgIHN1
Y2ggYW4gZXh0ZW5zaW9uIG9yIGNoYW5nZSwgaXQgcHJvdmlkZXMgdGhlIElDRSBvcHRpb24gdG8g
dGhlIHBlZXIgYWdlbnQNCiAgIGFzIHBhcnQgb2YgdGhlIGNhbmRpZGF0ZSBleGNoYW5nZS4NCg0K
KFNlY3Rpb24gMTAgYWxyZWFkeSBzYXlzIHRoYXQgdGhlIGVuY29kaW5nIG9mIHRoZSBJQ0Ugb3B0
aW9uIGlzIHVzYWdlLXNwZWNpZmljLCBzbyBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8gcmVwZWF0
IHRoYXQgaW4gc2VjdGlvbiAxMy4pDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBldGVyIFNhaW50LUFuZHJlIFttYWlsdG86c3Rw
ZXRlckBzdHBldGVyLmltXSANClNlbnQ6IDAxIEZlYnJ1YXJ5IDIwMTggMjI6NTQNClRvOiBCZW4g
Q2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbT4NCkNjOiBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1Ymlz
LmFsbEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1pY2UtdHJpY2tsZS5hbGxAaWV0Zi5vcmc7IGljZUBp
ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJY2VdIGljZS1vcHRpb25zIGluIGRyYWZ0LWlldGYtaWNl
LXJmYzUyNDViaXMgYW5kIGRyYWZ0LWlldGYtaWNlLXRyaWNrbGUNCg0KT24gMi8xLzE4IDE6NTEg
UE0sIEJlbiBDYW1wYmVsbCB3cm90ZToNCj4gDQo+IA0KPj4gT24gRmViIDEsIDIwMTgsIGF0IDI6
MDcgUE0sIFBldGVyIFNhaW50LUFuZHJlIDxzdHBldGVyQHN0cGV0ZXIuaW0+IHdyb3RlOg0KPj4N
Cj4+IE9uIDEvMzEvMTggOTo0NyBQTSwgQmVuIENhbXBiZWxsIHdyb3RlOg0KPj4+IFRoYW5rcyBm
b3IgeW91ciBxdWljayByZXNwb25zZSwgUGV0ZXI7IHRoaXMgZGlzY3Vzc2lvbiB3YXMgDQo+Pj4g
aGVscGZ1bOKAlHBhcnRpYWxseSBieSBicmluZ2luZyB1cCBhIHNlcGFyYXRlIGJ1dCByZWxhdGVk
IHF1ZXN0aW9uIA0KPj4+IChtb3JlIGZvciA1MjQ1YmlzIHRoYW4gZm9yIGljZS10cmlja2xlKToN
Cj4+Pg0KPj4+IFNlY3Rpb24gMTMgb2YgNTI0NWJpcyB0YWxrcyBhYm91dCBhIHNlcmllcyBvZiB0
b2tlbnMgZm9yIA0KPj4+IOKAnGljZS1vcHRpb25z4oCdLiBCdXQgc2luY2UgdGhlIGljZS1vcHRp
b25zICBTRFAgYXR0cmlidXRlIGluIG5vIGxvbmdlciANCj4+PiBkZWZpbmVkIGluIDUyNDViaXMs
IGRpZCB3ZSBsb3NlIHRoZSB0ZXh0IHRoYXQgc2F5cyB0aGF0IHRoZSBJQ0UgDQo+Pj4gb3B0aW9u
IG5lZWRzIHRvIGJlIGFibGUgdG8gY2FycnkgbXVsdGlwbGUgdGFncywgd2hhdGV2ZXIgdGhlIA0K
Pj4+IHNpZ25hbGluZyBwcm90b2NvbCBpcz8NCj4+DQo+PiBJIGRvbid0IHdhbnQgdG8gc3BlYWsg
Zm9yIHRoZSA1MjQ1YmlzIGF1dGhvcnMsIGJ1dCBpdCBzdHJpa2VzIG1lIHRoYXQgDQo+PiB0aGUg
ZXhhY3QgZm9ybSBvZiAidGhlIElDRSBvcHRpb24iIHdpbGwgZGVwZW5kIG9uIHRoZSBzaWduYWxp
bmcgDQo+PiBwcm90b2NvbC4gVGhhdCBpcywgaXQncyBub3QgbmVjZXNzYXJpbHkgdGhlIGNhc2Ug
dGhhdCBzeW50YWN0aWNhbGx5IA0KPj4gdGhlIHNpZ25hbGluZyBwcm90b2NvbCB3aWxsIGRlZmlu
ZSBhIHNpbmdsZSBjb25zdHJ1Y3QgZm9yICJ0aGUgSUNFIG9wdGlvbiINCj4+IHRoYXQgaXRzZWxm
IGNhbiBpbmNsdWRlICJtdWx0aXBsZSB0YWdzIiAtIHRoYXQgc3ludGF4IG1pZ2h0IGJlIHRydWUg
DQo+PiBmb3IgU0RQIGJ1dCBub3Qgb3RoZXIgc2lnbmFsaW5nIHByb3RvY29scy4NCj4gDQo+IFN1
cmUsIEkgZ3Vlc3MgSSBtZWFudCB0aGlzIG1vcmUgY29uY2VwdHVhbGx5IHRoYW4gc3ludGFjdGlj
YWxseS4gQnV0IA0KPiBpZiBhbiBhcHBsaWNhdGlvbiBzdXBwb3J0cywgZm9yIGV4YW1wbGUsIG5v
IGljZSwgNTI0NWJpcywgb3IgNTQyNWJpcyANCj4gd2l0aCB0cmlja2xlLCB0aGVuIHlvdSBuZWVk
IHRvIGJlIGFibGUgdG8gZGlzdGluZ3Vpc2ggYmV0d2VlbiB0aG9zZS4gDQo+IChOb3QgdG8gbWVu
dGlvbiBpZiB0aGV5IHN1cHBvcnQgNTI0NSBsZWdhY3kgYXMgYSBzZXBhcmF0ZSBtb2RlLikNCg0K
SW5kZWVkLg0KDQo+PiBGb3IgaW5zdGFuY2UsIGluIFhNUFAgKGZvciB3aGljaA0KPj4gd2Ugc3Rp
bGwgbmVlZCB0byB1cGRhdGUgdGhlIHJlbGV2YW50IEppbmdsZSB0cmFuc3BvcnQgbWV0aG9kIFsx
XSksIA0KPj4gdGhlIGZhY3QgdGhhdCBhbiBlbnRpdHkgc3VwcG9ydHMgImljZTIiIGFuZCAidHJp
Y2tsZSIgd2lsbCBiZSANCj4+IHNpZ25hbGVkIGJ5IGFkdmVydGlzaW5nIHRoZSAndXJuOnhtcHA6
amluZ2xlOnRyYW5zcG9ydHM6aWNlOjAnIFhNTCANCj4+IG5hbWVzcGFjZSAod2hlcmVhcyBzdXBw
b3J0IGZvciBwcmUtaWNlMiBpcyBzaWduYWxlZCBieSBhZHZlcnRpc2luZyANCj4+IHRoZSBvbGRl
ciAndXJuOnhtcHA6amluZ2xlOnRyYW5zcG9ydHM6aWNlLXVkcDoxJyBuYW1lc3BhY2UnIGRlZmlu
ZWQgaW4gWEVQLTAxNzYpLg0KPiANCj4gSUlSQywgSmluZ2xlIGFzc3VtZXMgdHJpY2tsZSBpZiB5
b3Ugc3VwcG9ydCBJQ0UsIGNvcnJlY3Q/DQoNClllcywgdGhhdCdzIGJlZW4gdGhlIHByaW1hcnkg
ZGF0YSB0cmFuc2ZlciBtZXRob2QgaW4gSmluZ2xlIHNpbmNlIHRoZSBiZWdpbm5pbmcuDQoNClBl
dGVyDQoNCg==


From nobody Thu Feb 22 11:50:57 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9AA129BBF; Thu, 22 Feb 2018 11:50:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 3H5Oc52MzgJF; Thu, 22 Feb 2018 11:50:48 -0800 (PST)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ADF9124BE8; Thu, 22 Feb 2018 11:50:48 -0800 (PST)
X-AuditID: 12074425-1a1ff70000006976-a5-5a8f1f14f5f1
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id EF.2F.26998.51F1F8A5; Thu, 22 Feb 2018 14:50:46 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w1MJoeBC015791; Thu, 22 Feb 2018 14:50:41 -0500
Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w1MJoZdo024220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Feb 2018 14:50:38 -0500
Date: Thu, 22 Feb 2018 13:50:36 -0600
From: Benjamin Kaduk 
To: Christer Holmberg 
Cc: IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , "pthatcher@google.com" , "ice@ietf.org" 
Message-ID: <20180222195035.GS54688@mit.edu>
References: <20180220220002.GS54688@mit.edu> <7594FB04B1934943A5C02806D1A2204B6C17B1A8@ESESSMB109.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C17B1A8@ESESSMB109.ericsson.se>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA02SX0hTURzHPfds8zi8dXb9d9JEWkplzbQ0hoVGiCzDih4HYVd355bbnd27 iYrFqBhhqGk+6CrSlCQJS1/soQhn/ywGM7EtorAyaTN6MAzMKe1qam+/c76f7/fLOfwQZFrl ycjM2zmBZy1qhVLGRBekaxLTWvTZoVCq1tc5CrS3x/xQO+6+rtD+9p3XdoRbofZd36z8sEL3 Z35Soesacuh6exeok1CvPGTgLOYaTthbcEZpanrQCKu/FdYOTCU4gT+7EcQggnNJ52Q71QiU iME9FOnpHpGvHgYBGfbf+Kd4KXL/xZSiESAkwxlkfDlWcitwOnFenYDSHI8PEP+vphUe4osU mfBelklCHC4jbYFBKHlpvId0eZF0zeBq0j/sjpZmGqvIWOf0Cg5xJgksBykJhziF9C0jaYzB x8nC3UKJSMDbyZNmT/Q1gN3/md3/md0b5i4A+0GqwVqvsbJmi8hVaMQKluc5QaPNsprtWZzB MQRW/rko4xG4uVTiARgBdSwdJTTpGTlbI9ZZPWALotQJNKxv1jObym2GOhMrmsoEh4UTPYAg qI6nHzMteoY2sHX1nGBbk1KQTJ1E63J36xlcydq5Ko6r5oQ1dStCakI/TI0YVQJXydUazRb7 hkyhGCk8NhLeITG0WM1aRXPlqv4a7Efhz0EXRIHvsy7IyHgbzyUn0cUSiiXU5ODX06RNIlVP G0IgKfK4OLpHomIje7aeF4pUUZEqn7JJqrKzG1KyEwDHvpFjHd335oKJPxfTtikmS4uN8Xy4 ZdiZlGIc9ZfM6p2n9V22Bu+zqJRA0HjL9Sad6sgvHfhQo/mYpsmpBWZd3jR9tGDXEbhj5n0Z Z6wq33lKdfaLytV+5S1TFAw7li4tnvvqCm9+NQf62/jZO59mfAdfnsjDF3Ln85//UMtEE5uT CQWR/Qvang8qJAMAAA==
Archived-At: 
Subject: Re: [Ice] Benjamin Kaduk's practice ballot on draft-ietf-ice-rfc5245bis-17: (with COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Feb 2018 19:50:51 -0000

On Wed, Feb 21, 2018 at 07:30:50PM +0000, Christer Holmberg wrote:
> Hi Ben,
> 
> Thank You for the review and comments! Please see inline.
> 
> >Given that this is a -bis document, there are some areas that may have aged poorly and could benefit from reconsideration:
> 
> Yes. The focus of the bis work was to fix bugs, and clarify procedures. But, if outdated information is found we can of course fix that.
> 
> > In Section 5.2, we say that for the Lite implementation, preferring
> > IPv4 is RECOMMENDED for dual-stack hosts.  Is that still the advice we want to give?
> 
> Suresh had the same comment. I suggest to remove the sentence.

Ok.

> > Section 17 is very focused on voice traffic; is that still the main use of ICE?
> 
> In my opinion it is.

Voice to the exclusion of video, or does that include voice+video?

> ---
> 
> >Appendix B.8 has:
> >
> >   Additionally, using a Binding Indication allows integrity to be
> >   disabled, allowing for better performance.  This is useful for large-
> >   scale endpoints, such as PSTN gateways and SBCs.
> >
> > which talks of disabling STUN's MESSAGE-INTEGRITY as a potential benefit.  Do we really want to advocate for 
> > increased levels of unauthenticated plaintext on the internet?
> 
> I wouldn't say that we are advocating. The truth is that people don't see it feasibly to integrity protect keep-alives.

I suppose I will have to defer to your experience, but that seems
surprising to me and not consistent with my viewport into the usage of
crypto in other areas.

> ---
> 
> >Appendix C has a table of bandwidth consumption in various scenarios, most of which are measured in kilobits per second.  Is this still relevant to modern deployments?
> 
> Appendix C was added to the bis document, based on real measurements (brought by Google, as far as I remember), so they are relevant.

Ok.  Sorry for not noticing it was new.

> ---
> 
> >Some other general comments/questions.
> >
> >
> >I was also a little confused in Section 6.1.2.2, where we say
> >
> >   for each interface.  To keep the amount of resulting candidate pairs
> >   reasonable and to avoid candidate pairs that are highly unlikely to
> >   work, IPv6 link-local addresses [RFC4291] MUST NOT be paired with
> >   other than link-local addresses.
> >
> > but in section 5.1.1.1 we say that IPv6 link-local addresses MUST NOT be gathered.  
> > Is this just to handle the chance that we might get a reflexive candiate for a link-local address?
> 
> Well, even if that happens, it shouldn't be used in my opinion.
> 
> I suggest to remove the text in Section 6.1.2.2, to avoid confusion.

Ok.

> ---
> 
> >Section 13 has:
> >
> >   Consequently, any future ICE enhancements MUST
> >   preserve triggered checks.
> >
> > which does not seem like an enforceable requirement, given that future updates to this document could just remove it.  
> > Perhaps it should be worded differently to give the motivation for the need to keep triggered checks.
> 
> Perhaps we could remove the sentence. There are many things that extensions need to keep, and I don't see any reason to just mention one of them. And, triggered checks isn't even needed for ICE to work - it's just an optimization.

Okay.  I have no strong preference for any given change (or not
change) here, and trust your judgment.

> ---
> 
> >In section 14.3:
> >
> >   For connectivity checks, agents SHOULD calculate the RTO value using
> >   the following formula:
> >
> >     RTO = MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress))
> >
> > What is 'N'?
> 
> The number of checks to be performed. See section 14.1.

Given that the other terms have their own prose description after
the formula, I would suggest doing so for N as well, as a reminder.

> ---
> 
> >In Section 15:
> >
> >   will succeed.  Consequently, agent R constructs a new candidate pair
> >   using the mapped address from the response as the local candidate (R-
> >   PUB-1) and the destination of the request (NAT-PUB-1) as the remote
> >   candidate.  This pair is added to the valid list for that data
> >   stream.
> >
> > which leaves me confused, perhaps just about which response is "the response" that we're taking the mapped address from.  
> > The previous text is about a STUN Binding request from L to R that causes R to generate a triggered check, so is this the response 
> > that R generates to the Binding request from L?
> 
> Correct.
> 
> >  IIUC the mapped address therein would be where R sees traffic from L as originating 
> > from, and would not be appropriate to use as a local address for R, etc..  So presumably I am picking the wrong response to use as the 
> > source of data.
> 
> I think you are picking the right response :)

Forgive me for being dense.  Does this mean that a change in the
text is needed?

> ---
> 
> > In Section 18.3:
> >
> >   [...] The process of determining
> >   connectivity is very robust.
> >
> > This seems to contrast with section 14.1, where
> >
> >   The loss of the first single packet for any
> >   connectivity check is likely to cause that pair to take a long time
> >   to be validated, and instead, a lower-priority check (but one for
> >   which there was no packet loss) is much more likely to complete
> >   first.
> 
> What is meant in 18.3 is that ICE is very robust when it comes to finding *A* connectivity, as there is no single point of failure in the network (you can use multiple STUN servers etc).

Ok.

> ---
> 
> > Something of a side note, but is HMAC-SHA1 still the state of the art for STUN MESSAGE-INTEGRITY?  
> > I know that there are no known breaks against HMAC-SHA1, but I would be a little surprised if no one was interested in producing an update.
> 
> RFC 5389 (STUN) uses HMAC-SHA1.

Right.  IIUC we use the STUN MESSAGE-INTEGRITY structure to protect
certain ICE messages, so it is at least somewhat relevant.

> Anyway, I don't think it is mentioned in the 5245bis document, is it?

I don't think so, which is why it's a side note and mostly for my
curiousity.

> ---
> 
> >In Section 19.3:
> >
> >   However, TURN servers are susceptible to DNS attacks for purposes of
> >   turning it into a zombie or rogue server.  These attacks can be
> >   mitigated by DNS-SEC and through good box and software security on
> >   TURN servers.
> >
> > I don't understand this.  Is the ICE agent or the TURN server "turned into" a zombie or rogue server by DNS attacks?  
> > If the TURN server, how would a bogus DNS response turn it into a rogue server?
> 
> I will have to come back on the security related comments, because I need input from others.

Sure.

Thanks again,

Benjamin

> ---
> 
> >On an editorial note, there is a general feel to the document that it started off life as only covering ICE for RTP and the application 
> >profiling was later split off into separtae documents.  I don't know that it's worth the effort to try to change that, though.  I might 
> >give some thought to factoring out some of the duplicated content, though, such as discussion of how RTP gets component ID 1 and 
> >RTCP id 2, and I think Ekr noted some other areas of duplication.
> >
> > Other purely editorial nits follow (IESG feel free to ignore).
> 
> ---
> 
> >Section 18.2:
> >
> >   Therefore, the servers get used less and
> >   less, and can eventually be remove when their usage goes to zero.
> >
> >*removed
> 
> I will fix as suggested.
> 
> ---
> 
> >Section 19.4:
> >
> >   In addition to attacks where the attacker is a third party trying to
> >   insert fake candidate information or stun messages,
> >
> > s/stun/STUN/
> 
> I will fix as suggested.
> 
> ---
> 
> >Section 21:
> >
> >   o  Make technical changes, due to discovered flows in RFC 5245 and
> >      based on feedback from the community that has implemented and
> >      deployed ICE applications based on RFC 5245.
> >
> > flows or flaws?
> 
> Flaws :) I will fix it.
> 
> ---
> 
> Regards,
> 
> Christer
> 


From nobody Thu Feb 22 12:06:44 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538C312D95B for ; Thu, 22 Feb 2018 12:06:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTuetCmCzAQx for ; Thu, 22 Feb 2018 12:06:15 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 9081F12D95A for ; Thu, 22 Feb 2018 12:06:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519329973; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GAPiGwkPoo1LebxkwJLBS0NjMyAoF4om7O/F5VPQYDs=; b=Cgd4vwoG8T/4aMjcw4Lj0t6N3jG87xciXOfOFq6TpoVeTDeyaKZGUrFfF38KR3Xr DmY8G5m3eWl6ripInOhsIQL/9FA1G37HuaTJvv98aHmaQlAuZ8isf4PQ8RXwjzsu GE4e3UOzlw9MMJBrOyfIGP6sMk/EE35a4Dwm7jf0ktM=;
X-AuditID: c1b4fb3a-35fff700000067b4-09-5a8f22b5b8fb
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 71.64.26548.5B22F8A5; Thu, 22 Feb 2018 21:06:13 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0352.000; Thu, 22 Feb 2018 21:06:13 +0100
From: Christer Holmberg 
To: Eric Rescorla , The IESG 
CC: "draft-ietf-ice-rfc5245bis@ietf.org" ,  Peter Thatcher , "ice-chairs@ietf.org" , "pthatcher@google.com" , "ice@ietf.org" 
Thread-Topic: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (Security Considerations)
Thread-Index: AdOpa92am2EAedaETYymCVvuj0ZDJw==
Date: Thu, 22 Feb 2018 20:06:12 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C17CDFA@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.166]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2K7ge5Wpf4og+e3TCzmn7zObLHi9Tl2 i4uzJrNZfLtQazHjz0Rmi2vLX7M6sHks2FTqsWTJTyaPyY/bmAOYo7hsUlJzMstSi/TtErgy Jm09wVwwS7GiddoDpgbGNQpdjJwcEgImEo823WAFsYUEDjNKtKwJ72LkArKXMEq0NnUwdTFy cLAJWEh0/9MGqRERsJJ49fsaC0gNs8BXRokVG3cygSSEBUolzl7ZxgRRVCbxomk6lK0nsfLn NrAFLAKqEhNXPQWzeQV8JXbvfsAIYjMKiEl8P7UGrJ5ZQFzi1pP5TBDHCUgs2XOeGcIWlXj5 +B8rhK0kcfT0JVaQ25gFNCXW79KHaFWUmNL9kB1ivKDEyZlPWCYwCs9CMnUWQscsJB2zkHQs YGRZxShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYIQe3/LbawXjwueMhRgEORiUe3j75/igh 1sSy4srcQ4wSHMxKIrx7hIBCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeZ3SLKKEBNITS1KzU1ML UotgskwcnFINjIUzRDculr7GvHjfjtzenV++SoXMXtsSt/XZAtNrcqULi1ZcOKJRPU33aW/t BP/KFQnsKVtbpNiuvd1c0ud4gWHPwtYGrgW2gn6zFbes5hfS1tvPkG89X+N9yLqXjnMUWgNv 6ga+aUsOEjCrC5nEy33lWKGs2kbmHesT1t5b8cvLO94vfanfIiWW4oxEQy3mouJEAP6kOo2M AgAA
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Feb 2018 20:06:43 -0000

SGksDQoNCkkgaGF2ZSB0byBhZG1pdCB0aGF0IEkgYW0gbm90IHZlcnkgZ29vZCBhdCBhZGRyZXNz
aW5nIEVrcidzIGNvbW1lbnRzIG9uIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAoYW5kIGhp
cyBjb21tZW50IG9uIFNUVU4gcGFjaW5nKSBpbiBhIGdvb2Qgd2F5LCBzbyBJIHJlYWxseSBuZWVk
IHNvbWUgaGVscCBmcm9tIG90aGVycy4NCg0KLS0tDQoNCj4gICBzb21ldGhpbmcgaW5jb3JyZWN0
IGFib3V0IHRoZSByZXN1bHRzIG9mIHRoZSBjb25uZWN0aXZpdHkgY2hlY2tzLg0KPiAgIFRoZSBw
b3NzaWJsZSBmYWxzZSBjb25jbHVzaW9ucyBhbiBhdHRhY2tlciBjYW4gdHJ5IGFuZCBjYXVzZSBh
cmU6DQo+IElNUE9SVEFOVDogVGhpcyBzZWN0aW9uIHdvdWxkIGJlIGEgbG90IHN0cm9uZ2VyIGlm
IGl0IHdhcyBmYWN0b3JlZCBieSBhdHRhY2tlciBjYXBhYmlsaXRpZXMgYXMgd2VsbC4gQXMtaXMg
aXQgaXMgdmVyeSBoYXJkIHRvIHVuZGVyc3RhbmQuDQoNCkluIHNvbWUgY2FzZXMgdGhlIGF0dGFj
a2VyIG9ubHkgbmVlZHMgdG8gYmUgYWJsZSB0byBjYXB0dXJlIHRoZSBiaW5kaW5nIHJlcXVlc3Qs
IGFuZCBkaXNjYXJkIGl0Lg0KDQpJbiBvdGhlciBjYXNlcyB0aGUgYXR0YWNrZXIgYWxzbyBuZWVk
cyB0byBoYXZlIGFjY2VzcyB0byB0aGUgc2VjdXJpdHkgY3JlZGVudGlhbHMsIGluIG9yZGVyIHRv
IGdlbmVyYXRlL21vZGlmeSBtZXNzYWdlcy4NCg0KT3IsIGRpZCB5b3UgaGF2ZSBzb21ldGhpbmcg
ZWxzZSBpbiBtaW5kPw0KDQotLS0NCg0KPiAgIHBvc3NpYmxlIGF0dGFjay4gIEZvcnR1bmF0ZWx5
LCB0aGlzIGF0dGFjayBpcyBtaXRpZ2F0ZWQgY29tcGxldGVseQ0KPiAgIHRocm91Z2ggdGhlIFNU
VU4gc2hvcnQtdGVybSBjcmVkZW50aWFsIG1lY2hhbmlzbS4gIFRoZSBhdHRhY2tlciBuZWVkcw0K
PiAgIHRvIGluamVjdCBhIGZha2UgcmVzcG9uc2UsIGFuZCBpbiBvcmRlciBmb3IgdGhpcyByZXNw
b25zZSB0byBiZSANCj4NCj4gVGhpcyB0ZXh0IGlzIGEgYml0IGNvbmZ1c2luZy4gSWYgeW91IGNh
biBnZW5lcmF0ZSBhIGRyb3AsIHRoZW4geW91IGNhbiBtb3VudCB0aGlzIGF0dGFjay4NCg0KTm90
IHN1cmUgSSB1bmRlcnN0YW5kLg0KDQotLS0NCg0KPiAgIGludmFsaWQgYXR0YWNrLCB0aGlzIGF0
dGFjayBpcyBtaXRpZ2F0ZWQgYnkgdGhlIFNUVU4gc2hvcnQtdGVybQ0KPiAgIGNyZWRlbnRpYWwg
bWVjaGFuaXNtIGluIGNvbmp1bmN0aW9uIHdpdGggYSBzZWN1cmUgY2FuZGlkYXRlIGV4Y2hhbmdl
Lg0KPg0KPiBUaGlzIGFsc28gaXNuJ3QgcXVpdGUgY29ycmVjdC4gQ29uc2lkZXIgdGhlIGNhc2Ug
d2hlcmUgQSBpcyBiZWhpbmQgYSBmaWx0ZXJpbmcgZWxlbWVudCAoZS5nLiwgYSBmaXJld2FsbCkg
YW5kIA0KPiBzaGFyZXMgYSBicm9hZGNhc3QgbmV0d29yayB3aXRoIHRoZSBhdHRhY2tlci4gVGhl
IGF0dGFja2VyIHRoZW4gY2FwdHVyZXMgYW4gb3V0Z29pbmcgbWVzc2FnZSB0aGF0IHdvdWxkIA0K
PiBoYXZlIGJlZW4gZmlsdGVyZWQgYW5kIHR1bm5lbHMgaXQgdG8gQiwgYW5kIHRoZW4gdHVubmVs
cyB0aGUgcmVzcG9uc2UgYmFjay4gVGhpcyBjYW4gY2F1c2UgQiBhbmQgQSB0byB0aGluaw0KPiB0
aGV5IGhhdmUgYSB2YWxpZCBwYXRoIHdoZW4gdGhleSBkbyBub3QuIEl0IHNlZW1zIGxpa2UgdGhp
cyBhdHRhY2sgaXMgZGVzY3JpYmVkIHNldmVyYWwgcGFyYWdyYXBocyBkb3duLCBidXQgDQo+IGlu
IHNvcnQgb2YgYSBjb25mdXNpbmcgd2F5Lg0KDQpPaywgSSBzZWUgd2hhdCB5b3UgbWVhbi4NCg0K
UGVyaGFwcyB3ZSBzaG91bGQganVzdCByZW1vdmUgdGhlICJGb3J0dW5hdGVseSwgdGhpcyBhdHRh
Y2suLi4iIHNlbnRlbmNlPw0KDQpUaGVuLCB0aGUgcmVzdCBvZiB0aGUgcGFyYWdyYXBoIGNvdWxk
IGJlIHNlcGFyYXRlIHBhcmFncmFwaCwgYW5kIG1vZGlmaWVkIGFzOg0KDQpPTEQ6DQoNCiAgICJU
aGUgYXR0YWNrZXIgbmVlZHMNCiAgIHRvIGluamVjdCBhIGZha2UgcmVzcG9uc2UsIGFuZCBpbiBv
cmRlciBmb3IgdGhpcyByZXNwb25zZSB0byBiZQ0KICAgcHJvY2Vzc2VkLCB0aGUgYXR0YWNrZXIg
bmVlZHMgdGhlIHBhc3N3b3JkLiAgSWYgdGhlIGNhbmRpZGF0ZQ0KICAgZXhjaGFuZ2Ugc2lnbmFs
aW5nIGlzIHNlY3VyZWQsIHRoZSBhdHRhY2tlciB3aWxsIG5vdCBoYXZlIHRoZQ0KICAgcGFzc3dv
cmQgYW5kIGl0cyByZXNwb25zZSB3aWxsIGJlIGRpc2NhcmRlZC4iDQoNCk5FVzoNCg0KICAgIkR1
ZSB0byB0aGUgU1RVTiBzaG9ydC10ZXJtIGNyZWRlbnRpYWwgbWVjaGFuaXNtLCBpbiBvcmRlciBm
b3IgdGhlIGF0dGFja2VyIA0KICAgIHRvIGluamVjdCBhIGZha2UgcmVzcG9uc2UsIGFuZCBpbiBv
cmRlciBmb3IgdGhpcyByZXNwb25zZSB0byBiZSBwcm9jZXNzZWQsIHRoZSANCiAgICBhdHRhY2tl
ciBuZWVkcyB0aGUgcGFzc3dvcmQuICBJZiB0aGUgY2FuZGlkYXRlIGV4Y2hhbmdlIHNpZ25hbGlu
ZyBpcyBzZWN1cmVkLCANCiAgICB0aGUgYXR0YWNrZXIgd2lsbCBub3QgaGF2ZSB0aGUgcGFzc3dv
cmQgYW5kIGl0cyByZXNwb25zZSB3aWxsIGJlIGRpc2NhcmRlZC4iDQoNCi0tLQ0KDQo+MTkuNC4x
LiAgU1RVTiBBbXBsaWZpY2F0aW9uIEF0dGFjaw0KPkl0J3MgcHJvYmFibHkgd29ydGggbm90aW5n
IHRoYXQgdGhpcyBmb3JtIG9mIGF0dGFjayBpcyBhIGxvdCB3b3JzZSB3aGVuIFdlYlJUQyBpcyBp
bnZvbHZlZC4NCg0KV2h5IGlzIHRoYXQ/DQoNCi0tLQ0KIA0KKEFwcGVuZGl4IEIuMSAtIG5vdCBz
ZWN1cml0eSByZWxhdGVkKQ0KDQo+ICAgcmF0ZSBhdCB3aGljaCB0aGV5IHdpbGwgY3JlYXRlIG5l
dyBiaW5kaW5ncy4gIEV4cGVyaW1lbnRzIGhhdmUgc2hvd24NCj4gICB0aGF0IG9uY2UgZXZlcnkg
NSBtcyBpcyB3ZWxsIHN1cHBvcnRlZC4gIFRoaXMgaXMgd2h5IFRhIGhhcyBhIGxvd2VyDQo+ICAg
Ym91bmQgb2YgNSBtcy4gIEZ1cnRoZXJtb3JlLCB0cmFuc21pc3Npb24gb2YgdGhlc2UgcGFja2V0
cyBvbiB0aGUgDQo+DQo+IENpdGF0aW9uIG5lZWRlZC4NCg0KSSBkb24ndCByZWFsbHkgaGF2ZSBh
bnkuIFRoaXMgd2FzIHRoZSBvdXRjb21lIG9mIGxvbmcgV0cgZGlzY3Vzc2lvbnMuLi4NCg0KLS0t
DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo=


From nobody Thu Feb 22 12:26:04 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87EF712D96A for ; Thu, 22 Feb 2018 12:26:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JW2upcK7gFL for ; Thu, 22 Feb 2018 12:26:00 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 5242A12D954 for ; Thu, 22 Feb 2018 12:26:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519331158; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NdCjRv2rsKol06DGuoGi+4r0xSFmGrX6lr2VrCyG7AQ=; b=BREj/FtQ6Qgrae1+zh4H4Dfy6HSwuVAuIQDnsUf/Q+OBm2hzBS1fcM5n7XRUvxAF aX8LWwMG9SiU4PfQVGBP3xCtDmPmI1BlxzUDOJg/XOREHMZtkaiA7U4/mIFVOY5S Dsx20raq5NquQQZMdJkUBSDf2t3fMFVv6wOrMLpdeb4=;
X-AuditID: c1b4fb2d-499ff70000005540-d1-5a8f2755c141
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 9E.C6.21824.5572F8A5; Thu, 22 Feb 2018 21:25:58 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Thu, 22 Feb 2018 21:25:57 +0100
From: Christer Holmberg 
To: Benjamin Kaduk 
CC: IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , "pthatcher@google.com" , "ice@ietf.org" 
Thread-Topic: Benjamin Kaduk's practice ballot on draft-ietf-ice-rfc5245bis-17: (with COMMENT)
Thread-Index: AQHTqpYy9FJdDoYDFk2qXCr+ZyLyBKOvKTtAgAGdpQCAABWzwA==
Date: Thu, 22 Feb 2018 20:25:57 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C17CEFB@ESESSMB109.ericsson.se>
References: <20180220220002.GS54688@mit.edu> <7594FB04B1934943A5C02806D1A2204B6C17B1A8@ESESSMB109.ericsson.se> <20180222195035.GS54688@mit.edu>
In-Reply-To: <20180222195035.GS54688@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.166]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2J7iG6Yen+Uwb5fPBbzT15ntrg4azKb xbcLtRYz/kxktli+cSaTxbXlr1kd2DwWbCr1WLLkJ5NH05mjzAHMUVw2Kak5mWWpRfp2CVwZ e3tmsxf8Val4voO1gXGpTBcjJ4eEgInExJOnWUFsIYHDjBL3dvNA2EsYJZ7PsOhi5OBgE7CQ 6P6nDRIWEVCSWHy2ha2LkYuDWeAJo8Th+1vZQRLCAvESVx6tZYIoSpA4d+ckG4TtJPFm1hyw +SwCqhKT+htYQGxeAV+Jjl13WEAGCQlMZpR437gDrIFTQFei78MXMJtRQEzi+6k1YEOZBcQl bj2ZzwRxtIDEkj3nmSFsUYmXj/+xQthKEkdPX2KFqNeRWLD7ExuErS2xbOFrZojFghInZz5h mcAoOgvJ2FlIWmYhaZmFpGUBI8sqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMCYOrjlt+4O xtWvHQ8xCnAwKvHwpsj1RwmxJpYVV+YeYpTgYFYS4d0jBBTiTUmsrEotyo8vKs1JLT7EKM3B oiTOe9KTN0pIID2xJDU7NbUgtQgmy8TBKdXAaDU3YeOqJwe1LzKURGVH+axb8v7vjZ/mV+1z 7sw/LpUXYrSGc0v/F+99QadnMzx7dLe9573cvu6fqZqcQf2d21fKbXu95ln39/WeX1X6mY1l uPMudR0qKC82XKC4fHHcrXfW8wwumywVcm54ejHB2ZZZqlB92mXB9mrugrxNO7JtlvL2R13b osRSnJFoqMVcVJwIADZC0pSlAgAA
Archived-At: 
Subject: Re: [Ice] Benjamin Kaduk's practice ballot on draft-ietf-ice-rfc5245bis-17: (with COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Feb 2018 20:26:03 -0000

Hi,

...

>>> Section 17 is very focused on voice traffic; is that still the main use=
 of ICE?
>>=20
>> In my opinion it is.
>
> Voice to the exclusion of video, or does that include voice+video?

While video has become more common due to WebRTC, my opinion is still that =
voice-only traffic is still the main use.

Note, however, that this is just my personal observation - feel free to tel=
l me I'm wrong :)

And, even if we would cover video, I don't think it would impact the text.

---
=20
Some other general comments/questions.

 ---
=20
>>>In section 14.3:
>>>
>>>   For connectivity checks, agents SHOULD calculate the RTO value using
>>>   the following formula:
>>>
>>>     RTO =3D MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress))
>>>
>>> What is 'N'?
>>>=20
>> The number of checks to be performed. See section 14.1.
>
> Given that the other terms have their own prose description after the for=
mula, I would suggest doing so for N as well, as a reminder.

Others also asked about N, so I will do that.
=20
---
=20
>>>In Section 15:
>>>
>>>   will succeed.  Consequently, agent R constructs a new candidate pair
>>>   using the mapped address from the response as the local candidate (R-
>>>   PUB-1) and the destination of the request (NAT-PUB-1) as the remote
>>>   candidate.  This pair is added to the valid list for that data
>>>   stream.
>>>
>>> which leaves me confused, perhaps just about which response is "the res=
ponse" that we're taking the mapped address from. =20
>>> The previous text is about a STUN Binding request from L to R that=20
>>> causes R to generate a triggered check, so is this the response that R =
generates to the Binding request from L?
>>=20
>> Correct.
>>=20
>>>  IIUC the mapped address therein would be where R sees traffic from=20
>>> L as originating from, and would not be appropriate to use as a=20
>>> local address for R, etc..  So presumably I am picking the wrong respon=
se to use as the source of data.
>>=20
>> I think you are picking the right response :)
>
> Forgive me for being dense.  Does this mean that a change in the text is =
needed?

I got some other comments on the example too, so I am going to take a close=
r look at it, and see what/if needs to be changed :)

---
=20
>>>In Section 19.3:
>>>
>>>   However, TURN servers are susceptible to DNS attacks for purposes of
>>>   turning it into a zombie or rogue server.  These attacks can be
>>>   mitigated by DNS-SEC and through good box and software security on
>>>   TURN servers.
>>>
>>> I don't understand this.  Is the ICE agent or the TURN server "turned i=
nto" a zombie or rogue server by DNS attacks? =20
>>> If the TURN server, how would a bogus DNS response turn it into a rogue=
 server?
>>=20
>> I will have to come back on the security related comments, because I nee=
d input from others.
>
> Sure.

I looked into this, and I have to admit that I have no clue that the text m=
eans (text comes from RFC 5245). If seems like a virus could cause the TURN=
 server to start doing bad things (or, to not do anything), but I am not su=
re that's something we would need to say.

So, but unless someone can explain what exactly it means, I suggest to remo=
ve the text.

Regards,

Christer





> ---
>=20
> >On an editorial note, there is a general feel to the document that it=20
> >started off life as only covering ICE for RTP and the application=20
> >profiling was later split off into separtae documents.  I don't know=20
> >that it's worth the effort to try to change that, though.  I might give =
some thought to factoring out some of the duplicated content, though, such =
as discussion of how RTP gets component ID 1 and RTCP id 2, and I think Ekr=
 noted some other areas of duplication.
> >
> > Other purely editorial nits follow (IESG feel free to ignore).
>=20
> ---
>=20
> >Section 18.2:
> >
> >   Therefore, the servers get used less and
> >   less, and can eventually be remove when their usage goes to zero.
> >
> >*removed
>=20
> I will fix as suggested.
>=20
> ---
>=20
> >Section 19.4:
> >
> >   In addition to attacks where the attacker is a third party trying to
> >   insert fake candidate information or stun messages,
> >
> > s/stun/STUN/
>=20
> I will fix as suggested.
>=20
> ---
>=20
> >Section 21:
> >
> >   o  Make technical changes, due to discovered flows in RFC 5245 and
> >      based on feedback from the community that has implemented and
> >      deployed ICE applications based on RFC 5245.
> >
> > flows or flaws?
>=20
> Flaws :) I will fix it.
>=20
> ---
>=20
> Regards,
>=20
> Christer
>=20


From nobody Thu Feb 22 12:27:47 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702E41241F5 for ; Thu, 22 Feb 2018 12:27:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 gOMqtwnSTUls for ; Thu, 22 Feb 2018 12:27:44 -0800 (PST)
Received: from mail-pl0-x236.google.com (mail-pl0-x236.google.com [IPv6:2607:f8b0:400e:c01::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 0FD3012D96C for ; Thu, 22 Feb 2018 12:27:42 -0800 (PST)
Received: by mail-pl0-x236.google.com with SMTP id bb3so3539712plb.2 for ; Thu, 22 Feb 2018 12:27:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=gwyNa4zWDzXhROInTI+BSetma/4IFrWwA4QIkPpD2G8=; b=IbB9K3Y3IFDF5JZaasQvwVcnLmgRfP6X1nLcENKWyGxT2CdnPaAHlhoGPdfQXRCbs+ LYY8OEtcnm3eiLYnHivcxzg8trng0gTwcjTRFXr6Cuw0hhk/dWbMv+5VJNwN6T899ta2 ZPDjElfcyZic6sbByAl2wOeB+EOKDRhwsfZdc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=gwyNa4zWDzXhROInTI+BSetma/4IFrWwA4QIkPpD2G8=; b=eUAQ+Bk89lC/lFftVU+d1a1n+hjMr0rKg0PCv/Tw3b8MVIByFspUA7Jex3U7D4KCR0 KKLB5nWrkvyN1bCpybdypcOqng123hSjj9C8EDvTnMysmsxMgHRo5Vgg2F7AwHSleKRa 7VjoJXlQOMtwQalgORDtHx21235k5XTlTymJcU73OJxRYw9l8td9FoUs+0WNYNsUkRyB RYcK0yfadcLcZlP1Sgu1fMYFBMl/FSDYgyJ2WNDhHqWNUeQU7h4C5H8ovWbnbxkp/Yr0 RF8Dd12hu3K8Q90Egz+lPm8Rb5x0Tk5pBe7X8d9HxuDHrIHBLZSJVqQ53SkHLaJYuJcR cY7w==
X-Gm-Message-State: APf1xPDiXHrwCk5gKRDm/VJQkBizDx2mD5u+Wh8O6gumEjq+xF3CjzCr L90P4deRpPw8Mq7k7m8H7p/1fg==
X-Google-Smtp-Source: AH8x224eS0ieqL989OdDgesmGAzo3I/gmdzrxuHM1pshdU6lrDvmLRoAYhE08lMRimMKoZwmb4498A==
X-Received: by 2002:a17:902:8a4:: with SMTP id 33-v6mr7611983pll.279.1519331261501;  Thu, 22 Feb 2018 12:27:41 -0800 (PST)
Received: from dragon.local ([2620:101:80f4:224:4cf6:6c49:d416:2988]) by smtp.gmail.com with ESMTPSA id c1sm1310069pfa.126.2018.02.22.12.27.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Feb 2018 12:27:40 -0800 (PST)
To: Christer Holmberg , Peter Saint-Andre , Ben Campbell 
Cc: "draft-ietf-ice-rfc5245bis.all@ietf.org" , "draft-ietf-ice-trickle.all@ietf.org" , "ice@ietf.org" 
References: <7594FB04B1934943A5C02806D1A2204B6C17CCBD@ESESSMB109.ericsson.se>
From: Peter Saint-Andre 
Message-ID: <98508a27-0a38-9edd-830c-b30630cb38ed@mozilla.com>
Date: Thu, 22 Feb 2018 12:27:39 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C17CCBD@ESESSMB109.ericsson.se>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EIuEVhTc90OOb50iZLrCCcUWc8PjDlqcH"
Archived-At: 
Subject: Re: [Ice] ice-options in draft-ietf-ice-rfc5245bis and draft-ietf-ice-trickle - ice-options
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Feb 2018 20:27:45 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--EIuEVhTc90OOb50iZLrCCcUWc8PjDlqcH
Content-Type: multipart/mixed; boundary="oM8dGVoW4onI6bidr2MHYU7jAIeOE6SlM";
 protected-headers="v1"
From: Peter Saint-Andre 
To: Christer Holmberg ,
 Peter Saint-Andre , Ben Campbell 
Cc: "draft-ietf-ice-rfc5245bis.all@ietf.org"
 ,
 "draft-ietf-ice-trickle.all@ietf.org" ,
 "ice@ietf.org" 
Message-ID: <98508a27-0a38-9edd-830c-b30630cb38ed@mozilla.com>
Subject: Re: [Ice] ice-options in draft-ietf-ice-rfc5245bis and
 draft-ietf-ice-trickle - ice-options
References: <7594FB04B1934943A5C02806D1A2204B6C17CCBD@ESESSMB109.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C17CCBD@ESESSMB109.ericsson.se>

--oM8dGVoW4onI6bidr2MHYU7jAIeOE6SlM
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2/22/18 11:38 AM, Christer Holmberg wrote:
> Hi,
>=20
> It seems like I missed this conversation (thanks to Ari for reminding m=
e).
>=20
> 5245bis does talk about ice options, but in my opinion the text in Sect=
ion 13 needs to be modified, to be more generic.
>=20
> I suggest the following modification:
>=20
> OLD:
>=20
>    First, ICE provides the ice-options attribute.  Each extension or
>    change to ICE is associated with a token.  When an agent supporting
>    such an extension or change triggers candidate exchange, it MUST
>    include the token for that extension in this attribute.  This allows=

>    each side to know what the other side is doing.  This attribute MUST=

>    NOT be present if the agent doesn't support any ICE extensions or
>    changes.
>=20
> NEW:
>=20
>    First, ICE provides the ICE option concept.  Each extension or
>    change to ICE is associated with an ICE option.  When an agent suppo=
rts
>    such an extension or change, it provides the ICE option to the peer =
agent
>    as part of the candidate exchange.

LGTM.

Peter



--oM8dGVoW4onI6bidr2MHYU7jAIeOE6SlM--

--EIuEVhTc90OOb50iZLrCCcUWc8PjDlqcH
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqPJ7sACgkQZWGMGH9o
FKnPuxAAt7U7FsayxeM3PNSTaTlq3or/VRkCtmohks410WU9olvaU/mLKoHqlO1W
SeVSxSClGusv9TY2svb6UUuJu8LaSPPUlab08LWH2C6KW9PNmMdCYcKuYe024vPs
0xA9XFkehg4ypzO4m85cPYJIdAn168170hcZHEHdSAS62xmLJzhlZAj9DB1ze7QJ
sE68FyOaIJo62ePPphejwElI8M/UeJ1435CRKixR2SVq8n2k361EjjCnd+pn8JRx
21FPoSBHUeG6bdj7tOSHu5jmw7N0FcRkoP16HLA6JpN1LLKNlM2qH1UGIcHaC8o0
7B2cFWiBXEL6rwMuqBPmKHhJcEprQxKwiTg5WhnhnX2WLjs8zcDIdmqOYDIgqu6q
UE47z6F3ZNg05qm8QacU12Glc1dTiD9WdxRQ2DhJqqW5EV7gaKw8dMV6yX8bN8R1
qmn2Jlv/0pqZ//aBtQ1ewVw65sUjm96pZphGYcoYCExwgN089mP6AlRs92XliDC5
qz9u7fvHeWQwf23wwG5Mm/GtWxKRBNgOHTwbBLF6BYzaLvWd2BtsLTfSjoMPfAXE
q93g/ldOQeAddTJcbRh1a7FYmd6GdFMZn4nLZLioUMwqqlH1SLZWEmFCFvkYm16X
5HEojNqS91JzqYpq99XSqwpH/vxHXEfhOeb/AuRHhvwBXl569/0=
=zZcA
-----END PGP SIGNATURE-----

--EIuEVhTc90OOb50iZLrCCcUWc8PjDlqcH--


From nobody Thu Feb 22 12:37:45 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB9512DA11 for ; Thu, 22 Feb 2018 12:37:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 7nfFWs3cmYKj for ; Thu, 22 Feb 2018 12:37:42 -0800 (PST)
Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::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 04E2412DA0A for ; Thu, 22 Feb 2018 12:37:41 -0800 (PST)
Received: by mail-pg0-x236.google.com with SMTP id y26so2462144pgv.4 for ; Thu, 22 Feb 2018 12:37:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=r9K4I9ZtCjmWO2p1KB79+TGJUY+E86ukxPJjT68ChwM=; b=QUu1CDmS+uTaIlDxYn20bgK9rPfummW+CnU+pz/7SczKimAOrc+/fnHTZwHNKoopdE VqdnRyYdCgTFlYPHlRSGwgl0wN4y3kpgNW2Jp6xi4DGAzxjSvIrUpUWUIz0GezjIFPQC EvgQrF42pR+ZFNI51u5V9Lp5/RtAyzbvk2IDM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=r9K4I9ZtCjmWO2p1KB79+TGJUY+E86ukxPJjT68ChwM=; b=t0uJztTLPNev2Ny0NKwlOrmj4qwQ2zP41TntVScgxc4lWULaWB+AXFbbaXK4Nqgiz2 WBVKtzu/0wxOi09hEe9ZBQH+s485H4R/C3jDApUfMUhLZY00LLkbpemMIxCirlyj6kWi r884LUc6CWLAvzqL+vrQqrMMRGFiNdvbBa/h/WzeySlkeG5QM1LkaBijopblNL+/W2+0 WtZL9cJaE2l70qd3s06n583eSl7m3w9ethe48WXaDjhdt8yAEZkZlnkFRoqTYDS7NYew Sqf0cTQvOTtA0f+11bzwp5CW/uSYtPZA5OwcSHXZ0+hvAZ8/6uYFtXVzqiT16y8WT8sQ sfLA==
X-Gm-Message-State: APf1xPDxLfu2a6AYFZnJyFkLg2qzYowJNoK342VcI7QXKvtbdyJNTZVp WPW0/b6VY8gEo7WeaLaAZnx3WQ==
X-Google-Smtp-Source: AH8x224p1zPj0h9CfqRhZYRyO5/+VX4lOG3H9NTb8XPOBEn2nwTTCjX7QdcBAamWD2uqXhQfVm32ow==
X-Received: by 10.99.171.70 with SMTP id k6mr6774082pgp.355.1519331861514; Thu, 22 Feb 2018 12:37:41 -0800 (PST)
Received: from dragon.local ([2620:101:80f4:224:4cf6:6c49:d416:2988]) by smtp.gmail.com with ESMTPSA id t16sm1259144pfh.131.2018.02.22.12.37.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Feb 2018 12:37:40 -0800 (PST)
To: Christer Holmberg , Benjamin Kaduk 
Cc: "ice@ietf.org" , "ice-chairs@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , IESG , "pthatcher@google.com" 
References: <20180220220002.GS54688@mit.edu> <7594FB04B1934943A5C02806D1A2204B6C17B1A8@ESESSMB109.ericsson.se> <20180222195035.GS54688@mit.edu> <7594FB04B1934943A5C02806D1A2204B6C17CEFB@ESESSMB109.ericsson.se>
From: Peter Saint-Andre 
Message-ID: <71931266-2676-a037-0c3f-2789c68f39fa@mozilla.com>
Date: Thu, 22 Feb 2018 12:37:39 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C17CEFB@ESESSMB109.ericsson.se>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gpSJztVvjjI6SD1V2b0gZAS1DY65AnHkW"
Archived-At: 
Subject: Re: [Ice] Benjamin Kaduk's practice ballot on draft-ietf-ice-rfc5245bis-17: (with COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Feb 2018 20:37:44 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--gpSJztVvjjI6SD1V2b0gZAS1DY65AnHkW
Content-Type: multipart/mixed; boundary="QPMxaeLE00aHC1K0t5xxYfo4Z9HBdek39";
 protected-headers="v1"
From: Peter Saint-Andre 
To: Christer Holmberg ,
 Benjamin Kaduk 
Cc: "ice@ietf.org" , "ice-chairs@ietf.org"
 ,
 "draft-ietf-ice-rfc5245bis@ietf.org" ,
 IESG , "pthatcher@google.com" 
Message-ID: <71931266-2676-a037-0c3f-2789c68f39fa@mozilla.com>
Subject: Re: [Ice] Benjamin Kaduk's practice ballot on
 draft-ietf-ice-rfc5245bis-17: (with COMMENT)
References: <20180220220002.GS54688@mit.edu>
 <7594FB04B1934943A5C02806D1A2204B6C17B1A8@ESESSMB109.ericsson.se>
 <20180222195035.GS54688@mit.edu>
 <7594FB04B1934943A5C02806D1A2204B6C17CEFB@ESESSMB109.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C17CEFB@ESESSMB109.ericsson.se>

--QPMxaeLE00aHC1K0t5xxYfo4Z9HBdek39
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2/22/18 12:25 PM, Christer Holmberg wrote:
>=20
>>>> Section 17 is very focused on voice traffic; is that still the main =
use of ICE?
>>>
>>> In my opinion it is.
>>
>> Voice to the exclusion of video, or does that include voice+video?
>=20
> While video has become more common due to WebRTC, my opinion is still t=
hat voice-only traffic is still the main use.
>=20
> Note, however, that this is just my personal observation - feel free to=
 tell me I'm wrong :)
>=20
> And, even if we would cover video, I don't think it would impact the te=
xt.

We might want to add a sentence to the end of Section 17.2.1 to the
effect that these planning considerations are more significant in
deployments involving video (e.g., video conferencing). Also, the number
of participants in a session obviously has an impact as well, and it
seems that the current text considers only 1:1 calls, not 1:many?

Peter


--QPMxaeLE00aHC1K0t5xxYfo4Z9HBdek39--

--gpSJztVvjjI6SD1V2b0gZAS1DY65AnHkW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqPKhMACgkQZWGMGH9o
FKmW0Q//aJq6ruWl973ZWtAgVJ8ATxwgtNvLKuZJdsDDT7KNwTli8j0eGX+qpysc
6Vuy74khQVxu5DiaI4njpOrurzdAKzWwSfwfGBCECua7cU2FyVlbtxw1YjYrl+Hq
h00//TjqGn7Kps+cYKxlR+rpip4C75wN4h2t3FtTg1Fe1EXpRtW2T2oGyEx2yySg
utFax4nXP9QljQWRd0mliJsaf5q4MS8eTxilRHnU7QRVB1NH32xcZz130KwNW6AP
pc4xgNAPAmvJCr55ZuP/dzQwxBQJ3aJz9bpGGnQPQJkDVR7iyXJebDexKGDYFAaK
meNTrJR8q5LdlnTpkei58S2QYH8JCzKebVa9ktFUzsif52tj30JcmPAUg0BLU6kG
TBp2/DOxkKhKXqLPui7Yr0Qov84dnNnF2BsY07T+lG/jPQAUCKyTDcA3Qh9yYjGu
NdE/NnD+LbhKTTetCucAc5T9q9lh0rTPJi2PNroWnO6LN1Dyj/wOwCpHMC166qtg
rAf43E2rHq1dz6B99WXoHQXcC+3y8GGcxjxj8HWhGrxttIaFTqIqcwthioTADjtF
XADl9QPuBpvebiybO+1YHRThKky4mbCUyyw5xDRrRx7FhdkqcSGzDC0cQE/cUQcf
aAjRsHaPgzD53JBLKClwXP9pUZ5t6CxkL9TwfB0m+Z7bP9y6cgE=
=T7dW
-----END PGP SIGNATURE-----

--gpSJztVvjjI6SD1V2b0gZAS1DY65AnHkW--


From nobody Fri Feb 23 06:05:03 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA6312E741 for ; Fri, 23 Feb 2018 06:05:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dx-J5_M8W0Vo for ; Fri, 23 Feb 2018 06:05:00 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 A7FDF12E054 for ; Fri, 23 Feb 2018 06:04:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519394697; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gSaJIymz20iky/FPsczm03VMV0DodH5XAk8jfg+WSPs=; b=cIz/+F/8OU1cgwXeINlP7T078SU5EsJyHj8jaOAE7QNdwWjrYXU9Dc3BvN0LzN+J 5/jYIcTG229aZj2nqHUchevafihM8/F5kMKzPJLNk69uI0xMpduPpqWRGBfI/2t4 SbRjJSLOhopmTg2L5Ia2ANnJ4O+WTksKnXKrZqPb+oU=;
X-AuditID: c1b4fb30-799639c000004778-97-5a901f894699
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 61.01.18296.98F109A5; Fri, 23 Feb 2018 15:04:57 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Fri, 23 Feb 2018 15:04:54 +0100
From: Christer Holmberg 
To: Peter Saint-Andre , Benjamin Kaduk 
CC: "ice@ietf.org" , "ice-chairs@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , IESG , "pthatcher@google.com" 
Thread-Topic: [Ice] Benjamin Kaduk's practice ballot on draft-ietf-ice-rfc5245bis-17: (with COMMENT)
Thread-Index: AQHTqpYy9FJdDoYDFk2qXCr+ZyLyBKOvKTtAgAGdpQCAABWzwP//93KAgAE1LPA=
Date: Fri, 23 Feb 2018 14:04:53 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C17E4A9@ESESSMB109.ericsson.se>
References: <20180220220002.GS54688@mit.edu> <7594FB04B1934943A5C02806D1A2204B6C17B1A8@ESESSMB109.ericsson.se> <20180222195035.GS54688@mit.edu> <7594FB04B1934943A5C02806D1A2204B6C17CEFB@ESESSMB109.ericsson.se> <71931266-2676-a037-0c3f-2789c68f39fa@mozilla.com>
In-Reply-To: <71931266-2676-a037-0c3f-2789c68f39fa@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.162]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7qG6n/IQog/lXdCzmn7zObHFx1mQ2 i28Xai1m/JnIbLF840wmi2vLX7NaPFt5itGB3WPBplKPJUt+Mnk0nTnK7NF3oIs1gCWKyyYl NSezLLVI3y6BK2PLjn6mgh/cFT/Xr2BtYLzA3cXIySEhYCJxfeVvxi5GLg4hgcOMEp1vm9kh nCWMEh/2PwZyODjYBCwkuv9pgzSICHhLdO84BlbDLPCEUWLGwdPsIAlhgVSJr1N/sUAUpUms /PiRHcL2k7j6ZwUbiM0ioCqx5/FNMJtXwFdi870lbBDLepgknlzoB2vgFLCXONv2A2wQo4CY xPdTa5hAbGYBcYlbT+YzQZwtILFkz3lmCFtU4uXjf6wQtpLE0/9LmECOZhbQlFi/Sx+iVVFi SvdDdoi9ghInZz5hmcAoOgvJ1FkIHbOQdMxC0rGAkWUVo2hxanFSbrqRkV5qUWZycXF+nl5e askmRmCkHdzy22AH48vnjocYBTgYlXh42YQnRAmxJpYVV+YeYpTgYFYS4S173h8lxJuSWFmV WpQfX1Sak1p8iFGag0VJnPekJ2+UkEB6YklqdmpqQWoRTJaJg1OqgTFrgXUdx85VNhtiRU/7 vOB3TK8NS27lypa40Wlq0WO2X+NenYL01gP72tic5x4StS46rs3K3db3QU1M/onGZ7adcwsX PlouUJTSzBwT3RShJdYf0b2Lh/+e+GZHzafS69Ubv51iaU29XeYm5z6tzdCv9LS5ff7Biwfl XnmZ+7R1/Zmn++KtEktxRqKhFnNRcSIAQvIm67ACAAA=
Archived-At: 
Subject: Re: [Ice] Benjamin Kaduk's practice ballot on draft-ietf-ice-rfc5245bis-17: (with COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 14:05:02 -0000

SGksDQoNCj4+Pj4+IFNlY3Rpb24gMTcgaXMgdmVyeSBmb2N1c2VkIG9uIHZvaWNlIHRyYWZmaWM7
IGlzIHRoYXQgc3RpbGwgdGhlIG1haW4gdXNlIG9mIElDRT8NCj4+Pj4NCj4+Pj4gSW4gbXkgb3Bp
bmlvbiBpdCBpcy4NCj4+Pg0KPj4+IFZvaWNlIHRvIHRoZSBleGNsdXNpb24gb2YgdmlkZW8sIG9y
IGRvZXMgdGhhdCBpbmNsdWRlIHZvaWNlK3ZpZGVvPw0KPj4gDQo+PiBXaGlsZSB2aWRlbyBoYXMg
YmVjb21lIG1vcmUgY29tbW9uIGR1ZSB0byBXZWJSVEMsIG15IG9waW5pb24gaXMgc3RpbGwgdGhh
dCB2b2ljZS1vbmx5IHRyYWZmaWMgaXMgc3RpbGwgdGhlIG1haW4gdXNlLg0KPj4gDQo+PiBOb3Rl
LCBob3dldmVyLCB0aGF0IHRoaXMgaXMganVzdCBteSBwZXJzb25hbCBvYnNlcnZhdGlvbiAtIGZl
ZWwgZnJlZSANCj4+IHRvIHRlbGwgbWUgSSdtIHdyb25nIDopDQo+PiANCj4+IEFuZCwgZXZlbiBp
ZiB3ZSB3b3VsZCBjb3ZlciB2aWRlbywgSSBkb24ndCB0aGluayBpdCB3b3VsZCBpbXBhY3QgdGhl
IHRleHQuDQo+DQo+IFdlIG1pZ2h0IHdhbnQgdG8gYWRkIGEgc2VudGVuY2UgdG8gdGhlIGVuZCBv
ZiBTZWN0aW9uIDE3LjIuMSB0byB0aGUgZWZmZWN0IHRoYXQgdGhlc2UgcGxhbm5pbmcgY29uc2lk
ZXJhdGlvbnMgDQo+IGFyZSBtb3JlIHNpZ25pZmljYW50IGluIGRlcGxveW1lbnRzIGludm9sdmlu
ZyB2aWRlbyAoZS5nLiwgdmlkZW8gY29uZmVyZW5jaW5nKS4gQWxzbywgdGhlIG51bWJlciBvZiBw
YXJ0aWNpcGFudHMgaW4gDQo+IGEgc2Vzc2lvbiBvYnZpb3VzbHkgaGFzIGFuIGltcGFjdCBhcyB3
ZWxsLCBhbmQgaXQgc2VlbXMgdGhhdCB0aGUgY3VycmVudCB0ZXh0IGNvbnNpZGVycyBvbmx5IDE6
MSBjYWxscywgbm90IDE6bWFueT8NCg0KSSBzdWdnZXN0IHRoZSBmb2xsb3dpbmc6DQoNCiJUaGUg
cGxhbm5pbmcgY29uc2lkZXJhdGlvbnMgYWJvdmUgYmVjb21lIG1vcmUgc2lnbmlmaWNhbnQgaW4g
bXVsdGktbWVkaWENCnNjZW5hcmlvcyAoZS5nLiwgYXVkaW8gYW5kIHZpZGVvIGNvbmZlcmVuY2Vz
KSwgYW5kIHdoZW4gdGhlIG51bWJlcnMgb2YNCnBhcnRpY2lwYW50cyBpbiBhIHNlc3Npb24gZ3Jv
dy4iDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg==


From nobody Fri Feb 23 08:29:48 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A3F12D77D for ; Fri, 23 Feb 2018 08:29:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 noURcPikhf10 for ; Fri, 23 Feb 2018 08:29:42 -0800 (PST)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 AC89B1270A3 for ; Fri, 23 Feb 2018 08:29:39 -0800 (PST)
Received: by mail-pf0-x230.google.com with SMTP id 17so3705918pfw.11 for ; Fri, 23 Feb 2018 08:29:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=hYRlm7vDKXODNpNf64BWr2s+eaidOVrCxDqhO+tC3XE=; b=HJjQHmlJYxsyBjLRNhj7CP9WJ+/2KG7Hx0FntxSXyVFavQ1jbAIQUbh+03bpITbXAh cRyHis8a6Hu46WlNqMQAkSlJd1wUWGXQY8JNKtqdZPTPufK5U8hOMNV1UrEEllG3gC4H 3004s70SpA6v2ItfIs3ase6ayifz+CNb2DC0A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=hYRlm7vDKXODNpNf64BWr2s+eaidOVrCxDqhO+tC3XE=; b=HD4/AjDAUtI3b1KgXKyXVImRyB3EyqA9UD9RKobWcViZUp/OZGdUt9KdHUwAR9hGoR WDfHiqdj8BrltXWT2baQZ7Sm9Qx2qE09juFtnTfFMtITCDaMsxks4hbWIQ/4041KX7Rx jLzxpyXJA0uTkL2drnNP6Bva/Fsz8tQ4PXRFO6SWdSMlum7smDkb13Cgfklq7bMoKs8J 1zqXb/YTNkKmzQUxUXbTUNk6TCC1dateXShFycFJ3jwHhvdhnIWqDn4iYNI6Q9el93Mg kfZB0lVHrEqLfA3MtX0bWGlXCXF6l2RXmJrdYsk9LGJL6gh8MkXbBtTIzMqtWtxD26cF OKCA==
X-Gm-Message-State: APf1xPBWpSMjjetY9zwl81aoebYY+ATqIbspFC9jqJX9XsUO02OkbPd9 F5/kny3xNBg7VQH8dvF7HrrI2A==
X-Google-Smtp-Source: AH8x227OikvVvVJOgRVNh5DAJxr62rm8drf769nzDIgUjlMWIB8r+zg4j5aWcaeege/4R5gsJpqheQ==
X-Received: by 10.98.160.90 with SMTP id r87mr2278498pfe.151.1519403379230; Fri, 23 Feb 2018 08:29:39 -0800 (PST)
Received: from dragon.local ([2620:101:80f4:224:e4d9:d03c:60cb:7d23]) by smtp.gmail.com with ESMTPSA id m3sm5010225pgs.90.2018.02.23.08.29.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Feb 2018 08:29:38 -0800 (PST)
To: Christer Holmberg , Benjamin Kaduk 
Cc: "ice@ietf.org" , "ice-chairs@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , IESG , "pthatcher@google.com" 
References: <20180220220002.GS54688@mit.edu> <7594FB04B1934943A5C02806D1A2204B6C17B1A8@ESESSMB109.ericsson.se> <20180222195035.GS54688@mit.edu> <7594FB04B1934943A5C02806D1A2204B6C17CEFB@ESESSMB109.ericsson.se> <71931266-2676-a037-0c3f-2789c68f39fa@mozilla.com> <7594FB04B1934943A5C02806D1A2204B6C17E4A9@ESESSMB109.ericsson.se>
From: Peter Saint-Andre 
Message-ID: 
Date: Fri, 23 Feb 2018 08:29:48 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C17E4A9@ESESSMB109.ericsson.se>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EqaNuyZ3dXqHlqmC4uB6OC9jgbKItHkIj"
Archived-At: 
Subject: Re: [Ice] Benjamin Kaduk's practice ballot on draft-ietf-ice-rfc5245bis-17: (with COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 16:29:43 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--EqaNuyZ3dXqHlqmC4uB6OC9jgbKItHkIj
Content-Type: multipart/mixed; boundary="YEqooYJFw11kJ1HJMVJGn4T0gxqeWkCiT";
 protected-headers="v1"
From: Peter Saint-Andre 
To: Christer Holmberg ,
 Benjamin Kaduk 
Cc: "ice@ietf.org" , "ice-chairs@ietf.org"
 ,
 "draft-ietf-ice-rfc5245bis@ietf.org" ,
 IESG , "pthatcher@google.com" 
Message-ID: 
Subject: Re: [Ice] Benjamin Kaduk's practice ballot on
 draft-ietf-ice-rfc5245bis-17: (with COMMENT)
References: <20180220220002.GS54688@mit.edu>
 <7594FB04B1934943A5C02806D1A2204B6C17B1A8@ESESSMB109.ericsson.se>
 <20180222195035.GS54688@mit.edu>
 <7594FB04B1934943A5C02806D1A2204B6C17CEFB@ESESSMB109.ericsson.se>
 <71931266-2676-a037-0c3f-2789c68f39fa@mozilla.com>
 <7594FB04B1934943A5C02806D1A2204B6C17E4A9@ESESSMB109.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C17E4A9@ESESSMB109.ericsson.se>

--YEqooYJFw11kJ1HJMVJGn4T0gxqeWkCiT
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2/23/18 6:04 AM, Christer Holmberg wrote:
> Hi,
>=20
>>>>>> Section 17 is very focused on voice traffic; is that still the mai=
n use of ICE?
>>>>>
>>>>> In my opinion it is.
>>>>
>>>> Voice to the exclusion of video, or does that include voice+video?
>>>
>>> While video has become more common due to WebRTC, my opinion is still=
 that voice-only traffic is still the main use.
>>>
>>> Note, however, that this is just my personal observation - feel free =

>>> to tell me I'm wrong :)
>>>
>>> And, even if we would cover video, I don't think it would impact the =
text.
>>
>> We might want to add a sentence to the end of Section 17.2.1 to the ef=
fect that these planning considerations=20
>> are more significant in deployments involving video (e.g., video confe=
rencing). Also, the number of participants in=20
>> a session obviously has an impact as well, and it seems that the curre=
nt text considers only 1:1 calls, not 1:many?
>=20
> I suggest the following:
>=20
> "The planning considerations above become more significant in multi-med=
ia
> scenarios (e.g., audio and video conferences), and when the numbers of
> participants in a session grow."

WFM. This probably isn't the spec in which to precisely define the
operational impact of running a videoconferencing service anyway...

Peter


--YEqooYJFw11kJ1HJMVJGn4T0gxqeWkCiT--

--EqaNuyZ3dXqHlqmC4uB6OC9jgbKItHkIj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqQQXwACgkQZWGMGH9o
FKkneg//dv8MNzPvQqZwDFC/MvwwMTPfAlE01UtE51+0KdlmjEoxy6ybjyAQts9m
3NFhy2DO5hNdwvKj3nqHnSu40WaKO6vdtf77K0uXtoVvw0SJPtZmxjJ0oOmGbFJO
vGKIf6GsDYsrHdXHmVED72e+MZwc2s223E6L86w0sKMKeqdEjt22Q6nDDcFMz1hl
tVQAfRj4j5BmBhXmMunBPKuXHkcjFScihEFB/gt9p9u7SVYk1AnPAX8oZalwrFsE
Y6YejPMbbcUNfLlQQ8zwwTe7qkJDcRQ0x155brHikSSndJjr0pz8npzuuP/olrRE
tGc/OqizIDLJdSTMQozXAAdrDmTd5erVNYhZ8XwEWBIJiFrDOSOF6CZHlyo0UPZe
qaoxNNxFi/Ai2Fv/gWE+BH5likVjRg+20zvR14vp6m0JKqnldDFetuVMqJQE/Lk1
N1+1OWYSxL4HXJ65RUvpLWtEBwVDSUUBf/MphXx0cM56ziJAWPRob9O+L16Iyem0
tcI9vtdX5Cd52AIYiJYxZv3XYwcga+kqID3Z9FBDdffNaCQlWNzPgIZEeV765GE6
ivBrUO3F1AJZEzu3QWk/y947H583cgB0QM4LT7cU16u9itA8aN2gBQeIZopLILdl
zVpbiJPfhjgatElEIBR/oYNVuPy5ZisTce7zMbMsqMXngy8/DXc=
=qNlh
-----END PGP SIGNATURE-----

--EqaNuyZ3dXqHlqmC4uB6OC9jgbKItHkIj--


From nobody Fri Feb 23 09:24:01 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B0512D7E5 for ; Fri, 23 Feb 2018 09:24:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdFPeymLQPPQ for ; Fri, 23 Feb 2018 09:23:58 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 3ECD212008A for ; Fri, 23 Feb 2018 09:23:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519406636; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=asfXyNjI1rjmCte5z32pyLDabX96ZLwb61M0kplGEVw=; b=PUw4bZL1vqn4BMJ0pHfu4hUrx4BH6m8YMMCWmomyykKfN2YJpnFlOlCHX6M6wCpL lgH4zf60zoBGYHyIp7yid4NlEClbMz207O+/oBRGtN86pdrLQbQWHZjQX6L2FJqO 1QVfUp718wm6c9XFPfAeJZ6SPpvX0+gWBuGctOpmgVQ=;
X-AuditID: c1b4fb30-799639c000004778-ce-5a904e2c3284
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D0.42.18296.C2E409A5; Fri, 23 Feb 2018 18:23:56 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Fri, 23 Feb 2018 18:23:07 +0100
From: Christer Holmberg 
To: Christer Holmberg , Adam Roach , The IESG 
CC: "ice-chairs@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , "pthatcher@google.com" , "ice@ietf.org" 
Thread-Topic: Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT) - Updated example in Section 15
Thread-Index: AdOsyp/bE2TD5gJDQPaRwfwN2dxcoA==
Date: Fri, 23 Feb 2018 17:23:06 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C17EC3B@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.172]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2J7iK6O34Qog31fJS32/F3EbjH/5HVm i4uzJrNZfLtQazHjz0Rmi2vLX7M6sHks2FTqsWTJTyaPWTufsAQwR3HZpKTmZJalFunbJXBl PDvTz1ZwSKKi4c9K1gbGD+JdjJwcEgImErufPGPrYuTiEBI4zCixdtV1KGcJo8STi+uYuhg5 ONgELCS6/2mDmCIChRKvDkuC9DILnGGUWHejAMQWFqiX+LDxBwuILSLQwCjxfaYmhK0nMXfx b0YQm0VAVeLbqZVsIDavgK9E09wZ7CA2o4CYxPdTa5ggZopL3HoynwniNgGJJXvOM0PYohIv H/9jBTlBQkBJomEmC4jJLKApsX6XPkSnosSU7ofsENMFJU7OfMIygVF4FpKhsxA6ZiHpmIWk YwEjyypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwOg4uOW3wQ7Gl88dDzEKcDAq8fD6ukyI EmJNLCuuzD3EKMHBrCTCW/a8P0qINyWxsiq1KD++qDQntfgQozQHi5I470lP3ighgfTEktTs 1NSC1CKYLBMHp1QDY8KlLUYyCVsCGbhOBJubFj0o2PM/ayHDmupqGb0VbTNWnDZc7njwwG8d b7eks2UmJQs8ZvSxBPdN+nD1dafGtp0eaV/ahRw6zCZNm/83Q/4Qk3zKf9kuzl9R4fanF+4U 2FP6Xu4Cc3e6QdtPC8E1Vs0NcydHT+yfVbDtYWTbs/XFilJlPpInlViKMxINtZiLihMBjw77 JIoCAAA=
Archived-At: 
Subject: Re: [Ice] Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT) - Updated example in Section 15
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 17:24:00 -0000

SGksDQoNCkkgaGF2ZSB1cGRhdGVkIHRoZSBleGFtcGxlIGluIFNlY3Rpb24gMTUsIGJhc2VkIG9u
IHRoZSBjb21tZW50cyBmcm9tIEFkYW0uIE5vdGUgdGhhdCBJIGhhdmUgbm90IHlldCBkb25lIGFu
eXRoaW5nIHRvIHRoZSBJUCB2ZXJzaW9ucy4NCg0KaHR0cHM6Ly9naXRodWIuY29tL2ljZS13Zy9y
ZmM1MjQ1YmlzL3B1bGwvNTkNCg0KTm90ZSB0aGF0IHRoZSBQUiBpcyBub3QgY29tcGxldGUgeWV0
LCBJIGFtIHN0aWxsIHdvcmtpbmcgb24gYWRkcmVzc2luZyB0aGUgaXNzdWVzLiBCdXQsIEkgd2Fu
dCBwZW9wbGUgdG8gdGFrZSBhIGxvb2sgYXQgdGhlIGV4YW1wbGUuDQoNCihGb3IgeW91ciByZWZl
cmVuY2UsIHRoZSBhc3NvY2lhdGVkIHJldmlldyBkaXNjdXNzaW9uIGJlbG93KQ0KDQotLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0NCg0KwqcxNToNCg0KPiAgICAgICAgICAgIHwgICAgICAgICAgICAgIHwoOSkg
QmluZCBSZXEgIHwgICAgICAgICAgICAgIHxCZWdpbg0KPiAgICAgICAgICAgIHwgICAgICAgICAg
ICAgIHxTPSRSLVBVQi0xICAgIHwgICAgICAgICAgICAgIHxDb25uZWN0aXZpdHkNCj4gICAgICAg
ICAgICB8ICAgICAgICAgICAgICB8RD1MLVBSSVYtMSAgICB8ICAgICAgICAgICAgICB8Q2hlY2tz
DQo+ICAgICAgICAgICAgfCAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tfA0KPiAgICAgICAgICAgIHwgICAgICAgICAgICAgIHxEcm9wcGVkICAgICAgIHwgICAgICAg
ICAgICAgIHwNCj4NCj4gVGhpcyBpcyBxdWl0ZSBtaXNsZWFkaW5nLiBJZiBhIGhvc3Qgb24gdGhl
IHB1YmxpYyBJbnRlcm5ldCAoYXMgUiBpcyBpbiANCj4gdGhpcw0KPiBleGFtcGxlKSBzZW50IGEg
QmluZGluZyBSZXF1ZXN0IHRvICRMLVBSSVYtMSAoMTAuMC4xLjEgaW4gdGhpcyANCj4gZXhhbXBs
ZSksIGl0IHdvdWxkICpub3QqIGJlIHJvdXRlZCB0byB0aGUgTkFULCBhcyBpcyBzaG93biBpbiB0
aGlzIA0KPiBleGFtcGxlLiBJZiBpdCBkaWRuJ3QgZ2V0IGJsb2NrZWQgYmVmb3JlIHJlYWNoaW5n
IHRoZSBkZWZhdWx0IGZyZWUgDQo+IHpvbmUsIEkgYmVsaWV2ZSBpdCB3b3VsZCBiZSBibGFja2hv
bGVkIG9uY2UgaXQgZGlkIHNvLiBJIHdvdWxkIHByb3Bvc2Uga2VlcGluZyB0aGUgYXJyb3csIGJ1
dCBoYXZpbmcgaXQgZW5kIHByaW9yIHRvIHJlYWNoaW5nIHRoZSBOQVQgbGluZS4NCg0KPihNaW5v
ciBuaXQ6IHBsZWFzZSByZXBsYWNlICJMLVBSSVYtMSIgd2l0aCAiJEwtUFJJVi0xIikNCg0KV2ls
bCBmaXguDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQrCpzE1Og0KDQo+ICBTaW5jZSB0aGUgY2hl
Y2sgd2FzIGdlbmVyYXRlZCBpbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24gb2YgYSAgY2hlY2sgDQo+
IHRoYXQgY29udGFpbmVkIHRoZSBVU0UtQ0FORElEQVRFIGF0dHJpYnV0ZS4uLg0KPg0KPiBJdCB3
YXM/IEkgZG9uJ3Qgc2VlIHRoYXQgaW4gdGhlIGxhZGRlciwgY2FuJ3QgZmluZCBpdCBpbiB0aGUg
cHJvc2UsIGFuZCBiZWxpZXZlIGl0IHRvIGJlIGFjdHVhbGx5IGluY29ycmVjdC4gDQo+IEJ5IG15
IHVuZGVyc3RhbmRpbmcsIHRoZSBleGFtcGxlIHdvdWxkIG5lZWQgYW4gYWRkaXRpb25hbCBtZXNz
YWdlcyAxOCANCj4gdGhyb3VnaCAyMSwgb3JpZ2luYXRpbmcgZnJvbSBMIChhcyB0aGUgY29udHJv
bGxpbmcgYWdlbnQpIHRoYXQgbm9taW5hdGVzIHRoaXMgcGFpci4NCj4NCj4gSSBiZWxpZXZlIHdo
YXQgeW91J3ZlIHNob3duIGlzIGFuIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiBjYWxsIGZsb3csIGJ1
dCB0aGlzIGRvY3VtZW50IG5vIGxvbmdlciBzdXBwb3J0cyBhZ2dyZXNzaXZlIG5vbWluYXRpb24u
DQo+DQo+IElmIEknbSBzaW1wbHkgY29uZnVzZWQgaGVyZSwgdGhlbiBwbGVhc2UgYWRkIHRoZSAi
VVNFLUNBTkRJREFURSIgYXR0cmlidXRlIHRvIHRoZSBsYWRkZXIgZGlhZ3JhbSBhbmQgdG8gdGhl
IGNvcnJlc3BvbmRpbmcgdGV4dCB3aGVyZSBpdCBiZWxvbmdzLg0KDQpJJ2xsIGRvdWJsZSBjaGVj
ayB0aGUgZXhhbXBsZS4gSSBkb27igJl0IHRoaW5rIHdlIGxvb2tlZCBhdCBpdCBpbiB0aGUgV0cs
IHNvIGl0IG1heSBlLmcuLCBzaG93IGFnZ3Jlc3NpdmUgbm9taW5hdGlvbi4NCg0KLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQo=


From nobody Fri Feb 23 13:22:55 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09175124D68; Fri, 23 Feb 2018 13:22:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.231
X-Spam-Level: 
X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 arp1fdAtsKBE; Fri, 23 Feb 2018 13:22:39 -0800 (PST)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 4F259124BAC; Fri, 23 Feb 2018 13:22:38 -0800 (PST)
X-AuditID: 12074422-a5fff7000000775d-68-5a90861b311c
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id A9.79.30557.C16809A5; Fri, 23 Feb 2018 16:22:36 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w1NLMYwZ004816; Fri, 23 Feb 2018 16:22:34 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w1NLMTRY028748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Feb 2018 16:22:31 -0500
Date: Fri, 23 Feb 2018 15:22:29 -0600
From: Benjamin Kaduk 
To: Peter Saint-Andre 
Cc: Christer Holmberg , "pthatcher@google.com" , "ice-chairs@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , IESG , "ice@ietf.org" 
Message-ID: <20180223212228.GI50954@kduck.kaduk.org>
References: <20180220220002.GS54688@mit.edu> <7594FB04B1934943A5C02806D1A2204B6C17B1A8@ESESSMB109.ericsson.se> <20180222195035.GS54688@mit.edu> <7594FB04B1934943A5C02806D1A2204B6C17CEFB@ESESSMB109.ericsson.se> <71931266-2676-a037-0c3f-2789c68f39fa@mozilla.com> <7594FB04B1934943A5C02806D1A2204B6C17E4A9@ESESSMB109.ericsson.se> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNKsWRmVeSWpSXmKPExsUixCmqrSvTNiHKYM5CVYsLMw8zWsw/eZ3Z 4uKsyWwW3y7UWsz4M5HZ4try16wWz1aeYnRg9/j19Sqbx4JNpR5Llvxk8ug70MUawBLFZZOS mpNZllqkb5fAlXH80132ggnCFX1TX7M3MPYKdDFyckgImEg8PLCEtYuRi0NIYDGTxIWJa9kg nI2MEg/+bmGGcK4ySaw90c8M0sIioCqx5cIXNhCbTUBFoqH7MlhcREBb4uahvSwgDcwC25gk Zh84ygKSEBZIlVi27RAriM0LtO/Ala3sEFNbmSWWfH3IDJEQlDg58wlYA7NAmcTKJW+B4hxA trTE8n8cIGFOAXuJ3Uv2gi0WFVCW2Nt3iH0Co8AsJN2zkHTPQuiGCGtJ3Pj3kglDWFti2cLX zBC2rcS6de9ZFjCyr2KUTcmt0s1NzMwpTk3WLU5OzMtLLdI11cvNLNFLTSndxAiKJXYXpR2M E/95HWIU4GBU4uHdIDkhSog1say4MvcQoyQHk5Iob5QFUIgvKT+lMiOxOCO+qDQntfgQowrQ rkcbVl9glGLJy89LVRLhLXveHyXEm5JYWZValA9TJs3BoiTO62GiHSUkkJ5YkpqdmlqQWgST leHgUJLgrW4FWiBYlJqeWpGWmVOCkGbi4DzEKMHBAzR8HkgNb3FBYm5xZjpE/hSjMcefhy/b mDluvHjdxiwEdoeUOO9xkFIBkNKM0jy4aaA0KZG9v+YVozjQo8K8zS1AVTzAFAs37xXQKiag VRe4ekFWlSQipKQaGIO7FsxR/2Kwt3qF6A/ultq91m+PfbOKn7DnvbbWvBtCGZOfRi8/ucr2 7vVcpzhuQfdcM2ed7csMZm7NVjgSGrX1yzaWKfeNGDSUp4tMrkubycfe8T/h2+E+HrYXvgYp +slL5frTdh/d2NKwMvvHY7eZYt6a5pXcb96ZiSbzLv59cfO/NcsqWJRYijMSDbWYi4oTAWYZ P2luAwAA
Archived-At: 
Subject: Re: [Ice] Benjamin Kaduk's practice ballot on draft-ietf-ice-rfc5245bis-17: (with COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 21:22:40 -0000

--x+6KMIRAuhnl3hBn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 23, 2018 at 08:29:48AM -0800, Peter Saint-Andre wrote:
> On 2/23/18 6:04 AM, Christer Holmberg wrote:
> > Hi,
> >=20
> >>>>>> Section 17 is very focused on voice traffic; is that still the mai=
n use of ICE?
> >>>>>
> >>>>> In my opinion it is.
> >>>>
> >>>> Voice to the exclusion of video, or does that include voice+video?
> >>>
> >>> While video has become more common due to WebRTC, my opinion is still=
 that voice-only traffic is still the main use.
> >>>
> >>> Note, however, that this is just my personal observation - feel free=
=20
> >>> to tell me I'm wrong :)
> >>>
> >>> And, even if we would cover video, I don't think it would impact the =
text.
> >>
> >> We might want to add a sentence to the end of Section 17.2.1 to the ef=
fect that these planning considerations=20
> >> are more significant in deployments involving video (e.g., video confe=
rencing). Also, the number of participants in=20
> >> a session obviously has an impact as well, and it seems that the curre=
nt text considers only 1:1 calls, not 1:many?
> >=20
> > I suggest the following:
> >=20
> > "The planning considerations above become more significant in multi-med=
ia
> > scenarios (e.g., audio and video conferences), and when the numbers of
> > participants in a session grow."
>=20
> WFM. This probably isn't the spec in which to precisely define the
> operational impact of running a videoconferencing service anyway...
>=20
> Peter
>=20


WFM as well.

-Benjamin

--x+6KMIRAuhnl3hBn
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQG3BAABCgAdFiEE2WGV4E2ARf9BYP0XKNmm82TrdRIFAlqQhggACgkQKNmm82Tr
dRJAvwwfQU9X1Hq6eWglYJLzI+gTBZ4BPEkKRkPPHBDC5gjLM3Lh9TgerbqRvEaJ
H/G491FgZcICHzuD4gYHf3W+Fqbll3OwyyoBHjTwwgq+zKl2XgsY1NERvUV2sJ/1
Jg0gp5eFHqMzYHlueUY37b3KTGlS6TPsxX55ZnBPRQKKNiVRneIsn7a6p4SUL96u
7CEg+n9+30bL6oFitf+PNxjj8YlpKbF+kZwomI23QO+1HqPx876m65ISBmUVLLUR
YkCPh1w/n+MetjyiCvkuRRfxs9X9SFC/cwkFLx3ZLrMF/FkYSRZ++xnirLnmJ747
ah5DcLZkjllNxRJ9ioso19bNo1iGfR9EbewhQTjGYjWQGpOAHZtz98cy8gQlmgAf
upFQDgdbRLHUjLRzpE+CxJ+fAcnDXQPfe9LuUE/Ol9H6wT+p9ttAWiszQb6oup5Q
dBiGfTJ/eZY9N6d7KFqFbvUi0LxT8da/tp0a62rZr9ntCbp09l0e1MR0SMKVvnn8
JxKuISNsNMKuIg==
=zU3o
-----END PGP SIGNATURE-----

--x+6KMIRAuhnl3hBn--


From nobody Fri Feb 23 14:10:44 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23E1127076 for ; Fri, 23 Feb 2018 14:10:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsxmCzXhYu1t for ; Fri, 23 Feb 2018 14:10:42 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 64805127010 for ; Fri, 23 Feb 2018 14:10:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519423838; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ExIbULaNJlTUPk374AwqAAU4p5VDzR8Z19NyRGacitg=; b=VXiCqaaVaKiEq5EpKKQb9QcYxyiduEjLSYbadnNsFA6s0Uh7kkz6Y7uHk4XW7Lrn jXFR8qryaKls+2BGA4U5kQc7a3IHIkfTVkv+VPBN7eWAedJXAUdgdRIADONK4066 mN2o/PlM+nnT5lcPu3K3tFEoMqxfbmTPL82iMXrHigk=;
X-AuditID: c1b4fb3a-35fff700000067b4-63-5a90915eef4e
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B5.8B.26548.E51909A5; Fri, 23 Feb 2018 23:10:38 +0100 (CET)
Received: from ESESSMB104.ericsson.se ([169.254.4.64]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Fri, 23 Feb 2018 23:10:37 +0100
From: =?utf-8?B?QXJpIEtlcsOkbmVu?= 
To: Christer Holmberg , Adam Roach 
CC: The IESG , "ice-chairs@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , Peter Thatcher , ICE WG 
Thread-Topic: [Ice] Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
Thread-Index: AQHTqvWUL4RerSy9UUOb/HLkf/KDiqOvQUQAgAM+TwA=
Date: Fri, 23 Feb 2018 22:10:36 +0000
Message-ID: 
References: <151920498287.9799.11602055137725027840.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C17B247@ESESSMB109.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C17B247@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [87.95.226.8]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2K7im7cxAlRBjdWilns+buI3WL+yevM FhdnTWaz+Hah1mLGn4nMFteWv2Z1YPNYsKnUY8mSn0wes3Y+YQlgjuKySUnNySxLLdK3S+DK uPz1M3tBm0DF5ZVPGBsYL/B3MXJySAiYSKybtI+li5GLQ0jgMKPE2XsfGCGcxYwSv079YgOp YhOwlXjSuo8VxBYRCJe49P0XM0gRs8A1Roltk88ygySEBVIl9n8/ClWUJnHt401mCNtKYvOs z2A2i4CqxI2G60wgNq+AvcS+c8/A4kICExkl3j0FW8Yp4Ccx4/gcRhCbUUBM4vupNWD1zALi EreezGeCOFtAYsme88wQtqjEy8f/WCFseYkZZ28B1XAA1WtKrN+lD9FqLXF74XE2CFtRYkr3 Q3aIEwQlTs58wjKBUWwWkg2zELpnIemehaR7FpLuBYysqxhFi1OLi3PTjYz0Uosyk4uL8/P0 8lJLNjECo/Dglt9WOxgPPnc8xCjAwajEw7uld0KUEGtiWXFl7iFGCQ5mJRHeeR1AId6UxMqq 1KL8+KLSnNTiQ4zSHCxK4rxOaRZRQgLpiSWp2ampBalFMFkmDk6pBkZJzyOLq7bEvOlclPdf uuDO/Md6DauT0k98dvzGpbK6zl+lbco8KY50NRYWCS6rQ4HnpJ7+zo87fkK4c4Vturn7uV4+ Pn7pUo7Vuzkn+IuyFxy10tH+b/XxRNNRkU+Zvz1evd/+Y2uufVKJuXLNKe8GZomdejxLlC2l ldTULmk+On8g79Dt90osxRmJhlrMRcWJAGjdsHW+AgAA
Archived-At: 
Subject: Re: [Ice] Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 22:10:44 -0000

DQoNCj4gT24gMjEgRmViIDIwMTgsIGF0IDIyLjM4LCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0
ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gDQo+PiBUaGUgZG9jdW1lbnQgY3Vy
cmVudGx5IGFwcGVhcnMgdG8gY29udGFpbiBub3JtYXRpdmUgc3RhdGVtZW50cyB0aGF0LCB3aGls
ZSBub3QgbGl0ZXJhbGx5IGNvbnRyYWRpY3RvcnksIGNlcnRhaW5seSBwb2ludCBpbXBsZW1lbnRv
cnMgaW4gY29uZmxpY3RpbmcgZGlyZWN0aW9ucy4NCj4+IMKnNS4xLjEuMSBzYXlzOg0KPj4gDQo+
PiBvICBIb3N0IGNhbmRpZGF0ZXMgY29ycmVzcG9uZGluZyB0byBJUHY2IGxpbmstbG9jYWwgYWRk
cmVzc2VzIE1VU1QNCj4+ICAgIE5PVCBiZSBnYXRoZXJlZC4NCj4+IA0KPj4gRnVydGhlciBkb3du
LCDCpzYuMS4yLjIgc2F5czoNCj4+IA0KPj4gVG8ga2VlcCB0aGUgYW1vdW50IG9mIHJlc3VsdGlu
ZyBjYW5kaWRhdGUgcGFpcnMgIHJlYXNvbmFibGUgYW5kIHRvIA0KPj4gYXZvaWQgY2FuZGlkYXRl
IHBhaXJzIHRoYXQgYXJlIGhpZ2hseSB1bmxpa2VseSB0byAgd29yaywgSVB2NiANCj4+IGxpbmst
bG9jYWwgYWRkcmVzc2VzIFtSRkM0MjkxXSBNVVNUIE5PVCBiZSBwYWlyZWQgd2l0aCAgb3RoZXIg
dGhhbiANCj4+IGxpbmstbG9jYWwgYWRkcmVzc2VzLg0KPj4gDQo+PiBUaGlzIHNlY29uZCBwYXNz
YWdlIGlzIG5vbnNlbnNpY2FsIGlmIElQdjYgbGluayBsb2NhbCBhZGRyZXNzZXMgTVVTVCBOT1Qg
YmUgZ2F0aGVyZWQuIFBsZWFzZSByZW1vdmUgb3IgYW1lbmQgb25lIG9mIA0KPj4gdGhlc2Ugbm9y
bWF0aXZlIHN0YXRlbWVudHMuIElmIHRoZSBmaXJzdCBzdGF0ZW1lbnQgaXMgcmV0YWluZWQsIHBs
ZWFzZSBhZGQgcmF0aW9uYWxlLg0KPiANCj4gQmVuIGhhZCB0aGUgc2FtZSBjb21tZW50LiBNeSBz
dWdnZXN0aW9uIHdhcyB0byByZW1vdmUgdGhlIHRleHQgaW4gNi4xLjIuMi4NCj4gDQo+IEkgZ3Vl
c3MgdGhlIHJhdGlvbmFsZSBpcyBzaW5jZSBhIGxvY2FsLWxpbmsgYWRkcmVzcyBtYXkgbm90IGJl
IHZhbGlkIGZvciBjb21tdW5pY2F0aW5nIHdpdGggdGhlIHBlZXIuDQoNCkFjdHVhbGx5IEkgdGhp
bmsgdGhpcyBpcyBqdXN0IGEgYnVnIGluIHRoZSBzcGVjIGludHJvZHVjZWQgaW4gLTEzIChzZWUg
WzFdKS4gVGhlIHRleHQgc2hvdWxkIHNheSB0aGF0IHRoZSBsaW5rLWxvY2FsIGhvc3QgY2FuZGlk
YXRlcyBNVVNUIE5PVCBiZSBnYXRoZXJlZCBpZiBSRkM3NzIxIHByaXZhY3kgbWVjaGFuaXNtcyBh
cmUgaW4gdXNlOyBpLmUuLCB0aGUgbGFzdCBidWxsZXQgc2hvdWxkIGJlIGNvbWJpbmVkIHdpdGgg
dGhlIHByZXZpb3VzIG9uZS4gT3RoZXJ3aXNlIGxpbmstbG9jYWxzIHNob3VsZCBiZSBnYXRoZXJl
ZCBhbmQgdGhlIHRleHQgaW4gNi4xLjIuMiBtYWtlcyBzZW5zZS4NCg0KDQpDaGVlcnMsDQpBcmkN
Cg0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtaWNl
LXJmYzUyNDViaXMtMTMudHh0


From nobody Fri Feb 23 15:12:05 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6F7126D3F; Fri, 23 Feb 2018 15:12:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level: 
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 eZslWypKxrHQ; Fri, 23 Feb 2018 15:11:59 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 0B16C120725; Fri, 23 Feb 2018 15:11:59 -0800 (PST)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w1NNBq9t019147 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 23 Feb 2018 17:11:53 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: Christer Holmberg , The IESG 
Cc: "draft-ietf-ice-rfc5245bis@ietf.org" ,  Peter Thatcher , "ice-chairs@ietf.org" , "ice@ietf.org" 
References: <151920498287.9799.11602055137725027840.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C17B247@ESESSMB109.ericsson.se>
From: Adam Roach 
Message-ID: <21c57c7c-6ba7-25d0-31a1-8cafbd42f3cd@nostrum.com>
Date: Fri, 23 Feb 2018 17:11:47 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C17B247@ESESSMB109.ericsson.se>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [Ice] Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 23:12:00 -0000

Christer --

Thanks for your quick responses. I've trimmed the issues that appear to 
be resolved, and have inline comments for the rest. Is it safe for me to 
assume that the comments you elided in your response will be addressed 
in the next version of the document?


On 2/21/18 2:38 PM, Christer Holmberg wrote:
> Hi Adam,
>
> Thank You for the review and comments! Please see inline.
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
>> Thanks to everyone who has contributed to this document over the many years of its development.
>>
>> The document currently appears to contain normative statements that, while not literally contradictory, certainly point implementors in conflicting directions.
>> §5.1.1.1 says:
>>
>>   o  Host candidates corresponding to IPv6 link-local addresses MUST
>>      NOT be gathered.
>>
>> Further down, §6.1.2.2 says:
>>
>>   To keep the amount of resulting candidate pairs  reasonable and to
>> avoid candidate pairs that are highly unlikely to  work, IPv6
>> link-local addresses [RFC4291] MUST NOT be paired with  other than
>> link-local addresses.
>>
>> This second passage is nonsensical if IPv6 link local addresses MUST NOT be gathered. Please remove or amend one of
>> these normative statements. If the first statement is retained, please add rationale.
> Ben had the same comment. My suggestion was to remove the text in 6.1.2.2.
>
> I guess the rationale is since a local-link address may not be valid for communicating with the peer.

Well, it is if they're on the same link. For example, when I ssh from 
one machine in my house to another, it generally uses an IPv6 link-local 
address. WebRTC is explicitly expected to use this optimal path if it 
exists. I think the fix that Ari proposes makes more sense.

> ---------------------------------------------------------------------------
>
> §5.2:
>
>>   This default
>>   SHOULD be chosen such that it is the candidate most likely to be used
>> with a peer.  For IPv6-only hosts, this would typically be a globally
>> scoped IPv6 address.  For dual-stack hosts, the IPv4 address is
>> RECOMMENDED.
>>
>>
>> I support Suresh's DISCUSS. I would propose that you recommend that dual-stack hosts SHOULD allow configuration
>> of whether IPv4 or IPv6 is used for the default, and that the configuration needs to be based on which one its administrator
>> believes has a higher chance of success in the current network environment. I am of the understanding, for example, that
>> in certain Japanese carriers, the selection of IPv6 as the default would maximize the chance of success, even today.
> My suggestion to Suresh was to simply remove the statement.

That would seem to leave the behavior undefined rather than defined in 
an unfortunate manner. I suppose that's an improvement, but not much of 
one. I still propose that the document recommend that dual-stack hosts 
SHOULD allow configuration of whether IPv4 or IPv6 is used for the 
default, and that the configuration needs to be based on which one its 
administrator believes has a higher chance of success in the current 
network environment. Do you have an objection to this approach?

> ---------------------------------------------------------------------------
>
> §8.1.2:
>
>>      *  The agent MAY begin transmitting data for this data stream as
>>         described in Section 12.1.
>>
>> This seems redundant with the fact that the data could be sent even before nomination, and runs the risk that
>> implementors might interpret it to mean that they must not send data *prior* to nomination. I think it would be
>> safest to remove this, and possibly reiterate right here that sending data is not blocked on successful pair nomination.
> I suggest to simply remove the text.

I'm okay with that.

> ---------------------------------------------------------------------------
>
>>   Nomination, Regular Nomination:  The process of the controlling agent
>>      indicating to the controlled agent which candidate pair the ICE
>>      agents will use for sending and receiving data.
>>
>> With the exception of its use in §13 (which I think should be removed), the term "Regular Nomination" (which was used to distinguish
>> from the now-removed aggressive nomination) does not appear in this document. I suggest it be removed from this definition.
> Ekr had the same comment. As people did request that we should make clear that nomination in this spec is what was called regular nomination in RFC 5245, I suggested the following modification:
>
> Nomination:  The process of the controlling agent
>        indicating to the controlled agent which candidate pair the ICE
>        agents will use for sending and receiving data. The nomination
>        process defined in this specification was referred to "regular nomination"
>        in RFC 5245.

That sounds good to me.

> ---------------------------------------------------------------------------
>
> §6.1.2.6:
>
>>                       Figure 8: Initial Pair State
>>
>> I think calling this a figure is quite a stretch. I was really thrown for a loop after reading four paragraphs to find this
>> non-sequitur label just hanging out at the end of the section.
> Ekr had the same comment. I suggest to remove the Figure text.

That seems reasonable, but it does raise the question of what happens to 
the "The table in Figure 8 illustrates an example" text -- make sure it 
is updated appropriately, please.

>
> ---------------------------------------------------------------------------
>
> §14.3:
>
>>     RTO = MAX (500ms, Ta*N * (Num-Waiting + Num-In-Progress))
>>
>> I can't tell whether the "*N" in "Ta*N" is a typo, or if the document simply doesn't define the meaning of "N" anywhere.
>> Please either fix the formula, or add a description of the meaning of "N."
> N is defined in Section 14.1.

Please either copy that definition into §14.3, or cite it here. Given 
that its definition is pretty short, I suggest copying it here.

/a


From nobody Sat Feb 24 02:58:44 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE463127275 for ; Sat, 24 Feb 2018 02:58:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGf9Y0gsX3IL for ; Sat, 24 Feb 2018 02:58:37 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 14487128954 for ; Sat, 24 Feb 2018 02:58:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519469913; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8ObHPct9rIXMEGJ5fya4ceqhS2HCrwlpxQARzbG3Hb0=; b=TNMAtKRhB2dGTsTR9Fh0B6/esdKzIlOLHgr1PZUpZlLfb4TXW1uxRoh8gFpIXzLb 5lUD1FraAQtux/9Q18wRsm0qvarF/XcBNerUeG3ZGCKpszKV1aj9viat6fgKt1+L OVXKJTvbJJsLrBMUfL7PX25TsmSgi9xIw7UWSI42ENU=;
X-AuditID: c1b4fb30-3b1ff70000004778-6f-5a9145598a5b
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 79.7C.18296.955419A5; Sat, 24 Feb 2018 11:58:33 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Sat, 24 Feb 2018 11:58:32 +0100
From: Christer Holmberg 
To: =?utf-8?B?QXJpIEtlcsOkbmVu?= , Adam Roach 
CC: The IESG , "ice-chairs@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , Peter Thatcher , ICE WG 
Thread-Topic: [Ice] Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
Thread-Index: AQHTqvWUaf7qEwtdZ0KrkPtHSF2TaKOvQY5ggAM+BQCAAOdMUA==
Date: Sat, 24 Feb 2018 10:58:32 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C190EDA@ESESSMB109.ericsson.se>
References: <151920498287.9799.11602055137725027840.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C17B247@ESESSMB109.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.165]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7tG6k68Qog877IhZ7/i5it5h/8jqz xcVZk9ksvl2otZjxZyKzxbXlr1kd2DwWbCr1WLLkJ5PHrJ1PWAKYo7hsUlJzMstSi/TtErgy Hp06wVqwSLSifeUUxgbGOyJdjBwcEgImEm/3V3cxcnEICRxmlHiz/TAThLOYUWL+lhXsIEVs AhYS3f+0uxg5OUQEYiR6509nBKlhFrjGKLFt8llmkISwQKrE9SMTmSCK0iSufbzJDGE7Sfw7 NoUNxGYRUJX4MuEvmM0r4Ctx8ckGdohlxxklmjq+s4MkOAUcJO68nQQ2iFFATOL7qTVgNrOA uMStJ/PBbAkBAYkle84zQ9iiEi8f/2OFsJUkZt3ayARyNLOApsT6XfoQrYoSU7ofskPsFZQ4 OfMJywRG0VlIps5C6JiFpGMWko4FjCyrGEWLU4uTctONjPRSizKTi4vz8/TyUks2MQJj6uCW 3wY7GF8+dzzEKMDBqMTDm2sxMUqINbGsuDL3EKMEB7OSCO9DRqAQb0piZVVqUX58UWlOavEh RmkOFiVx3pOevFFCAumJJanZqakFqUUwWSYOTqkGRuvbHdeL5ulIMhb/8f1d7hD55crsvKdf ZpQfNgkRcJrDr+qWr+uzasH94x2vFnXmzKpfzn3x69IQo2+nK27rzQ7WfP0v7XHIJqs7svet LzmoSd6Zs0D2YqZLaKrn1/XH92vz3pU85+P3XfGG55xNBWeXLJEpXZq9JNxzx5SN83kiIh62 d52ebqPEUpyRaKjFXFScCACNBkjYpQIAAA==
Archived-At: 
Subject: Re: [Ice] Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Feb 2018 10:58:39 -0000

SGkgQXJpLA0KDQpQbGVhc2Ugc3VnZ2VzdCBleGFjdCB0ZXh0IDopDQoNClJlZ2FyZHMsDQoNCkNo
cmlzdGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBcmkgS2Vyw6RuZW4g
DQpTZW50OiAyNCBGZWJydWFyeSAyMDE4IDAwOjExDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNo
cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT47IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5j
b20+DQpDYzogVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+OyBpY2UtY2hhaXJzQGlldGYub3JnOyBk
cmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYub3JnOyBQZXRlciBUaGF0Y2hlciA8cHRoYXRj
aGVyQGdvb2dsZS5jb20+OyBJQ0UgV0cgPGljZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSWNl
XSBBZGFtIFJvYWNoJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzLTE3OiAo
d2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQoNCg0KPiBPbiAyMSBGZWIgMjAxOCwgYXQgMjIu
MzgsIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdy
b3RlOg0KPiANCj4+IFRoZSBkb2N1bWVudCBjdXJyZW50bHkgYXBwZWFycyB0byBjb250YWluIG5v
cm1hdGl2ZSBzdGF0ZW1lbnRzIHRoYXQsIHdoaWxlIG5vdCBsaXRlcmFsbHkgY29udHJhZGljdG9y
eSwgY2VydGFpbmx5IHBvaW50IGltcGxlbWVudG9ycyBpbiBjb25mbGljdGluZyBkaXJlY3Rpb25z
Lg0KPj4gwqc1LjEuMS4xIHNheXM6DQo+PiANCj4+IG8gIEhvc3QgY2FuZGlkYXRlcyBjb3JyZXNw
b25kaW5nIHRvIElQdjYgbGluay1sb2NhbCBhZGRyZXNzZXMgTVVTVA0KPj4gICAgTk9UIGJlIGdh
dGhlcmVkLg0KPj4gDQo+PiBGdXJ0aGVyIGRvd24sIMKnNi4xLjIuMiBzYXlzOg0KPj4gDQo+PiBU
byBrZWVwIHRoZSBhbW91bnQgb2YgcmVzdWx0aW5nIGNhbmRpZGF0ZSBwYWlycyAgcmVhc29uYWJs
ZSBhbmQgdG8gDQo+PiBhdm9pZCBjYW5kaWRhdGUgcGFpcnMgdGhhdCBhcmUgaGlnaGx5IHVubGlr
ZWx5IHRvICB3b3JrLCBJUHY2IA0KPj4gbGluay1sb2NhbCBhZGRyZXNzZXMgW1JGQzQyOTFdIE1V
U1QgTk9UIGJlIHBhaXJlZCB3aXRoICBvdGhlciB0aGFuIA0KPj4gbGluay1sb2NhbCBhZGRyZXNz
ZXMuDQo+PiANCj4+IFRoaXMgc2Vjb25kIHBhc3NhZ2UgaXMgbm9uc2Vuc2ljYWwgaWYgSVB2NiBs
aW5rIGxvY2FsIGFkZHJlc3NlcyBNVVNUIA0KPj4gTk9UIGJlIGdhdGhlcmVkLiBQbGVhc2UgcmVt
b3ZlIG9yIGFtZW5kIG9uZSBvZiB0aGVzZSBub3JtYXRpdmUgc3RhdGVtZW50cy4gSWYgdGhlIGZp
cnN0IHN0YXRlbWVudCBpcyByZXRhaW5lZCwgcGxlYXNlIGFkZCByYXRpb25hbGUuDQo+IA0KPiBC
ZW4gaGFkIHRoZSBzYW1lIGNvbW1lbnQuIE15IHN1Z2dlc3Rpb24gd2FzIHRvIHJlbW92ZSB0aGUg
dGV4dCBpbiA2LjEuMi4yLg0KPiANCj4gSSBndWVzcyB0aGUgcmF0aW9uYWxlIGlzIHNpbmNlIGEg
bG9jYWwtbGluayBhZGRyZXNzIG1heSBub3QgYmUgdmFsaWQgZm9yIGNvbW11bmljYXRpbmcgd2l0
aCB0aGUgcGVlci4NCg0KQWN0dWFsbHkgSSB0aGluayB0aGlzIGlzIGp1c3QgYSBidWcgaW4gdGhl
IHNwZWMgaW50cm9kdWNlZCBpbiAtMTMgKHNlZSBbMV0pLiBUaGUgdGV4dCBzaG91bGQgc2F5IHRo
YXQgdGhlIGxpbmstbG9jYWwgaG9zdCBjYW5kaWRhdGVzIE1VU1QgTk9UIGJlIGdhdGhlcmVkIGlm
IFJGQzc3MjEgcHJpdmFjeSBtZWNoYW5pc21zIGFyZSBpbiB1c2U7IGkuZS4sIHRoZSBsYXN0IGJ1
bGxldCBzaG91bGQgYmUgY29tYmluZWQgd2l0aCB0aGUgcHJldmlvdXMgb25lLiBPdGhlcndpc2Ug
bGluay1sb2NhbHMgc2hvdWxkIGJlIGdhdGhlcmVkIGFuZCB0aGUgdGV4dCBpbiA2LjEuMi4yIG1h
a2VzIHNlbnNlLg0KDQoNCkNoZWVycywNCkFyaQ0KDQpbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9y
Zy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpcy0xMy50eHQNCg==


From nobody Sat Feb 24 03:14:17 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F79812D775 for ; Sat, 24 Feb 2018 03:14:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzhS3-gdqNef for ; Sat, 24 Feb 2018 03:14:14 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 30DFA12AF83 for ; Sat, 24 Feb 2018 03:14:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519470850; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OYqTAih47llF22FQ2TNydSLtCQRADGg0x86zwiz8ZFU=; b=cbCv9ZDzu2AMP9NSyndvtEBLgwp5f+5Q3hO6t2uHRDCCnVr4Blnvyv/UV1KCBr9U H7vej/bPTvj0J4dR5kzfmNVRjj8JfBf3azaGpqdRdd4cVq1qeDOD/d0h5l/x0H/I 5zo0XLUdESjEDRyP7pSNlS6HpYN2JJtvJmEyVMn4bDI=;
X-AuditID: c1b4fb30-799639c000004778-bd-5a91490266dc
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id DF.DD.18296.209419A5; Sat, 24 Feb 2018 12:14:10 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Sat, 24 Feb 2018 12:14:09 +0100
From: Christer Holmberg 
To: Adam Roach , The IESG 
CC: "draft-ietf-ice-rfc5245bis@ietf.org" ,  Peter Thatcher , "ice-chairs@ietf.org" , "ice@ietf.org" 
Thread-Topic: Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
Thread-Index: AQHTqvWUaf7qEwtdZ0KrkPtHSF2TaKOvQY5ggANPHoCAANh/EA==
Date: Sat, 24 Feb 2018 11:14:09 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C192F5D@ESESSMB109.ericsson.se>
References: <151920498287.9799.11602055137725027840.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C17B247@ESESSMB109.ericsson.se> <21c57c7c-6ba7-25d0-31a1-8cafbd42f3cd@nostrum.com>
In-Reply-To: <21c57c7c-6ba7-25d0-31a1-8cafbd42f3cd@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.165]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7ri6T58Qog8dHjC32/F3EbjH/5HVm i4uzJrNZfLtQazHjz0Rmi2vLX7M6sHks2FTqsWTJTyaPWTufsAQwR3HZpKTmZJalFunbJXBl PH/4nKngkGbF/Ht3WRoYd2h0MXJySAiYSPyev469i5GLQ0jgMKPE/W39LBDOYkaJ841rmLsY OTjYBCwkuv9pgzSICFhLnG4+yQxSwyxwhFHi5Y+PjCAJYYF4iTfn5rNDFCVI9PUeZYGwnSSO 79vCDGKzCKhK7JgwiRXE5hXwldjTswJq2TFGiXn905lAEpwC9hL3580DsxkFxCS+n1oDZjML iEvcejKfCeJsAYkle84zQ9iiEi8f/2OFsJUkZt3ayARyNLOApsT6XfoQrYoSU7ofskPsFZQ4 OfMJywRG0VlIps5C6JiFpGMWko4FjCyrGEWLU4uTctONjPRSizKTi4vz8/TyUks2MQKj6uCW 3wY7GF8+dzzEKMDBqMTDm2sxMUqINbGsuDL3EKMEB7OSCO9DRqAQb0piZVVqUX58UWlOavEh RmkOFiVx3pOevFFCAumJJanZqakFqUUwWSYOTqkGxoYrlseVVX11/jisXsvJnf+w0eUsr8Qe 0w8qTwoyYp5s2eBn8kvb8tLepluB845GhNSbyHhkGG1dNPGxiFVEDf/zUPE1atM+7+RrmbyX c+PXb+/0Xb0XtHo+nSva6fVxnmj35qjV7kfTb9+fcPGq0qOITyWrvddplrFF7Aled6tGlGv9 ta2LLyqxFGckGmoxFxUnAgD3aXZipgIAAA==
Archived-At: 
Subject: Re: [Ice] Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Feb 2018 11:14:15 -0000

SGksDQoNCj5UaGFua3MgZm9yIHlvdXIgcXVpY2sgcmVzcG9uc2VzLiBJJ3ZlIHRyaW1tZWQgdGhl
IGlzc3VlcyB0aGF0IGFwcGVhciB0byBiZSByZXNvbHZlZCwgYW5kIGhhdmUgaW5saW5lIGNvbW1l
bnRzIGZvciB0aGUgcmVzdC4gDQo+SXMgaXQgc2FmZSBmb3IgbWUgdG8gYXNzdW1lIHRoYXQgdGhl
IGNvbW1lbnRzIHlvdSBlbGlkZWQgaW4geW91ciByZXNwb25zZSB3aWxsIGJlIGFkZHJlc3NlZCBp
biB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudD8NCg0KWWVzLg0KDQo+Pj4gVGhlIGRv
Y3VtZW50IGN1cnJlbnRseSBhcHBlYXJzIHRvIGNvbnRhaW4gbm9ybWF0aXZlIHN0YXRlbWVudHMg
dGhhdCwgd2hpbGUgbm90IGxpdGVyYWxseSBjb250cmFkaWN0b3J5LCBjZXJ0YWlubHkgcG9pbnQg
aW1wbGVtZW50b3JzIGluIGNvbmZsaWN0aW5nIGRpcmVjdGlvbnMuDQo+Pj4gwqc1LjEuMS4xIHNh
eXM6DQo+Pj4NCj4+PiAgIG8gIEhvc3QgY2FuZGlkYXRlcyBjb3JyZXNwb25kaW5nIHRvIElQdjYg
bGluay1sb2NhbCBhZGRyZXNzZXMgTVVTVA0KPj4+ICAgICAgTk9UIGJlIGdhdGhlcmVkLg0KPj4+
DQo+Pj4gRnVydGhlciBkb3duLCDCpzYuMS4yLjIgc2F5czoNCj4+Pg0KPj4+ICAgVG8ga2VlcCB0
aGUgYW1vdW50IG9mIHJlc3VsdGluZyBjYW5kaWRhdGUgcGFpcnMgIHJlYXNvbmFibGUgYW5kIHRv
IA0KPj4+IGF2b2lkIGNhbmRpZGF0ZSBwYWlycyB0aGF0IGFyZSBoaWdobHkgdW5saWtlbHkgdG8g
IHdvcmssIElQdjYgDQo+Pj4gbGluay1sb2NhbCBhZGRyZXNzZXMgW1JGQzQyOTFdIE1VU1QgTk9U
IGJlIHBhaXJlZCB3aXRoICBvdGhlciB0aGFuIA0KPj4+IGxpbmstbG9jYWwgYWRkcmVzc2VzLg0K
Pj4+DQo+Pj4gVGhpcyBzZWNvbmQgcGFzc2FnZSBpcyBub25zZW5zaWNhbCBpZiBJUHY2IGxpbmsg
bG9jYWwgYWRkcmVzc2VzIE1VU1QgDQo+Pj4gTk9UIGJlIGdhdGhlcmVkLiBQbGVhc2UgcmVtb3Zl
IG9yIGFtZW5kIG9uZSBvZiB0aGVzZSBub3JtYXRpdmUgc3RhdGVtZW50cy4gSWYgdGhlIGZpcnN0
IHN0YXRlbWVudCBpcyByZXRhaW5lZCwgcGxlYXNlIGFkZCByYXRpb25hbGUuDQo+PiBCZW4gaGFk
IHRoZSBzYW1lIGNvbW1lbnQuIE15IHN1Z2dlc3Rpb24gd2FzIHRvIHJlbW92ZSB0aGUgdGV4dCBp
biA2LjEuMi4yLg0KPj4NCj4+IEkgZ3Vlc3MgdGhlIHJhdGlvbmFsZSBpcyBzaW5jZSBhIGxvY2Fs
LWxpbmsgYWRkcmVzcyBtYXkgbm90IGJlIHZhbGlkIGZvciBjb21tdW5pY2F0aW5nIHdpdGggdGhl
IHBlZXIuDQo+DQo+IFdlbGwsIGl0IGlzIGlmIHRoZXkncmUgb24gdGhlIHNhbWUgbGluay4gRm9y
IGV4YW1wbGUsIHdoZW4gSSBzc2ggZnJvbSBvbmUgbWFjaGluZSBpbiBteSBob3VzZSB0byBhbm90
aGVyLCBpdCBnZW5lcmFsbHkgdXNlcyBhbiANCj4gSVB2NiBsaW5rLWxvY2FsIGFkZHJlc3MuIFdl
YlJUQyBpcyBleHBsaWNpdGx5IGV4cGVjdGVkIHRvIHVzZSB0aGlzIG9wdGltYWwgcGF0aCBpZiBp
dCBleGlzdHMuIEkgdGhpbmsgdGhlIGZpeCB0aGF0IEFyaSBwcm9wb3NlcyBtYWtlcyBtb3JlIHNl
bnNlLg0KDQpJIGFncmVlLiBJIHdpbGwgZml4IGFzIHN1Z2dlc3RlZCBieSBBcmkuDQoNCi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0NCg0KPj4gwqc1LjI6DQo+Pg0KPj4+ICAgVGhpcyBkZWZhdWx0DQo+Pj4gICBTSE9V
TEQgYmUgY2hvc2VuIHN1Y2ggdGhhdCBpdCBpcyB0aGUgY2FuZGlkYXRlIG1vc3QgbGlrZWx5IHRv
IGJlIA0KPj4+IHVzZWQgd2l0aCBhIHBlZXIuICBGb3IgSVB2Ni1vbmx5IGhvc3RzLCB0aGlzIHdv
dWxkIHR5cGljYWxseSBiZSBhIA0KPj4+IGdsb2JhbGx5IHNjb3BlZCBJUHY2IGFkZHJlc3MuICBG
b3IgZHVhbC1zdGFjayBob3N0cywgdGhlIElQdjQgYWRkcmVzcyANCj4+PiBpcyBSRUNPTU1FTkRF
RC4NCj4+Pg0KPj4+DQo+Pj4gSSBzdXBwb3J0IFN1cmVzaCdzIERJU0NVU1MuIEkgd291bGQgcHJv
cG9zZSB0aGF0IHlvdSByZWNvbW1lbmQgdGhhdCANCj4+PiBkdWFsLXN0YWNrIGhvc3RzIFNIT1VM
RCBhbGxvdyBjb25maWd1cmF0aW9uIG9mIHdoZXRoZXIgSVB2NCBvciBJUHY2IA0KPj4+IGlzIHVz
ZWQgZm9yIHRoZSBkZWZhdWx0LCBhbmQgdGhhdCB0aGUgY29uZmlndXJhdGlvbiBuZWVkcyB0byBi
ZSBiYXNlZCANCj4+PiBvbiB3aGljaCBvbmUgaXRzIGFkbWluaXN0cmF0b3IgYmVsaWV2ZXMgaGFz
IGEgaGlnaGVyIGNoYW5jZSBvZiBzdWNjZXNzIGluIHRoZSBjdXJyZW50IG5ldHdvcmsgZW52aXJv
bm1lbnQuIA0KPj4+IEkgYW0gb2YgdGhlIHVuZGVyc3RhbmRpbmcsIGZvciBleGFtcGxlLCB0aGF0
IGluIGNlcnRhaW4gSmFwYW5lc2UgY2FycmllcnMsIHRoZSBzZWxlY3Rpb24gb2YgSVB2NiBhcyB0
aGUgZGVmYXVsdCANCj4+PiB3b3VsZCBtYXhpbWl6ZSB0aGUgY2hhbmNlIG9mIHN1Y2Nlc3MsIGV2
ZW4gdG9kYXkuDQo+PiBNeSBzdWdnZXN0aW9uIHRvIFN1cmVzaCB3YXMgdG8gc2ltcGx5IHJlbW92
ZSB0aGUgc3RhdGVtZW50Lg0KPg0KPiBUaGF0IHdvdWxkIHNlZW0gdG8gbGVhdmUgdGhlIGJlaGF2
aW9yIHVuZGVmaW5lZCByYXRoZXIgdGhhbiBkZWZpbmVkIGluIGFuIHVuZm9ydHVuYXRlIG1hbm5l
ci4gSSBzdXBwb3NlIHRoYXQncyANCj4gYW4gaW1wcm92ZW1lbnQsIGJ1dCBub3QgbXVjaCBvZiBv
bmUuIEkgc3RpbGwgcHJvcG9zZSB0aGF0IHRoZSBkb2N1bWVudCByZWNvbW1lbmQgdGhhdCBkdWFs
LXN0YWNrIGhvc3RzIFNIT1VMRCANCj4gYWxsb3cgY29uZmlndXJhdGlvbiBvZiB3aGV0aGVyIElQ
djQgb3IgSVB2NiBpcyB1c2VkIGZvciB0aGUgZGVmYXVsdCwgYW5kIHRoYXQgdGhlIGNvbmZpZ3Vy
YXRpb24gbmVlZHMgdG8gYmUgYmFzZWQgb24NCj4gd2hpY2ggb25lIGl0cyBhZG1pbmlzdHJhdG9y
IGJlbGlldmVzIGhhcyBhIGhpZ2hlciBjaGFuY2Ugb2Ygc3VjY2VzcyBpbiB0aGUgY3VycmVudCBu
ZXR3b3JrIGVudmlyb25tZW50LiANCj4gRG8geW91IGhhdmUgYW4gb2JqZWN0aW9uIHRvIHRoaXMg
YXBwcm9hY2g/DQoNCkkgYW0gb2sgd2l0aCBpdC4gSSB3aWxsIG1vZGlmeSBhcyBzdWdnZXN0ZWQu
DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0NCg0KPj4gwqc2LjEuMi42Og0KPj4NCj4+PiAgICAgICAgICAgICAg
ICAgICAgICAgRmlndXJlIDg6IEluaXRpYWwgUGFpciBTdGF0ZQ0KPj4+DQo+Pj4gSSB0aGluayBj
YWxsaW5nIHRoaXMgYSBmaWd1cmUgaXMgcXVpdGUgYSBzdHJldGNoLiBJIHdhcyByZWFsbHkgdGhy
b3duIA0KPj4+IGZvciBhIGxvb3AgYWZ0ZXIgcmVhZGluZyBmb3VyIHBhcmFncmFwaHMgdG8gZmlu
ZCB0aGlzIG5vbi1zZXF1aXR1ciBsYWJlbCBqdXN0IGhhbmdpbmcgb3V0IGF0IHRoZSBlbmQgb2Yg
dGhlIHNlY3Rpb24uDQo+PiBFa3IgaGFkIHRoZSBzYW1lIGNvbW1lbnQuIEkgc3VnZ2VzdCB0byBy
ZW1vdmUgdGhlIEZpZ3VyZSB0ZXh0Lg0KPg0KPiBUaGF0IHNlZW1zIHJlYXNvbmFibGUsIGJ1dCBp
dCBkb2VzIHJhaXNlIHRoZSBxdWVzdGlvbiBvZiB3aGF0IGhhcHBlbnMgdG8gdGhlICJUaGUgdGFi
bGUgaW4gRmlndXJlIDggaWxsdXN0cmF0ZXMgYW4gDQo+IGV4YW1wbGUiIHRleHQgLS0gbWFrZSBz
dXJlIGl0IGlzIHVwZGF0ZWQgYXBwcm9wcmlhdGVseSwgcGxlYXNlLg0KDQpPbmUgc3VnZ2VzdGlv
biB3b3VsZCBiZSB0byBzcGxpdCB0aGUgZmlndXJlLCBhbmQgdGhlIHRleHQgYmVsb3csIGludG8g
dHdvIHNlcGFyYXRlIDxmaWd1cmU+IGVsZW1lbnRzLiBUaGF0IHdheSwgIkZpZ3VyZSA4IiB3b3Vs
ZCBhcHBlYXIgZGlyZWN0bHkgYmVsb3cgdGhlIGZpZ3VyZS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0
ZXINCg==


From nobody Sat Feb 24 03:46:38 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7871012D871 for ; Sat, 24 Feb 2018 03:46:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VW-zWUK8jt2 for ; Sat, 24 Feb 2018 03:46:35 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 3A38F12D82F for ; Sat, 24 Feb 2018 03:46:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519472793; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=oedpaIskw2pYTBPcEqBUygYV8eziH1B6/crEHUxV1+4=; b=OAcinc+ZuIpZ8eVapKW+GHkJqnigo8x6VAqAldPp8iF3HsvjYEUx/TLsT7vAEkKJ Hxawpa8q+fwlebbE+0QJIZ0nNMCe8r1wUI5gDuuoMas1pzcRXt/LAAwF60xNAtRe oZKurcxbOxad6Z38Ld4c5ae7WbQxFtRDuS0dfDlJizY=;
X-AuditID: c1b4fb2d-499ff70000005540-46-5a91509862d0
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 22.D7.21824.890519A5; Sat, 24 Feb 2018 12:46:33 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Sat, 24 Feb 2018 12:46:32 +0100
From: Christer Holmberg 
To: Christer Holmberg , Adam Roach , The IESG 
CC: "draft-ietf-ice-rfc5245bis@ietf.org" ,  Peter Thatcher , "ice-chairs@ietf.org" , "ice@ietf.org" 
Thread-Topic: Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
Thread-Index: AQHTqvWUaf7qEwtdZ0KrkPtHSF2TaKOvQY5ggANPHoCAANh/EIAACr/g
Date: Sat, 24 Feb 2018 11:46:32 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1940CF@ESESSMB109.ericsson.se>
References: <151920498287.9799.11602055137725027840.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B6C17B247@ESESSMB109.ericsson.se> <21c57c7c-6ba7-25d0-31a1-8cafbd42f3cd@nostrum.com> <7594FB04B1934943A5C02806D1A2204B6C192F5D@ESESSMB109.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C192F5D@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.165]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7lu7MgIlRBs/n8Fjs+buI3WL+yevM FhdnTWaz+Hah1mLGn4nMFteWv2Z1YPNYsKnUY8mSn0wes3Y+YQlgjuKySUnNySxLLdK3S+DK 2H/5H1tBD09F4+Rm5gbGJ9xdjBwcEgImErs3eHQxcnIICRxmlNhw1ryLkQvIXswoMfPSJxaQ GjYBC4nuf9ogpohAocSrw5IgJcwCRxglXv74yAjSKywQL/Hm3Hx2EFtEIEGir/coC4TtJrH/ 1R9mEJtFQFViw7VJTCA2r4CvxNw191ggdnUxSZxZ/x4swSngJ7G4ZyVYM6OAmMT3U2vA4swC 4hK3nswHsyUEBCSW7DnPDGGLSrx8/I8VwlaSmHVrIxPIocwCmhLrd+lDtCpKTOl+yA6xV1Di 5MwnLBMYRWchmToLoWMWko5ZSDoWMLKsYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAiMp4Nb fuvuYFz92vEQowAHoxIP7yPziVFCrIllxZW5hxglOJiVRHgfMgKFeFMSK6tSi/Lji0pzUosP MUpzsCiJ85705I0SEkhPLEnNTk0tSC2CyTJxcEo1MDL9f5akJj1DxnHWrMs/9Tz3HuVLr/FQ K5Gw5anU+eEz7c/l0uVzyzcaFSz9KWpramG7TP1hWvW+J/tmfpTbrZKx1CXBbOvjVbsUJfL5 /TOVNwW8N5KYetj1rumv2e4RTzbpTAqaZl7K73pBXe5LrfmWq6ZavssfZzoc4bCMYJ4hHT/5 zrGfn5RYijMSDbWYi4oTAYEQ2ZijAgAA
Archived-At: 
Subject: Re: [Ice] Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Feb 2018 11:46:37 -0000

SGksDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KPj4+IMKnNi4xLjIuNjoNCj4+Pg0KPj4+PiAgICAgICAg
ICAgICAgICAgICAgICAgRmlndXJlIDg6IEluaXRpYWwgUGFpciBTdGF0ZQ0KPj4+Pg0KPj4+PiBJ
IHRoaW5rIGNhbGxpbmcgdGhpcyBhIGZpZ3VyZSBpcyBxdWl0ZSBhIHN0cmV0Y2guIEkgd2FzIHJl
YWxseSANCj4+Pj4gdGhyb3duIGZvciBhIGxvb3AgYWZ0ZXIgcmVhZGluZyBmb3VyIHBhcmFncmFw
aHMgdG8gZmluZCB0aGlzIG5vbi1zZXF1aXR1ciBsYWJlbCBqdXN0IGhhbmdpbmcgb3V0IGF0IHRo
ZSBlbmQgb2YgdGhlIHNlY3Rpb24uDQo+Pj4gRWtyIGhhZCB0aGUgc2FtZSBjb21tZW50LiBJIHN1
Z2dlc3QgdG8gcmVtb3ZlIHRoZSBGaWd1cmUgdGV4dC4NCj4+DQo+PiBUaGF0IHNlZW1zIHJlYXNv
bmFibGUsIGJ1dCBpdCBkb2VzIHJhaXNlIHRoZSBxdWVzdGlvbiBvZiB3aGF0IGhhcHBlbnMgDQo+
PiB0byB0aGUgIlRoZSB0YWJsZSBpbiBGaWd1cmUgOCBpbGx1c3RyYXRlcyBhbiBleGFtcGxlIiB0
ZXh0IC0tIG1ha2Ugc3VyZSBpdCBpcyB1cGRhdGVkIGFwcHJvcHJpYXRlbHksIHBsZWFzZS4NCj4N
Cj4gT25lIHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gc3BsaXQgdGhlIGZpZ3VyZSwgYW5kIHRoZSB0
ZXh0IGJlbG93LCBpbnRvIHR3byBzZXBhcmF0ZSA8ZmlndXJlPiBlbGVtZW50cy4gVGhhdCB3YXks
ICJGaWd1cmUgOCIgd291bGQgYXBwZWFyIGRpcmVjdGx5IGJlbG93IHRoZSBmaWd1cmUuDQoNCkFj
dHVhbGx5LCBJIG5vdGVkIHRoYXQgbXkgc3VnZ2VzdGlvbiBhYm92ZSBpc24ndCB2ZXJ5IGdvb2Qs
IGFzIHRoZXJlIGlzIGFsc28gdGV4dCBiZXR3ZWVuIHRoZSB0YWJsZXMuDQoNClNvLCBJIHN1Z2dl
c3QgdG8gc2ltcGx5IHJlbW92ZSB0aGUgZmlndXJlIHRleHQsIGFuZCBtb2RpZnkgdGhlIGZvbGxv
d2luZyBzZW50ZW5jZToNCg0KT0xEOg0KDQogICAgICAgVGhlIHRhYmxlIGluIEZpZ3VyZSA4IGls
bHVzdHJhdGVzIGFuIGV4YW1wbGUuDQoNCk5FVzoNCg0KICAgICAgIFRoZSB0YWJsZSBiZWxvdyBp
bGx1c3RyYXRlcyBhbiBleGFtcGxlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K


From nobody Sat Feb 24 05:07:54 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD0612D87C for ; Sat, 24 Feb 2018 05:07:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 kdVJiK_0ite5 for ; Sat, 24 Feb 2018 05:07:50 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 5D680129C6C for ; Sat, 24 Feb 2018 05:07:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519477668; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pPBpSGnWEGGm2b2f2vbPKtkvblT2ZotD5+HxEMeIWyM=; b=UcbTdxN0SSI4HdNf1KORurzbgbgOvu8cEJKxEWbFRYXy24ssXmwbjdAFWv5spfTM Fycz7N2VQyrGMDS3ufDmMS+J/4gQOCXZeyGoqdXvPPlSe2NFGuI/V8VzXmZo4ft2 Ne4QPbMI0wb3l6ok0KIrszFBXTeXf1TY2//wxwrWxvk=;
X-AuditID: c1b4fb30-3b1ff70000004778-8a-5a9163a4fa17
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id AB.C6.18296.4A3619A5; Sat, 24 Feb 2018 14:07:48 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Sat, 24 Feb 2018 14:07:48 +0100
From: Christer Holmberg 
To: Adam Roach , The IESG 
CC: "draft-ietf-ice-rfc5245bis@ietf.org" ,  Peter Thatcher , "ice-chairs@ietf.org" , "ice@ietf.org" 
Thread-Topic: Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT) - the pull request
Thread-Index: AdOtb9qE5FIvhEYbSnOLjTl5qCr/ng==
Date: Sat, 24 Feb 2018 13:07:47 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1941F8@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.165]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM2K7tO6S5IlRBu0rZCz2/F3EbjH/5HVm i4uzJrNZfLtQazHjz0Rmi2vLX7M6sHks2FTqsWTJTyaPWTufsAQwR3HZpKTmZJalFunbJXBl HN6SU7BKrGLDvO2MDYwPRLsYOTkkBEwkLj88ztLFyMUhJHCYUWJ78yNGCGcxo8SJ76eAHA4O NgELie5/2iANIgLWEqebTzKD1DALHGGUePnjIyNIQligSGLG/sesEEXFEkcWTIay9SQ+N55h A7FZBFQlVr6+zwJi8wr4Skx+ux6shlFATOL7qTVMIDazgLjErSfzmSCuE5BYsuc8M4QtKvHy 8T9WCFtJYtatjUwgtzELaEqs36UP0aooMaX7ITvEeEGJkzOfsExgFJ6FZOoshI5ZSDpmIelY wMiyilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMwQg5u+W2wg/Hlc8dDjAIcjEo8vHZBE6OE WBPLiitzDzFKcDArifA+ZAQK8aYkVlalFuXHF5XmpBYfYpTmYFES5z3pyRslJJCeWJKanZpa kFoEk2Xi4JRqYBRwjXA94uKttZN7L5ex0/T5J97vE9uVecJgkrbNV+nLLmk3Ql3tTwebfuFf VcLPcVdZbMvTuXPen3k+rWxtlOEqtaao6BJ2x2kzMp+xMxdMDri7LMXnyt9/e6Omzt4wMzvh wc2oDxs8zLZ/PisxyXRb8Qxb1QbOqzUVRfdehh6M1rpzzKmcu0KJpTgj0VCLuag4EQDiqZxA jAIAAA==
Archived-At: 
Subject: Re: [Ice] Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT) - the pull request
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Feb 2018 13:07:52 -0000

SGksDQoNCkkgaGF2ZSB1cGRhdGVkIHRoZSBwdWxsIHJlcXVlc3QgYmFzZWQgb24gQWRhbSdzIHJl
dmlldzoNCg0KaHR0cHM6Ly9naXRodWIuY29tL2ljZS13Zy9yZmM1MjQ1YmlzL3B1bGwvNTkNCg0K
Tm90ZSB0aGF0IHRoZSBmb2xsb3dpbmcgaXNzdWVzIHN0aWxsIG5lZWQgdG8gYmUgYWRkcmVzc2Vk
Og0KDQpRMTogSVB2NiBleGFtcGxlIGluIFNlY3Rpb24gMTUNCg0KU3RhdHVzOiBXb3JraW5nIG9u
IGl0Lg0KDQoNClEyOiBNZWFuaW5nIG9mIEhUTyB0aW1lci4gDQoNClN0YXR1czogIERvZXMgc29t
ZW9uZSBrbm93IHdoZXJlICJIVE8iIGNvbWVzIGZyb20sIGFuZCB3aGF0IGl0IG1lYW5zPw0KDQoN
ClEzOiBDaXRhdGlvbiBvZiBleHBlcmltZW50cyBzaG93aW5nIHRoYXQgNW1zIGlzIGdvb2QuDQoN
ClN0YXR1czogTm90IHN1cmUgaG93IHRvIGRvIHdpdGggdGhpcy4gQUZBSVIsIEdvb2dsZSBicm91
Z2h0IG51bWJlcnMgdG8gYW4gSUVURiBtZWV0aW5nLCBhbmQgdGhlIGdyb3VwIGFncmVlZCBvbiA1
bXMuDQoNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgDQpTZW50OiAyNCBGZWJydWFyeSAyMDE4IDEz
OjQ3DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv
bT47IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb20+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9y
Zz4NCkNjOiBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYub3JnOyBQZXRlciBUaGF0Y2hl
ciA8cHRoYXRjaGVyQGdvb2dsZS5jb20+OyBpY2UtY2hhaXJzQGlldGYub3JnOyBpY2VAaWV0Zi5v
cmcNClN1YmplY3Q6IFJFOiBBZGFtIFJvYWNoJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLWljZS1y
ZmM1MjQ1YmlzLTE3OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KDQpIaSwNCg0KLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQ0KDQo+Pj4gwqc2LjEuMi42Og0KPj4+DQo+Pj4+ICAgICAgICAgICAgICAgICAgICAg
ICBGaWd1cmUgODogSW5pdGlhbCBQYWlyIFN0YXRlDQo+Pj4+DQo+Pj4+IEkgdGhpbmsgY2FsbGlu
ZyB0aGlzIGEgZmlndXJlIGlzIHF1aXRlIGEgc3RyZXRjaC4gSSB3YXMgcmVhbGx5IA0KPj4+PiB0
aHJvd24gZm9yIGEgbG9vcCBhZnRlciByZWFkaW5nIGZvdXIgcGFyYWdyYXBocyB0byBmaW5kIHRo
aXMgbm9uLXNlcXVpdHVyIGxhYmVsIGp1c3QgaGFuZ2luZyBvdXQgYXQgdGhlIGVuZCBvZiB0aGUg
c2VjdGlvbi4NCj4+PiBFa3IgaGFkIHRoZSBzYW1lIGNvbW1lbnQuIEkgc3VnZ2VzdCB0byByZW1v
dmUgdGhlIEZpZ3VyZSB0ZXh0Lg0KPj4NCj4+IFRoYXQgc2VlbXMgcmVhc29uYWJsZSwgYnV0IGl0
IGRvZXMgcmFpc2UgdGhlIHF1ZXN0aW9uIG9mIHdoYXQgaGFwcGVucyANCj4+IHRvIHRoZSAiVGhl
IHRhYmxlIGluIEZpZ3VyZSA4IGlsbHVzdHJhdGVzIGFuIGV4YW1wbGUiIHRleHQgLS0gbWFrZSBz
dXJlIGl0IGlzIHVwZGF0ZWQgYXBwcm9wcmlhdGVseSwgcGxlYXNlLg0KPg0KPiBPbmUgc3VnZ2Vz
dGlvbiB3b3VsZCBiZSB0byBzcGxpdCB0aGUgZmlndXJlLCBhbmQgdGhlIHRleHQgYmVsb3csIGlu
dG8gdHdvIHNlcGFyYXRlIDxmaWd1cmU+IGVsZW1lbnRzLiBUaGF0IHdheSwgIkZpZ3VyZSA4IiB3
b3VsZCBhcHBlYXIgZGlyZWN0bHkgYmVsb3cgdGhlIGZpZ3VyZS4NCg0KQWN0dWFsbHksIEkgbm90
ZWQgdGhhdCBteSBzdWdnZXN0aW9uIGFib3ZlIGlzbid0IHZlcnkgZ29vZCwgYXMgdGhlcmUgaXMg
YWxzbyB0ZXh0IGJldHdlZW4gdGhlIHRhYmxlcy4NCg0KU28sIEkgc3VnZ2VzdCB0byBzaW1wbHkg
cmVtb3ZlIHRoZSBmaWd1cmUgdGV4dCwgYW5kIG1vZGlmeSB0aGUgZm9sbG93aW5nIHNlbnRlbmNl
Og0KDQpPTEQ6DQoNCiAgICAgICBUaGUgdGFibGUgaW4gRmlndXJlIDggaWxsdXN0cmF0ZXMgYW4g
ZXhhbXBsZS4NCg0KTkVXOg0KDQogICAgICAgVGhlIHRhYmxlIGJlbG93IGlsbHVzdHJhdGVzIGFu
IGV4YW1wbGUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo=


From nobody Sat Feb 24 12:17:39 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA1D12D7F5 for ; Sat, 24 Feb 2018 12:17:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toqrl85da52Z for ; Sat, 24 Feb 2018 12:17:36 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 A4817120454 for ; Sat, 24 Feb 2018 12:17:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519503453; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NF1VJv8CXiQjc09ijwRlinUJsG9ATpP7qQnU6oOewKc=; b=b3ULeMecRRcLRgdbDVzfrRr27wwIUZYqD34ncl6sZ6xiYE6GFyQJKtj87f6ZqH0J zx+8v5213GJxlgQyb8Hme4DTJzWB1F/DleRNARI4bfwrVnIs3sklgtC7380UVeUu sRFI4m/cI1PQ4ABVGlcYjqWYEKhATJjMCDkOf1Mvvzs=;
X-AuditID: c1b4fb30-3b1ff70000004778-39-5a91c85d261d
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C9.B3.18296.D58C19A5; Sat, 24 Feb 2018 21:17:33 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Sat, 24 Feb 2018 21:17:33 +0100
From: Christer Holmberg 
To: Christer Holmberg , Eric Rescorla 
CC: The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , "pthatcher@google.com" , "ice@ietf.org" 
Thread-Topic: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
Thread-Index: AdOpa677O8VqdAW5ThyXNM/NhWOUGQAG8xsAAApmZdD///0JgP//0MkQ//fXbgA=
Date: Sat, 24 Feb 2018 20:17:32 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C19788F@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C17768D@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C17801A@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C1781B1@ESESSMB109.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1781B1@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.166]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7um7siYlRBssOqFvMP3md2WLF63Ps FhdnTWaz+Hah1mLGn4nMFteWv2Z1YPNYsKnUY8mSn0wekx+3MQcwR3HZpKTmZJalFunbJXBl XDoXUHCJqaJz3SymBsYTTF2MnBwSAiYS82++Z+5i5OIQEjjMKNHcNJMRwlnMKPHywGWgDAcH m4CFRPc/bRBTRCBM4tpmLpASZoEXjBLnZr4CGyQsUC/xaFU/G0hCRKCBUeLLpSmsIAkRAT+J t+susIDYLAKqEg0P1rGDDOIV8JV4+7oUYtdjJolrK5czg9RwAtWvPvgPzGYUEJP4fmoN2AJm AXGJW0/mQ10tILFkz3lmCFtU4uXjf6wQtpLE0dOXWEHmMwtoSqzfpQ/RqigxpfshO4jNKyAo cXLmE5YJjKKzkEydhdAxC0nHLCQdCxhZVjGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIERtTB Lb8NdjC+fO54iFGAg1GJh/fSlolRQqyJZcWVuYcYJTiYlUR4HzIChXhTEiurUovy44tKc1KL DzFKc7AoifOe9OSNEhJITyxJzU5NLUgtgskycXBKNTAKs+37cVhFpX82z423G9hee8vN0sr+ u+bHk6sZB5QOrlkuq7hoLcOjs7VCR090zT9l+2ZG6IyoeX1FfhZW115Nstu3oJRRbs8fo5KA JV+kNvhfuv12Buf9qA2d+j5aP2/KZk2d4f7h7Lqtmu82OykwNrgGrdf9/Gb717nmsUrHsxTK l949IZmVp8RSnJFoqMVcVJwIAAyRaCqkAgAA
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Feb 2018 20:17:38 -0000

SGksDQoNCkJhc2VkIG9uIEVrcidzIG5vbi1zZWN1cml0eSBJRVNHIGNvbW1lbnRzLCBJIGhhdmUg
dXBkYXRlZCB0aGUgcHVsbCByZXF1ZXN0Og0KDQpodHRwczovL2dpdGh1Yi5jb20vaWNlLXdnL3Jm
YzUyNDViaXMvcHVsbC81OQ0KDQpTdGlsbCB0byBkbzoNCg0KLSBBZGRpdGlvbiBvZiBJUHY2IGFk
ZHJlc3NlcyB0byBleGFtcGxlDQotIEZpeCByb2xlIGNvbmZsaWN0IGlzc3VlDQoNClJlZ2FyZHMs
DQoNCkNocmlzdGVyDQoNCg==


From nobody Sat Feb 24 12:38:14 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C319312D869 for ; Sat, 24 Feb 2018 12:38:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.319
X-Spam-Level: 
X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOmflwJuHsKz for ; Sat, 24 Feb 2018 12:38:01 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6350112D86A for ; Sat, 24 Feb 2018 12:37:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519504675; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qJs2e8l6+FMefWyWx4g8VUN/PqaaU5ENGX1G6CTLxOA=; b=GyhNMKBeqrqYj8viBmlJTyihnrAQmn4cnhL3rQCvdG/F5G6U9IsGBn52mJnwcc8e hUfvjJ7ROvXqSWuVyNhntMQQ+Gg7QINdyXXKxkgZ2R4ft+dg1C6IDTdVciXlQSnc xstDY7Z+i0UkoCdwKtR68dXLaG0Z1uomgvzh6wxHvJ0=;
X-AuditID: c1b4fb25-06bff70000002d5f-fc-5a91cd235b8f
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 26.76.11615.32DC19A5; Sat, 24 Feb 2018 21:37:55 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0352.000; Sat, 24 Feb 2018 21:37:55 +0100
From: Christer Holmberg 
To: Eric Rescorla , Taylor Brandstetter 
CC: Ben Campbell , "ice-chairs@ietf.org" , "ice@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , "pthatcher@google.com" , The IESG 
Thread-Topic: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) - Role conflict issue
Thread-Index: AdOtrLvZAFt0StyXRbqqxzpPZeyvVQ==
Date: Sat, 24 Feb 2018 20:37:54 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1978FA@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.166]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C1978FAESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7h67y2YlRBkvOKVvM7zzNbnF5xUNW i/knrzNbrHh9jt3i4qzJbBbfLtRazPgzkdni2vLXrA4cHgs2lXosWfKTyWPWzicsHpMftzEH sERx2aSk5mSWpRbp2yVwZTx41s5U8GUxU8XMacUNjAvmMHUxcnJICJhIfPhyirGLkYtDSOAw o8SyNcvYQRJCAosZJV50c3cxcnCwCVhIdP/TBgmLCHhLzF7xhQmknlmgg0li2et5YI6wwFxG iT1vVzCDOCIC8xglWt+fZQXpFhHQkzi3uxCkm0VAVeLL+XOMIDavgK/ExD9H2UBsRgExie+n 1oBdxCwgLnHryXyo6wQkluw5zwxhi0q8fPyPFcJWkjh6+hIrRH2+xMrPS9ggZgpKnJz5hGUC o9AsJKNmISmbhaRsFtB1zAKaEut36UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0Vo2hxanFSbrqR sV5qUWZycXF+nl5easkmRmDUHdzyW3UH4+U3jocYBTgYlXh45bZMjBJiTSwrrsw9xCjBwawk wvuQESjEm5JYWZValB9fVJqTWnyIUZqDRUmcd45we5SQQHpiSWp2ampBahFMlomDU6qBUbPj 6Po3hzWWVO1fVa0r+aTl8Nr1B271+qe3Bbg33+gO93h782OgcI3opGWSSRY9825LVXiJZIXa Ljqn+2wfv+S+Waf3LcmfmjzXREKjcuq0lVrZK4p1rs5ZMF36zJKiiu7bJ+5VdD02eMS95flT yz9xelpyiWH3PB44HjAVrN6Zc+nC/q0l15RYijMSDbWYi4oTAV/pzm62AgAA
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) - Role conflict issue
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Feb 2018 20:38:04 -0000

--_000_7594FB04B1934943A5C02806D1A2204B6C1978FAESESSMB109erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNCkkgaGFkIGEgY2xvc2VyIGxvb2sgYXQgdGhlIHJvbGUgY29uZmxpY3QgaXNzdWUuDQoN
CkZpcnN0LCB0aGUgZHJhZnQgYWxyZWFkeSBjb3ZlcnMgdGhlIGNhc2Ugd2hlbiB0aGUgdGllLWJy
ZWFrZXIgdmFsdWVzIGFyZSBpZGVudGljYWwuIEl0IGlzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDcu
My4xLjE6DQoNCiAgIOKAnElmIHRoZSBhZ2VudCdzIHRpZS1icmVha2VyIHZhbHVlIGlzIGxhcmdl
ciB0aGFuIG9yIGVxdWFsIHRv4oCm4oCdDQoNCuKApnRoZSBhZ2VudCBzZW5kcyA0ODcuDQoNClRo
ZW4sIGFjY29yZGluZyB0byBzZWN0aW9uIDcuMi41LjEuLCB3aGVuIGFuIGFnZW50IHJlY2VpdmVz
IHRoZSA0ODcgcmVzcG9uc2UgaXQgd2lsbCBjaGFuZ2UgaXRzIHJvbGUuDQoNCk5vdywgaWYgQk9U
SCBhZ2VudHMgc2VuZCA0ODcsIGl0IG1lYW5zIEJPVEggYWdlbnRzIHdpbGwgc3dpdGNoIHRoZWly
IHJvbGVzLCBhbmQgdHJ5IGFnYWluLiBOb3csIHNpbmNlIGJvdGggYWdlbnRzIHN3aXRjaCB0aGVp
ciByb2xlLCBhbmQga2VlcCB0aGUgc2FtZSB0aWUtYnJlYWtlciB2YWx1ZSwgdGhlIHJlc3VsdCB3
aWxsIGFnYWluIGJlIHRoZSBzYW1lIChvbmx5IHdpdGggZGlmZmVyZW50IHJvbGVzKS4NCg0KQnV0
LCBpZiBib3RoIGFnZW50cyBhbHNvIGNoYW5nZSB0aGVpciB0aWUtYnJlYWtlciB2YWx1ZSwgbW9z
dCBsaWtlbHkgb25seSBvbmUgYWdlbnQgd2lsbCBzZW5kIDQ4NywgYW5kIHRoaW5ncyB3aWxsIHdv
cmsuDQoNCihTZWN0aW9uIDcuMi41LjEgYWN0dWFsbHkgYWxyZWFkeSBhbGxvd3MgY2hhbmdpbmcg
dGhlIHRpZS1icmVha2VyIHZhbHVlLCB3aGljaCBjb250cmFkaWN0cyB0aGUgbXVzdC1ub3QtY2hh
bmdlIHJ1bGUgaW4gU2VjdGlvbiAxNi4xKQ0KDQoNClNvLCBiYXNlZCBvbiB0aGUgaWRlYSBhYm92
ZSwgdGhlIGNoYW5nZXMgd291bGQgYmU6DQoNClNlY3Rpb24gNy4yLjUuMToNCj09PT09PT09PT09
PT0NCg0KT0xEOg0KDQpPbmNlIHRoZSBhZ2VudCBoYXMgc3dpdGNoZWQgaXRzIHJvbGUsIHRoZSBh
Z2VudCBNVVNUIGFkZCB0aGUNCmNhbmRpZGF0ZSBwYWlyIHdob3NlIGNoZWNrIGdlbmVyYXRlZCB0
aGUgNDg3IGVycm9yIHJlc3BvbnNlIHRvIHRoZQ0KdHJpZ2dlcmVkIGNoZWNrIHF1ZXVlIGFzc29j
aWF0ZWQgd2l0aCB0aGUgY2hlY2sgbGlzdCB0byB3aGljaCB0aGUNCnBhaXIgYmVsb25ncywgYW5k
IHNldCB0aGUgY2FuZGlkYXRlIHBhaXIgc3RhdGUgdG8gV2FpdGluZy4gIFdoZW4gdGhlDQp0cmln
Z2VyZWQgY29ubmVjdGl2aXR5IGNoZWNrIGlzIGxhdGVyIHBlcmZvcm1lZCwgdGhlIElDRS1DT05U
Uk9MTElORy8NCklDRS1DT05UUk9MTEVEIGF0dHJpYnV0ZSBvZiB0aGUgQmluZGluZyByZXF1ZXN0
IHdpbGwgaW5kaWNhdGUgdGhlDQphZ2VudCdzIG5ldyByb2xlLiAgVGhlIGFnZW50IE1BWSBjaGFu
Z2UgdGhlIHRpZS1icmVha2VyIHZhbHVlLg0KDQoNCk5FVzoNCg0KT25jZSB0aGUgYWdlbnQgaGFz
IHN3aXRjaGVkIGl0cyByb2xlLCB0aGUgYWdlbnQgTVVTVCBhZGQgdGhlDQpjYW5kaWRhdGUgcGFp
ciB3aG9zZSBjaGVjayBnZW5lcmF0ZWQgdGhlIDQ4NyBlcnJvciByZXNwb25zZSB0byB0aGUNCnRy
aWdnZXJlZCBjaGVjayBxdWV1ZSBhc3NvY2lhdGVkIHdpdGggdGhlIGNoZWNrIGxpc3QgdG8gd2hp
Y2ggdGhlDQpwYWlyIGJlbG9uZ3MsIGFuZCBzZXQgdGhlIGNhbmRpZGF0ZSBwYWlyIHN0YXRlIHRv
IFdhaXRpbmcuICBXaGVuIHRoZQ0KdHJpZ2dlcmVkIGNvbm5lY3Rpdml0eSBjaGVjayBpcyBsYXRl
ciBwZXJmb3JtZWQsIHRoZSBJQ0UtQ09OVFJPTExJTkcvDQpJQ0UtQ09OVFJPTExFRCBhdHRyaWJ1
dGUgb2YgdGhlIEJpbmRpbmcgcmVxdWVzdCB3aWxsIGluZGljYXRlIHRoZQ0KYWdlbnQncyBuZXcg
cm9sZS4gIFRoZSBhZ2VudCBNVVNUIGNoYW5nZSB0aGUgdGllLWJyZWFrZXIgdmFsdWUuDQoNCg0K
U2VjdGlvbiAxNi4xOg0KPT09PT09PT09PT0NCg0KT0xEOg0KDQpBbiBJQ0UgYWdlbnQgTVVTVCB1
c2UgdGhlIHNhbWUgbnVtYmVyIGZvciBhbGwNCkJpbmRpbmcgcmVxdWVzdHMsIGZvciBhbGwgc3Ry
ZWFtcywgd2l0aGluIGFuIElDRSBzZXNzaW9uLiBUaGUgYWdlbnQNCk1BWSBjaGFuZ2UgdGhlIG51
bWJlciB3aGVuIGFuIElDRSByZXN0YXJ0IG9jY3Vycy4NCg0KTkVXOg0KDQpBbiBJQ0UgYWdlbnQg
TVVTVCB1c2UgdGhlIHNhbWUgbnVtYmVyIGZvciBhbGwNCkJpbmRpbmcgcmVxdWVzdHMsIGZvciBh
bGwgc3RyZWFtcywgd2l0aGluIGFuIElDRSBzZXNzaW9uLCB1bmxlc3MNCml0IHJlY2VpdmVzIGEg
NDg3IHJlc3BvbnNlLCBpbiB3aGljaCBjYXNlIGl0IE1VU1QgY2hhbmdlIHRoZQ0KbnVtYmVyIChT
ZWN0aW9uIDcuMi41LjEpLiBUaGUgYWdlbnQgTUFZIGNoYW5nZSB0aGUgbnVtYmVyIHdoZW4NCmFu
IElDRSByZXN0YXJ0IG9jY3Vycy4NCg0KUHJvYmxlbSBzb2x2ZWQ/IDopDQoNClJlZ2FyZHMsDQoN
CkNocmlzdGVyDQoNCg0KDQpGcm9tOiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29t
XQ0KU2VudDogMjEgRmVicnVhcnkgMjAxOCAwMTowNw0KVG86IFRheWxvciBCcmFuZHN0ZXR0ZXIg
PGRlYWRiZWVmQGdvb2dsZS5jb20+DQpDYzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhv
bG1iZXJnQGVyaWNzc29uLmNvbT47IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPjsgaWNl
LWNoYWlyc0BpZXRmLm9yZzsgaWNlQGlldGYub3JnOyBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1Ymlz
QGlldGYub3JnOyBwdGhhdGNoZXJAZ29vZ2xlLmNvbTsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+
DQpTdWJqZWN0OiBSZTogW0ljZV0gRXJpYyBSZXNjb3JsYSdzIE5vIE9iamVjdGlvbiBvbiBkcmFm
dC1pZXRmLWljZS1yZmM1MjQ1YmlzLTE3OiAod2l0aCBDT01NRU5UKSAoZXhjbHVkaW5nIFNlY3Vy
aXR5IENvbnNpZGVyYXRpb25zKQ0KDQpJIHdvdWxkbid0IG9iamVjdCBpZiBzb21lb25lIHByb2R1
Y2VkIGEgcHJpbmNpcGxlZCBmaXguIEkganVzdCBkb24ndCB3YW50IHRvIGNyZWF0ZSBhIGxvdCBv
ZiB3b3JrIGZvciBwZW9wbGUNCg0KDQpPbiBUdWUsIEZlYiAyMCwgMjAxOCBhdCAyOjUxIFBNLCBU
YXlsb3IgQnJhbmRzdGV0dGVyIDxkZWFkYmVlZkBnb29nbGUuY29tPG1haWx0bzpkZWFkYmVlZkBn
b29nbGUuY29tPj4gd3JvdGU6DQpUaGUgdGllLWJyZWFrZXIgY29sbGlzaW9uIHByb2JsZW0gaGFz
IGNvbWUgdXAgYSBmZXcgdGltZXMgYmVmb3JlLCBhY3R1YWxseS4gQXMgSSd2ZSBzYWlkLCBJIGJl
bGlldmUgaXQgY291bGQgYmUgZml4ZWQgdmVyeSBlYXNpbHkgYnkgc2F5aW5nICJwaWNrIGEgbmV3
IHRpZS1icmVha2VyIGlmIHRoaXMgaGFwcGVucy4iDQoNCkFzIGZvciB0aGUgIk1VU1Qgbm90IGNo
YW5nZSB0aWUtYnJlYWtlciIgcnVsZSBpbiBzZWN0aW9uIDE2LjEsIHJlcXVpcmluZyBhbiBJQ0Ug
cmVzdGFydCBpcyBvdmVya2lsbC4gV2UgY2FuIGp1c3QgY2hhbmdlIGl0IHRvICJNVVNUIG5vdCBj
aGFuZ2UgdGllLWJyZWFrZXIgdW5sZXNzIHRoZXJlJ3MgYSBjb2xsaXNpb24uIg0KDQpPbiBNb24s
IEZlYiAxOSwgMjAxOCBhdCAxMDozMyBBTSwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1h
aWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToNCg0KDQpPbiBNb24sIEZlYiAxOSwgMjAxOCBhdCAx
MDoyOSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv
bTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0K
Li4uDQoNCj4+Pj4gSUYgd2UgcmVhbGx5IHdhbnQgdG8gc29sdmUgdGhpcywgb25lIHNpbXBsZSBz
b2x1dGlvbiBiZSB0byBzYXkgdGhhdCwgaWYgdGhpcyBoYXBwZW5zLCBhbmQgZW5kcG9pbnQgc2lt
cGx5IGNhbGN1bGF0ZXMgYQ0KPj4+PiBuZXcgdGllLWJyZWFrZXIgdmFsdWUsIGFuZCB0cmllcyBh
Z2Fpbj8gQlVULCB0aGVuIHdlIHdvdWxkIGhhdmUgdG8gY2hhbmdlIHNlY3Rpb24gMTYuMSwgd2hp
Y2ggc2F5cyB0aGF0IGEgbmV3IHZhbHVlIGNhbiBvbmx5IGJlIGNhbGN1bGF0ZWQgYXQgYW4gSUNF
IHJlc3RhcnQuDQo+Pj4+DQo+Pj4+IFNvLCBjb3VsZCB3ZSBzaW1wbHkgc2F5IHRoYXQsIGlmIHRo
aXMgaGFwcGVucywgdGhlIGFnZW50IE1VU1QgZG8gYW4gSUNFIHJlc3RhcnQsIGFuZCBpdCBNVVNU
IGNhbGN1bGF0ZSBhIG5ldyB0aWUtYnJlYWtlciB2YWx1ZT8NCj4+Pg0KPj4+IE5vdyBib3RoIHNp
ZGVzIG1pZ2h0IGRvIGEgc2ltdWx0YW5lb3VzIHJlc3RhcnQuIElzIHRoYXQgZ29pbmcgdG8gd29y
az8NCj4+DQo+PiBXZSBjb3VsZCBzYXkgdGhhdCB0aGUgaW5pdGlhdGluZyBhZ2VudCBNVVNUIGRv
IHRoZSByZXN0YXJ0Lg0KPg0KPiBJbiB0aGlzIHNjZW5hcmlvLCBkb24ndCBib3RoIHNpZGVzIGJl
bGlldmUgdGhleSBhcmUgdGhlIGluaXRpYXRpbmcgcGVlciwgaGVuY2UgdGhlIG5lZWQgZm9yIHRo
ZSB0aWVicmVha2VyPw0KDQpQcm9iYWJseS4uLg0KDQpCdXQsIHRoZW4gSSBkb24ndCBzZWUgd2hh
dCB3ZSBjb3VsZCBkby4gSWYgYm90aCBhZ2VudHMgc2VuZCBhIGNoZWNrLCBhbmQgcmVjZWl2ZSA0
ODcsIHdlIGNhbid0IGRlZmluZSBhIHByb2NlZHVyZSBmb3Igb25lIG9mIHRoZSBhZ2VudHMuDQoN
ClBlcmhhcHMgd2Ugc2hvdWxkIHRoZW4gY2hhbmdlIHRoZSBtdXN0LW5vdC1jaGFuZ2UtdGhlLXZh
bHVlLXVubGVzcy1yZXN0YXJ0IGFuZCBzYXkgdGhhdCBhbiBhZ2VudCBjaGFuZ2VzIHRoZSB0aWUt
YnJlYWtlciB2YWx1ZSBhbmQgdHJ5IGFnYWluLg0KDQpBcyB5b3Ugc2F5LCB0aGUgcHJvYmxlbSBp
cyBpbmhlcmVudGx5IHRoYXQgdGhlIHNpdHVhdGlvbiBpcyBzeW1tZXRyaWNhbC4NCg0KQXQgdGhp
cyBwb2ludCBpbiB0aGUgZGVzaWduIHByb2Nlc3MsIEkgZG9uJ3QgdGhpbmsgaXQncyB3b3J0aCB0
cnlpbmcgdG8gYWN0dWFsbHkgbWFrZSB0aGUgY2FsbCBzdWNjZWVkOyBhIDJeey02NH0gZmFpbHVy
ZSByYXRlIGlzIG11Y2ggbG93ZXIgdGhhbiBvcmdhbmljIGNhbGwgZmFpbHVyZSByYXRlcyBmcm9t
IG90aGVyIGNhdXNlcywgZXZlbiBpbiBub24tM1BDQyBzY2VuYXJpb3MuIFJhdGhlciwgSSB0aGlu
ayB0aGUgc3BlYyBzaG91bGQganVzdCBwcmVzY3JpYmUgYSBjbGVhbiBmYWlsdXJlIG1vZGUgdmlh
IGEgbmV3IGVycm9yIGNvZGUsIHJhdGhlciB0aGFuIGhhdmluZyBib3RoIHNpZGVzIHdpbGRseSBv
c2NpbGxhdGUgYmV0d2VlbiBjb250cm9sbGVkIGFuZCBjb250cm9sbGluZw0KDQotRWtyDQoNCg0K
UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KSWNlIG1haWxpbmcgbGlzdA0KSWNlQGlldGYub3JnPG1haWx0bzpJ
Y2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZQ0K
DQoNCg==

--_000_7594FB04B1934943A5C02806D1A2204B6C1978FAESESSMB109erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z
ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10
eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7
DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl
eHBvcnQtb25seTsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2Vj
dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu
MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t
Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0
PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4
dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N
CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N
CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGhhZCBhIGNsb3NlciBsb29r
IGF0IHRoZSByb2xlIGNvbmZsaWN0IGlzc3VlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0
LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n
dWFnZTpFTi1VUyI+Rmlyc3QsIHRoZSBkcmFmdCBhbHJlYWR5IGNvdmVycyB0aGUgY2FzZSB3aGVu
IHRoZSB0aWUtYnJlYWtlciB2YWx1ZXMgYXJlIGlkZW50aWNhbC4gSXQgaXMgZGVzY3JpYmVkIGlu
IHNlY3Rpb24gNy4zLjEuMTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi
PiZuYnNwOyZuYnNwOyDigJxJZiB0aGUgYWdlbnQncyB0aWUtYnJlYWtlciB2YWx1ZSBpcyBsYXJn
ZXIgdGhhbg0KPGI+b3IgZXF1YWwgdG88L2I+4oCm4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh
cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0
LWxhbmd1YWdlOkVOLVVTIj7igKZ0aGUgYWdlbnQgc2VuZHMgNDg3Lg0KPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z
by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGVuLCBhY2NvcmRpbmcgdG8gc2VjdGlvbiA3LjIu
NS4xLiwgd2hlbiBhbiBhZ2VudCByZWNlaXZlcyB0aGUgNDg3IHJlc3BvbnNlIGl0IHdpbGwgY2hh
bmdlIGl0cyByb2xlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Tm93
LCBpZiBCT1RIIGFnZW50cyBzZW5kIDQ4NywgaXQgbWVhbnMgQk9USCBhZ2VudHMgd2lsbCBzd2l0
Y2ggdGhlaXIgcm9sZXMsIGFuZCB0cnkgYWdhaW4uIE5vdywgc2luY2UgYm90aCBhZ2VudHMgc3dp
dGNoIHRoZWlyIHJvbGUsDQogYW5kIGtlZXAgdGhlIHNhbWUgdGllLWJyZWFrZXIgdmFsdWUsIHRo
ZSByZXN1bHQgd2lsbCBhZ2FpbiBiZSB0aGUgc2FtZSAob25seSB3aXRoIGRpZmZlcmVudCByb2xl
cykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5CdXQsIGlmIGJvdGgg
YWdlbnRzIGFsc28gY2hhbmdlIHRoZWlyIHRpZS1icmVha2VyIHZhbHVlLCBtb3N0IGxpa2VseSBv
bmx5IG9uZSBhZ2VudCB3aWxsIHNlbmQgNDg3LCBhbmQgdGhpbmdzIHdpbGwgd29yay48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPihTZWN0aW9uIDcuMi41LjEgYWN0dWFs
bHkgYWxyZWFkeSBhbGxvd3MgY2hhbmdpbmcgdGhlIHRpZS1icmVha2VyIHZhbHVlLCB3aGljaCBj
b250cmFkaWN0cyB0aGUgbXVzdC1ub3QtY2hhbmdlIHJ1bGUgaW4gU2VjdGlvbiAxNi4xKTxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNvLCBiYXNlZCBvbiB0aGUgaWRlYSBhYm92
ZSwgdGhlIGNoYW5nZXMgd291bGQgYmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl
OkVOLVVTIj5TZWN0aW9uIDcuMi41LjE6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6RU4tVVMiPj09PT09PT09PT09PT08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s
YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh
Z2U6RU4tVVMiPk9MRDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V
UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk9u
Y2UgdGhlIGFnZW50IGhhcyBzd2l0Y2hlZCBpdHMgcm9sZSwgdGhlIGFnZW50IE1VU1QgYWRkIHRo
ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5jYW5kaWRhdGUg
cGFpciB3aG9zZSBjaGVjayBnZW5lcmF0ZWQgdGhlIDQ4NyBlcnJvciByZXNwb25zZSB0byB0aGU8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+dHJpZ2dlcmVkIGNo
ZWNrIHF1ZXVlIGFzc29jaWF0ZWQgd2l0aCB0aGUgY2hlY2sgbGlzdCB0byB3aGljaCB0aGU8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+cGFpciBiZWxvbmdzLCBh
bmQgc2V0IHRoZSBjYW5kaWRhdGUgcGFpciBzdGF0ZSB0byBXYWl0aW5nLiZuYnNwOyBXaGVuIHRo
ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj50cmlnZ2VyZWQg
Y29ubmVjdGl2aXR5IGNoZWNrIGlzIGxhdGVyIHBlcmZvcm1lZCwgdGhlIElDRS1DT05UUk9MTElO
Ry88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SUNFLUNPTlRS
T0xMRUQgYXR0cmlidXRlIG9mIHRoZSBCaW5kaW5nIHJlcXVlc3Qgd2lsbCBpbmRpY2F0ZSB0aGU8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+YWdlbnQncyBuZXcg
cm9sZS4mbmJzcDsgVGhlIGFnZW50DQo8Yj5NQVk8L2I+IGNoYW5nZSB0aGUgdGllLWJyZWFrZXIg
dmFsdWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TkVXOjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+T25jZSB0aGUgYWdlbnQgaGFzIHN3aXRjaGVk
IGl0cyByb2xlLCB0aGUgYWdlbnQgTVVTVCBhZGQgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh
cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPmNhbmRpZGF0ZSBwYWlyIHdob3NlIGNoZWNrIGdlbmVyYXRl
ZCB0aGUgNDg3IGVycm9yIHJlc3BvbnNlIHRvIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl
YXN0LWxhbmd1YWdlOkVOLVVTIj50cmlnZ2VyZWQgY2hlY2sgcXVldWUgYXNzb2NpYXRlZCB3aXRo
IHRoZSBjaGVjayBsaXN0IHRvIHdoaWNoIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0
LWxhbmd1YWdlOkVOLVVTIj5wYWlyIGJlbG9uZ3MsIGFuZCBzZXQgdGhlIGNhbmRpZGF0ZSBwYWly
IHN0YXRlIHRvIFdhaXRpbmcuJm5ic3A7IFdoZW4gdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh
cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPnRyaWdnZXJlZCBjb25uZWN0aXZpdHkgY2hlY2sgaXMgbGF0
ZXIgcGVyZm9ybWVkLCB0aGUgSUNFLUNPTlRST0xMSU5HLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m
YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JQ0UtQ09OVFJPTExFRCBhdHRyaWJ1dGUgb2YgdGhlIEJp
bmRpbmcgcmVxdWVzdCB3aWxsIGluZGljYXRlIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl
YXN0LWxhbmd1YWdlOkVOLVVTIj5hZ2VudCdzIG5ldyByb2xlLiZuYnNwOyBUaGUgYWdlbnQNCjxi
Pk1VU1Q8L2I+IGNoYW5nZSB0aGUgdGllLWJyZWFrZXIgdmFsdWUuPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7
bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m
YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz
dC1sYW5ndWFnZTpFTi1VUyI+U2VjdGlvbiAxNi4xOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl
YXN0LWxhbmd1YWdlOkVOLVVTIj49PT09PT09PT09PTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl
YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s
YW5ndWFnZTpFTi1VUyI+T0xEOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl
OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V
UyI+QW4gSUNFIGFnZW50IE1VU1QgdXNlIHRoZSBzYW1lIG51bWJlciBmb3IgYWxsPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJpbmRpbmcgcmVxdWVzdHMsIGZv
ciBhbGwgc3RyZWFtcywgd2l0aGluIGFuIElDRSBzZXNzaW9uLiBUaGUgYWdlbnQ8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TUFZIGNoYW5nZSB0aGUgbnVtYmVy
IHdoZW4gYW4gSUNFIHJlc3RhcnQgb2NjdXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0
LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n
dWFnZTpFTi1VUyI+TkVXOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO
LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+
QW4gSUNFIGFnZW50IE1VU1QgdXNlIHRoZSBzYW1lIG51bWJlciBmb3IgYWxsPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJpbmRpbmcgcmVxdWVzdHMsIGZvciBh
bGwgc3RyZWFtcywgd2l0aGluIGFuIElDRSBzZXNzaW9uPGI+LCB1bmxlc3MNCjxvOnA+PC9vOnA+
PC9iPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+aXQgcmVjZWl2ZXMgYSA0
ODcgcmVzcG9uc2UsIGluIHdoaWNoIGNhc2UgaXQgTVVTVCBjaGFuZ2UgdGhlPG86cD48L286cD48
L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5udW1iZXIgKFNlY3Rpb24g
Ny4yLjUuMSkuPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy
ZWFzdC1sYW5ndWFnZTpFTi1VUyI+DQogVGhlIGFnZW50IE1BWSBjaGFuZ2UgdGhlIG51bWJlciB3
aGVuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5hbiBJQ0Ug
cmVzdGFydCBvY2N1cnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Q
cm9ibGVtIHNvbHZlZD8gOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi
PlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3Rl
cjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21w
b3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gRXJpYyBSZXNjb3JsYSBbbWFpbHRvOmVrckBydGZt
LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyMSBGZWJydWFyeSAyMDE4IDAxOjA3PGJyPg0KPGI+
VG86PC9iPiBUYXlsb3IgQnJhbmRzdGV0dGVyICZsdDtkZWFkYmVlZkBnb29nbGUuY29tJmd0Ozxi
cj4NCjxiPkNjOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVy
aWNzc29uLmNvbSZndDs7IEJlbiBDYW1wYmVsbCAmbHQ7YmVuQG5vc3RydW0uY29tJmd0OzsgaWNl
LWNoYWlyc0BpZXRmLm9yZzsgaWNlQGlldGYub3JnOyBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1Ymlz
QGlldGYub3JnOyBwdGhhdGNoZXJAZ29vZ2xlLmNvbTsgVGhlIElFU0cgJmx0O2llc2dAaWV0Zi5v
cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbSWNlXSBFcmljIFJlc2NvcmxhJ3MgTm8g
T2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXMtMTc6ICh3aXRoIENPTU1FTlQp
IChleGNsdWRpbmcgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMpPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5JIHdvdWxkbid0IG9iamVjdCBpZiBzb21lb25lIHByb2R1Y2VkIGEgcHJpbmNp
cGxlZCBmaXguIEkganVzdCBkb24ndCB3YW50IHRvIGNyZWF0ZSBhIGxvdCBvZiB3b3JrIGZvciBw
ZW9wbGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBGZWIgMjAsIDIwMTggYXQgMjo1
MSBQTSwgVGF5bG9yIEJyYW5kc3RldHRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRlYWRiZWVmQGdv
b2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5kZWFkYmVlZkBnb29nbGUuY29tPC9hPiZndDsgd3Jv
dGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp
bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+VGhlIHRpZS1icmVha2VyIGNvbGxpc2lv
biBwcm9ibGVtIGhhcyBjb21lIHVwIGEgZmV3IHRpbWVzIGJlZm9yZSwgYWN0dWFsbHkuIEFzIEkn
dmUgc2FpZCwgSSBiZWxpZXZlJm5ic3A7PC9zcGFuPml0IGNvdWxkIGJlIGZpeGVkIHZlcnkgZWFz
aWx5IGJ5IHNheWluZyAmcXVvdDtwaWNrIGEgbmV3IHRpZS1icmVha2VyDQogaWYgdGhpcyBoYXBw
ZW5zLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
QXMgZm9yIHRoZSAmcXVvdDtNVVNUIG5vdCBjaGFuZ2UgdGllLWJyZWFrZXImcXVvdDsgcnVsZSBp
biBzZWN0aW9uIDE2LjEsIHJlcXVpcmluZyBhbiBJQ0UgcmVzdGFydCBpcyBvdmVya2lsbC4gV2Ug
Y2FuIGp1c3QgY2hhbmdlIGl0IHRvICZxdW90O01VU1Qgbm90IGNoYW5nZSB0aWUtYnJlYWtlcjxp
PiB1bmxlc3MgdGhlcmUncyBhIGNvbGxpc2lvbjwvaT4uJnF1b3Q7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9u
LCBGZWIgMTksIDIwMTggYXQgMTA6MzMgQU0sIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1h
aWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3
cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw
Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBGZWIgMTksIDIwMTggYXQgMTA6MjkgQU0s
IENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdA
ZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u
Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g
MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SGksPGJyPg0KPGJyPg0KLi4uPGJyPg0KPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyBJRiB3ZSByZWFsbHkgd2FudCB0byBzb2x2ZSB0aGlzLCBvbmUgc2ltcGxlIHNvbHV0aW9uIGJl
IHRvIHNheSB0aGF0LCBpZiB0aGlzIGhhcHBlbnMsIGFuZCBlbmRwb2ludCBzaW1wbHkgY2FsY3Vs
YXRlcyBhPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBuZXcgdGllLWJyZWFrZXIgdmFsdWUsIGFuZCB0
cmllcyBhZ2Fpbj8gQlVULCB0aGVuIHdlIHdvdWxkIGhhdmUgdG8gY2hhbmdlIHNlY3Rpb24gMTYu
MSwgd2hpY2ggc2F5cyB0aGF0IGEgbmV3IHZhbHVlIGNhbiBvbmx5IGJlIGNhbGN1bGF0ZWQgYXQg
YW4gSUNFIHJlc3RhcnQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn
dDsgU28sIGNvdWxkIHdlIHNpbXBseSBzYXkgdGhhdCwgaWYgdGhpcyBoYXBwZW5zLCB0aGUgYWdl
bnQgTVVTVCBkbyBhbiBJQ0UgcmVzdGFydCwgYW5kIGl0IE1VU1QgY2FsY3VsYXRlIGEgbmV3IHRp
ZS1icmVha2VyIHZhbHVlPzxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBOb3cg
Ym90aCBzaWRlcyBtaWdodCBkbyBhIHNpbXVsdGFuZW91cyByZXN0YXJ0LiBJcyB0aGF0IGdvaW5n
IHRvIHdvcms/PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBXZSBjb3VsZCBzYXkgdGhhdCB0
aGUgaW5pdGlhdGluZyBhZ2VudCBNVVNUIGRvIHRoZSByZXN0YXJ0Ljxicj4NCiZndDs8YnI+DQom
Z3Q7IEluIHRoaXMgc2NlbmFyaW8sIGRvbid0IGJvdGggc2lkZXMgYmVsaWV2ZSB0aGV5IGFyZSB0
aGUgaW5pdGlhdGluZyBwZWVyLCBoZW5jZSB0aGUgbmVlZCBmb3IgdGhlIHRpZWJyZWFrZXI/PGJy
Pg0KPGJyPg0KUHJvYmFibHkuLi48YnI+DQo8YnI+DQpCdXQsIHRoZW4gSSBkb24ndCBzZWUgd2hh
dCB3ZSBjb3VsZCBkby4gSWYgYm90aCBhZ2VudHMgc2VuZCBhIGNoZWNrLCBhbmQgcmVjZWl2ZSA0
ODcsIHdlIGNhbid0IGRlZmluZSBhIHByb2NlZHVyZSBmb3Igb25lIG9mIHRoZSBhZ2VudHMuPGJy
Pg0KPGJyPg0KUGVyaGFwcyB3ZSBzaG91bGQgdGhlbiBjaGFuZ2UgdGhlIG11c3Qtbm90LWNoYW5n
ZS10aGUtdmFsdWUtdW5sZXNzLXJlc3RhcnQgYW5kIHNheSB0aGF0IGFuIGFnZW50IGNoYW5nZXMg
dGhlIHRpZS1icmVha2VyIHZhbHVlIGFuZCB0cnkgYWdhaW4uPG86cD48L286cD48L3A+DQo8L2Js
b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyB5b3Ugc2F5LCB0aGUg
cHJvYmxlbSBpcyBpbmhlcmVudGx5IHRoYXQgdGhlIHNpdHVhdGlvbiBpcyBzeW1tZXRyaWNhbC48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXQg
dGhpcyBwb2ludCBpbiB0aGUgZGVzaWduIHByb2Nlc3MsIEkgZG9uJ3QgdGhpbmsgaXQncyB3b3J0
aCB0cnlpbmcgdG8gYWN0dWFsbHkgbWFrZSB0aGUgY2FsbCBzdWNjZWVkOyBhIDJeey02NH0gZmFp
bHVyZSByYXRlIGlzIG11Y2ggbG93ZXIgdGhhbiBvcmdhbmljIGNhbGwgZmFpbHVyZSByYXRlcyBm
cm9tIG90aGVyIGNhdXNlcywgZXZlbiBpbiBub24tM1BDQyBzY2VuYXJpb3MuIFJhdGhlciwgSSB0
aGluaw0KIHRoZSBzcGVjIHNob3VsZCBqdXN0IHByZXNjcmliZSBhIGNsZWFuIGZhaWx1cmUgbW9k
ZSB2aWEgYSBuZXcgZXJyb3IgY29kZSwgcmF0aGVyIHRoYW4gaGF2aW5nIGJvdGggc2lkZXMgd2ls
ZGx5IG9zY2lsbGF0ZSBiZXR3ZWVuIGNvbnRyb2xsZWQgYW5kIGNvbnRyb2xsaW5nPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp
bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlz
dGVyPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+X19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJY2UgbWFpbGluZyBsaXN0PGJy
Pg0KPGEgaHJlZj0ibWFpbHRvOkljZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkljZUBpZXRm
Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2ljZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vaWNlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1
b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
b2R5Pg0KPC9odG1sPg0K

--_000_7594FB04B1934943A5C02806D1A2204B6C1978FAESESSMB109erics_--


From nobody Sat Feb 24 12:53:34 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A83112D879 for ; Sat, 24 Feb 2018 12:53:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level: 
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 5eM__clPhcWI for ; Sat, 24 Feb 2018 12:53:29 -0800 (PST)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 EB57B12D870 for ; Sat, 24 Feb 2018 12:53:25 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id z197so14876981qkb.6 for ; Sat, 24 Feb 2018 12:53:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VG6Cgmw1el8Z4K7gXPAkbtE4m+sA+e0KPCrE7SAS4vs=; b=MZZqm46G4wxpKdiccJyvEjC2quPwg2NbiZCIDwj3IeSFQolofVmFvMqZFbs+HdYUGJ ZW2+SUgLEf3q+kxQKhwylDUGbXBHjjO7akSvupZMZIbWAntKU10fdU2194GlOSn8JcOI nAvnH77uZNoB3E7QfcCrq6ezcSjb+NqxfMZHaXohdwLECZD9x1GhhK73juq8BH13v0ci nMNKtQx71Y4m5qjoGz01/z2QDWfmdA7bP/KsOvlLrf4+bVd4yyGhIVUZDRWyYayKfJzP Izh83k7eHSIw1Ffyv0r4ETT3RCqzqoK33qyuhXYsU4R1exLMQ1jLF7ANUBaVh/2hvrx/ fnnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VG6Cgmw1el8Z4K7gXPAkbtE4m+sA+e0KPCrE7SAS4vs=; b=BSIu0lckLL9B2hb0wuYTCfAqADtVHW/AXP9uUaxI2kUVn+kbRg3nORdkHy1RMvGkNn +UKEW5NhBdvWlsc/7BFZXvIx3sY/2kZdsqlP9w8DiwJbg5z3bo7OoPdUqtvNSPlGXswG zqZGKki3p3S1qTFMbkPZvMhHrBzyzpFys1aW1scUhpBeNpmbw9Ows6fKbL9cFupiwY0X T7RYGkKSYOwaH6X5dbAm6C2ogSvp/+XqYH/4UtGdC7IDJQTPTg4r5CYh05csBndx7WrY +TKECIANRwZexTnBUCzCoTnh4B0OKxWDpxTDxF9fyybjb+83KXh1we9i8uehzJD3pN5S swxw==
X-Gm-Message-State: APf1xPCzKCEpuxnBrhJs6bocAY2pakO2zrz6GajKw3wMR09vzFrt3GT9 nN4zKZYKGJqZHxy6edzuqXnWowQ2wXr3PDluHrdi1g==
X-Google-Smtp-Source: AG47ELtTemUN2LLmYNt3MzFQN1pElIH2TxxiLI66qEC9ykrfpTKO/7AXCI1opVtXj+120ZOqXBOIHOi3hHJWv5xPIOc=
X-Received: by 10.55.103.1 with SMTP id b1mr9586471qkc.98.1519505604959; Sat, 24 Feb 2018 12:53:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Sat, 24 Feb 2018 12:52:44 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1978FA@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C1978FA@ESESSMB109.ericsson.se>
From: Eric Rescorla 
Date: Sat, 24 Feb 2018 12:52:44 -0800
Message-ID: 
To: Christer Holmberg 
Cc: Taylor Brandstetter , Ben Campbell ,  "ice-chairs@ietf.org" , "ice@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" ,  "pthatcher@google.com" , The IESG 
Content-Type: multipart/alternative; boundary="94eb2c0571b8d178950565fb7704"
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) - Role conflict issue
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Feb 2018 20:53:31 -0000

--94eb2c0571b8d178950565fb7704
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Feb 24, 2018 at 12:37 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
>
>
> I had a closer look at the role conflict issue.
>
>
>
> First, the draft already covers the case when the tie-breaker values are
> identical. It is described in section 7.3.1.1:
>
>
>
>    =E2=80=9CIf the agent's tie-breaker value is larger than *or equal to*=
=E2=80=A6=E2=80=9D
>

Yes. My point is that this is broken.



>
>
> =E2=80=A6the agent sends 487.
>
>
>
> Then, according to section 7.2.5.1., when an agent receives the 487
> response it will change its role.
>
>
>
> Now, if BOTH agents send 487, it means BOTH agents will switch their
> roles, and try again. Now, since both agents switch their role, and keep
> the same tie-breaker value, the result will again be the same (only with
> different roles).
>

Yes, so they oscillate back and forth.



Section 7.2.5.1:
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
>
> OLD:
>
>
>
> Once the agent has switched its role, the agent MUST add the
>
> candidate pair whose check generated the 487 error response to the
>
> triggered check queue associated with the check list to which the
>
> pair belongs, and set the candidate pair state to Waiting.  When the
>
> triggered connectivity check is later performed, the ICE-CONTROLLING/
>
> ICE-CONTROLLED attribute of the Binding request will indicate the
>
> agent's new role.  The agent *MAY* change the tie-breaker value.
>
>
>
>
>
> NEW:
>
>
>
> Once the agent has switched its role, the agent MUST add the
>
> candidate pair whose check generated the 487 error response to the
>
> triggered check queue associated with the check list to which the
>
> pair belongs, and set the candidate pair state to Waiting.  When the
>
> triggered connectivity check is later performed, the ICE-CONTROLLING/
>
> ICE-CONTROLLED attribute of the Binding request will indicate the
>
> agent's new role.  The agent *MUST* change the tie-breaker value.
>
>
>
>
>
> Section 16.1:
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
>
> OLD:
>
>
>
> An ICE agent MUST use the same number for all
>
> Binding requests, for all streams, within an ICE session. The agent
>
> MAY change the number when an ICE restart occurs.
>
>
>
> NEW:
>
>
>
> An ICE agent MUST use the same number for all
>
> Binding requests, for all streams, within an ICE session*, unless *
>
> *it receives a 487 response, in which case it MUST change the*
>
> *number (Section 7.2.5.1).* The agent MAY change the number when
>
> an ICE restart occurs.
>
>
>
> Problem solved? :)
>

This would be fine with me, but presumably needs WG signoff.

-Ekr


>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> *From:* Eric Rescorla [mailto:ekr@rtfm.com]
> *Sent:* 21 February 2018 01:07
> *To:* Taylor Brandstetter 
> *Cc:* Christer Holmberg ; Ben Campbell <
> ben@nostrum.com>; ice-chairs@ietf.org; ice@ietf.org;
> draft-ietf-ice-rfc5245bis@ietf.org; pthatcher@google.com; The IESG <
> iesg@ietf.org>
> *Subject:* Re: [Ice] Eric Rescorla's No Objection on
> draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security
> Considerations)
>
>
>
> I wouldn't object if someone produced a principled fix. I just don't want
> to create a lot of work for people
>
>
>
>
>
> On Tue, Feb 20, 2018 at 2:51 PM, Taylor Brandstetter 
> wrote:
>
> The tie-breaker collision problem has come up a few times before,
> actually. As I've said, I believe it could be fixed very easily by saying
> "pick a new tie-breaker if this happens."
>
>
>
> As for the "MUST not change tie-breaker" rule in section 16.1, requiring
> an ICE restart is overkill. We can just change it to "MUST not change
> tie-breaker* unless there's a collision*."
>
>
>
> On Mon, Feb 19, 2018 at 10:33 AM, Eric Rescorla  wrote:
>
>
>
>
>
> On Mon, Feb 19, 2018 at 10:29 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> Hi,
>
> ...
>
> >>>> IF we really want to solve this, one simple solution be to say that,
> if this happens, and endpoint simply calculates a
> >>>> new tie-breaker value, and tries again? BUT, then we would have to
> change section 16.1, which says that a new value can only be calculated a=
t
> an ICE restart.
> >>>>
> >>>> So, could we simply say that, if this happens, the agent MUST do an
> ICE restart, and it MUST calculate a new tie-breaker value?
> >>>
> >>> Now both sides might do a simultaneous restart. Is that going to work=
?
> >>
> >> We could say that the initiating agent MUST do the restart.
> >
> > In this scenario, don't both sides believe they are the initiating peer=
,
> hence the need for the tiebreaker?
>
> Probably...
>
> But, then I don't see what we could do. If both agents send a check, and
> receive 487, we can't define a procedure for one of the agents.
>
> Perhaps we should then change the must-not-change-the-value-unless-restar=
t
> and say that an agent changes the tie-breaker value and try again.
>
>
>
> As you say, the problem is inherently that the situation is symmetrical.
>
>
>
> At this point in the design process, I don't think it's worth trying to
> actually make the call succeed; a 2^{-64} failure rate is much lower than
> organic call failure rates from other causes, even in non-3PCC scenarios.
> Rather, I think the spec should just prescribe a clean failure mode via a
> new error code, rather than having both sides wildly oscillate between
> controlled and controlling
>
>
>
> -Ekr
>
>
>
>
> Regards,
>
> Christer
>
>
>
>
>
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice
>
>
>
>
>

--94eb2c0571b8d178950565fb7704
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Sat, Feb 24, 2018 at 12:37 PM, Christer Holmberg &=
lt;chri=
ster.holmberg@ericsson.com> wrote:











Hi,


=C2=A0


I had a closer look at the role confl=
ict issue.


=C2=A0


First, the draft already covers the c=
ase when the tie-breaker values are identical. It is described in section <=
a href=3D"http://7.3.1.1" target=3D"_blank">7.3.1.1:


=C2=A0


=C2=A0=C2=A0 =E2=80=9CIf the agent=
9;s tie-breaker value is larger than
or equal to=E2=80=A6=E2=80=9D

Yes. My point is that this is broken.

=

=C2=A0


=C2=A0


=E2=80=A6the agent sends 487.



=C2=A0


Then, according to section 7.2.5.1., =
when an agent receives the 487 response it will change its role.<=
/u>


=C2=A0


Now, if BOTH agents send 487, it mean=
s BOTH agents will switch their roles, and try again. Now, since both agent=
s switch their role,
 and keep the same tie-breaker value, the result will again be the same (on=
ly with different roles).

Yes, so they oscillate back and forth.
=C2=A0



Section 7.2.5.1:


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D


=C2=A0


OLD:


=C2=A0


Once the agent has switched its role,=
 the agent MUST add the


candidate pair whose check generated =
the 487 error response to the


triggered check queue associated with=
 the check list to which the


pair belongs, and set the candidate p=
air state to Waiting.=C2=A0 When the


triggered connectivity check is later=
 performed, the ICE-CONTROLLING/


ICE-CONTROLLED attribute of the Bindi=
ng request will indicate the


agent's new role.=C2=A0 The agent
MAY change the tie-breaker value.


=C2=A0


=C2=A0


NEW:


=C2=A0


Once the agent has switched its role,=
 the agent MUST add the


candidate pair whose check generated =
the 487 error response to the


triggered check queue associated with=
 the check list to which the


pair belongs, and set the candidate p=
air state to Waiting.=C2=A0 When the


triggered connectivity check is later=
 performed, the ICE-CONTROLLING/


ICE-CONTROLLED attribute of the Bindi=
ng request will indicate the


agent's new role.=C2=A0 The agent
MUST change the tie-breaker value.


=C2=A0


=C2=A0


Section 16.1:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
/u>


=C2=A0


OLD:


=C2=A0


An ICE agent MUST use the same number=
 for all


Binding requests, for all streams, wi=
thin an ICE session. The agent


MAY change the number when an ICE res=
tart occurs.


=C2=A0


NEW:


=C2=A0


An ICE agent MUST use the same number=
 for all


Binding requests, for all streams, wi=
thin an ICE session, unless



it receives a 487 response, in whi=
ch case it MUST change the


number (Section 7.2.5.1).
 The agent MAY change the number when 


an ICE restart occurs.<=
/span>


=C2=A0


Problem solved? :)

This would be fine with me, but presum=
ably needs WG signoff.

-Ekr
=C2=A0
=



=C2=A0


Regards,


=C2=A0


Christer


=C2=A0


=C2=A0


=C2=A0


From: =
Eric Rescorla [mailto:ekr=
@rtfm.com]


Sent: 21 February 2018 01:07

To: Taylor Brandstetter <deadbeef@google.com>

Cc: Christer Holmberg <christer.holmberg@ericsson.com>; Ben =
Campbell <ben@nostr=
um.com>; ic=
e-chairs@ietf.org; ic=
e@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; pthatcher@google.com; The IESG=
 <iesg@ietf.org&g=
t;

Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ic=
e-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)<=
u>


=C2=A0


I wouldn't object if someone produced a principl=
ed fix. I just don't want to create a lot of work for people<=
/u>


=C2=A0=C2=A0


=C2=A0




On Tue, Feb 20, 2018 at 2:51 PM, Taylor Brandstetter=
 <deadbeef@goog=
le.com> wrote:






The tie-breaker collision problem has c=
ome up a few times before, actually. As I've said, I believe=C2=A0it could be fixed very easily by saying "pick a new tie-breaker
 if this happens."




=C2=A0






As for the "MUST not change tie-breaker" r=
ule in section 16.1, requiring an ICE restart is overkill. We can just chan=
ge it to "MUST not change tie-breaker unless there's a collisio=
n."








=C2=A0








On Mon, Feb 19, 2018 at 10:33 AM, Eric Rescorla <=
ekr@rtfm.com> wrot=
e:














=C2=A0




=C2=A0




On Mon, Feb 19, 2018 at 10:29 AM, Christer Holmberg =
<chr=
ister.holmberg@ericsson.com> wrote:




Hi,



...



>>>> IF we really want to solve this, one simple solution be to=
 say that, if this happens, and endpoint simply calculates a

>>>> new tie-breaker value, and tries again? BUT, then we would=
 have to change section 16.1, which says that a new value can only be calcu=
lated at an ICE restart.

>>>>

>>>> So, could we simply say that, if this happens, the agent M=
UST do an ICE restart, and it MUST calculate a new tie-breaker value?

>>>

>>> Now both sides might do a simultaneous restart. Is that going =
to work?

>>

>> We could say that the initiating agent MUST do the restart.

>

> In this scenario, don't both sides believe they are the initiating=
 peer, hence the need for the tiebreaker?



Probably...



But, then I don't see what we could do. If both agents send a check, an=
d receive 487, we can't define a procedure for one of the agents.



Perhaps we should then change the must-not-change-the-value-unless-res=
tart and say that an agent changes the tie-breaker value and try again.<=
/u>






=C2=A0






As you say, the problem is inherently that the situa=
tion is symmetrical.






=C2=A0






At this point in the design process, I don't thi=
nk it's worth trying to actually make the call succeed; a 2^{-64} failu=
re rate is much lower than organic call failure rates from other causes, ev=
en in non-3PCC scenarios. Rather, I think
 the spec should just prescribe a clean failure mode via a new error code, =
rather than having both sides wildly oscillate between controlled and contr=
olling






=C2=A0






-Ekr






=C2=A0








Regards,



Christer






=C2=A0






=C2=A0






_____________________=
__________________________

Ice mailing list

Ice@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/ice






=C2=A0














=C2=A0
















--94eb2c0571b8d178950565fb7704--


From nobody Sat Feb 24 16:06:14 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEED12D94A for ; Sat, 24 Feb 2018 16:06:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 FXdpytcwRIUS for ; Sat, 24 Feb 2018 16:06:09 -0800 (PST)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 A07EA1243F6 for ; Sat, 24 Feb 2018 16:06:07 -0800 (PST)
Received: by mail-qt0-x231.google.com with SMTP id m13so10163207qtg.13 for ; Sat, 24 Feb 2018 16:06:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=twWBuZlPPUKydPVy3NIgy9GerKun9vAO51ua7nP7VLU=; b=GJ9cj8mSr/+0VR76KCwRZK4q3ixeWHEiZx9XytYc01ikW8s4bNPQYluJFciWznFvcp /p4QAr3dO2lq48ULejiIBIam7YMvwCeeid643gWeG8JwvIDVbUoso2b/1t9Xa3J7HzIP Z5lO6pxXXcyzYHh3Vlpdd03lOWagUMIXFRN2mNinwtJectN3+qwbaY5UCYxXD0C9psy4 lwnXfMRNK/bxWLgeJXyVICQ2DIhfiQekIFkAyuU7mXOIj92nxOYLpmril8qJJnQl/ksZ v3JXw9Zg+zmzRMRoN0RlUP5/YGf9s6714+CyCsoEJlD7h620hjmjElJNgY7Q1XJ2qmf0 zDMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=twWBuZlPPUKydPVy3NIgy9GerKun9vAO51ua7nP7VLU=; b=DwxGmySAklIeT7XklDQRUhhxIgFcxKWfOPDqrHYsDXd20NzDv0YmxATVXrqBEjXIRH l/y28eQIOJpBWeK7hNnuCx9xEujptdgRg+42Mr7WaBkz6O5mmcfFPB0lYQCdyaGTdzKB g52xFh8Zt6eS8k96yrlgmrF960vfkzte96MesXlyYf1jzSm43zWDnvoR4gAxZRy36aVg KUpTn9JpN1IkFs2ylfq7o7B/aRsuFl/eGr/qOMUA/34ayLxYkef/RNVUS84wp0Ep4SkX QUpf/PQC1PZHAjNamIcrQ8YXriEk6ur+lRevdQBzlsgoBb32xmEmur9xu71rffiffU5p HRLQ==
X-Gm-Message-State: APf1xPDGBVCn7sdcUvUi3NRGhHXJW/OhGF7g6J1Q821VYn9+uSkFecv4 H8KuQmpnz3/HC+eDo9Xu/8t4+7a+RvBJTklBWSye8w==
X-Google-Smtp-Source: AG47ELvrR9+2oBrXEYd0ooWTou4r032mSfJQB2DcO+ZOEgT6i68BBqnCpskK9cWSBdEME2p+dboVAZtatfCfnSlnT6U=
X-Received: by 10.237.56.34 with SMTP id j31mr10631218qte.208.1519517166702; Sat, 24 Feb 2018 16:06:06 -0800 (PST)
MIME-Version: 1.0
Received: by 10.200.37.176 with HTTP; Sat, 24 Feb 2018 16:05:26 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C17CDFA@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C17CDFA@ESESSMB109.ericsson.se>
From: Eric Rescorla 
Date: Sat, 24 Feb 2018 16:05:26 -0800
Message-ID: 
To: Christer Holmberg 
Cc: The IESG ,  "draft-ietf-ice-rfc5245bis@ietf.org" ,  "ice-chairs@ietf.org" , "pthatcher@google.com" ,  "ice@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113b7f18f3a8960565fe287c"
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Feb 2018 00:06:11 -0000

--001a113b7f18f3a8960565fe287c
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 22, 2018 at 12:06 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> I have to admit that I am not very good at addressing Ekr's comments on
> the Security Considerations (and his comment on STUN pacing) in a good way,
> so I really need some help from others.
>
> ---
>
> >   something incorrect about the results of the connectivity checks.
> >   The possible false conclusions an attacker can try and cause are:
> > IMPORTANT: This section would be a lot stronger if it was factored by
> attacker capabilities as well. As-is it is very hard to understand.
>
> In some cases the attacker only needs to be able to capture the binding
> request, and discard it.
>
> In other cases the attacker also needs to have access to the security
> credentials, in order to generate/modify messages.
>

It seems to me that there are (at least) the following classes of attacker

- Off-path attackers
- On-path attackers
- Attackers who control an endpoint (legitimate callers)
- Attackers who control an endpoint via WebRTC.


> Or, did you have something else in mind?
>
> ---
>
> >   possible attack.  Fortunately, this attack is mitigated completely
> >   through the STUN short-term credential mechanism.  The attacker needs
> >   to inject a fake response, and in order for this response to be
> >
> > This text is a bit confusing. If you can generate a drop, then you can
> mount this attack.
>
> Not sure I understand.
>

If you want to simulate check failure, you only need to be able to drop
packets.


> ---
>
> >   invalid attack, this attack is mitigated by the STUN short-term
> >   credential mechanism in conjunction with a secure candidate exchange.
> >
> > This also isn't quite correct. Consider the case where A is behind a
> filtering element (e.g., a firewall) and
> > shares a broadcast network with the attacker. The attacker then captures
> an outgoing message that would
> > have been filtered and tunnels it to B, and then tunnels the response
> back. This can cause B and A to think
> > they have a valid path when they do not. It seems like this attack is
> described several paragraphs down, but
> > in sort of a confusing way.
>
> Ok, I see what you mean.
>
> Perhaps we should just remove the "Fortunately, this attack..." sentence?
>
> Then, the rest of the paragraph could be separate paragraph, and modified
> as:
>
> OLD:
>
>    "The attacker needs
>    to inject a fake response, and in order for this response to be
>    processed, the attacker needs the password.  If the candidate
>    exchange signaling is secured, the attacker will not have the
>    password and its response will be discarded."
>
> NEW:
>
>    "Due to the STUN short-term credential mechanism, in order for the
> attacker
>     to inject a fake response, and in order for this response to be
> processed, the
>     attacker needs the password.  If the candidate exchange signaling is
> secured,
>     the attacker will not have the password and its response will be
> discarded."
>

My point is that an on-path attacker can actually simulate success for
paths that would fail, and that the credentials don't help.



> >19.4.1.  STUN Amplification Attack
> >It's probably worth noting that this form of attack is a lot worse when
> WebRTC is involved.
>
> Why is that?
>

Because the attacker can force endpoints to make calls for him and can
supply any candidates he chooses


> ---
>
> (Appendix B.1 - not security related)
>
> >   rate at which they will create new bindings.  Experiments have shown
> >   that once every 5 ms is well supported.  This is why Ta has a lower
> >   bound of 5 ms.  Furthermore, transmission of these packets on the
> >
> > Citation needed.
>
> I don't really have any. This was the outcome of long WG discussions...
>

Well, you can't really claim "Experiments have shown" if you can't cite
those experiemnts

-Ekr


>
> ---
>
> Regards,
>
> Christer
>

--001a113b7f18f3a8960565fe287c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Feb 22, 2018 at 12:06 PM, Christer Holmberg &=
lt;chri=
ster.holmberg@ericsson.com> wrote:
Hi,



I have to admit that I am not very good at addressing Ekr's comments on=
 the Security Considerations (and his comment on STUN pacing) in a good way=
, so I really need some help from others.



---



>=C2=A0 =C2=A0something incorrect about the results of the connectivity =
checks.

>=C2=A0 =C2=A0The possible false conclusions an attacker can try and cau=
se are:

> IMPORTANT: This section would be a lot stronger if it was factored by =
attacker capabilities as well. As-is it is very hard to understand.



In some cases the attacker only needs to be able to capture the binding req=
uest, and discard it.



In other cases the attacker also needs to have access to the security crede=
ntials, in order to generate/modify messages.

It seems to me that there are (at least) the following classes of at=
tacker

- Off-path attackers
- On-path at=
tackers
- Attackers who control an endpoint (legitimate callers)<=
/div>
- Attackers who control an endpoint via WebRTC.




Or, did you have something else in mind?



---



>=C2=A0 =C2=A0possible attack.=C2=A0 Fortunately, this attack is mitigat=
ed completely

>=C2=A0 =C2=A0through the STUN short-term credential mechanism.=C2=A0 Th=
e attacker needs

>=C2=A0 =C2=A0to inject a fake response, and in order for this response =
to be

>

> This text is a bit confusing. If you can generate a drop, then you can=
 mount this attack.



Not sure I understand.

If you want to s=
imulate check failure, you only need to be able to drop packets.=C2=A0




---



>=C2=A0 =C2=A0invalid attack, this attack is mitigated by the STUN short=
-term

>=C2=A0 =C2=A0credential mechanism in conjunction with a secure candidat=
e exchange.

>

> This also isn't quite correct. Consider the case where A is behind=
 a filtering element (e.g., a firewall) and

> shares a broadcast network with the attacker. The attacker then captur=
es an outgoing message that would

> have been filtered and tunnels it to B, and then tunnels the response =
back. This can cause B and A to think

> they have a valid path when they do not. It seems like this attack is =
described several paragraphs down, but

> in sort of a confusing way.



Ok, I see what you mean.



Perhaps we should just remove the "Fortunately, this attack..." s=
entence?



Then, the rest of the paragraph could be separate paragraph, and modified a=
s:



OLD:



=C2=A0 =C2=A0"The attacker needs

=C2=A0 =C2=A0to inject a fake response, and in order for this response to b=
e

=C2=A0 =C2=A0processed, the attacker needs the password.=C2=A0 If the candi=
date

=C2=A0 =C2=A0exchange signaling is secured, the attacker will not have the<=
br>
=C2=A0 =C2=A0password and its response will be discarded."



NEW:



=C2=A0 =C2=A0"Due to the STUN short-term credential mechanism, in orde=
r for the attacker

=C2=A0 =C2=A0 to inject a fake response, and in order for this response to =
be processed, the

=C2=A0 =C2=A0 attacker needs the password.=C2=A0 If the candidate exchange =
signaling is secured,

=C2=A0 =C2=A0 the attacker will not have the password and its response will=
 be discarded."

My point is that a=
n on-path attacker can actually simulate success for paths that would fail,=
 and that the credentials don't help.

=C2=A0

>19.4.1.=C2=A0 STUN Amplification Attack

>It's probably worth noting that this form of attack is a lot worse =
when WebRTC is involved.



Why is that?

Because the attacker can f=
orce endpoints to make calls for him and can supply any candidates he choos=
es




---



(Appendix B.1 - not security related)



>=C2=A0 =C2=A0rate at which they will create new bindings.=C2=A0 Experim=
ents have shown

>=C2=A0 =C2=A0that once every 5 ms is well supported.=C2=A0 This is why =
Ta has a lower

>=C2=A0 =C2=A0bound of 5 ms.=C2=A0 Furthermore, transmission of these pa=
ckets on the

>

> Citation needed.



I don't really have any. This was the outcome of long WG discussions...=


Well, you can't really claim "=
;Experiments have shown" if you can't cite those experiemnts
=


-Ekr
=C2=A0



---



Regards,



Christer





--001a113b7f18f3a8960565fe287c--


From nobody Sun Feb 25 01:49:03 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083B5127137 for ; Sun, 25 Feb 2018 01:49:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Az_5dhmUKoZM for ; Sun, 25 Feb 2018 01:49:01 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 C6E0912708C for ; Sun, 25 Feb 2018 01:49:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519552138; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4evSxYw/HdtlgThmuCRw/ipqhPLa5RjxPdJuauf+njA=; b=do1nfchpLrtnFY8hp259BbwzZghNsBy7r2gqPkrkNsBLBqA0eOk1kRJO/lCB8qfQ V/CzM6l8Lu5yTu6ts7bSf4GIKLWW8LRDsmlO0z7Hwf6AWgj1o8T26gMOs9tMghlf LW1wN6E+7NbyrTbvq2uU0t3LYoJva/b6RR6j0cQr3rg=;
X-AuditID: c1b4fb30-799639c000004778-1d-5a92868a7046
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 92.B5.18296.A86829A5; Sun, 25 Feb 2018 10:48:58 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Sun, 25 Feb 2018 10:48:57 +0100
From: Christer Holmberg 
To: Eric Rescorla 
CC: The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , "pthatcher@google.com" , "ice@ietf.org" 
Thread-Topic: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (Security Considerations)
Thread-Index: AdOpa92am2EAedaETYymCVvuj0ZDJwEWBcgAABQTWQA=
Date: Sun, 25 Feb 2018 09:48:57 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C19C4EB@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C17CDFA@ESESSMB109.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.166]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7k25X26Qog12rxC3mn7zObLHi9Tl2 i4uzJrNZfLtQazHjz0Rmi2vLX7M6sHks2FTqsWTJTyaPyY/bmAOYo7hsUlJzMstSi/TtErgy upv5C55EVlyZ/IKxgXFPeBcjJ4eEgInE+XO32LoYuTiEBA4zSry4sxLKWcwoseXxISCHg4NN wEKi+582SIOIgILErz8nWEBqmAVeMEqcm/mKCSQhLFAqcfbKNiaIojKJF03ToWwricUf9jOC 2CwCqhKvtz1iA7F5BXwlPu67zgKxbAqjxObJXUwgyzgFAiUevnQDqWEUEJP4fmoN2BxmAXGJ W0/mM0FcLSCxZM95ZghbVOLl43+sELaSxNHTl1hBxjALaEqs36UP0aooMaX7ITvEWkGJkzOf sExgFJ2FZOoshI5ZSDpmIelYwMiyilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMwog5u+W2w g/Hlc8dDjAIcjEo8vP8rJ0UJsSaWFVfmHmKU4GBWEuG9VQUU4k1JrKxKLcqPLyrNSS0+xCjN waIkznvSkzdKSCA9sSQ1OzW1ILUIJsvEwSnVwCjiHzure/fTz8UBt1mKfzAcfFpaV/mqR6Sp 57nexdkhUxe6zNzd9a1isZGIx+TYH7fZLCM5vONaZb1j5rObcjZ/OZb1lyfDr1fDWG7qW87+ bVVKCjsuSki0iC15esb72nGmTVFTta3/n4rNX5wpydyi5ev8e/oBA6asKf1iO19Z6533PLr3 lxJLcUaioRZzUXEiAEdmbD2kAgAA
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (Security Considerations)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Feb 2018 09:49:03 -0000

SGksDQoNCj4+PsKgIMKgc29tZXRoaW5nIGluY29ycmVjdCBhYm91dCB0aGUgcmVzdWx0cyBvZiB0
aGUgY29ubmVjdGl2aXR5IGNoZWNrcy4NCj4+PsKgIMKgVGhlIHBvc3NpYmxlIGZhbHNlIGNvbmNs
dXNpb25zIGFuIGF0dGFja2VyIGNhbiB0cnkgYW5kIGNhdXNlIGFyZToNCj4+PiBJTVBPUlRBTlQ6
IFRoaXMgc2VjdGlvbiB3b3VsZCBiZSBhIGxvdCBzdHJvbmdlciBpZiBpdCB3YXMgZmFjdG9yZWQg
YnkgYXR0YWNrZXIgY2FwYWJpbGl0aWVzIGFzIHdlbGwuIEFzLWlzIGl0IGlzIHZlcnkgaGFyZCB0
byB1bmRlcnN0YW5kLg0KPj4NCj4+IEluIHNvbWUgY2FzZXMgdGhlIGF0dGFja2VyIG9ubHkgbmVl
ZHMgdG8gYmUgYWJsZSB0byBjYXB0dXJlIHRoZSBiaW5kaW5nIHJlcXVlc3QsIGFuZCBkaXNjYXJk
IGl0Lg0KPj4NCj4+IEluIG90aGVyIGNhc2VzIHRoZSBhdHRhY2tlciBhbHNvIG5lZWRzIHRvIGhh
dmUgYWNjZXNzIHRvIHRoZSBzZWN1cml0eSBjcmVkZW50aWFscywgaW4gb3JkZXIgdG8gZ2VuZXJh
dGUvbW9kaWZ5IG1lc3NhZ2VzLg0KPj4NCj4gSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGVyZSBhcmUg
KGF0IGxlYXN0KSB0aGUgZm9sbG93aW5nIGNsYXNzZXMgb2YgYXR0YWNrZXINCj4NCj4gLSBPZmYt
cGF0aCBhdHRhY2tlcnMNCj4gLSBPbi1wYXRoIGF0dGFja2Vycw0KPiAtIEF0dGFja2VycyB3aG8g
Y29udHJvbCBhbiBlbmRwb2ludCAobGVnaXRpbWF0ZSBjYWxsZXJzKQ0KPiAtIEF0dGFja2VycyB3
aG8gY29udHJvbCBhbiBlbmRwb2ludCB2aWEgV2ViUlRDLg0KDQpXaGF0IGFib3V0IHRoZSBmb2xs
b3dpbmcgbW9kaWZpY2F0aW9uOg0KDQpPTEQ6DQoNCiAgICJBbiBhdHRhY2tlciBtaWdodCBhdHRl
bXB0IHRvIGRpc3J1cHQgdGhlIFNUVU4gY29ubmVjdGl2aXR5IGNoZWNrcy4NCiAgIFVsdGltYXRl
bHksIGFsbCBvZiB0aGVzZSBhdHRhY2tzIGZvb2wgYW4gSUNFIGFnZW50IGludG8gdGhpbmtpbmcN
CiAgIHNvbWV0aGluZyBpbmNvcnJlY3QgYWJvdXQgdGhlIHJlc3VsdHMgb2YgdGhlIGNvbm5lY3Rp
dml0eSBjaGVja3MuDQogICBUaGUgcG9zc2libGUgZmFsc2UgY29uY2x1c2lvbnMgYW4gYXR0YWNr
ZXIgY2FuIHRyeSBhbmQgY2F1c2UgYXJlOiINCg0KTkVXOg0KDQogICAiQW4gYXR0YWNrZXIgbWln
aHQgYXR0ZW1wdCB0byBkaXNydXB0IHRoZSBTVFVOIGNvbm5lY3Rpdml0eSBjaGVja3MuDQogICBV
bHRpbWF0ZWx5LCBhbGwgb2YgdGhlc2UgYXR0YWNrcyBmb29sIGFuIElDRSBhZ2VudCBpbnRvIHRo
aW5raW5nDQogICBzb21ldGhpbmcgaW5jb3JyZWN0IGFib3V0IHRoZSByZXN1bHRzIG9mIHRoZSBj
b25uZWN0aXZpdHkgY2hlY2tzLg0KICAgRGVwZW5kaW5nIG9uIHRoZSB0eXBlIG9mIGF0dGFjaywg
dGhlIGF0dGFja2VyIG5lZWRzIHRvIGhhdmUgZGlmZmVyZW50DQogICBjYXBhYmlsaXRpZXMuIElu
IHNvbWUgY2FzZXMgdGhlIGF0dGFja2VyIG5lZWRzIHRvIGJlIG9uIHRoZSBwYXRoIG9mIHRoZQ0K
ICAgY29ubmVjdGl2aXR5IGNoZWNrcy4gSW4gb3RoZXIgY2FzZXMgdGhlIGF0dGFja2VyIGRvZXMg
bm90IG5lZWQgdG8gYmUgb24NCiAgIHRoZSBwYXRoLCBhcyBsb25nIGFzIGl0IGlzIGFibGUgdG8g
Z2VuZXJhdGUgU1RVTiBjb25uZWN0aXZpdHkgY2hlY2tzLg0KICAgV2hpbGUgYXR0YWNrcyBvbiBj
b25uZWN0aXZpdHkgY2hlY2tzIGFyZSB0eXBpY2FsbHkgcGVyZm9ybWVkIGJ5IG5ldHdvcmsNCiAg
IGVudGl0aWVzLCBpZiBhbiBhdHRhY2tlciBpcyBhYmxlIHRvIGNvbnRyb2wgYW4gZW5kcG9pbnQg
aXQgY2FuIG1pZ2h0IGJlIGFibGUNCiAgIHRvIHRyaWdnZXIgY29ubmVjdGl2aXR5IGNoZWNrIGF0
dGFja3MuIFRoZSBwb3NzaWJsZSBmYWxzZSBjb25jbHVzaW9ucyBhbiBhdHRhY2tlciANCiAgIGNh
biB0cnkgYW5kIGNhdXNlIGFyZToiDQogDQotLS0NCg0KPj4+wqAgwqBwb3NzaWJsZSBhdHRhY2su
wqAgRm9ydHVuYXRlbHksIHRoaXMgYXR0YWNrIGlzIG1pdGlnYXRlZCBjb21wbGV0ZWx5DQo+Pj7C
oCDCoHRocm91Z2ggdGhlIFNUVU4gc2hvcnQtdGVybSBjcmVkZW50aWFsIG1lY2hhbmlzbS7CoCBU
aGUgYXR0YWNrZXIgbmVlZHMNCj4+PsKgIMKgdG8gaW5qZWN0IGEgZmFrZSByZXNwb25zZSwgYW5k
IGluIG9yZGVyIGZvciB0aGlzIHJlc3BvbnNlIHRvIGJlDQo+Pj4NCj4+PiBUaGlzIHRleHQgaXMg
YSBiaXQgY29uZnVzaW5nLiBJZiB5b3UgY2FuIGdlbmVyYXRlIGEgZHJvcCwgdGhlbiB5b3UgY2Fu
IG1vdW50IHRoaXMgYXR0YWNrLg0KPj4NCj4+IE5vdCBzdXJlIEkgdW5kZXJzdGFuZC4NCj4NCj4g
SWYgeW91IHdhbnQgdG8gc2ltdWxhdGUgY2hlY2sgZmFpbHVyZSwgeW91IG9ubHkgbmVlZCB0byBi
ZSBhYmxlIHRvIGRyb3AgcGFja2V0cy7CoA0KDQpBYWFoLi4uIG5vdyBJIGdldCBpdC4gSSBvbmx5
IGhhZCB0aGUgY2FzZSBpbiBtaW5kIHdoZXJlIHRoZSBhdHRhY2tlciBnZW5lcmF0ZXMgYSBmYWtl
IHJlc3BvbnNlLg0KIA0KU28sIEkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nIGNoYW5nZXM6DQoNCk9M
RDoNCg0KICAgIlRvIGZvcmNlIHRoZSBmYWxzZSBpbnZhbGlkIHJlc3VsdCwgdGhlIGF0dGFja2Vy
IGhhcyB0byB3YWl0IGZvciB0aGUNCiAgIGNvbm5lY3Rpdml0eSBjaGVjayBmcm9tIG9uZSBvZiB0
aGUgYWdlbnRzIHRvIGJlIHNlbnQuICBXaGVuIGl0IGlzLA0KICAgdGhlIGF0dGFja2VyIG5lZWRz
IHRvIGluamVjdCBhIGZha2UgcmVzcG9uc2Ugd2l0aCBhbiB1bnJlY292ZXJhYmxlDQogICBlcnJv
ciByZXNwb25zZSwgc3VjaCBhcyBhIDQwMC4iDQoNCk5FVzoNCg0KICAgIlRvIGZvcmNlIHRoZSBm
YWxzZSBpbnZhbGlkIHJlc3VsdCwgdGhlIGF0dGFja2VyIGhhcyB0byB3YWl0IGZvciB0aGUNCiAg
IGNvbm5lY3Rpdml0eSBjaGVjayBmcm9tIG9uZSBvZiB0aGUgYWdlbnRzIHRvIGJlIHNlbnQuICBX
aGVuIGl0IGlzLA0KICAgdGhlIGF0dGFja2VyIG5lZWRzIHRvIGluamVjdCBhIGZha2UgcmVzcG9u
c2Ugd2l0aCBhbiB1bnJlY292ZXJhYmxlDQogICBlcnJvciByZXNwb25zZSAoc3VjaCBhcyBhIDQw
MCksIG9yIGRyb3AgdGhlIHJlc3BvbnNlIHNvIHRoYXQgaXQgbmV2ZXINCiAgIHJlYWNoZXMgdGhl
IGFnZW50LiINCg0KLi4uYW5kOg0KDQpPTEQ6DQoNCiAgICJGb3J0dW5hdGVseSwgdGhpcyBhdHRh
Y2sgaXMgbWl0aWdhdGVkIGNvbXBsZXRlbHkNCiAgIHRocm91Z2ggdGhlIFNUVU4gc2hvcnQtdGVy
bSBjcmVkZW50aWFsIG1lY2hhbmlzbS4gIFRoZSBhdHRhY2tlciBuZWVkcw0KICAgdG8gaW5qZWN0
IGEgZmFrZSByZXNwb25zZSwgYW5kIGluIG9yZGVyIGZvciB0aGlzIHJlc3BvbnNlIHRvIGJlDQog
ICBwcm9jZXNzZWQsIHRoZSBhdHRhY2tlciBuZWVkcyB0aGUgcGFzc3dvcmQuICBJZiB0aGUgY2Fu
ZGlkYXRlDQogICBleGNoYW5nZSBzaWduYWxpbmcgaXMgc2VjdXJlZCwgdGhlIGF0dGFja2VyIHdp
bGwgbm90IGhhdmUgdGhlDQogICBwYXNzd29yZCBhbmQgaXRzIHJlc3BvbnNlIHdpbGwgYmUgZGlz
Y2FyZGVkLiINCg0KTkVXOg0KDQogICAiVGhlIGFiaWxpdHkgZm9yIHRoZSBhdHRhY2tlciB0byBn
ZW5lcmF0ZSBhIGZha2UgcmVzcG9uc2UgaXMgbWl0aWdhdGVkDQogICB0aHJvdWdoIHRoZSBTVFVO
IHNob3J0LXRlcm0gY3JlZGVudGlhbCBtZWNoYW5pc20uIEluIG9yZGVyIGZvciB0aGlzIA0KICAg
cmVzcG9uc2UgdG8gYmUgcHJvY2Vzc2VkLCB0aGUgYXR0YWNrZXIgbmVlZHMgdGhlIHBhc3N3b3Jk
LiAgSWYgdGhlIGNhbmRpZGF0ZQ0KICAgZXhjaGFuZ2Ugc2lnbmFsaW5nIGlzIHNlY3VyZWQsIHRo
ZSBhdHRhY2tlciB3aWxsIG5vdCBoYXZlIHRoZQ0KICAgcGFzc3dvcmQgYW5kIGl0cyByZXNwb25z
ZSB3aWxsIGJlIGRpc2NhcmRlZC4iDQoNCi0tLQ0KDQo+Pj7CoCDCoGludmFsaWQgYXR0YWNrLCB0
aGlzIGF0dGFjayBpcyBtaXRpZ2F0ZWQgYnkgdGhlIFNUVU4gc2hvcnQtdGVybQ0KPj4+wqAgwqBj
cmVkZW50aWFsIG1lY2hhbmlzbSBpbiBjb25qdW5jdGlvbiB3aXRoIGEgc2VjdXJlIGNhbmRpZGF0
ZSBleGNoYW5nZS4NCj4+Pg0KPj4+IFRoaXMgYWxzbyBpc24ndCBxdWl0ZSBjb3JyZWN0LiBDb25z
aWRlciB0aGUgY2FzZSB3aGVyZSBBIGlzIGJlaGluZCBhIGZpbHRlcmluZyBlbGVtZW50IChlLmcu
LCBhIGZpcmV3YWxsKSBhbmQNCj4+PiBzaGFyZXMgYSBicm9hZGNhc3QgbmV0d29yayB3aXRoIHRo
ZSBhdHRhY2tlci4gVGhlIGF0dGFja2VyIHRoZW4gY2FwdHVyZXMgYW4gb3V0Z29pbmcgbWVzc2Fn
ZSB0aGF0IHdvdWxkDQo+Pj4gaGF2ZSBiZWVuIGZpbHRlcmVkIGFuZCB0dW5uZWxzIGl0IHRvIEIs
IGFuZCB0aGVuIHR1bm5lbHMgdGhlIHJlc3BvbnNlIGJhY2suIFRoaXMgY2FuIGNhdXNlIEIgYW5k
IEEgdG8gdGhpbmsNCj4+PiB0aGV5IGhhdmUgYSB2YWxpZCBwYXRoIHdoZW4gdGhleSBkbyBub3Qu
IEl0IHNlZW1zIGxpa2UgdGhpcyBhdHRhY2sgaXMgZGVzY3JpYmVkIHNldmVyYWwgcGFyYWdyYXBo
cyBkb3duLCBidXQNCj4+PiBpbiBzb3J0IG9mIGEgY29uZnVzaW5nIHdheS4NCj4+DQo+PiBPaywg
SSBzZWUgd2hhdCB5b3UgbWVhbi4NCj4+DQo+PiBQZXJoYXBzIHdlIHNob3VsZCBqdXN0IHJlbW92
ZSB0aGUgIkZvcnR1bmF0ZWx5LCB0aGlzIGF0dGFjay4uLiIgc2VudGVuY2U/DQo+Pg0KPj4gVGhl
biwgdGhlIHJlc3Qgb2YgdGhlIHBhcmFncmFwaCBjb3VsZCBiZSBzZXBhcmF0ZSBwYXJhZ3JhcGgs
IGFuZCBtb2RpZmllZCBhczoNCj4+DQo+PiBPTEQ6DQo+Pg0KPj7CoCDCoCJUaGUgYXR0YWNrZXIg
bmVlZHMgdG8gaW5qZWN0IGEgZmFrZSByZXNwb25zZSwgYW5kIGluIG9yZGVyIGZvciB0aGlzIHJl
c3BvbnNlIHRvIGJlDQo+PiDCoCDCoHByb2Nlc3NlZCwgdGhlIGF0dGFja2VyIG5lZWRzIHRoZSBw
YXNzd29yZC7CoCBJZiB0aGUgY2FuZGlkYXRlIGV4Y2hhbmdlIHNpZ25hbGluZyBpcyBzZWN1cmVk
LCANCj4+ICAgIHRoZSBhdHRhY2tlciB3aWxsIG5vdCBoYXZlIHRoZSBwYXNzd29yZCBhbmQgaXRz
IHJlc3BvbnNlIHdpbGwgYmUgZGlzY2FyZGVkLiINCj4+DQo+PiBORVc6DQo+Pg0KPj4gwqAiRHVl
IHRvIHRoZSBTVFVOIHNob3J0LXRlcm0gY3JlZGVudGlhbCBtZWNoYW5pc20sIGluIG9yZGVyIGZv
ciB0aGUgYXR0YWNrZXINCj4+wqAgwqAgdG8gaW5qZWN0IGEgZmFrZSByZXNwb25zZSwgYW5kIGlu
IG9yZGVyIGZvciB0aGlzIHJlc3BvbnNlIHRvIGJlIHByb2Nlc3NlZCwgdGhlDQo+PsKgIMKgIGF0
dGFja2VyIG5lZWRzIHRoZSBwYXNzd29yZC7CoCBJZiB0aGUgY2FuZGlkYXRlIGV4Y2hhbmdlIHNp
Z25hbGluZyBpcyBzZWN1cmVkLA0KPj7CoCDCoCB0aGUgYXR0YWNrZXIgd2lsbCBub3QgaGF2ZSB0
aGUgcGFzc3dvcmQgYW5kIGl0cyByZXNwb25zZSB3aWxsIGJlIGRpc2NhcmRlZC4iDQo+DQo+IE15
IHBvaW50IGlzIHRoYXQgYW4gb24tcGF0aCBhdHRhY2tlciBjYW4gYWN0dWFsbHkgc2ltdWxhdGUg
c3VjY2VzcyBmb3IgcGF0aHMgdGhhdCB3b3VsZCBmYWlsLCBhbmQgdGhhdCB0aGUgY3JlZGVudGlh
bHMgZG9uJ3QgaGVscC4NCg0KV2hhdCBhYm91dCB0aGUgZm9sbG93aW5nOg0KDQpPTEQ6DQoNCiAg
ICJGb3JjaW5nIHRoZSBmYWtlIHZhbGlkIHJlc3VsdCB3b3JrcyBpbiBhIHNpbWlsYXIgd2F5LiAg
VGhlIGFnZW50DQogICBuZWVkcyB0byB3YWl0IGZvciB0aGUgQmluZGluZyByZXF1ZXN0IGZyb20g
ZWFjaCBhZ2VudCwgYW5kIGluamVjdCBhDQogICBmYWtlIHN1Y2Nlc3MgcmVzcG9uc2UuICBUaGUg
YXR0YWNrZXIgd29uJ3QgbmVlZCB0byB3b3JyeSBhYm91dA0KICAgZGlzcnVwdGluZyB0aGUgYWN0
dWFsIHJlc3BvbnNlIHNpbmNlLCBpZiB0aGUgY2FuZGlkYXRlIGlzIG5vdCB2YWxpZCwNCiAgIGl0
IHByZXN1bWFibHkgd291bGRuJ3QgYmUgcmVjZWl2ZWQgYW55d2F5LiAgSG93ZXZlciwgbGlrZSB0
aGUgZmFrZQ0KICAgaW52YWxpZCBhdHRhY2ssIHRoaXMgYXR0YWNrIGlzIG1pdGlnYXRlZCBieSB0
aGUgU1RVTiBzaG9ydC10ZXJtDQogICBjcmVkZW50aWFsIG1lY2hhbmlzbSBpbiBjb25qdW5jdGlv
biB3aXRoIGEgc2VjdXJlIGNhbmRpZGF0ZSBleGNoYW5nZS4iDQoNCk5FVzoNCg0KICAgIkZvcmNp
bmcgdGhlIGZha2UgdmFsaWQgcmVzdWx0IHdvcmtzIGluIGEgc2ltaWxhciB3YXkuICBUaGUgYWdl
bnQNCiAgIG5lZWRzIHRvIHdhaXQgZm9yIHRoZSBCaW5kaW5nIHJlcXVlc3QgZnJvbSBlYWNoIGFn
ZW50LCBhbmQgaW5qZWN0IGENCiAgIGZha2Ugc3VjY2VzcyByZXNwb25zZSwgb3Igcm91dGUgKGUu
Zy4sIHVzaW5nIGEgdHVubmVsbGluZyBtZWNoYW5pc20pIGEgDQogICBzdWNjZXNzIHJlc3BvbnNl
IHRoYXQgIG5vcm1hbGx5IHdvdWxkIGJlIGRyb3BwZWQgb3IgcmVqZWN0ZWQgYnkgdGhlIA0KICAg
bmV0d29yayB0byB0aGUgYWdlbnQuIEFnYWluLCBkdWUgdG8gdGhlIFNUVU4gc2hvcnQtdGVybSBj
cmVkZW50aWFsIA0KICAgbWVjaGFuaXNtLCBpbiBvcmRlciBmb3IgdGhlIGF0dGFja2VyIHRvIGlu
amVjdCBhIHZhbGlkIHN1Y2Nlc3MgcmVzcG9uc2UsIHRoZQ0KICAgYXR0YWNrZXIgbmVlZHMgdGhl
IHBhc3N3b3JkLiINCsKgDQotLS0NCg0KPj4+MTkuNC4xLsKgIFNUVU4gQW1wbGlmaWNhdGlvbiBB
dHRhY2sNCj4+Pkl0J3MgcHJvYmFibHkgd29ydGggbm90aW5nIHRoYXQgdGhpcyBmb3JtIG9mIGF0
dGFjayBpcyBhIGxvdCB3b3JzZSB3aGVuIFdlYlJUQyBpcyBpbnZvbHZlZC4NCj4+DQo+PiBXaHkg
aXMgdGhhdD8NCj4NCj4gQmVjYXVzZSB0aGUgYXR0YWNrZXIgY2FuIGZvcmNlIGVuZHBvaW50cyB0
byBtYWtlIGNhbGxzIGZvciBoaW0gYW5kIGNhbiBzdXBwbHkgYW55IGNhbmRpZGF0ZXMgaGUgY2hv
b3Nlcw0KDQpUbyB0aGUgZm9sbG93aW5nIHRleHQ6DQoNCiAgICJUaGUgYXR0YWNrZXIgc2VuZHMg
YW4gYSBsYXJnZSBudW1iZXIgb2YgY2FuZGlkYXRlcywgc2F5LCA1MC4gIFRoZQ0KICAgcmVzcG9u
ZGluZyBhZ2VudCByZWNlaXZlcyB0aGUgY2FuZGlkYXRlIGluZm9ybWF0aW9uLCBhbmQgc3RhcnRz
IGl0cw0KICAgY2hlY2tzLCB3aGljaCBhcmUgZGlyZWN0ZWQgYXQgdGhlIHRhcmdldCwgYW5kIGNv
bnNlcXVlbnRseSwgbmV2ZXINCiAgIGdlbmVyYXRlIGEgcmVzcG9uc2UuIg0KDQouLi5JIGNvdWxk
IGFwcGVuZCB0aGUgZm9sbG93aW5nOg0KDQogICAiSW4gdGhlIGNhc2Ugb2YgV2ViUlRDIHRoZSB1
c2VyIG1pZ2h0IG5vdCBldmVuIGJlIGF3YXJlIHRoYXQgdGhpcyBhdHRhY2sgaXMgb25nb2luZywg
c2luY2UgaXQgbWlnaHQgYmUgdHJpZ2dlcmVkIGluIHRoZSBiYWNrZ3JvdW5kIGJ5IG1hbGljaW91
cyANCiAgICBKYXZhU2NyaXB0IGNvZGUgdGhhdCB0aGUgdXNlciBoYXMgZmV0Y2hlZC4iDQoNCi0t
LQ0KDQo+Pj4gKEFwcGVuZGl4IEIuMSAtIG5vdCBzZWN1cml0eSByZWxhdGVkKQ0KPj4+DQo+Pj7C
oCByYXRlIGF0IHdoaWNoIHRoZXkgd2lsbCBjcmVhdGUgbmV3IGJpbmRpbmdzLsKgIEV4cGVyaW1l
bnRzIGhhdmUgc2hvd24NCj4+PsKgIHRoYXQgb25jZSBldmVyeSA1IG1zIGlzIHdlbGwgc3VwcG9y
dGVkLsKgIFRoaXMgaXMgd2h5IFRhIGhhcyBhIGxvd2VyDQo+Pj7CoCBib3VuZCBvZiA1IG1zLsKg
IEZ1cnRoZXJtb3JlLCB0cmFuc21pc3Npb24gb2YgdGhlc2UgcGFja2V0cyBvbiB0aGUNCj4+Pg0K
Pj4+IENpdGF0aW9uIG5lZWRlZC4NCj4+DQo+PiBJIGRvbid0IHJlYWxseSBoYXZlIGFueS4gVGhp
cyB3YXMgdGhlIG91dGNvbWUgb2YgbG9uZyBXRyBkaXNjdXNzaW9ucy4uLg0KPj4NCj4+IFdlbGws
IHlvdSBjYW4ndCByZWFsbHkgY2xhaW0gIkV4cGVyaW1lbnRzIGhhdmUgc2hvd24iIGlmIHlvdSBj
YW4ndCBjaXRlIHRob3NlIGV4cGVyaWVtbnRzDQoNClJGQyA1MjQ1IGhhZCB0aGUgc2FtZSB0ZXh0
LCBidXQgd2l0aCAyMG1zLg0KDQpJIHNlZSBhIGNvdXBsZSBvZiBhbHRlcm5hdGl2ZXM6DQoNCkFs
dCAjMS4gTW9kaWZ5IHRoZSB0ZXh0IGFuZCBzYXkgc29tZXRoaW5nIGxpa2U6DQoNCk9MRDoNCg0K
IkV4cGVyaW1lbnRzIGhhdmUgc2hvd24gdGhhdCBvbmNlIGV2ZXJ5IDUgbXMgaXMgd2VsbCBzdXBw
b3J0ZWQuICBUaGlzIGlzIHdoeSBUYSBoYXMgYSBsb3dlciBib3VuZCBvZiA1IG1zLiINCg0KTkVX
Og0KDQoiRGlzY3Vzc2lvbnMgaW4gdGhlIElFVEYgSUNFIFdHIGR1cmluZyB0aGUgd29yayBvbiB0
aGlzIHNwZWNpZmljYXRpb24gY29uY2x1ZGVkIHRoYXQsIHRoYXQgb25jZSBldmVyeSA1DQptcyBp
cyB3aWxsIHN1cHBvcnRlZC4gVGhpcyBpcyB3aHkgVGEgaGFzIGEgbG92ZXIgYm91bmQgb2YgNSBt
cy4iIA0KDQpEb2VzIHRoYXQgaGVscD8gSXQgZG9lc24ndCByZWFsbHkgcHJvdmlkZSBhIGNpdGF0
aW9uLCBidXQgYXQgbGVhc3QgaXQgZ2l2ZXMgc29tZSBndWlkYW5jZSB3aGVyZSB0aGUgbnVtYmVy
IGNvbWVzIGZyb20uDQoNCkFsdCAjMi4gUmVtb3ZlIHRoZSB0ZXh0Lg0KDQotLS0NCg0KUmVnYXJk
cywNCg0KQ2hyaXN0ZXINCg0K


From nobody Sun Feb 25 01:53:42 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B091270AC for ; Sun, 25 Feb 2018 01:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9h6MjaNH6sY for ; Sun, 25 Feb 2018 01:53:39 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 9FDB612708C for ; Sun, 25 Feb 2018 01:53:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519552416; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Mhp4XwoMxfLgXnuv9HuJjWl9QAKVnUO2dCoRYmDj5/4=; b=UDPPV9FZbJnaEZk4p0d6rBcWp+v592mEXnqnppeXSer3S9ns0uNHpp21WrVgYRls 2Z/QpWFeSZW+LQAPKY0F9U9AqOsMkrmFmti/MLGEJqGxGNEajGMRnn4sQt0yClTM +lI7XH31Rg7mVYcDtDlkOxj92Kh5GuyjlumtOYLJ8pk=;
X-AuditID: c1b4fb3a-728f89c0000067b4-ab-5a92879f9332
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 95.23.26548.F97829A5; Sun, 25 Feb 2018 10:53:36 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0352.000; Sun, 25 Feb 2018 10:53:35 +0100
From: Christer Holmberg 
To: "ice@ietf.org" 
CC: "ice-chairs@ietf.org" 
Thread-Topic: ICE role-determination even if the criteria are not fulfilled
Thread-Index: AdOuHo20Jh0ijTx9TzuCO/QbgGnutA==
Date: Sun, 25 Feb 2018 09:53:34 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C19C51F@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.166]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C19C51FESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUyM2K7q+6C9klRBqePc1tcnDWZzeLbhVoH Jo8lS34yBTBGcdmkpOZklqUW6dslcGU83f6fseCTbMXD09vZGhg7pboYOTkkBEwkTlzfxgZi CwkcZpTY2+TbxcgFZC9mlLi66gFzFyMHB5uAhUT3P22QGhEBRYmZLc+YQWxmAX2J04eWMYHY wgJuEldfXmaBqPGWONL/gQ3C1pP4+v09I4jNIqAqsfrYEjCbV8BX4vazZ2D1jAJiEt9PrWGC mCkucevJfCaI2wQkluw5zwxhi0q8fPyPFcJWkjh6+hIrRH2+xJO+XawQMwUlTs58wjKBUWgW klGzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzGKFqcWF+emGxnppRZlJhcX 5+fp5aWWbGIERsbBLb+tdjAefO54iFGAg1GJh/dc1aQoIdbEsuLK3EOMEhzMSiK8t0BCvCmJ lVWpRfnxRaU5qcWHGKU5WJTEeZ3SLKKEBNITS1KzU1MLUotgskwcnFINjLkPxI8eUMuweGFq mZFzbeOG/R+Elq9dU++/OzLHYDLTtXNLfs1Z8f3yxowq/euX4rpljilME/6R/El89gXpc5k7 LtRzfd8z135S15Vfkju/lAnwzivrDtS8XNGYu2x7K3/uf0Orr4pch4W2tH4sfzmt7IiApdq9 T0kL2/9PF5lQeZ0rxWKnTK8SS3FGoqEWc1FxIgCQRW5LiAIAAA==
Archived-At: 
Subject: [Ice] ICE role-determination even if the criteria are not fulfilled
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Feb 2018 09:53:40 -0000

--_000_7594FB04B1934943A5C02806D1A2204B6C19C51FESESSMB109erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Section 6.1.1. of draft-5245bis contains the following statement:

   "An agent MUST accept if the peer initiates a re-determination of the
   roles even if the criteria for doing so are not fulfilled.  This can
   happen if the peer is compliant with RFC 5245."

I was told that is not a problem with RFC 5245-compiant peers - it may be a=
 problem with *PRE*-RFC 5245 drafts.

If that is true, I don't think we need to cover it, and we could remove the=
 text.

Regards,

Christer


--_000_7594FB04B1934943A5C02806D1A2204B6C19C51FESESSMB109erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


Section 6.1.1. of draft-5245bis contains the followi=
ng statement:


 


   “An agent MUST accept if the peer=
 initiates a re-determination of the


   roles even if the criteria for doing so=
 are not fulfilled.  This can


   happen if the peer is compliant with RF=
C 5245.”


 


I was told that is not a problem with RFC 5245-compi=
ant peers – it may be a problem with *PRE*-RFC 5245 drafts.


 


If that is true, I don’t think we need to cove=
r it, and we could remove the text.


 


Regards,


 


Christer


 






--_000_7594FB04B1934943A5C02806D1A2204B6C19C51FESESSMB109erics_--


From nobody Sun Feb 25 02:08:41 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0B8126DED for ; Sun, 25 Feb 2018 02:08:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.319
X-Spam-Level: 
X-Spam-Status: No, score=-4.319 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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adZY5Zge0FwP for ; Sun, 25 Feb 2018 02:08:36 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7801B126CB6 for ; Sun, 25 Feb 2018 02:08:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519553312; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ymRAsakjpAQCoCIxabptcLSnWU/RAszBmtvIEuJsNCU=; b=Wgf5W1COJBS96c2vTNXvAg3M04obXA6DDLf/p0bDshRHnVH6i4O08vvifOTNoLxX UT8CrHmVlOwZnpnaRP63DR8hUNlNK+2iekjSa0kedWjWBreqnTDBFy8QH0pcr2em QOxWPaDsDfoWETiy7HfMZKQVIZ6RYzyUlHFPAd76srI=;
X-AuditID: c1b4fb25-06bff70000002d5f-e7-5a928b20f2d3
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 97.A7.11615.02B829A5; Sun, 25 Feb 2018 11:08:32 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Sun, 25 Feb 2018 11:08:32 +0100
From: Christer Holmberg 
To: "ice@ietf.org" 
CC: "ice-chairs@ietf.org" , Ben Campbell 
Thread-Topic: ICE change in role conflict ([was: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) - Role conflict issue)
Thread-Index: AdOuH3YziFMqGJv8S0OuiisPdqGWgg==
Date: Sun, 25 Feb 2018 10:08:31 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C19C590@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.166]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C19C590ESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGbHdTFehe1KUweSryhbzO0+zW1ycNZnN 4tuFWgdmjyVLfjJ5zNr5hCWAKYrLJiU1J7MstUjfLoEro/XcK6aCBbuZKzadO8vUwHhnPXMX IweHhICJRGevQhcjF4eQwGFGiYcH97BCOIsZJXY+amYEKWITsJDo/qfdxcjJISKgKDGz5Rkz iM0sECix7EcDO0i9sMB2RolbhycygzgiAnsYJQ59fccM0aEn8WzuWjYQm0VAVWLflGlMIDav gK/E6UOvweKMAmIS30+tYYKYKi5x68l8MFtCQEBiyZ7zzBC2qMTLx/9YIWwliaOnL7FC1OdL NE9/CzVTUOLkzCcsExiFZiEZNQtJ2SwkZbOAfmMW0JRYv0sfokRRYkr3Q3YIW0Oidc5cdmTx BYzsqxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjECY+bglt+qOxgvv3E8xCjAwajEw+tVOSlK iDWxrLgy9xCjBAezkgjvrSqgEG9KYmVValF+fFFpTmrxIUZpDhYlcd45wu1RQgLpiSWp2amp BalFMFkmDk6pBsZSre36bi6Ln+bUhn+PMDsUqnhC79Wjy9ImPzVET2QH/F7srv+MJX4/R62V y9dpSaU2PiK3WuVOFeb8exg1Tb76buGk8/lX7vHsd97bvtPu/6rAvnlXEvcvaVxRymngskdR 9fzF4snHLnd/4pv9/VHNubcXjD6b+H4wmbN6oln7bVPvB8xuG72VWIozEg21mIuKEwECizMO lQIAAA==
Archived-At: 
Subject: [Ice] ICE change in role conflict ([was: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) - Role conflict issue)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Feb 2018 10:08:39 -0000

--_000_7594FB04B1934943A5C02806D1A2204B6C19C590ESESSMB109erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGksDQoNCkkgYXNrIHRoZSBjb21tdW5pdHkgdG8gdGFrZSBhIGxvb2sgYXQgdGhlIHN1Z2dlc3Rl
ZCBjaGFuZ2UgYmVsb3csIGFuZCBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBoYXZlIGFueSBpc3N1ZXMu
DQoNCk5VVFNIRUxMOg0KDQpXaGF04oCZcyB0aGUgcHJvYmxlbT8NCg0KSW4gY2FzZSBib3RoIGFn
ZW50cyBhc3N1bWUgdGhlIHNhbWUgcm9sZSAobWlnaHQgaGFwcGVuIGluIGNlcnRhaW4gM1BDQyBz
Y2VuYXJpb3MpLCBBTkQgdXNlIHRoZSBzYW1lIHRpZS1icmVha2VyIHZhbHVlICh1bmxpa2VseSB0
byBoYXBwZW4sIGJ1dCBwb3NzaWJsZSBpbiB0aGVvcnkpLCB3aGljaCBtYXkgY2F1c2UgYm90aCBl
bmRwb2ludHMgdG8gc2VuZCBhIDQ4NyByZXNwb25zZS4NCg0KVGhlIDQ4NyByZXNwb25zZSB3aWxs
IGNhdXNlIGJvdGggZW5kcG9pbnRzIGFuZCBjaGFuZ2UgdGhlaXIgcm9sZXMsIGFuZCB0cnkgYWdh
aW4uIEJ1dCwgdW5sZXNzIHRoZXkgYWxzbyBjaGFuZ2UgdGhlIHRpZS1icmVha2VyIHZhbHVlLCB0
aGUgcmVzdWx0IHdpbGwgYmUgdGhlIHNhbWU6IGJvdGggd2lsbCBhc3N1bWUgdGhlIHNhbWUgcm9s
ZSAoc2luY2UgYm90aCByZWNlaXZlZCA0ODcpLCBhbmQgbWlnaHQgdXNlIHRoZSBzYW1lIHRpZS1i
cmVha2VyIHZhbHVlcy4NCg0KDQpXaGF04oCZcyB0aGUgc29sdXRpb24/DQoNClNwZWNpZnkgdGhh
dCwgd2hlbiBhbiBlbmRwb2ludCByZWNlaXZlcyA0ODcsIGFuZCBjaGFuZ2VzIGl0cyByb2xlLCBp
dCBNVVNUIGFsc28gY2hhbmdlIHRoZSB0aWUtYnJlYWtlciB2YWx1ZS4gVGhhdCB3YXksIHdoZW4g
Ym90aCBlbmRwb2ludHMgYWdhaW4gdHJ5LCB1bmxlc3MgdGhlIGVuZHBvaW50cyBhZ2FpbiBjaG9v
c2UgdGhlIHNhbWUgdGllLWJyZWFrZXIgdmFsdWUgKGV2ZW4gbW9yZSB1bmxpa2VseSkgb25seSBv
bmUgc2hvdWxkIHNlbmQgYSA0ODcsIGFuZCB0aGUgcm9sZSBjb25mbGljdCB3aWxsIGJlIHNvbHZl
ZC4NCg0KDQpXaGF0IGlmIEkgZG9u4oCZdCBsaWtlIHRoZSBzdWdnZXN0ZWQgc29sdXRpb24/DQoN
ClN1Z2dlc3Qgc29tZXRoaW5nIGJldHRlciAocmVhZDogcHJvdmlkZSBhY3R1YWwgdGV4dCBjaGFu
Z2UvcmVtb3ZhbC9hZGRpdGlvbnMpLg0KDQoNCkRFVEFJTFM6DQoNClBsZWFzZSBzZWUgZGlzY3Vz
c2lvbiB0aHJlYWQgYmVsb3cuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQpGcm9tOiBF
cmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tXQ0KU2VudDogMjQgRmVicnVhcnkgMjAx
OCAyMjo1Mw0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv
bi5jb20+DQpDYzogVGF5bG9yIEJyYW5kc3RldHRlciA8ZGVhZGJlZWZAZ29vZ2xlLmNvbT47IEJl
biBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPjsgaWNlLWNoYWlyc0BpZXRmLm9yZzsgaWNlQGll
dGYub3JnOyBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYub3JnOyBwdGhhdGNoZXJAZ29v
Z2xlLmNvbTsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0ljZV0gRXJp
YyBSZXNjb3JsYSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzLTE3
OiAod2l0aCBDT01NRU5UKSAoZXhjbHVkaW5nIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zKSAtIFJv
bGUgY29uZmxpY3QgaXNzdWUNCg0KDQoNCk9uIFNhdCwgRmViIDI0LCAyMDE4IGF0IDEyOjM3IFBN
LCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0
bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhpLA0KDQpJIGhhZCBh
IGNsb3NlciBsb29rIGF0IHRoZSByb2xlIGNvbmZsaWN0IGlzc3VlLg0KDQpGaXJzdCwgdGhlIGRy
YWZ0IGFscmVhZHkgY292ZXJzIHRoZSBjYXNlIHdoZW4gdGhlIHRpZS1icmVha2VyIHZhbHVlcyBh
cmUgaWRlbnRpY2FsLiBJdCBpcyBkZXNjcmliZWQgaW4gc2VjdGlvbiA3LjMuMS4xPGh0dHA6Ly83
LjMuMS4xPjoNCg0KICAg4oCcSWYgdGhlIGFnZW50J3MgdGllLWJyZWFrZXIgdmFsdWUgaXMgbGFy
Z2VyIHRoYW4gb3IgZXF1YWwgdG/igKbigJ0NCg0KWWVzLiBNeSBwb2ludCBpcyB0aGF0IHRoaXMg
aXMgYnJva2VuLg0KDQoNCg0K4oCmdGhlIGFnZW50IHNlbmRzIDQ4Ny4NCg0KVGhlbiwgYWNjb3Jk
aW5nIHRvIHNlY3Rpb24gNy4yLjUuMS4sIHdoZW4gYW4gYWdlbnQgcmVjZWl2ZXMgdGhlIDQ4NyBy
ZXNwb25zZSBpdCB3aWxsIGNoYW5nZSBpdHMgcm9sZS4NCg0KTm93LCBpZiBCT1RIIGFnZW50cyBz
ZW5kIDQ4NywgaXQgbWVhbnMgQk9USCBhZ2VudHMgd2lsbCBzd2l0Y2ggdGhlaXIgcm9sZXMsIGFu
ZCB0cnkgYWdhaW4uIE5vdywgc2luY2UgYm90aCBhZ2VudHMgc3dpdGNoIHRoZWlyIHJvbGUsIGFu
ZCBrZWVwIHRoZSBzYW1lIHRpZS1icmVha2VyIHZhbHVlLCB0aGUgcmVzdWx0IHdpbGwgYWdhaW4g
YmUgdGhlIHNhbWUgKG9ubHkgd2l0aCBkaWZmZXJlbnQgcm9sZXMpLg0KDQpZZXMsIHNvIHRoZXkg
b3NjaWxsYXRlIGJhY2sgYW5kIGZvcnRoLg0KDQoNCg0KU2VjdGlvbiA3LjIuNS4xPGh0dHA6Ly83
LjIuNS4xPjoNCj09PT09PT09PT09PT0NCg0KT0xEOg0KDQpPbmNlIHRoZSBhZ2VudCBoYXMgc3dp
dGNoZWQgaXRzIHJvbGUsIHRoZSBhZ2VudCBNVVNUIGFkZCB0aGUNCmNhbmRpZGF0ZSBwYWlyIHdo
b3NlIGNoZWNrIGdlbmVyYXRlZCB0aGUgNDg3IGVycm9yIHJlc3BvbnNlIHRvIHRoZQ0KdHJpZ2dl
cmVkIGNoZWNrIHF1ZXVlIGFzc29jaWF0ZWQgd2l0aCB0aGUgY2hlY2sgbGlzdCB0byB3aGljaCB0
aGUNCnBhaXIgYmVsb25ncywgYW5kIHNldCB0aGUgY2FuZGlkYXRlIHBhaXIgc3RhdGUgdG8gV2Fp
dGluZy4gIFdoZW4gdGhlDQp0cmlnZ2VyZWQgY29ubmVjdGl2aXR5IGNoZWNrIGlzIGxhdGVyIHBl
cmZvcm1lZCwgdGhlIElDRS1DT05UUk9MTElORy8NCklDRS1DT05UUk9MTEVEIGF0dHJpYnV0ZSBv
ZiB0aGUgQmluZGluZyByZXF1ZXN0IHdpbGwgaW5kaWNhdGUgdGhlDQphZ2VudCdzIG5ldyByb2xl
LiAgVGhlIGFnZW50IE1BWSBjaGFuZ2UgdGhlIHRpZS1icmVha2VyIHZhbHVlLg0KDQoNCk5FVzoN
Cg0KT25jZSB0aGUgYWdlbnQgaGFzIHN3aXRjaGVkIGl0cyByb2xlLCB0aGUgYWdlbnQgTVVTVCBh
ZGQgdGhlDQpjYW5kaWRhdGUgcGFpciB3aG9zZSBjaGVjayBnZW5lcmF0ZWQgdGhlIDQ4NyBlcnJv
ciByZXNwb25zZSB0byB0aGUNCnRyaWdnZXJlZCBjaGVjayBxdWV1ZSBhc3NvY2lhdGVkIHdpdGgg
dGhlIGNoZWNrIGxpc3QgdG8gd2hpY2ggdGhlDQpwYWlyIGJlbG9uZ3MsIGFuZCBzZXQgdGhlIGNh
bmRpZGF0ZSBwYWlyIHN0YXRlIHRvIFdhaXRpbmcuICBXaGVuIHRoZQ0KdHJpZ2dlcmVkIGNvbm5l
Y3Rpdml0eSBjaGVjayBpcyBsYXRlciBwZXJmb3JtZWQsIHRoZSBJQ0UtQ09OVFJPTExJTkcvDQpJ
Q0UtQ09OVFJPTExFRCBhdHRyaWJ1dGUgb2YgdGhlIEJpbmRpbmcgcmVxdWVzdCB3aWxsIGluZGlj
YXRlIHRoZQ0KYWdlbnQncyBuZXcgcm9sZS4gIFRoZSBhZ2VudCBNVVNUIGNoYW5nZSB0aGUgdGll
LWJyZWFrZXIgdmFsdWUuDQoNCg0KU2VjdGlvbiAxNi4xOg0KPT09PT09PT09PT0NCg0KT0xEOg0K
DQpBbiBJQ0UgYWdlbnQgTVVTVCB1c2UgdGhlIHNhbWUgbnVtYmVyIGZvciBhbGwNCkJpbmRpbmcg
cmVxdWVzdHMsIGZvciBhbGwgc3RyZWFtcywgd2l0aGluIGFuIElDRSBzZXNzaW9uLiBUaGUgYWdl
bnQNCk1BWSBjaGFuZ2UgdGhlIG51bWJlciB3aGVuIGFuIElDRSByZXN0YXJ0IG9jY3Vycy4NCg0K
TkVXOg0KDQpBbiBJQ0UgYWdlbnQgTVVTVCB1c2UgdGhlIHNhbWUgbnVtYmVyIGZvciBhbGwNCkJp
bmRpbmcgcmVxdWVzdHMsIGZvciBhbGwgc3RyZWFtcywgd2l0aGluIGFuIElDRSBzZXNzaW9uLCB1
bmxlc3MNCml0IHJlY2VpdmVzIGEgNDg3IHJlc3BvbnNlLCBpbiB3aGljaCBjYXNlIGl0IE1VU1Qg
Y2hhbmdlIHRoZQ0KbnVtYmVyIChTZWN0aW9uIDcuMi41LjEpLiBUaGUgYWdlbnQgTUFZIGNoYW5n
ZSB0aGUgbnVtYmVyIHdoZW4NCmFuIElDRSByZXN0YXJ0IG9jY3Vycy4NCg0KUHJvYmxlbSBzb2x2
ZWQ/IDopDQoNClRoaXMgd291bGQgYmUgZmluZSB3aXRoIG1lLCBidXQgcHJlc3VtYWJseSBuZWVk
cyBXRyBzaWdub2ZmLg0KDQotRWtyDQoNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCkZy
b206IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNv
bT5dDQpTZW50OiAyMSBGZWJydWFyeSAyMDE4IDAxOjA3DQpUbzogVGF5bG9yIEJyYW5kc3RldHRl
ciA8ZGVhZGJlZWZAZ29vZ2xlLmNvbTxtYWlsdG86ZGVhZGJlZWZAZ29vZ2xlLmNvbT4+DQpDYzog
Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86
Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj47IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3Ry
dW0uY29tPG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+PjsgaWNlLWNoYWlyc0BpZXRmLm9yZzxtYWls
dG86aWNlLWNoYWlyc0BpZXRmLm9yZz47IGljZUBpZXRmLm9yZzxtYWlsdG86aWNlQGlldGYub3Jn
PjsgZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpc0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1p
Y2UtcmZjNTI0NWJpc0BpZXRmLm9yZz47IHB0aGF0Y2hlckBnb29nbGUuY29tPG1haWx0bzpwdGhh
dGNoZXJAZ29vZ2xlLmNvbT47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPG1haWx0bzppZXNnQGll
dGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSWNlXSBFcmljIFJlc2NvcmxhJ3MgTm8gT2JqZWN0aW9u
IG9uIGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXMtMTc6ICh3aXRoIENPTU1FTlQpIChleGNsdWRp
bmcgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMpDQoNCkkgd291bGRuJ3Qgb2JqZWN0IGlmIHNvbWVv
bmUgcHJvZHVjZWQgYSBwcmluY2lwbGVkIGZpeC4gSSBqdXN0IGRvbid0IHdhbnQgdG8gY3JlYXRl
IGEgbG90IG9mIHdvcmsgZm9yIHBlb3BsZQ0KDQoNCk9uIFR1ZSwgRmViIDIwLCAyMDE4IGF0IDI6
NTEgUE0sIFRheWxvciBCcmFuZHN0ZXR0ZXIgPGRlYWRiZWVmQGdvb2dsZS5jb208bWFpbHRvOmRl
YWRiZWVmQGdvb2dsZS5jb20+PiB3cm90ZToNClRoZSB0aWUtYnJlYWtlciBjb2xsaXNpb24gcHJv
YmxlbSBoYXMgY29tZSB1cCBhIGZldyB0aW1lcyBiZWZvcmUsIGFjdHVhbGx5LiBBcyBJJ3ZlIHNh
aWQsIEkgYmVsaWV2ZSBpdCBjb3VsZCBiZSBmaXhlZCB2ZXJ5IGVhc2lseSBieSBzYXlpbmcgInBp
Y2sgYSBuZXcgdGllLWJyZWFrZXIgaWYgdGhpcyBoYXBwZW5zLiINCg0KQXMgZm9yIHRoZSAiTVVT
VCBub3QgY2hhbmdlIHRpZS1icmVha2VyIiBydWxlIGluIHNlY3Rpb24gMTYuMSwgcmVxdWlyaW5n
IGFuIElDRSByZXN0YXJ0IGlzIG92ZXJraWxsLiBXZSBjYW4ganVzdCBjaGFuZ2UgaXQgdG8gIk1V
U1Qgbm90IGNoYW5nZSB0aWUtYnJlYWtlciB1bmxlc3MgdGhlcmUncyBhIGNvbGxpc2lvbi4iDQoN
Ck9uIE1vbiwgRmViIDE5LCAyMDE4IGF0IDEwOjMzIEFNLCBFcmljIFJlc2NvcmxhIDxla3JAcnRm
bS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KDQoNCk9uIE1vbiwgRmViIDE5LCAy
MDE4IGF0IDEwOjI5IEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp
Y3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToN
CkhpLA0KDQouLi4NCg0KPj4+PiBJRiB3ZSByZWFsbHkgd2FudCB0byBzb2x2ZSB0aGlzLCBvbmUg
c2ltcGxlIHNvbHV0aW9uIGJlIHRvIHNheSB0aGF0LCBpZiB0aGlzIGhhcHBlbnMsIGFuZCBlbmRw
b2ludCBzaW1wbHkgY2FsY3VsYXRlcyBhDQo+Pj4+IG5ldyB0aWUtYnJlYWtlciB2YWx1ZSwgYW5k
IHRyaWVzIGFnYWluPyBCVVQsIHRoZW4gd2Ugd291bGQgaGF2ZSB0byBjaGFuZ2Ugc2VjdGlvbiAx
Ni4xLCB3aGljaCBzYXlzIHRoYXQgYSBuZXcgdmFsdWUgY2FuIG9ubHkgYmUgY2FsY3VsYXRlZCBh
dCBhbiBJQ0UgcmVzdGFydC4NCj4+Pj4NCj4+Pj4gU28sIGNvdWxkIHdlIHNpbXBseSBzYXkgdGhh
dCwgaWYgdGhpcyBoYXBwZW5zLCB0aGUgYWdlbnQgTVVTVCBkbyBhbiBJQ0UgcmVzdGFydCwgYW5k
IGl0IE1VU1QgY2FsY3VsYXRlIGEgbmV3IHRpZS1icmVha2VyIHZhbHVlPw0KPj4+DQo+Pj4gTm93
IGJvdGggc2lkZXMgbWlnaHQgZG8gYSBzaW11bHRhbmVvdXMgcmVzdGFydC4gSXMgdGhhdCBnb2lu
ZyB0byB3b3JrPw0KPj4NCj4+IFdlIGNvdWxkIHNheSB0aGF0IHRoZSBpbml0aWF0aW5nIGFnZW50
IE1VU1QgZG8gdGhlIHJlc3RhcnQuDQo+DQo+IEluIHRoaXMgc2NlbmFyaW8sIGRvbid0IGJvdGgg
c2lkZXMgYmVsaWV2ZSB0aGV5IGFyZSB0aGUgaW5pdGlhdGluZyBwZWVyLCBoZW5jZSB0aGUgbmVl
ZCBmb3IgdGhlIHRpZWJyZWFrZXI/DQoNClByb2JhYmx5Li4uDQoNCkJ1dCwgdGhlbiBJIGRvbid0
IHNlZSB3aGF0IHdlIGNvdWxkIGRvLiBJZiBib3RoIGFnZW50cyBzZW5kIGEgY2hlY2ssIGFuZCBy
ZWNlaXZlIDQ4Nywgd2UgY2FuJ3QgZGVmaW5lIGEgcHJvY2VkdXJlIGZvciBvbmUgb2YgdGhlIGFn
ZW50cy4NCg0KUGVyaGFwcyB3ZSBzaG91bGQgdGhlbiBjaGFuZ2UgdGhlIG11c3Qtbm90LWNoYW5n
ZS10aGUtdmFsdWUtdW5sZXNzLXJlc3RhcnQgYW5kIHNheSB0aGF0IGFuIGFnZW50IGNoYW5nZXMg
dGhlIHRpZS1icmVha2VyIHZhbHVlIGFuZCB0cnkgYWdhaW4uDQoNCkFzIHlvdSBzYXksIHRoZSBw
cm9ibGVtIGlzIGluaGVyZW50bHkgdGhhdCB0aGUgc2l0dWF0aW9uIGlzIHN5bW1ldHJpY2FsLg0K
DQpBdCB0aGlzIHBvaW50IGluIHRoZSBkZXNpZ24gcHJvY2VzcywgSSBkb24ndCB0aGluayBpdCdz
IHdvcnRoIHRyeWluZyB0byBhY3R1YWxseSBtYWtlIHRoZSBjYWxsIHN1Y2NlZWQ7IGEgMl57LTY0
fSBmYWlsdXJlIHJhdGUgaXMgbXVjaCBsb3dlciB0aGFuIG9yZ2FuaWMgY2FsbCBmYWlsdXJlIHJh
dGVzIGZyb20gb3RoZXIgY2F1c2VzLCBldmVuIGluIG5vbi0zUENDIHNjZW5hcmlvcy4gUmF0aGVy
LCBJIHRoaW5rIHRoZSBzcGVjIHNob3VsZCBqdXN0IHByZXNjcmliZSBhIGNsZWFuIGZhaWx1cmUg
bW9kZSB2aWEgYSBuZXcgZXJyb3IgY29kZSwgcmF0aGVyIHRoYW4gaGF2aW5nIGJvdGggc2lkZXMg
d2lsZGx5IG9zY2lsbGF0ZSBiZXR3ZWVuIGNvbnRyb2xsZWQgYW5kIGNvbnRyb2xsaW5nDQoNCi1F
a3INCg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpJY2UgbWFpbGluZyBsaXN0DQpJY2VAaWV0Zi5vcmc8
bWFpbHRvOkljZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vaWNlDQoNCg0KDQo=

--_000_7594FB04B1934943A5C02806D1A2204B6C19C590ESESSMB109erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z
ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10
eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7
DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl
eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy
ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0
IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2
IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N
CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9
IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh
cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0
LWxhbmd1YWdlOkVOLVVTIj5JIGFzayB0aGUgY29tbXVuaXR5IHRvIHRha2UgYSBsb29rIGF0IHRo
ZSBzdWdnZXN0ZWQgY2hhbmdlIGJlbG93LCBhbmQgaW5kaWNhdGUgd2hldGhlciB5b3UgaGF2ZSBh
bnkgaXNzdWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TlVU
U0hFTEw6PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2hh
dOKAmXMgdGhlIHByb2JsZW0/PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1
YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF
Ti1VUyI+SW4gY2FzZSBib3RoIGFnZW50cyBhc3N1bWUgdGhlIHNhbWUgcm9sZSAobWlnaHQgaGFw
cGVuIGluIGNlcnRhaW4gM1BDQyBzY2VuYXJpb3MpLCBBTkQgdXNlIHRoZSBzYW1lIHRpZS1icmVh
a2VyIHZhbHVlICh1bmxpa2VseSB0bw0KIGhhcHBlbiwgYnV0IHBvc3NpYmxlIGluIHRoZW9yeSks
IHdoaWNoIG1heSBjYXVzZSBib3RoIGVuZHBvaW50cyB0byBzZW5kIGEgNDg3IHJlc3BvbnNlLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIDQ4NyByZXNwb25zZSB3
aWxsIGNhdXNlIGJvdGggZW5kcG9pbnRzIGFuZCBjaGFuZ2UgdGhlaXIgcm9sZXMsIGFuZCB0cnkg
YWdhaW4uIEJ1dCwgdW5sZXNzIHRoZXkgYWxzbyBjaGFuZ2UgdGhlIHRpZS1icmVha2VyIHZhbHVl
LA0KIHRoZSByZXN1bHQgd2lsbCBiZSB0aGUgc2FtZTogYm90aCB3aWxsIGFzc3VtZSB0aGUgc2Ft
ZSByb2xlIChzaW5jZSBib3RoIHJlY2VpdmVkIDQ4NyksIGFuZCBtaWdodCB1c2UgdGhlIHNhbWUg
dGllLWJyZWFrZXIgdmFsdWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl
OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V
UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi
PldoYXTigJlzIHRoZSBzb2x1dGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt
bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1
YWdlOkVOLVVTIj5TcGVjaWZ5IHRoYXQsIHdoZW4gYW4gZW5kcG9pbnQgcmVjZWl2ZXMgNDg3LCBh
bmQgY2hhbmdlcyBpdHMgcm9sZSwgaXQgTVVTVCBhbHNvIGNoYW5nZSB0aGUgdGllLWJyZWFrZXIg
dmFsdWUuIFRoYXQgd2F5LCB3aGVuIGJvdGggZW5kcG9pbnRzDQogYWdhaW4gdHJ5LCB1bmxlc3Mg
dGhlIGVuZHBvaW50cyBhZ2FpbiBjaG9vc2UgdGhlIHNhbWUgdGllLWJyZWFrZXIgdmFsdWUgKGV2
ZW4gbW9yZSB1bmxpa2VseSkgb25seSBvbmUgc2hvdWxkIHNlbmQgYSA0ODcsIGFuZCB0aGUgcm9s
ZSBjb25mbGljdCB3aWxsIGJlIHNvbHZlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s
YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh
Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl
OkVOLVVTIj5XaGF0IGlmIEkgZG9u4oCZdCBsaWtlIHRoZSBzdWdnZXN0ZWQgc29sdXRpb24/PG86
cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U3VnZ2VzdCBzb21ldGhp
bmcgYmV0dGVyIChyZWFkOiBwcm92aWRlIGFjdHVhbCB0ZXh0IGNoYW5nZS9yZW1vdmFsL2FkZGl0
aW9ucykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+REVUQUlMUzo8bzpw
PjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5QbGVhc2Ugc2VlIGRpc2N1
c3Npb24gdGhyZWFkIGJlbG93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl
OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V
UyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlz
dGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENv
bXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl
OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0
Zm0uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDI0IEZlYnJ1YXJ5IDIwMTggMjI6NTM8YnI+DQo8
Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv
bi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBUYXlsb3IgQnJhbmRzdGV0dGVyICZsdDtkZWFkYmVl
ZkBnb29nbGUuY29tJmd0OzsgQmVuIENhbXBiZWxsICZsdDtiZW5Abm9zdHJ1bS5jb20mZ3Q7OyBp
Y2UtY2hhaXJzQGlldGYub3JnOyBpY2VAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaWNlLXJmYzUyNDVi
aXNAaWV0Zi5vcmc7IHB0aGF0Y2hlckBnb29nbGUuY29tOyBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRm
Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJY2VdIEVyaWMgUmVzY29ybGEncyBO
byBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpcy0xNzogKHdpdGggQ09NTUVO
VCkgKGV4Y2x1ZGluZyBTZWN1cml0eSBDb25zaWRlcmF0aW9ucykgLSBSb2xlIGNvbmZsaWN0IGlz
c3VlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCBGZWIgMjQsIDIwMTggYXQgMTI6
MzcgUE0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9s
bWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp
Y3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj
bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij5JIGhhZCBhIGNsb3NlciBsb29rIGF0IHRoZSByb2xlIGNvbmZsaWN0IGlzc3VlLjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkZpcnN0LCB0aGUgZHJhZnQg
YWxyZWFkeSBjb3ZlcnMgdGhlIGNhc2Ugd2hlbiB0aGUgdGllLWJyZWFrZXIgdmFsdWVzIGFyZSBp
ZGVudGljYWwuIEl0IGlzIGRlc2NyaWJlZA0KIGluIHNlY3Rpb24gPGEgaHJlZj0iaHR0cDovLzcu
My4xLjEiIHRhcmdldD0iX2JsYW5rIj43LjMuMS4xPC9hPjo8L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsg4oCcSWYgdGhlIGFnZW50J3Mg
dGllLWJyZWFrZXIgdmFsdWUgaXMgbGFyZ2VyIHRoYW4NCjxiPm9yIGVxdWFsIHRvPC9iPuKApuKA
nTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMuIE15IHBvaW50IGlzIHRoYXQgdGhpcyBp
cyBicm9rZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAw
Y20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igKZ0aGUgYWdlbnQgc2VuZHMgNDg3Lg0K
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlbiwgYWNj
b3JkaW5nIHRvIHNlY3Rpb24gNy4yLjUuMS4sIHdoZW4gYW4gYWdlbnQgcmVjZWl2ZXMgdGhlIDQ4
NyByZXNwb25zZSBpdCB3aWxsIGNoYW5nZSBpdHMgcm9sZS48L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ob3csIGlmIEJPVEggYWdlbnRzIHNlbmQgNDg3LCBp
dCBtZWFucyBCT1RIIGFnZW50cyB3aWxsIHN3aXRjaCB0aGVpciByb2xlcywgYW5kIHRyeSBhZ2Fp
bi4gTm93LCBzaW5jZQ0KIGJvdGggYWdlbnRzIHN3aXRjaCB0aGVpciByb2xlLCBhbmQga2VlcCB0
aGUgc2FtZSB0aWUtYnJlYWtlciB2YWx1ZSwgdGhlIHJlc3VsdCB3aWxsIGFnYWluIGJlIHRoZSBz
YW1lIChvbmx5IHdpdGggZGlmZmVyZW50IHJvbGVzKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+WWVzLCBzbyB0aGV5IG9zY2lsbGF0ZSBiYWNrIGFuZCBmb3J0aC48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0
OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm
dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2VjdGlvbg0KPGEgaHJlZj0i
aHR0cDovLzcuMi41LjEiIHRhcmdldD0iX2JsYW5rIj43LjIuNS4xPC9hPjo8L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj49PT09PT09PT09PT09PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+T0xEOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPk9uY2UgdGhlIGFnZW50IGhhcyBzd2l0Y2hlZCBpdHMgcm9sZSwgdGhlIGFnZW50IE1V
U1QgYWRkIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmNhbmRpZGF0ZSBwYWlyIHdob3NlIGNoZWNr
IGdlbmVyYXRlZCB0aGUgNDg3IGVycm9yIHJlc3BvbnNlIHRvIHRoZTwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPnRyaWdnZXJlZCBjaGVjayBxdWV1ZSBhc3NvY2lhdGVkIHdpdGggdGhlIGNoZWNrIGxpc3Qg
dG8gd2hpY2ggdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+cGFpciBiZWxvbmdzLCBhbmQgc2V0IHRo
ZSBjYW5kaWRhdGUgcGFpciBzdGF0ZSB0byBXYWl0aW5nLiZuYnNwOyBXaGVuIHRoZTwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPnRyaWdnZXJlZCBjb25uZWN0aXZpdHkgY2hlY2sgaXMgbGF0ZXIgcGVyZm9y
bWVkLCB0aGUgSUNFLUNPTlRST0xMSU5HLzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklDRS1DT05UUk9M
TEVEIGF0dHJpYnV0ZSBvZiB0aGUgQmluZGluZyByZXF1ZXN0IHdpbGwgaW5kaWNhdGUgdGhlPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+YWdlbnQncyBuZXcgcm9sZS4mbmJzcDsgVGhlIGFnZW50DQo8Yj5N
QVk8L2I+IGNoYW5nZSB0aGUgdGllLWJyZWFrZXIgdmFsdWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TkVX
Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9uY2UgdGhl
IGFnZW50IGhhcyBzd2l0Y2hlZCBpdHMgcm9sZSwgdGhlIGFnZW50IE1VU1QgYWRkIHRoZTwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPmNhbmRpZGF0ZSBwYWlyIHdob3NlIGNoZWNrIGdlbmVyYXRlZCB0aGUg
NDg3IGVycm9yIHJlc3BvbnNlIHRvIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRyaWdnZXJlZCBj
aGVjayBxdWV1ZSBhc3NvY2lhdGVkIHdpdGggdGhlIGNoZWNrIGxpc3QgdG8gd2hpY2ggdGhlPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+cGFpciBiZWxvbmdzLCBhbmQgc2V0IHRoZSBjYW5kaWRhdGUgcGFp
ciBzdGF0ZSB0byBXYWl0aW5nLiZuYnNwOyBXaGVuIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRy
aWdnZXJlZCBjb25uZWN0aXZpdHkgY2hlY2sgaXMgbGF0ZXIgcGVyZm9ybWVkLCB0aGUgSUNFLUNP
TlRST0xMSU5HLzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklDRS1DT05UUk9MTEVEIGF0dHJpYnV0ZSBv
ZiB0aGUgQmluZGluZyByZXF1ZXN0IHdpbGwgaW5kaWNhdGUgdGhlPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+YWdlbnQncyBuZXcgcm9sZS4mbmJzcDsgVGhlIGFnZW50DQo8Yj5NVVNUPC9iPiBjaGFuZ2Ug
dGhlIHRpZS1icmVha2VyIHZhbHVlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNlY3Rpb24gMTYuMTo8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj49PT09PT09PT09PTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPk9MRDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj5BbiBJQ0UgYWdlbnQgTVVTVCB1c2UgdGhlIHNhbWUgbnVtYmVyIGZvciBh
bGw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CaW5kaW5nIHJlcXVlc3RzLCBmb3IgYWxsIHN0cmVhbXMs
IHdpdGhpbiBhbiBJQ0Ugc2Vzc2lvbi4gVGhlIGFnZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TUFZ
IGNoYW5nZSB0aGUgbnVtYmVyIHdoZW4gYW4gSUNFIHJlc3RhcnQgb2NjdXJzLjwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk5FVzo8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbiBJQ0UgYWdlbnQgTVVTVCB1c2UgdGhl
IHNhbWUgbnVtYmVyIGZvciBhbGw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CaW5kaW5nIHJlcXVlc3Rz
LCBmb3IgYWxsIHN0cmVhbXMsIHdpdGhpbiBhbiBJQ0Ugc2Vzc2lvbjxiPiwgdW5sZXNzDQo8L2I+
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aXQgcmVjZWl2ZXMgYSA0ODcgcmVzcG9uc2UsIGluIHdo
aWNoIGNhc2UgaXQgTVVTVCBjaGFuZ2UgdGhlPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPm51
bWJlciAoU2VjdGlvbiA3LjIuNS4xKS48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj4NCiBUaGUgYWdlbnQgTUFZIGNoYW5nZSB0aGUgbnVtYmVyIHdoZW4gPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+YW4gSUNFIHJlc3RhcnQgb2NjdXJzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu
YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlByb2JsZW0gc29sdmVkPyA6KTwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5UaGlzIHdvdWxkIGJlIGZpbmUgd2l0aCBtZSwgYnV0IHByZXN1bWFibHkg
bmVlZHMgV0cgc2lnbm9mZi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp
bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1fLTYxNTUxOTA4MTkw
MjQyMTgzN19fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m
bmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+IEVyaWMNCiBSZXNjb3JsYSBbbWFpbHRvOjxhIGhyZWY9Im1h
aWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+XQ0KPGJy
Pg0KPGI+U2VudDo8L2I+IDIxIEZlYnJ1YXJ5IDIwMTggMDE6MDc8YnI+DQo8Yj5Ubzo8L2I+IFRh
eWxvciBCcmFuZHN0ZXR0ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpkZWFkYmVlZkBnb29nbGUuY29t
IiB0YXJnZXQ9Il9ibGFuayI+ZGVhZGJlZWZAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6
PC9iPiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1i
ZXJnQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNz
c29uLmNvbTwvYT4mZ3Q7OyBCZW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiZW5Abm9z
dHJ1bS5jb20iIHRhcmdldD0iX2JsYW5rIj5iZW5Abm9zdHJ1bS5jb208L2E+Jmd0OzsNCjxhIGhy
ZWY9Im1haWx0bzppY2UtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWNlLWNoYWly
c0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzppY2VAaWV0Zi5vcmciIHRhcmdldD0iX2Js
YW5rIj4NCmljZUBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWljZS1y
ZmM1MjQ1YmlzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1pZXRmLWljZS1yZmM1
MjQ1YmlzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29t
IiB0YXJnZXQ9Il9ibGFuayI+DQpwdGhhdGNoZXJAZ29vZ2xlLmNvbTwvYT47IFRoZSBJRVNHICZs
dDs8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmllc2dAaWV0
Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0ljZV0gRXJpYyBSZXNjb3Js
YSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzLTE3OiAod2l0aCBD
T01NRU5UKSAoZXhjbHVkaW5nIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zKTwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgd291bGRuJ3Qgb2JqZWN0IGlmIHNvbWVvbmUgcHJvZHVj
ZWQgYSBwcmluY2lwbGVkIGZpeC4gSSBqdXN0IGRvbid0IHdhbnQgdG8gY3JlYXRlIGEgbG90IG9m
IHdvcmsgZm9yIHBlb3BsZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIEZl
YiAyMCwgMjAxOCBhdCAyOjUxIFBNLCBUYXlsb3IgQnJhbmRzdGV0dGVyICZsdDs8YSBocmVmPSJt
YWlsdG86ZGVhZGJlZWZAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRlYWRiZWVmQGdvb2ds
ZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj
bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln
aHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj5UaGUgdGllLWJyZWFrZXIgY29sbGlzaW9u
IHByb2JsZW0gaGFzIGNvbWUgdXAgYSBmZXcgdGltZXMgYmVmb3JlLCBhY3R1YWxseS4gQXMgSSd2
ZSBzYWlkLCBJIGJlbGlldmUmbmJzcDs8L3NwYW4+aXQNCiBjb3VsZCBiZSBmaXhlZCB2ZXJ5IGVh
c2lseSBieSBzYXlpbmcgJnF1b3Q7cGljayBhIG5ldyB0aWUtYnJlYWtlciBpZiB0aGlzIGhhcHBl
bnMuJnF1b3Q7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+QXMgZm9yIHRoZSAmcXVvdDtNVVNUIG5vdCBjaGFuZ2UgdGllLWJyZWFrZXImcXVvdDsgcnVs
ZSBpbiBzZWN0aW9uIDE2LjEsIHJlcXVpcmluZyBhbiBJQ0UgcmVzdGFydCBpcyBvdmVya2lsbC4g
V2UgY2FuIGp1c3QgY2hhbmdlIGl0IHRvICZxdW90O01VU1Qgbm90IGNoYW5nZSB0aWUtYnJlYWtl
cjxpPiB1bmxlc3MgdGhlcmUncyBhIGNvbGxpc2lvbjwvaT4uJnF1b3Q7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
Pk9uIE1vbiwgRmViIDE5LCAyMDE4IGF0IDEwOjMzIEFNLCBFcmljIFJlc2NvcmxhICZsdDs8YSBo
cmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9h
PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu
ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5PbiBNb24sIEZlYiAxOSwgMjAxOCBhdCAxMDoyOSBBTSwgQ2hyaXN0
ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv
bi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+
Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u
ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w
cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSw8YnI+DQo8YnI+
DQouLi48YnI+DQo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IElGIHdlIHJlYWxseSB3YW50IHRvIHNv
bHZlIHRoaXMsIG9uZSBzaW1wbGUgc29sdXRpb24gYmUgdG8gc2F5IHRoYXQsIGlmIHRoaXMgaGFw
cGVucywgYW5kIGVuZHBvaW50IHNpbXBseSBjYWxjdWxhdGVzIGE8YnI+DQomZ3Q7Jmd0OyZndDsm
Z3Q7IG5ldyB0aWUtYnJlYWtlciB2YWx1ZSwgYW5kIHRyaWVzIGFnYWluPyBCVVQsIHRoZW4gd2Ug
d291bGQgaGF2ZSB0byBjaGFuZ2Ugc2VjdGlvbiAxNi4xLCB3aGljaCBzYXlzIHRoYXQgYSBuZXcg
dmFsdWUgY2FuIG9ubHkgYmUgY2FsY3VsYXRlZCBhdCBhbiBJQ0UgcmVzdGFydC48YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBTbywgY291bGQgd2Ugc2ltcGx5IHNh
eSB0aGF0LCBpZiB0aGlzIGhhcHBlbnMsIHRoZSBhZ2VudCBNVVNUIGRvIGFuIElDRSByZXN0YXJ0
LCBhbmQgaXQgTVVTVCBjYWxjdWxhdGUgYSBuZXcgdGllLWJyZWFrZXIgdmFsdWU/PGJyPg0KJmd0
OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IE5vdyBib3RoIHNpZGVzIG1pZ2h0IGRvIGEgc2lt
dWx0YW5lb3VzIHJlc3RhcnQuIElzIHRoYXQgZ29pbmcgdG8gd29yaz88YnI+DQomZ3Q7Jmd0Ozxi
cj4NCiZndDsmZ3Q7IFdlIGNvdWxkIHNheSB0aGF0IHRoZSBpbml0aWF0aW5nIGFnZW50IE1VU1Qg
ZG8gdGhlIHJlc3RhcnQuPGJyPg0KJmd0Ozxicj4NCiZndDsgSW4gdGhpcyBzY2VuYXJpbywgZG9u
J3QgYm90aCBzaWRlcyBiZWxpZXZlIHRoZXkgYXJlIHRoZSBpbml0aWF0aW5nIHBlZXIsIGhlbmNl
IHRoZSBuZWVkIGZvciB0aGUgdGllYnJlYWtlcj88YnI+DQo8YnI+DQpQcm9iYWJseS4uLjxicj4N
Cjxicj4NCkJ1dCwgdGhlbiBJIGRvbid0IHNlZSB3aGF0IHdlIGNvdWxkIGRvLiBJZiBib3RoIGFn
ZW50cyBzZW5kIGEgY2hlY2ssIGFuZCByZWNlaXZlIDQ4Nywgd2UgY2FuJ3QgZGVmaW5lIGEgcHJv
Y2VkdXJlIGZvciBvbmUgb2YgdGhlIGFnZW50cy48YnI+DQo8YnI+DQpQZXJoYXBzIHdlIHNob3Vs
ZCB0aGVuIGNoYW5nZSB0aGUgbXVzdC1ub3QtY2hhbmdlLXRoZS12YWx1ZS11bmxlc3MtcmVzdGFy
dCBhbmQgc2F5IHRoYXQgYW4gYWdlbnQgY2hhbmdlcyB0aGUgdGllLWJyZWFrZXIgdmFsdWUgYW5k
IHRyeSBhZ2Fpbi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj5BcyB5b3Ugc2F5LCB0aGUgcHJvYmxlbSBpcyBpbmhlcmVudGx5
IHRoYXQgdGhlIHNpdHVhdGlvbiBpcyBzeW1tZXRyaWNhbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkF0IHRoaXMgcG9pbnQgaW4gdGhl
IGRlc2lnbiBwcm9jZXNzLCBJIGRvbid0IHRoaW5rIGl0J3Mgd29ydGggdHJ5aW5nIHRvIGFjdHVh
bGx5IG1ha2UgdGhlIGNhbGwgc3VjY2VlZDsgYSAyXnstNjR9IGZhaWx1cmUgcmF0ZSBpcyBtdWNo
IGxvd2VyIHRoYW4gb3JnYW5pYyBjYWxsIGZhaWx1cmUgcmF0ZXMgZnJvbQ0KIG90aGVyIGNhdXNl
cywgZXZlbiBpbiBub24tM1BDQyBzY2VuYXJpb3MuIFJhdGhlciwgSSB0aGluayB0aGUgc3BlYyBz
aG91bGQganVzdCBwcmVzY3JpYmUgYSBjbGVhbiBmYWlsdXJlIG1vZGUgdmlhIGEgbmV3IGVycm9y
IGNvZGUsIHJhdGhlciB0aGFuIGhhdmluZyBib3RoIHNpZGVzIHdpbGRseSBvc2NpbGxhdGUgYmV0
d2VlbiBjb250cm9sbGVkIGFuZCBjb250cm9sbGluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk
ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw
dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy
Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0ZXI8bzpw
PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy
LjBwdCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+
DQpJY2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkljZUBpZXRmLm9yZyIgdGFy
Z2V0PSJfYmxhbmsiPkljZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j
a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_7594FB04B1934943A5C02806D1A2204B6C19C590ESESSMB109erics_--


From nobody Sun Feb 25 05:00:08 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCB5126FB3 for ; Sun, 25 Feb 2018 05:00:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BF_7bLLjEKHw for ; Sun, 25 Feb 2018 05:00:04 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 EE564127023 for ; Sun, 25 Feb 2018 05:00:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519563600; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cFR/luuFRuib1n7RjyiAS2W+Mpj1qoQJj3URECRf0Gs=; b=AX43NtT0wcXukyGs5udd2z6P2a2+TC/yeKNvBmQ4CQbxwtgOdpJj7tLEpcTy56Z8 u239JYCrtZ54TZ7ZseIbW6qcBCtElHvkBsIlRbGbFINhLcTKhoCViEkdMFEcdIQ0 LP3I8zuOh4bXF5xXpjVvWQs3wKWORU93x5Mg+O0HSas=;
X-AuditID: c1b4fb2d-499ff70000005540-a9-5a92b3507213
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 16.F8.21824.053B29A5; Sun, 25 Feb 2018 14:00:00 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Sun, 25 Feb 2018 14:00:00 +0100
From: Christer Holmberg 
To: "ice@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" 
CC: "Black, David" , "jri@google.com" 
Thread-Topic: 5245bis: STUN/TURN transaction timeout timer
Thread-Index: AdOuOI+oEAiBXZOTQm+Dl/LRxGi/pA==
Date: Sun, 25 Feb 2018 12:59:59 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C19C90C@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.172]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C19C90CESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZGbHdWDdg86QogxUT1C22Hl7LbjH/5HVm i4uzJrNZfLtQazHp6EIWB1aPI0dms3gs2FTqsWTJT6YA5igum5TUnMyy1CJ9uwSujOMvb7MV fFOu2PZuJnsD4xr5LkZODgkBE4kXX76wdjFycQgJHGaU2HziEjuEs5hR4vz9JSxdjBwcbAIW Et3/tEHiIgJzGSXaP/WygHQzC3hLPN/0mBHEFhYwlejYvAusXkTASmLqBgGQsIiAnsTkB0/Z QGwWAVWJ1i8/wcp5BXwlvjdsBRvDKCAm8f3UGiaIkeISt57MZ4I4TkBiyZ7zzBC2qMTLx/9Y QcZLCChJNMyEuiBfYvLjxUwQIwUlTs58wjKBUWgWkkmzkJTNQlIGEdeRWLD7ExuErS2xbOFr Zhj7zIHHTMjiCxjZVzGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIERtLBLb91dzCufu14iFGA g1GJhzdnxaQoIdbEsuLK3EOMEhzMSiK8t6qAQrwpiZVVqUX58UWlOanFhxilOViUxHlPevJG CQmkJ5akZqemFqQWwWSZODilGhj1GBwP35DPbc0MXWdb16d1vaMuO+/4FW4Gg4qsHbEPbNdP DSveVKa4bfka2Q/JZ8oWtzDNXZrjeWVHxxGTUGMXoRufTVbcnLtr+lquhVF6hyMrlf0UTqs+ 2v898ZXjAse+K9vZP2bE1Eu8T31Uxa3o2rXpXtilz1qbVxmwHZ/6SoP1wvZfBlxKLMUZiYZa zEXFiQARCdX5oAIAAA==
Archived-At: 
Subject: [Ice] 5245bis: STUN/TURN transaction timeout timer
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Feb 2018 13:00:06 -0000

--_000_7594FB04B1934943A5C02806D1A2204B6C19C90CESESSMB109erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

In draft-5245bis, the name of the STUN/TURN transaction timeout timer is 'H=
TO'.

As part of the IESG review, I have been asked what the 'H' stands for. Afte=
r some digging in the mail archives (2016-09-14), I figured out it stands f=
or "handshake":

https://www.ietf.org/mail-archive/web/ice/current/msg00378.html

      "2.  A timeout for request packets, call it handshake timeout or HTO =
which SHOULD be 2*RTT if the RTT is known and 500ms otherwise."

Now, in RFC 5389, the transaction timeout timer is called 'Ti'. However, th=
e default value for that SHOULD be 39,5 seconds - which is quite different =
from 500ms.

But, still, is there a reason we couldn't use 'Ti' also in 5245bis, and poi=
nt out the big value difference when used with ICE?

Regards,

Christer

--_000_7594FB04B1934943A5C02806D1A2204B6C19C90CESESSMB109erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


In draft-5245bis, the name of the STUN/TURN transact=
ion timeout timer is ‘HTO’.


 


As part of the IESG review, I have been asked what t=
he ‘H’ stands for. After some digging in the mail archives (201=
6-09-14), I figured out it stands for “handshake”:

 


https://www.ietf.org/mail-archive/web/ice/current/m=
sg00378.html


 


      “2.  A tim=
eout for request packets, call it handshake timeout or HTO which SHOULD be =
2*RTT if the RTT is known and 500ms otherwise.”


 


Now, in RFC 5389, the transaction timeout timer is c=
alled ‘Ti’. However, the default value for that SHOULD be 39,5 =
seconds – which is quite different from 500ms.


 


But, still, is there a reason we couldn’t use =
‘Ti’ also in 5245bis, and point out the big value difference wh=
en used with ICE?



 


Regards,


 


Christer






--_000_7594FB04B1934943A5C02806D1A2204B6C19C90CESESSMB109erics_--


From nobody Sun Feb 25 08:38:15 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA51126FDC for ; Sun, 25 Feb 2018 07:05:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ao72sevxqJeV for ; Sun, 25 Feb 2018 07:05:51 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 5455E120227 for ; Sun, 25 Feb 2018 07:05:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519571149; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GlcQjvbgy41+3OzzeUgl4Hzc9yHiPjmElHQEOWbKw8s=; b=WbPcRX0wRUsIca4PEKU7aJnyW3f7oqh8n5MFNoDRpD37XOrEYznBBEWAvz/Uq8dL 0Quceumuntn+2Mhz2I8NjKysP05ddyB4GyxLPZaAf2RBUs2P0/6jcWzHvtHqiu9h 2p8YeiX7DE5bYVHQvsgMqnMKupSnUMNKBwsUG00Jo5w=;
X-AuditID: c1b4fb2d-4b1ff70000005540-72-5a92d0ccea5a
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3B.C2.21824.CC0D29A5; Sun, 25 Feb 2018 16:05:49 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0352.000; Sun, 25 Feb 2018 16:05:48 +0100
From: Christer Holmberg 
To: Adam Roach , The IESG , "Eric Rescorla (ekr@rtfm.com)" , Benjamin Kaduk , "Peter Saint-Andre" 
CC: "draft-ietf-ice-rfc5245bis@ietf.org" ,  Peter Thatcher , "ice-chairs@ietf.org" , "pthatcher@google.com" , "ice@ietf.org" 
Thread-Topic: Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT) - IPv4 and IPv6 addresses in the example
Thread-Index: AdOuSXxHezPFd3MSQcu7YYRepum9NA==
Date: Sun, 25 Feb 2018 15:05:47 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C19DA71@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.172]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7tO7ZC5OiDF7XWuz5u4jdYv7J68wW K16fY7e4OGsym8W3C7UWM/5MZLZYvnEmk8W15a9ZLY7t6Wd24PRYsKnUY8mSn0weTWeOMnvM 2vmExWPy4zZmj7l7XjAHsEVx2aSk5mSWpRbp2yVwZXSv+stccIOzYsq/bawNjDs4uxg5OSQE TCRufznJ3MXIxSEkcJhRYvbHBihnMaPEgg0TWbsYOTjYBCwkuv9pg8RFBHYwSuyZBRLn4mAW +MoosWLjTiYQR1igg1Fi/t3drBBlnYwSM1ZfYAZpFxHQkzi2nA1kH4uAqsTMXzdZQWxeAV+J KTe2sYDYjAJiEt9PrWECsZkFxCVuPZnPBHGfgMSSPeeZIWxRiZeP/4FdJCGgJNEwkwXEZBbQ lFi/Sx+iU1FiSvdDdojpghInZz5hmcAoPAvJ0FkIHbOQdMxC0rGAkWUVo2hxanFxbrqRsV5q UWZycXF+nl5easkmRmB8HdzyW3cH4+rXjocYBTgYlXh4H++fFCXEmlhWXJl7iFGCg1lJhPdW FVCINyWxsiq1KD++qDQntfgQozQHi5I470lP3ighgfTEktTs1NSC1CKYLBMHp1QDo9ac/Pka rJs+qxidPLU0+5Lm2Z3+clWPHf3al8x/uCfv3Eqb0mXrrr1YffjtNOc4t8Rc91NHVWenS8zN uZz1a3PA69mfJ34wTeXfq/WgyLwg8ELQNv0zgnlfW168OHC+zi5o957Ie/eDs+KuTl+21sQ3 RN349LTvr47vb764a3UA29znWzyUzRmUWIozEg21mIuKEwEwzR8lqwIAAA==
Archived-At: 
X-Mailman-Approved-At: Sun, 25 Feb 2018 08:38:13 -0800
Subject: Re: [Ice] Adam Roach's Discuss on draft-ietf-ice-rfc5245bis-17: (with DISCUSS and COMMENT) - IPv4 and IPv6 addresses in the example
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Feb 2018 15:05:53 -0000

SGksDQoNCkkgaGF2ZSB1cGRhdGVkIHRoZSBwdWxsIHJlcXVlc3QsIGFuZCB0aGUgZHJhZnQgbm93
IGluY2x1ZGVzIHR3byBleGFtcGxlczogb25lIHVzaW5nIElQdjQgYWRkcmVzc2VzIGFuZCBvbmUg
dXNpbmcgSVB2NiBhZGRyZXNzZXMuIFRoZSBleGFtcGxlIGlzIHJhdGhlciBzaW1wbGUsIHdpdGgg
Ym90aCBhZ2VudHMgaGF2aW5nIHB1YmxpYyBhZGRyZXNzZXMsIGFuZCBubyBOQVRzIG9yIGZpcmV3
YWxscy4NCg0KSW4gYWRkaXRpb24gdG8gYWRkaW5nIHRoZSBJUHY2IGV4YW1wbGUsIEkgY2xlYW5l
ZCB1cC9jbGFyaWZpZWQgdGhlIGV4YW1wbGVzLiBJIHRoaW5rIHRoZXkgYXJlIGVhc2llciB0byBy
ZWFkIGFuZCB1bmRlcnN0YW5kIG5vdywgZXNwZWNpYWxseSBmb3IgYW4gSUNFIG5ld2JpZS4NCg0K
aHR0cHM6Ly9naXRodWIuY29tL2ljZS13Zy9yZmM1MjQ1YmlzL3B1bGwvNTkNCg0KUmVnYXJkcywN
Cg0KQ2hyaXN0ZXINCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCsKnMTU6DQoNClBsZWFzZSBlaXRo
ZXIgdXBkYXRlIHRoZSBleGFtcGxlIHRvIHVzZSBJUHY2IGluIGFkZGl0aW9uIHRvIElQdjQsIG9y
IHByb3ZpZGUgYW4gYWRkaXRpb25hbCBleGFtcGxlIHRoYXQgdXNlcyBJUHY2IGFkZHJlc3Nlcy4g
IFNlZSBodHRwczovL3d3dy5pYWIub3JnLzIwMTYvMTEvMDcvaWFiLXN0YXRlbWVudC1vbi1pcHY2
LyBmb3IgZ3VpZGFuY2Ugb24gdGhlIHVzZSBvZiBJUHY2IGluIElFVEYgc3BlY2lmaWNhdGlvbnMs
IGluY2x1ZGluZyB0aGVpciBleGFtcGxlcy4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo=


From nobody Sun Feb 25 10:23:58 2018
Return-Path: 
X-Original-To: ice@ietf.org
Delivered-To: ice@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD79124D6C; Sun, 25 Feb 2018 10:23:52 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: ice@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.4
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151958303201.12894.10397595318282442105@ietfa.amsl.com>
Date: Sun, 25 Feb 2018 10:23:52 -0800
Archived-At: 
Subject: [Ice] I-D Action: draft-ietf-ice-trickle-17.txt
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Feb 2018 18:23:52 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interactive Connectivity Establishment WG of the IETF.

        Title           : Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol
        Authors         : Emil Ivov
                          Eric Rescorla
                          Justin Uberti
                          Peter Saint-Andre
	Filename        : draft-ietf-ice-trickle-17.txt
	Pages           : 32
	Date            : 2018-02-25

Abstract:
   This document describes "Trickle ICE", an extension to the
   Interactive Connectivity Establishment (ICE) protocol that enables
   ICE agents to send and receive candidates incrementally rather than
   exchanging complete lists.  With such incremental provisioning, ICE
   agents can begin connectivity checks while they are still gathering
   candidates and considerably shorten the time necessary for ICE
   processing to complete.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ice-trickle-17
https://datatracker.ietf.org/doc/html/draft-ietf-ice-trickle-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-trickle-17


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sun Feb 25 10:24:54 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77082124D6C for ; Sun, 25 Feb 2018 10:24:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 TfipAMH0dxfC for ; Sun, 25 Feb 2018 10:24:51 -0800 (PST)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 CC1A31270A0 for ; Sun, 25 Feb 2018 10:24:51 -0800 (PST)
Received: by mail-io0-x22f.google.com with SMTP id p78so14826824iod.13 for ; Sun, 25 Feb 2018 10:24:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=CR7R6gDdVVupIvZTkrUGDk0mQYbE4fzbFLJeVkdXnRY=; b=ApL6BDMwts22TDSwQ8eyK+RThoJc/d0NzpCzRFB6vMF5M9IXklGpBy/8HcisdNRZ1s Oau4KlHKPNOOv8U5k4uvXmsDFbIfRtauC+TbbHA+3NYKVBYGqnGkBdIZtXy1cu64oH6F aEDJvJ0zwSBL/vOUzH0nbhH1bvnobl4BGjHEU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=CR7R6gDdVVupIvZTkrUGDk0mQYbE4fzbFLJeVkdXnRY=; b=lDhuE6p6Itr8tP4lkEj4kQUqvhcP6sTs1zElYcc3dxE7T2RrhkjdsZ24qcggZgUU/b idj3KpxaADZAOTJtNaWz/B5OPmNZj/9ClgnV11PNuUtFZAoWHhajo6tmkPwrCqMMYbse V28lEFyiZXM/rUkOnXG83B12NFb6UB7V1bVK+ozpamJNnfyyc/7FzFJL6hNb/3lI1EhY NaWwkuOB52dsYagz5Vf2Ls1nMK6HrsR8Lpx/Fu4S70N4ppLyp60bdNCFk0LfZUFFOM6T AvCK0HVWKsOGI/yA4TCafEAqeFXDerlgbvdmMmYQ559pOH9IA+qKFAkqpOHwfIRwWyWZ XXOw==
X-Gm-Message-State: APf1xPAvMA4rSiZ8x/Uvvd7kY5CgE+fN9bSY/y8pUyeJ7bkW2ZZaC2Pn rjEs/xPnggtEdAQFT2fu+suGLjqD7Ns=
X-Google-Smtp-Source: AG47ELvteheRpFpuirYeNQsBAlrHAL1ZhSKla+koWIKXY86w77RlLi4k+n/o3QuIzG63Jm/Ezxl1Bg==
X-Received: by 10.107.163.11 with SMTP id m11mr8795519ioe.26.1519583091103; Sun, 25 Feb 2018 10:24:51 -0800 (PST)
Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id w142sm4039721ita.25.2018.02.25.10.24.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Feb 2018 10:24:50 -0800 (PST)
To: ice@ietf.org
References: <151958303201.12894.10397595318282442105@ietfa.amsl.com>
From: Peter Saint-Andre 
Message-ID: <9d285e83-296a-bcfa-0d07-156f3f06a7b7@mozilla.com>
Date: Sun, 25 Feb 2018 10:24:49 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <151958303201.12894.10397595318282442105@ietfa.amsl.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cBDpzgcxiJV0NMYEAAok1VX3AxgAd1gAz"
Archived-At: 
Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-17.txt
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Feb 2018 18:24:53 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--cBDpzgcxiJV0NMYEAAok1VX3AxgAd1gAz
Content-Type: multipart/mixed; boundary="ao57FNa3T8Qj8K1KziK2amkHWGNv2gvdJ";
 protected-headers="v1"
From: Peter Saint-Andre 
To: ice@ietf.org
Message-ID: <9d285e83-296a-bcfa-0d07-156f3f06a7b7@mozilla.com>
Subject: Re: [Ice] I-D Action: draft-ietf-ice-trickle-17.txt
References: <151958303201.12894.10397595318282442105@ietfa.amsl.com>
In-Reply-To: <151958303201.12894.10397595318282442105@ietfa.amsl.com>

--ao57FNa3T8Qj8K1KziK2amkHWGNv2gvdJ
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

This version addresses feedback provided by the GENART and SECDIR reviewe=
rs.

Peter

On 2/25/18 10:23 AM, internet-drafts@ietf.org wrote:
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts dire=
ctories.
> This draft is a work item of the Interactive Connectivity Establishment=
 WG of the IETF.
>=20
>         Title           : Trickle ICE: Incremental Provisioning of Cand=
idates for the Interactive Connectivity Establishment (ICE) Protocol
>         Authors         : Emil Ivov
>                           Eric Rescorla
>                           Justin Uberti
>                           Peter Saint-Andre
> 	Filename        : draft-ietf-ice-trickle-17.txt
> 	Pages           : 32
> 	Date            : 2018-02-25
>=20
> Abstract:
>    This document describes "Trickle ICE", an extension to the
>    Interactive Connectivity Establishment (ICE) protocol that enables
>    ICE agents to send and receive candidates incrementally rather than
>    exchanging complete lists.  With such incremental provisioning, ICE
>    agents can begin connectivity checks while they are still gathering
>    candidates and considerably shorten the time necessary for ICE
>    processing to complete.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ice-trickle-17
> https://datatracker.ietf.org/doc/html/draft-ietf-ice-trickle-17
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ice-trickle-17
>=20
>=20
> Please note that it may take a couple of minutes from the time of submi=
ssion
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice
>=20


--ao57FNa3T8Qj8K1KziK2amkHWGNv2gvdJ--

--cBDpzgcxiJV0NMYEAAok1VX3AxgAd1gAz
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqS/3EACgkQZWGMGH9o
FKlarxAAyczBQoVo5WuJ99yJkiFoctlg2tR4Tn8bnZqYZfczzbN+DE4lJ7ihgXkg
apY2tAaqa7YCAt7WR04/jZwmbP9MolFC+fH5S22KqejPPlfTJZq5TZA3yf4ec2L7
hZ3wG8FayVcia1qeBiXGqsemkh+0Tq8xzkuzWKUeEHmcHv8KqaxGVlBb7N3vNmrq
+lRzYAAqNfkF5zn2aKou80zaZmy+6CU0ozAAJtUeClNF+4WNlgri6JsxGFbz+0Mi
9GCnq96mYwJDnGIaRvOmnVccn+t72J4ALIM/68uBf6elb3kVGHI7CD3xjQ+qyBna
wkiTT0iyqD4ZU3v9wkWov7owlpbwJpg3UE6O+lXq8d5Yb8/EzSkm6gv2U/duJR4m
f3na0lJ3YuL0VLQn7sFDSUkdVbAmBb+VR4iC6NAC0WXslQUInVmKMqsG7GOQULvo
l6zjesSQ7K4GUR33IWUUgII6SUO1PDAVrP+ghN82hU7/lJZqoK6ILGDCjMuZKuPU
N8kCwCuCI8J6r5rHxRh/yw6BOADAtygZTbJkc/tSMoP6Tz37MFAU3zwJAExjyypw
InE47h/7PIvEtNPyXXTFqfxSquNI7D60ASFYqs1LtAgwZ92w4VV1B5sczvuAVc5J
TaxP/gXM7/Ld+89HKdpMXHXrn5t9jC0pps81c/MwAS8tUvIVcLE=
=pUs/
-----END PGP SIGNATURE-----

--cBDpzgcxiJV0NMYEAAok1VX3AxgAd1gAz--


From nobody Sun Feb 25 11:41:10 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B5A1271DF for ; Sun, 25 Feb 2018 11:41:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBSh0X559xIq for ; Sun, 25 Feb 2018 11:41:07 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 12EA01241F8 for ; Sun, 25 Feb 2018 11:41:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519587665; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4OuuOdQomKiOquSKWfl0j0rTEAFsx2wDH1Yt1WCn/mk=; b=TGqZxWDBOPD2bgjfl3NCbFx5gh00omOxM6I8LMZAnEeXCR6HP+iYsR2cm15Iju7H jFgj26B8wyuF6u3SqEQ/Jab43q5iHc4DDr/AMKjcl5oFw2TLDnnd5tST/nWB4zSY KjYR2xW92SZmz7d2cANW28lnuQmBYbujJkVlMd1AEkg=;
X-AuditID: c1b4fb2d-499ff70000005540-23-5a9311513300
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 85.53.21824.151139A5; Sun, 25 Feb 2018 20:41:05 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0352.000; Sun, 25 Feb 2018 20:41:04 +0100
From: Christer Holmberg 
To: "ice@ietf.org" 
Thread-Topic: Trickle: A couple of questions on section 7
Thread-Index: AdOucJgg+M5x/JnqQAe0nEYDsAIfMA==
Date: Sun, 25 Feb 2018 19:41:04 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.172]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C19E021ESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM2K7om6g4OQog9NLxS2+Xah1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfG65vfWAr2aFf8mjifuYHxiWoXIyeHhICJxO5PVxi7GLk4hAQO M0qsn3SDHcJZzCjxcucvIIeDg03AQqL7nzZIg4iAosTMlmfMILYwUPOJvg42iLilxKEluxgh bD2JRxeusIPYLAKqEmef7GICsXkFfCV+tR0Dq2EUEJP4fmoNWJxZQFzi1pP5TBAHCUgs2XOe GcIWlXj5+B8ryAkSAkoSDTNZIMrzJf68ncEGMVJQ4uTMJywTGAVnIZk0C0nZLCRlEHEdiQW7 P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRWjaHFqcXFuupGxXmpRZnJxcX6eXl5qySZGYNgf3PJb dwfj6teOhxgFOBiVeHj5uSdHCbEmlhVX5h5ilOBgVhLhvVU1KUqINyWxsiq1KD++qDQntfgQ ozQHi5I470lP3ighgfTEktTs1NSC1CKYLBMHp1QDY7TOTsd1KZPsk1b+f2R6sHPep1Xv9QOX 3TLndmY/WHVqbmxUyfGk0KQ6lwgmjxLHWL9rBfuvK0+Q+BwxL7RodSevvSDftEvb3iszWxQ+ n27z+6f1zKptQZ76T1wl1VQDeNaH5LxwXvCH00g9tL2gnHvSYnnhultPuWaveBPc0HfgdvXd /nAGJZbijERDLeai4kQAha7QI3cCAAA=
Archived-At: 
Subject: [Ice] Trickle: A couple of questions on section 7
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Feb 2018 19:41:09 -0000

--_000_7594FB04B1934943A5C02806D1A2204B6C19E021ESESSMB109erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

While catching some breath between trying to address IESG comments on 5245b=
is, I took a look at trickle-16, and I have a couple of questions.

Q1:

Section 7.1 says:

   "The ICE specification [rfc5245bis], Section 6.1.4.2, specifies that
   an agent will terminate the timer for a triggered check in relation
   to a check list once the agent has exhausted all frozen pairs in the
   check list.  This will not work with Trickle ICE, because more pairs
   will be added to the check list incrementally."

Exactly what procedure in 5245bis dos this text refer to?


Q2:

Section 7.2 says:

   "When a check list is set to Failed as described above, regular ICE
   requires the agent to update all other check lists, placing one pair
   from each check list into the Waiting state and thereby effectively
   placing all remaining check lists into the Running state."

Exactly what procedure in 5245bis dos this text refer to?


Regards,

Christer


--_000_7594FB04B1934943A5C02806D1A2204B6C19E021ESESSMB109erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


While catching some breath between trying to address=
 IESG comments on 5245bis, I took a look at trickle-16, and I have a couple=
 of questions.


 


Q1:


 


Section 7.1 says:


 


   “The ICE specification [rfc5245bi=
s], Section 6.1.4.2, specifies that


   an agent will terminate the timer for a=
 triggered check in relation


   to a check list once the agent has exha=
usted all frozen pairs in the


   check list.  This will not work wi=
th Trickle ICE, because more pairs


   will be added to the check list increme=
ntally.”


 


Exactly what procedure in 5245bis dos this text refe=
r to?


 


 


Q2:


 


Section 7.2 says:


 


   “When a check list is set to Fail=
ed as described above, regular ICE


   requires the agent to update all other =
check lists, placing one pair


   from each check list into the Waiting s=
tate and thereby effectively


   placing all remaining check lists into =
the Running state.”


 


Exactly what procedure in 5245bis dos this text refe=
r to?


 


 


Regards,


 


Christer


 






--_000_7594FB04B1934943A5C02806D1A2204B6C19E021ESESSMB109erics_--


From nobody Mon Feb 26 06:14:14 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D0512D7E6; Mon, 26 Feb 2018 06:14:12 -0800 (PST)
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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=l2LMv6ps; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=go/LCg67
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 NWsJ1W3C3GN6; Mon, 26 Feb 2018 06:14:06 -0800 (PST)
Received: from esa2.dell-outbound.iphmx.com (esa2.dell-outbound.iphmx.com [68.232.149.220]) (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 57B9912D7ED; Mon, 26 Feb 2018 06:14:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1519654446; x=1551190446; h=from:cc:to:subject:date:message-id:references: in-reply-to:mime-version; bh=9bX7RIhzymgF/sPqnWSQeLWhTQiffj8fRSLYS3hmk04=; b=l2LMv6psrC+B23/4p6KrDjVE4XjpDeQ/1paNONwxNek3b+5yu5D4fcOW Vu9a1lCTf43eFF3ivCD8+qVbRudhIiW76GQEy2GuYXEm04iMrqB85DSPl EG7V5xif1/2mR9PaDPLZuE7n6f67Cvq8cRsI2eT1uS7YkOT3Iin7AWd13 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2ErAQCHFZRamGOa6ERcGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJaIoEpEHAoCptpggKBFpYFgTcDGUMKI4UQAoJCVhYBAgEBAQEBAQI?= =?us-ascii?q?BAhABAQEBAQgLCwYoL4I4JAEOLxwhBgYBAQEBAQEmAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBFwI9ARICGAEBAQMBDCETHxoBBAsCAQgRBAEBCx0HMhQJCAEBBAESCIQkXAg?= =?us-ascii?q?BD60ngwqFW4IUAQEBAQEBAQEBAQEBAQEBAQEBAQEBFQMFhlBygViBZYMtgy4CA?= =?us-ascii?q?YFQAQEgKwmDCII0iy+GBJAzAwYCpn6Sa4JdAgQCBAUCGoEvJAFXDYEfcIMSCYJ?= =?us-ascii?q?Kggd3AYodgSKBFwEBAQ?=
X-IPAS-Result: =?us-ascii?q?A2ErAQCHFZRamGOa6ERcGgEBAQEBAgEBAQEIAQEBAYJaIoE?= =?us-ascii?q?pEHAoCptpggKBFpYFgTcDGUMKI4UQAoJCVhYBAgEBAQEBAQIBAhABAQEBAQgLC?= =?us-ascii?q?wYoL4I4JAEOLxwhBgYBAQEBAQEmAQEBAQEBAQEBAQEBAQEBAQEBFwI9ARICGAE?= =?us-ascii?q?BAQMBDCETHxoBBAsCAQgRBAEBCx0HMhQJCAEBBAESCIQkXAgBD60ngwqFW4IUA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBFQMFhlBygViBZYMtgy4CAYFQAQEgKwmDCII?= =?us-ascii?q?0iy+GBJAzAwYCpn6Sa4JdAgQCBAUCGoEvJAFXDYEfcIMSCYJKggd3AYodgSKBF?= =?us-ascii?q?wEBAQ?=
Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa2.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 08:14:05 -0600
From: "Black, David" 
Cc: "jri@google.com" , "Black, David" 
Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 20:14:04 +0600
Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w1QEE3Wv001039 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Feb 2018 09:14:03 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com w1QEE3Wv001039
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1519654443; bh=EdylDu6REFEYu3siMzlxeG2Qmn0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=go/LCg67IeOBJfdMUA//JHIed1CML6glOuqfXCS3PbrxRVtBBmTXJrOfUdiissXNB exGfhFNyVTnxDbDSAN5taeZocEjilIsaZLyiKWekmuSThXLxpdDOiPIes4rLeWPwqe QDscLKHgtJN+KZtsRxBAMU1E9E+KrDD6pfu2u4lg=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com w1QEE3Wv001039
Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd04.lss.emc.com (RSA Interceptor); Mon, 26 Feb 2018 09:13:56 -0500
Received: from MXHUB305.corp.emc.com (MXHUB305.corp.emc.com [10.146.3.31]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w1QEDu5Q021588 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 26 Feb 2018 09:13:56 -0500
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB305.corp.emc.com ([10.146.3.31]) with mapi id 14.03.0352.000; Mon, 26 Feb 2018 09:13:55 -0500
To: Christer Holmberg , "ice@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" 
Thread-Topic: 5245bis: STUN/TURN transaction timeout timer
Thread-Index: AdOuOI+oEAiBXZOTQm+Dl/LRxGi/pAA0o/rg
Date: Mon, 26 Feb 2018 14:13:55 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B6C19C90C@ESESSMB109.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C19C90C@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.238.44.138]
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D2432779493630022D46MX307CL04corpem_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com
X-RSA-Classifications: public
Archived-At: 
Subject: Re: [Ice] 5245bis: STUN/TURN transaction timeout timer
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 14:14:12 -0000

--_000_CE03DB3D7B45C245BCA0D2432779493630022D46MX307CL04corpem_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

> But, still, is there a reason we couldn't use 'Ti' also in 5245bis, and p=
oint out the big value difference when used with ICE?

Given the nearly 2-orders-of-magnitude difference in the time periods, I'd =
be concerned that using the same name risks leaving an incorrect impression=
 on an implementer who is familiar with one protocol, but new to the other.=
   Different names may also improve clarity in other documents that describ=
e how STUN and ICE work together.

Thanks, --David

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Sunday, February 25, 2018 8:00 AM
To: ice@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org
Cc: Black, David ; jri@google.com
Subject: 5245bis: STUN/TURN transaction timeout timer

Hi,

In draft-5245bis, the name of the STUN/TURN transaction timeout timer is 'H=
TO'.

As part of the IESG review, I have been asked what the 'H' stands for. Afte=
r some digging in the mail archives (2016-09-14), I figured out it stands f=
or "handshake":

https://www.ietf.org/mail-archive/web/ice/current/msg00378.html

      "2.  A timeout for request packets, call it handshake timeout or HTO =
which SHOULD be 2*RTT if the RTT is known and 500ms otherwise."

Now, in RFC 5389, the transaction timeout timer is called 'Ti'. However, th=
e default value for that SHOULD be 39,5 seconds - which is quite different =
from 500ms.

But, still, is there a reason we couldn't use 'Ti' also in 5245bis, and poi=
nt out the big value difference when used with ICE?

Regards,

Christer

--_000_CE03DB3D7B45C245BCA0D2432779493630022D46MX307CL04corpem_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











>=
; But, still, is there a reason we couldn’t use ‘Ti’ also=
 in 5245bis, and point out the big value difference when used with ICE?



 


Given the nearly 2-ord=
ers-of-magnitude difference in the time periods, I’d be concerned tha=
t using the same name risks leaving an incorrect impression on an implement=
er who is familiar with one protocol, but
 new to the other.   Different names may also improve clarity in =
other documents that describe how STUN and ICE work together.


 




Thanks, --David




 








From: Christer Holmberg [mailto:christer.holm=
berg@ericsson.com]


Sent: Sunday, February 25, 2018 8:00 AM

To: ice@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@iet=
f.org

Cc: Black, David <david.black@emc.com>; jri@google.com

Subject: 5245bis: STUN/TURN transaction timeout timer






 


Hi,


 


In draft-5245bis, the name of t=
he STUN/TURN transaction timeout timer is ‘HTO’.


 


As part of the IESG review, I h=
ave been asked what the ‘H’ stands for. After some digging in t=
he mail archives (2016-09-14), I figured out it stands for “handshake=
”:


 


https://www.ietf.org/mail-arch=
ive/web/ice/current/msg00378.html


 


      =
“2.  A timeout for request packets, call it handshake timeout or=
 HTO which SHOULD be 2*RTT if the RTT is known and 500ms otherwise.”<=
o:p>


 


Now, in RFC 5389, the transacti=
on timeout timer is called ‘Ti’. However, the default value for=
 that SHOULD be 39,5 seconds – which is quite different from 500ms.


 


But, still, is there a reason w=
e couldn’t use ‘Ti’ also in 5245bis, and point out the bi=
g value difference when used with ICE?



 


Regards,


 


Christer








--_000_CE03DB3D7B45C245BCA0D2432779493630022D46MX307CL04corpem_--


From nobody Mon Feb 26 06:22:25 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B02412D7F5 for ; Mon, 26 Feb 2018 06:22:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsQvhk7W8bsC for ; Mon, 26 Feb 2018 06:22:20 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A5511242F5 for ; Mon, 26 Feb 2018 06:22:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519654938; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8az/NMYXI8OrzJoviVFeM19ljUPGzHWQ4tqmYr8s3ok=; b=Ht5HakCFhuvDdJmabEF25bHYco6jcQ2cL5sfPl9ALtQWoG6DpAgmHcaEcuFKP5Ke 5/6T4QwdpL9v1DvmoMsdJvW2BFJfkYimZvxoZ/GukGcEF2eQw/j5jIDJK4rLfke8 tIhlZC0cy+m23lYz/5dipzIZbNQjhcH7Czy7DgSTiBE=;
X-AuditID: c1b4fb25-083ff70000002d5f-ce-5a94181984d7
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FB.AB.11615.918149A5; Mon, 26 Feb 2018 15:22:18 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0352.000; Mon, 26 Feb 2018 15:22:17 +0100
From: Christer Holmberg 
To: "Black, David" , "ice@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" 
CC: "jri@google.com" 
Thread-Topic: 5245bis: STUN/TURN transaction timeout timer
Thread-Index: AdOuOI+oEAiBXZOTQm+Dl/LRxGi/pAA0o/rgAAMPdYA=
Date: Mon, 26 Feb 2018 14:22:16 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B6C19C90C@ESESSMB109.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.19]
Content-Type: multipart/alternative; boundary="_000_D6B9E77B2BA3Dchristerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyM2J7lK6UxJQog5NnmSw+zlrMYjH/5HVm i4uzJrNZfLtQazHp6EIWB1aPSTNnMHss2FTqsWTJT6YA5igum5TUnMyy1CJ9uwSujGuXXrEV 7POqaDk4i6WB8ZBjFyMHh4SAicTuM5VdjFwcQgKHGSXaps5hhXAWM0pMn97CDFLEJmAh0f1P GyQuInAEKL76LnsXIycHs4CqxILDK1hBaoQFLCXu7hcCMUUErCSmbhAAqQAxu668YgSxWYCq 559pAOvkFbCW2PH5BxPEqomMEh8uPgFLcAr4Sdz4spcZxGYUEJP4fmoNE8QqcYlbT+aD2RIC AhJL9pxnhrBFJV4+/scKYosK6ElsOHGbHSKuKNH+tIERojdB4sSUaYwQiwUlTs58wjKBUXQW krGzkJTNQlIGETeQeH9uPjOErS2xbOFrKFtfYuOXs4wQtrXEqb4v7MhqFjByrGIULU4tTspN NzLWSy3KTC4uzs/Ty0st2cQIjNSDW36r7mC8/MbxEKMAB6MSD+/ff5OjhFgTy4orcw8xSnAw K4nwrlwMFOJNSaysSi3Kjy8qzUktPsQozcGiJM47R7g9SkggPbEkNTs1tSC1CCbLxMEp1cBo unWyF1PrKRHxZzUC7tfv5H3+yh4hdj1t+YffS0vOvTQN/CDS0bx9ssQZtumCGkyP43/y1N7u TWzl+sE7Zckfi3KnC2uTxd9vrnKQ+/534p/+XMHKJb3BfadXKf//beSyw6ulwP3ACzOVJWuP bJX4Jr9N07po6//Febc5t8j/epR07eTJHkNpJZbijERDLeai4kQAiiGgYNACAAA=
Archived-At: 
Subject: Re: [Ice] 5245bis: STUN/TURN transaction timeout timer
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 14:22:23 -0000

--_000_D6B9E77B2BA3Dchristerholmbergericssoncom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

>> But, still, is there a reason we couldn=92t use =91Ti=92 also in 5245bis=
, and point out the big value difference when used with ICE?
>
>Given the nearly 2-orders-of-magnitude difference in the time periods, I=
=92d be concerned that using the same name risks leaving an incorrect impre=
ssion on an implementer who
>is familiar with one protocol, but new to the other.   Different names may=
 also improve clarity in other documents that describe how STUN and ICE wor=
k together.

Fair enough. But, should we then point out that Ti isn=92t used with ICE?

Regards,

Christer



From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Sunday, February 25, 2018 8:00 AM
To: ice@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org
Cc: Black, David >; jri@goo=
gle.com
Subject: 5245bis: STUN/TURN transaction timeout timer

Hi,

In draft-5245bis, the name of the STUN/TURN transaction timeout timer is =
=91HTO=92.

As part of the IESG review, I have been asked what the =91H=92 stands for. =
After some digging in the mail archives (2016-09-14), I figured out it stan=
ds for =93handshake=94:

https://www.ietf.org/mail-archive/web/ice/current/msg00378.html

      =932.  A timeout for request packets, call it handshake timeout or HT=
O which SHOULD be 2*RTT if the RTT is known and 500ms otherwise.=94

Now, in RFC 5389, the transaction timeout timer is called =91Ti=92. However=
, the default value for that SHOULD be 39,5 seconds =96 which is quite diff=
erent from 500ms.

But, still, is there a reason we couldn=92t use =91Ti=92 also in 5245bis, a=
nd point out the big value difference when used with ICE?

Regards,

Christer

--_000_D6B9E77B2BA3Dchristerholmbergericssoncom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi,
















>=
;> But, still, is there a reason we couldn=92t use =91Ti=92 also in 5245=
bis, and point out the big value difference when used with ICE?



>=



>Given the nearly 2=
-orders-of-magnitude difference in the time periods, I=92d be concerned tha=
t using the same name risks leaving an incorrect impression on an implement=
er who










>is famil=
iar with one protocol, but new to the other.   Different names ma=
y also improve clarity in other documents that describe how STUN and ICE wo=
rk together.









 









Fair enough. But, should we then point out that Ti isn=92t used with I=
CE?







Regards,







Christer












 















From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]


Sent: Sunday, February 25, 2018 8:00 AM

To: ice@ietf.org; 
draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org

Cc: Black, David <david.bl=
ack@emc.com>;
jri@google.com

Subject: 5245bis: STUN/TURN transaction timeout timer






 


Hi,


 


In draft-5245bis, the name of t=
he STUN/TURN transaction timeout timer is =91HTO=92.


 


As part of the IESG review, I h=
ave been asked what the =91H=92 stands for. After some digging in the mail =
archives (2016-09-14), I figured out it stands for =93handshake=94:


 


https://www.ietf.org/mail-arch=
ive/web/ice/current/msg00378.html


 


      =
=932.  A timeout for request packets, call it handshake timeout or HTO=
 which SHOULD be 2*RTT if the RTT is known and 500ms otherwise.=94


 


Now, in RFC 5389, the transacti=
on timeout timer is called =91Ti=92. However, the default value for that SH=
OULD be 39,5 seconds =96 which is quite different from 500ms.


 


But, still, is there a reason w=
e couldn=92t use =91Ti=92 also in 5245bis, and point out the big value diff=
erence when used with ICE?



 


Regards,


 


Christer













--_000_D6B9E77B2BA3Dchristerholmbergericssoncom_--


From nobody Mon Feb 26 06:54:03 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DF212D872; Mon, 26 Feb 2018 06:53:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level: 
X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=WconvkKQ; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=oyAl962M
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 DkPh4m-YZ-QW; Mon, 26 Feb 2018 06:53:51 -0800 (PST)
Received: from esa3.dell-outbound.iphmx.com (esa3.dell-outbound.iphmx.com [68.232.153.94]) (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 419DE12D82F; Mon, 26 Feb 2018 06:53:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1519656246; x=1551192246; h=from:cc:to:subject:date:message-id:references: in-reply-to:mime-version; bh=Vcjaz9uMKN/pel6IluT+ie6VtS46MF7EXc5Yo0lXXYQ=; b=WconvkKQ/uGiYG/x0Ur1GmJVjmZGj+MLC2wjgEo2NImriIdkl/glhTVn RXq8x/joiOuhg84sAPou/8OxRgYxd+PTz+bfQC2Y1MmHazdjiWl+KQ+B0 L5N0dypyFYFH76PqfllQoGIp+yKnqI/H1jPlTQFQOk4D3hku6N4CA8HBV o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2G2AAADHpRamMuZ6ERcGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJaIoEpEHAoCptpggKBFpYFgTcDGUMKI4UQAoJCVhYBAgEBAQE?= =?us-ascii?q?BAQIBAhABAQEBAQYNCwYoL4I4JAEOLxwhBgYBAQEBAQEmAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBFwI9ARICGAEBAQMBDCETHxoBDwIBCBEEAQELHQcyFAkIAQEEARIIhCR?= =?us-ascii?q?cCAEPrSiDCoVbghQBAQEBAQEBAQEBAQEBAQEBAQEBAQEVAwWGUHKBWIFlgy2DL?= =?us-ascii?q?gIBgVABASArCYMIgjSLL4YEkDMDBgKmfpJrgl0CBAIEBQIagS8kAVcNgR9wgxI?= =?us-ascii?q?JgkqCB3cBiiGBIoEXAQEB?=
X-IPAS-Result: =?us-ascii?q?A2G2AAADHpRamMuZ6ERcGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?aIoEpEHAoCptpggKBFpYFgTcDGUMKI4UQAoJCVhYBAgEBAQEBAQIBAhABAQEBA?= =?us-ascii?q?QYNCwYoL4I4JAEOLxwhBgYBAQEBAQEmAQEBAQEBAQEBAQEBAQEBAQEBFwI9ARI?= =?us-ascii?q?CGAEBAQMBDCETHxoBDwIBCBEEAQELHQcyFAkIAQEEARIIhCRcCAEPrSiDCoVbg?= =?us-ascii?q?hQBAQEBAQEBAQEBAQEBAQEBAQEBAQEVAwWGUHKBWIFlgy2DLgIBgVABASArCYM?= =?us-ascii?q?IgjSLL4YEkDMDBgKmfpJrgl0CBAIEBQIagS8kAVcNgR9wgxIJgkqCB3cBiiGBI?= =?us-ascii?q?oEXAQEB?=
Received: from esa5.dell-outbound2.iphmx.com ([68.232.153.203]) by esa3.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 08:44:06 -0600
From: "Black, David" 
Cc: "jri@google.com" , "Black, David" 
Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 20:47:54 +0600
Received: from maildlpprd53.lss.emc.com (maildlpprd53.lss.emc.com [10.106.48.157]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w1QErgDV001906 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Feb 2018 09:53:46 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com w1QErgDV001906
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1519656826; bh=eGYYDeYbsueSe/LUFa1TiFwBjTk=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=oyAl962MHK56YtDbgehoXz6rtvtYdhmUEbHFkCNt7bC9GSbz/QCtmdv7ApDaQ87jq L62PMua6qahp3CdedouYWlOn3EcdYEJ6eOcehVwWyGLu5LMAavw1+5lA6Z1I2RRJSa Tuyq4YnWQ9Uir9I6werXNhQEbk1NOtNsqw7FMKF8=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com w1QErgDV001906
Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd53.lss.emc.com (RSA Interceptor); Mon, 26 Feb 2018 09:53:21 -0500
Received: from MXHUB306.corp.emc.com (MXHUB306.corp.emc.com [10.146.3.32]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w1QErXtD025127 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 26 Feb 2018 09:53:33 -0500
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB306.corp.emc.com ([10.146.3.32]) with mapi id 14.03.0352.000; Mon, 26 Feb 2018 09:53:33 -0500
To: Christer Holmberg , "ice@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" 
Thread-Topic: 5245bis: STUN/TURN transaction timeout timer
Thread-Index: AdOuOI+oEAiBXZOTQm+Dl/LRxGi/pAA0o/rgAAMPdYAAAXfKMA==
Date: Mon, 26 Feb 2018 14:53:32 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B6C19C90C@ESESSMB109.ericsson.se>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.238.44.138]
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D2432779493630022F21MX307CL04corpem_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com
X-RSA-Classifications: public
Archived-At: 
Subject: Re: [Ice] 5245bis: STUN/TURN transaction timeout timer
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 14:53:54 -0000

--_000_CE03DB3D7B45C245BCA0D2432779493630022F21MX307CL04corpem_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

That would be a fine thing to do, Thanks, --David

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Monday, February 26, 2018 9:22 AM
To: Black, David ; ice@ietf.org; draft-ietf-ice-rfc524=
5bis@ietf.org; ice-chairs@ietf.org
Cc: jri@google.com
Subject: Re: 5245bis: STUN/TURN transaction timeout timer

Hi,

>> But, still, is there a reason we couldn't use 'Ti' also in 5245bis, and =
point out the big value difference when used with ICE?
>
>Given the nearly 2-orders-of-magnitude difference in the time periods, I'd=
 be concerned that using the same name risks leaving an incorrect impressio=
n on an implementer who
>is familiar with one protocol, but new to the other.   Different names may=
 also improve clarity in other documents that describe how STUN and ICE wor=
k together.

Fair enough. But, should we then point out that Ti isn't used with ICE?

Regards,

Christer



From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Sunday, February 25, 2018 8:00 AM
To: ice@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org
Cc: Black, David >; jri@goo=
gle.com
Subject: 5245bis: STUN/TURN transaction timeout timer

Hi,

In draft-5245bis, the name of the STUN/TURN transaction timeout timer is 'H=
TO'.

As part of the IESG review, I have been asked what the 'H' stands for. Afte=
r some digging in the mail archives (2016-09-14), I figured out it stands f=
or "handshake":

https://www.ietf.org/mail-archive/web/ice/current/msg00378.html

      "2.  A timeout for request packets, call it handshake timeout or HTO =
which SHOULD be 2*RTT if the RTT is known and 500ms otherwise."

Now, in RFC 5389, the transaction timeout timer is called 'Ti'. However, th=
e default value for that SHOULD be 39,5 seconds - which is quite different =
from 500ms.

But, still, is there a reason we couldn't use 'Ti' also in 5245bis, and poi=
nt out the big value difference when used with ICE?

Regards,

Christer

--_000_CE03DB3D7B45C245BCA0D2432779493630022F21MX307CL04corpem_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











That would be a fine thing to do,
Thanks, --David<=
/p>

 








From: Christer Holmberg [mailto:christer.holm=
berg@ericsson.com]


Sent: Monday, February 26, 2018 9:22 AM

To: Black, David <david.black@emc.com>; ice@ietf.org; draft-ie=
tf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org

Cc: jri@google.com

Subject: Re: 5245bis: STUN/TURN transaction timeout timer=







 




Hi,






&n=
bsp;








>> =
But, still, is there a reason we couldn’t use ‘Ti’ also i=
n 5245bis, and point out the big value difference when used with ICE?



> 


>Given the nearly 2=
-orders-of-magnitude difference in the time periods, I’d be concerned=
 that using the same name risks leaving an incorrect impression on an imple=
menter who









>is familiar with one protocol, but new to=
 the other.   Different names may also improve clarity in other d=
ocuments that describe how STUN and ICE work together.








 








Fair en=
ough. But, should we then point out that Ti isn’t used with ICE?=







&n=
bsp;






Regards=
,






&n=
bsp;






Christe=
r






&n=
bsp;






&n=
bsp;






 














From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]


Sent: Sunday, February 25, 2018 8:00 AM

To: ice@ietf.org; 
draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org

Cc: Black, David <david.bl=
ack@emc.com>;
jri@google.com

Subject: 5245bis: STUN/TURN transaction timeout timer






 =



Hi,


 


In draft-=
5245bis, the name of the STUN/TURN transaction timeout timer is ‘HTO&=
#8217;.


 


As part o=
f the IESG review, I have been asked what the ‘H’ stands for. A=
fter some digging in the mail archives (2016-09-14), I figured out it stand=
s for “handshake”:


 


https:=
//www.ietf.org/mail-archive/web/ice/current/msg00378.html


 


 &nb=
sp;    “2.  A timeout for request packets, call i=
t handshake timeout or HTO which SHOULD be 2*RTT if the RTT is known and 50=
0ms otherwise.”<=
/p>

 


Now, in R=
FC 5389, the transaction timeout timer is called ‘Ti’. However,=
 the default value for that SHOULD be 39,5 seconds – which is quite d=
ifferent from 500ms.

 


But, stil=
l, is there a reason we couldn’t use ‘Ti’ also in 5245bis=
, and point out the big value difference when used with ICE?



 


Regards,<=
/span>


 


Christer<=
/span>














--_000_CE03DB3D7B45C245BCA0D2432779493630022F21MX307CL04corpem_--


From nobody Mon Feb 26 07:48:33 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF16127137 for ; Mon, 26 Feb 2018 07:48:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDT42LfAf9FB for ; Mon, 26 Feb 2018 07:48:29 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 15119126FB3 for ; Mon, 26 Feb 2018 07:48:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519660105; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pvanQFex8Kt0X9Zc9+nBsmXiruxTP3a4weFjVSMq7tw=; b=gDiPPzPLlgeSV2zPgSqbOr65z6lkHVluNIfRQG8mRWLVhmWWTLLVbPZIk5OQJiT5 /emHo2TkK5PG7N7JYbM3mSl/DVLr9BxS2M7FwrDfx35jULLI8dcqeQrgDj7DipZa AfWk7BVBH9HBCpMp3wBV2tq6rmnkUh+rGvVOWlzFQ8E=;
X-AuditID: c1b4fb3a-347ff700000067b4-42-5a942c49e8ee
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 85.ED.26548.94C249A5; Mon, 26 Feb 2018 16:48:25 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Mon, 26 Feb 2018 16:48:24 +0100
From: Christer Holmberg 
To: "Black, David" , "ice@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" 
CC: "jri@google.com" 
Thread-Topic: 5245bis: STUN/TURN transaction timeout timer
Thread-Index: AdOuOI+oEAiBXZOTQm+Dl/LRxGi/pAA0o/rgAAMPdYAAAXfKMAACL39Q
Date: Mon, 26 Feb 2018 15:48:24 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1A8CC5@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C19C90C@ESESSMB109.ericsson.se>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.170]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C1A8CC5ESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyM2K7ja6nzpQog5tnZCw+zlrMYjH/5HVm i4uzJrNZfLtQazHp6EIWB1aPSTNnMHss2FTqsWTJT6YA5igum5TUnMyy1CJ9uwSujKdnupkK ntdWTFt1kL2BcUVBFyMnh4SAicTEI22MXYxcHEIChxklrrdsZINwFjNK3D32nrmLkYODTcBC ovufNkhcROAIo8T01XfZQbqZBVQlFhxewQpiCwtYSnRePswGUi8iYCUxdYMAhOkmsficOkgF C1B1+8zfLCA2r4CvxJwVM6D2tjNJTLzRANbKKeAn8bbBAqSGUUBM4vupNUwQm8Qlbj2ZzwRx s4DEkj3nmSFsUYmXj/+xQthKEmc2PWeBqM+XeLD/IyPELkGJkzOfsExgFJmFZNQsJGWzkJRB xHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYyixanFxbnpRkZ6qUWZycXF+Xl6eaklmxiB kXdwy2+rHYwHnzseYhTgYFTi4XWWmhIlxJpYVlyZe4hRgoNZSYR35eLJUUK8KYmVValF+fFF pTmpxYcYpTlYlMR5ndIsooQE0hNLUrNTUwtSi2CyTBycUg2McXPXfg3f8WhyyuQnayb/vNIk r3LU5esSBXaGQ7m9SdlanMdvx26Q8SvVCpD4OlNzi2u9/fZbaZOEWerNQ4R9fKd9OfWraqXQ /YIJ8VJLIrXXpy3aH+YrVhK16bRYauvr2PPaAhl5WjphKeeaHpq9nnBTIdLhp5jt7Kgy/7kW myfyzjsRdUBViaU4I9FQi7moOBEAkkaChLgCAAA=
Archived-At: 
Subject: Re: [Ice] 5245bis: STUN/TURN transaction timeout timer
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 15:48:31 -0000

--_000_7594FB04B1934943A5C02806D1A2204B6C1A8CC5ESESSMB109erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Maybe adding the following note to the existing Timer HTO definition:

Timer HTO:  The timeout timer for a given STUN or TURN transaction.

  "NOTE: When STUN and TURN are used with ICE, timer HTO is used instead of=
 timer Ti [RFC5389] as transaction timeout timer."

Regards,

Christer

From: Black, David [mailto:David.Black@dell.com]
Sent: 26 February 2018 16:54
To: Christer Holmberg ; ice@ietf.org; draft=
-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org
Cc: jri@google.com; Black, David 
Subject: RE: 5245bis: STUN/TURN transaction timeout timer

That would be a fine thing to do, Thanks, --David

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Monday, February 26, 2018 9:22 AM
To: Black, David >; ice@iet=
f.org; draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org
Cc: jri@google.com
Subject: Re: 5245bis: STUN/TURN transaction timeout timer

Hi,

>> But, still, is there a reason we couldn't use 'Ti' also in 5245bis, and =
point out the big value difference when used with ICE?
>
>Given the nearly 2-orders-of-magnitude difference in the time periods, I'd=
 be concerned that using the same name risks leaving an incorrect impressio=
n on an implementer who
>is familiar with one protocol, but new to the other.   Different names may=
 also improve clarity in other documents that describe how STUN and ICE wor=
k together.

Fair enough. But, should we then point out that Ti isn't used with ICE?

Regards,

Christer



From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Sunday, February 25, 2018 8:00 AM
To: ice@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org
Cc: Black, David >; jri@goo=
gle.com
Subject: 5245bis: STUN/TURN transaction timeout timer

Hi,

In draft-5245bis, the name of the STUN/TURN transaction timeout timer is 'H=
TO'.

As part of the IESG review, I have been asked what the 'H' stands for. Afte=
r some digging in the mail archives (2016-09-14), I figured out it stands f=
or "handshake":

https://www.ietf.org/mail-archive/web/ice/current/msg00378.html

      "2.  A timeout for request packets, call it handshake timeout or HTO =
which SHOULD be 2*RTT if the RTT is known and 500ms otherwise."

Now, in RFC 5389, the transaction timeout timer is called 'Ti'. However, th=
e default value for that SHOULD be 39,5 seconds - which is quite different =
from 500ms.

But, still, is there a reason we couldn't use 'Ti' also in 5245bis, and poi=
nt out the big value difference when used with ICE?

Regards,

Christer

--_000_7594FB04B1934943A5C02806D1A2204B6C1A8CC5ESESSMB109erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


Maybe adding the following note to the existing Timer HTO definition:<=
o:p>


 


Timer HTO:  The timeout timer for a given STUN or TURN transactio=
n.


 


  “NOTE: When STUN and TURN are used with ICE, timer HTO is=
 used instead of timer Ti [RFC5389] as transaction timeout timer.”


 


Regards,


 


Christer



 






From: Black, David [mailto:David.Black@dell.com]


Sent: 26 February 2018 16:54

To: Christer Holmberg <christer.holmberg@ericsson.com>; ice@ie=
tf.org; draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org

Cc: jri@google.com; Black, David <David.Black@dell.com>

Subject: RE: 5245bis: STUN/TURN transaction timeout timer=







 


That wo=
uld be a fine thing to do, Thanks, --David


&n=
bsp;








From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]


Sent: Monday, February 26, 2018 9:22 AM

To: Black, David <david.bl=
ack@emc.com>;
ice@ietf.org; 
draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org

Cc: jri@google.com

Subject: Re: 5245bis: STUN/TURN transaction timeout timer=







 




Hi,






 








>> But, still, is =
there a reason we couldn’t use ‘Ti’ also in 5245bis, and =
point out the big value difference when used with ICE?



> 


>Giv=
en the nearly 2-orders-of-magnitude difference in the time periods, I’=
;d be concerned that using the same name risks leaving an incorrect impress=
ion on an implementer who









>is familiar=
 with one protocol, but new to the other.   Different names may a=
lso improve clarity in other documents that describe how
 STUN and ICE work together.








 <=
/span>








Fair enough. But, should we then point out that Ti isn’t used=
 with ICE?






 






Regards,






 






Christer






 






 






 <=
/span>














From:<=
/span> Christer Holmberg [mailto:christer.holmberg@er=
icsson.com]


Sent: Sunday, February 25, 2018 8:00 AM

To: ice@ietf.org; 
draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org

Cc: Black, David <david.bl=
ack@emc.com>;
jri@google.com

Subject: 5245bis: STUN/TURN transaction timeout timer






 


Hi,


 


In draft-5245bis, the na=
me of the STUN/TURN transaction timeout timer is ‘HTO’.<=
span lang=3D"EN-US" style=3D"color:black">


 


As part of the IESG revi=
ew, I have been asked what the ‘H’ stands for. After some diggi=
ng in the mail archives (2016-09-14), I figured out it stands for “ha=
ndshake”:


 


https://www.ietf.org/ma=
il-archive/web/ice/current/msg00378.html


 


    =
  “2.  A timeout for request packets, call it handshake tim=
eout or HTO which SHOULD be 2*RTT if the RTT is known and 500ms otherwise.&=
#8221;<=
/p>

 


Now, in RFC 5389, the tr=
ansaction timeout timer is called ‘Ti’. However, the default va=
lue for that SHOULD be 39,5 seconds – which is quite different from 5=
00ms.

 


But, still, is there a r=
eason we couldn’t use ‘Ti’ also in 5245bis, and point out=
 the big value difference when used with ICE?



 


Regards,


 


Christer














--_000_7594FB04B1934943A5C02806D1A2204B6C1A8CC5ESESSMB109erics_--


From nobody Mon Feb 26 11:45:03 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307DD127369; Mon, 26 Feb 2018 11:45:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 l5scTdu64a_9; Mon, 26 Feb 2018 11:44:57 -0800 (PST)
Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::235]) (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 4C10312711A; Mon, 26 Feb 2018 11:44:57 -0800 (PST)
Received: by mail-ot0-x235.google.com with SMTP id g97so1331494otg.13; Mon, 26 Feb 2018 11:44:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=efNgdqQpbCAaxZZa45417095sxDX5Gb4wFUU1iLLzlU=; b=cnzCtS/6TZmBugQLHijLeGRg8hwmAHDsOrt9V3z89A9RrV34NIgkTQK5jFijluVOgO 6oeY/FD1m8DGX7PnVSVWUubi/oQ7MIbQCHtlJ8vuV+EYoaqe4mX+hWmiacYokWfyTUiz 0r+bnk5X1IRc71ldpLuA04Ubh7atRJu5Ii6yBtqmSoljOvNwT4seyBjHvs4CdOdVL4sN qM65b/CHQ/MklFenP82/ouAISc8uM6pKV9UKXExmsPBpxHSkSf5ElHCVnLO1MJ2n4f7D ZpiSAbNbwQkXGuOOFs+a3afAvzIPCrHHIt/Gj2RcpIcy9ZPtp+l7eWTmQHWINiuHpU8V cxBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=efNgdqQpbCAaxZZa45417095sxDX5Gb4wFUU1iLLzlU=; b=lhZdYPGwQoc/MpkHaTYGeilPtO00cQp4Uuzf9eRsQqso+6iBHmfvU/Dsere0WeRlvP U0vyanFPBqFDDcTsn7zRTJkMYlIIi0p+/cSzAglMrXc07mlGVqVgYRcu/DMl3Ke8WwEl G2fdGAN80+Zh7Cnah7S9HaujpOfngJ3CO6okPjZJSWBXVFDDjy5zWfCs/fN1hNuJiqr+ mtirnT2B83BKosXpPGDM4Y7U//nmnC3t2fsgdr5j9iXo5cjkUz1D8EZ8INJUs9tBurYm 9rYLX6bwJ4juBmxpVdF1l4pgEvAvzX3cn4zW9oKUp72RrGH/3PMiqjAdkanL0kv0vIGe ax7Q==
X-Gm-Message-State: APf1xPCXH1YkBlK4XFdIu/8KYA7syxI+nbzWeZNdgVXQMdhpbVroBNTC msz+njmpARiCCenqkXrwan1Qa1WxTj8R2iEafog=
X-Google-Smtp-Source: AG47ELvxyLDqUbnbo946/yKFt1FNx/iduBbuQc7jueOKV9C1Wh/1TcowvawOY6iLrqNEtCcBNyKudgLH6Ex3FRMv8vg=
X-Received: by 10.202.235.12 with SMTP id j12mr7309609oih.284.1519674296264; Mon, 26 Feb 2018 11:44:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.74.3.71 with HTTP; Mon, 26 Feb 2018 11:44:25 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C19C590@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C19C590@ESESSMB109.ericsson.se>
From: Ted Hardie 
Date: Mon, 26 Feb 2018 11:44:25 -0800
Message-ID: 
To: Christer Holmberg 
Cc: "ice@ietf.org" , Ben Campbell ,  "ice-chairs@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113cc70c9a81a3056622be06"
Archived-At: 
Subject: Re: [Ice] ICE change in role conflict ([was: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) - Role conflict issue)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 19:45:01 -0000

--001a113cc70c9a81a3056622be06
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Christer,

On Sun, Feb 25, 2018 at 2:08 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
>
>
> I ask the community to take a look at the suggested change below, and
> indicate whether you have any issues.
>
>
>
> *NUTSHELL:*
>
>
>
> *What=E2=80=99s the problem?*
>
>
>
> In case both agents assume the same role (might happen in certain 3PCC
> scenarios), AND use the same tie-breaker value (unlikely to happen, but
> possible in theory), which may cause both endpoints to send a 487 respons=
e.
>
>
>
> The 487 response will cause both endpoints and change their roles, and tr=
y
> again. But, unless they also change the tie-breaker value, the result wil=
l
> be the same: both will assume the same role (since both received 487), an=
d
> might use the same tie-breaker values.
>
>
>
>
>
> *What=E2=80=99s the solution?*
>
>
>
> Specify that, when an endpoint receives 487, and changes its role, it MUS=
T
> also change the tie-breaker value. That way, when both endpoints again tr=
y,
> unless the endpoints again choose the same tie-breaker value (even more
> unlikely) only one should send a 487, and the role conflict will be solve=
d.
>
>
>

So, I propose something even simpler.  In the very rare case that the peers
see that the tie-breaker values are the same, both sides should restart
ICE.  Restarting ICE results in new tie-breaker values being selected in
any case.

My logic here is this:  this occurs pretty rarely to start with,
essentially only in the case of third-party call control.  In that subset
of cases, the two sides have to select the same value out of a 4-billion
odd range.   So, at least hopefully, this is not a common occurrence.  Code
covering uncommon occurrences tends to bit rot.  Using "re-start ICE" means
re-using code that will be maintained for other reasons, where re-start
with a new tie-breaker value will not be.

I am willing to accept your current solution, though, if other folks are
not concerned about the complexity.

Ted




>
>
> *What if I don=E2=80=99t like the suggested solution?*
>
>
>
> Suggest something better (read: provide actual text
> change/removal/additions).
>
>
>
>
>
> *DETAILS:*
>
>
>
> Please see discussion thread below.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> *From:* Eric Rescorla [mailto:ekr@rtfm.com]
> *Sent:* 24 February 2018 22:53
> *To:* Christer Holmberg 
> *Cc:* Taylor Brandstetter ; Ben Campbell <
> ben@nostrum.com>; ice-chairs@ietf.org; ice@ietf.org;
> draft-ietf-ice-rfc5245bis@ietf.org; pthatcher@google.com; The IESG <
> iesg@ietf.org>
> *Subject:* Re: [Ice] Eric Rescorla's No Objection on
> draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security
> Considerations) - Role conflict issue
>
>
>
>
>
>
>
> On Sat, Feb 24, 2018 at 12:37 PM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> Hi,
>
>
>
> I had a closer look at the role conflict issue.
>
>
>
> First, the draft already covers the case when the tie-breaker values are
> identical. It is described in section 7.3.1.1:
>
>
>
>    =E2=80=9CIf the agent's tie-breaker value is larger than *or equal to*=
=E2=80=A6=E2=80=9D
>
>
>
> Yes. My point is that this is broken.
>
>
>
>
>
>
>
> =E2=80=A6the agent sends 487.
>
>
>
> Then, according to section 7.2.5.1., when an agent receives the 487
> response it will change its role.
>
>
>
> Now, if BOTH agents send 487, it means BOTH agents will switch their
> roles, and try again. Now, since both agents switch their role, and keep
> the same tie-breaker value, the result will again be the same (only with
> different roles).
>
>
>
> Yes, so they oscillate back and forth.
>
>
>
>
>
>
>
> Section 7.2.5.1:
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
>
> OLD:
>
>
>
> Once the agent has switched its role, the agent MUST add the
>
> candidate pair whose check generated the 487 error response to the
>
> triggered check queue associated with the check list to which the
>
> pair belongs, and set the candidate pair state to Waiting.  When the
>
> triggered connectivity check is later performed, the ICE-CONTROLLING/
>
> ICE-CONTROLLED attribute of the Binding request will indicate the
>
> agent's new role.  The agent *MAY* change the tie-breaker value.
>
>
>
>
>
> NEW:
>
>
>
> Once the agent has switched its role, the agent MUST add the
>
> candidate pair whose check generated the 487 error response to the
>
> triggered check queue associated with the check list to which the
>
> pair belongs, and set the candidate pair state to Waiting.  When the
>
> triggered connectivity check is later performed, the ICE-CONTROLLING/
>
> ICE-CONTROLLED attribute of the Binding request will indicate the
>
> agent's new role.  The agent *MUST* change the tie-breaker value.
>
>
>
>
>
> Section 16.1:
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
>
> OLD:
>
>
>
> An ICE agent MUST use the same number for all
>
> Binding requests, for all streams, within an ICE session. The agent
>
> MAY change the number when an ICE restart occurs.
>
>
>
> NEW:
>
>
>
> An ICE agent MUST use the same number for all
>
> Binding requests, for all streams, within an ICE session*, unless *
>
> *it receives a 487 response, in which case it MUST change the*
>
> *number (Section 7.2.5.1).* The agent MAY change the number when
>
> an ICE restart occurs.
>
>
>
> Problem solved? :)
>
>
>
> This would be fine with me, but presumably needs WG signoff.
>
>
>
> -Ekr
>
>
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> *From:* Eric Rescorla [mailto:ekr@rtfm.com]
> *Sent:* 21 February 2018 01:07
> *To:* Taylor Brandstetter 
> *Cc:* Christer Holmberg ; Ben Campbell <
> ben@nostrum.com>; ice-chairs@ietf.org; ice@ietf.org;
> draft-ietf-ice-rfc5245bis@ietf.org; pthatcher@google.com; The IESG <
> iesg@ietf.org>
> *Subject:* Re: [Ice] Eric Rescorla's No Objection on
> draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security
> Considerations)
>
>
>
> I wouldn't object if someone produced a principled fix. I just don't want
> to create a lot of work for people
>
>
>
>
>
> On Tue, Feb 20, 2018 at 2:51 PM, Taylor Brandstetter 
> wrote:
>
> The tie-breaker collision problem has come up a few times before,
> actually. As I've said, I believe it could be fixed very easily by saying
> "pick a new tie-breaker if this happens."
>
>
>
> As for the "MUST not change tie-breaker" rule in section 16.1, requiring
> an ICE restart is overkill. We can just change it to "MUST not change
> tie-breaker* unless there's a collision*."
>
>
>
> On Mon, Feb 19, 2018 at 10:33 AM, Eric Rescorla  wrote:
>
>
>
>
>
> On Mon, Feb 19, 2018 at 10:29 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> Hi,
>
> ...
>
> >>>> IF we really want to solve this, one simple solution be to say that,
> if this happens, and endpoint simply calculates a
> >>>> new tie-breaker value, and tries again? BUT, then we would have to
> change section 16.1, which says that a new value can only be calculated a=
t
> an ICE restart.
> >>>>
> >>>> So, could we simply say that, if this happens, the agent MUST do an
> ICE restart, and it MUST calculate a new tie-breaker value?
> >>>
> >>> Now both sides might do a simultaneous restart. Is that going to work=
?
> >>
> >> We could say that the initiating agent MUST do the restart.
> >
> > In this scenario, don't both sides believe they are the initiating peer=
,
> hence the need for the tiebreaker?
>
> Probably...
>
> But, then I don't see what we could do. If both agents send a check, and
> receive 487, we can't define a procedure for one of the agents.
>
> Perhaps we should then change the must-not-change-the-value-unless-restar=
t
> and say that an agent changes the tie-breaker value and try again.
>
>
>
> As you say, the problem is inherently that the situation is symmetrical.
>
>
>
> At this point in the design process, I don't think it's worth trying to
> actually make the call succeed; a 2^{-64} failure rate is much lower than
> organic call failure rates from other causes, even in non-3PCC scenarios.
> Rather, I think the spec should just prescribe a clean failure mode via a
> new error code, rather than having both sides wildly oscillate between
> controlled and controlling
>
>
>
> -Ekr
>
>
>
>
> Regards,
>
> Christer
>
>
>
>
>
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice
>
>
>
>
>
>
>
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice
>
>

--001a113cc70c9a81a3056622be06
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi Christer,

O=
n Sun, Feb 25, 2018 at 2:08 AM, Christer Holmberg <christer.h=
olmberg@ericsson.com> wrote:




Hi,


=C2=A0


I ask the community to take a look at=
 the suggested change below, and indicate whether you have any issues.


=C2=A0


NUTSHELL:=



=C2=A0


What=E2=80=99s the problem?=



=C2=A0


In case both agents assume the same r=
ole (might happen in certain 3PCC scenarios), AND use the same tie-breaker =
value (unlikely to
 happen, but possible in theory), which may cause both endpoints to send a =
487 response.


=C2=A0


The 487 response will cause both endp=
oints and change their roles, and try again. But, unless they also change t=
he tie-breaker value,
 the result will be the same: both will assume the same role (since both re=
ceived 487), and might use the same tie-breaker values.


=C2=A0


=C2=A0


What=E2=80=99s the solution?


=C2=A0


Specify that, when an endpoint receiv=
es 487, and changes its role, it MUST also change the tie-breaker value. Th=
at way, when both endpoints
 again try, unless the endpoints again choose the same tie-breaker value (e=
ven more unlikely) only one should send a 487, and the role conflict will b=
e solved.


=C2=A0
<=
/blockquote>

So, I propose something even simpler.=C2=A0 In t=
he very rare case that the peers see that the tie-breaker values are the sa=
me, both sides should restart ICE.=C2=A0 Restarting ICE results in new tie-=
breaker values being selected in any case.

My logic here =
is this:=C2=A0 this occurs pretty rarely to start with, essentially only in=
 the case of third-party call control.=C2=A0 In that subset of cases, the t=
wo sides have to select the same value out of a 4-billion odd range. =C2=A0=
 So, at least hopefully, this is not a common occurrence.=C2=A0 Code coveri=
ng uncommon occurrences tends to bit rot.=C2=A0 Using "re-start ICE&qu=
ot; means re-using code that will be maintained for other reasons, where re=
-start with a new tie-breaker value will not be.

I am wil=
ling to accept your current solution, though, if other folks are not concer=
ned about the complexity.

Ted


=C2=A0


=C2=A0


What if I don=E2=80=99t like the s=
uggested solution?


=C2=A0


Suggest something better (read: provi=
de actual text change/removal/additions).


=C2=A0


=C2=A0


DETAILS:<=
/p>

=C2=A0


Please see discussion thread below.


=C2=A0


Regards,


=C2=A0


Christer


=C2=A0


=C2=A0


<=
span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c=
olor:#1f497d">=C2=A0


From: =
Eric Rescorla [mailto:ekr=
@rtfm.com]


Sent: 24 February 2018 22:53

To: Christer Holmberg <christer.holmberg@ericsson.com>

Cc: Taylor Brandstetter <deadbeef@google.com>; Ben Campbell <ben@nostrum.com>; ice-chairs@ietf.org; =
ice@ietf.org; draft-ietf=
-ice-rfc5245bis@ietf.org; pthatcher@google.com; The IESG <iesg@ietf.org>

Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ic=
e-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) - Role =
conflict issue


=C2=A0




=C2=A0




=C2=A0




On Sat, Feb 24, 2018 at 12:37 PM, Christer Holmberg =
<chr=
ister.holmberg@ericsson.com> wrote:








Hi,


=C2=A0


I had a closer look at the role confl=
ict issue.


=C2=A0


First, the draft already covers the c=
ase when the tie-breaker values are identical. It is described
 in section 7.3.1.1:


=C2=A0


=C2=A0=C2=A0 =E2=80=9CIf the agent=
9;s tie-breaker value is larger than
or equal to=E2=80=A6=E2=80=9D










=C2=A0






Yes. My point is that this is broken.<=
/p>





=C2=A0






=C2=A0










=C2=A0


=E2=80=A6the agent sends 487.



=C2=A0


Then, according to section 7.2.5.1., =
when an agent receives the 487 response it will change its role.<=
/u>


=C2=A0


Now, if BOTH agents send 487, it mean=
s BOTH agents will switch their roles, and try again. Now, since
 both agents switch their role, and keep the same tie-breaker value, the re=
sult will again be the same (only with different roles).










=C2=A0






Yes, so they oscillate back and forth.=







=C2=A0






=C2=A0






=C2=A0










Section
7.2.5.1:<=
/u>


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D


=C2=A0


OLD:


=C2=A0


Once the agent has switched its role,=
 the agent MUST add the


candidate pair whose check generated =
the 487 error response to the


triggered check queue associated with=
 the check list to which the


pair belongs, and set the candidate p=
air state to Waiting.=C2=A0 When the


triggered connectivity check is later=
 performed, the ICE-CONTROLLING/


ICE-CONTROLLED attribute of the Bindi=
ng request will indicate the


agent's new role.=C2=A0 The agent
MAY change the tie-breaker value.


=C2=A0


=C2=A0


NEW:


=C2=A0


Once the agent has switched its role,=
 the agent MUST add the


candidate pair whose check generated =
the 487 error response to the


triggered check queue associated with=
 the check list to which the


pair belongs, and set the candidate p=
air state to Waiting.=C2=A0 When the


triggered connectivity check is later=
 performed, the ICE-CONTROLLING/


ICE-CONTROLLED attribute of the Bindi=
ng request will indicate the


agent's new role.=C2=A0 The agent
MUST change the tie-breaker value.


=C2=A0


=C2=A0


Section 16.1:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


=C2=A0


OLD:


=C2=A0


An ICE agent MUST use the same number=
 for all


Binding requests, for all streams, wi=
thin an ICE session. The agent


MAY change the number when an ICE res=
tart occurs.


=C2=A0


NEW:


=C2=A0


An ICE agent MUST use the same number=
 for all


Binding requests, for all streams, wi=
thin an ICE session, unless



it receives a 487 response, in whi=
ch case it MUST change the


number (Section 7.2.5.1).
 The agent MAY change the number when 


an ICE restart occurs.<=
u>


=C2=A0


Problem solved? :)










=C2=A0






This would be fine with me, but presumably needs WG =
signoff.






=C2=A0






-Ekr






=C2=A0










=C2=A0


Regards,


=C2=A0


Christer


=C2=A0


=C2=A0


=C2=A0


From: =
Eric
 Rescorla [mailto:ekr@rtf=
m.com]


Sent: 21 February 2018 01:07

To: Taylor Brandstetter <deadbeef@google.com>

Cc: Christer Holmberg <christer.holmberg@ericsson.com>; Ben =
Campbell <ben@nostr=
um.com>;
ice-chairs@ietf.or=
g; 
ice@ietf.org; 
draft-ietf-ice-rfc5245bis@ietf.org; 
pthatcher@google.com; The IESG <iesg@ietf.org>

Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ic=
e-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)<=
u>


=C2=A0


I wouldn't object if someone produced a principl=
ed fix. I just don't want to create a lot of work for people<=
/u>


=C2=A0=C2=A0


=C2=A0




On Tue, Feb 20, 2018 at 2:51 PM, Taylor Brandstetter=
 <deadbeef@goog=
le.com> wrote:






The tie-breaker collision problem has c=
ome up a few times before, actually. As I've said, I believe=C2=A0it
 could be fixed very easily by saying "pick a new tie-breaker if this =
happens."




=C2=A0






As for the "MUST not change tie-breaker" r=
ule in section 16.1, requiring an ICE restart is overkill. We can just chan=
ge it to "MUST not change tie-breaker unless there's a collisio=
n."








=C2=A0








On Mon, Feb 19, 2018 at 10:33 AM, Eric Rescorla <=
ekr@rtfm.com> wrot=
e:














=C2=A0




=C2=A0




On Mon, Feb 19, 2018 at 10:29 AM, Christer Holmberg =
<chr=
ister.holmberg@ericsson.com> wrote:




Hi,



...



>>>> IF we really want to solve this, one simple solution be to=
 say that, if this happens, and endpoint simply calculates a

>>>> new tie-breaker value, and tries again? BUT, then we would=
 have to change section 16.1, which says that a new value can only be calcu=
lated at an ICE restart.

>>>>

>>>> So, could we simply say that, if this happens, the agent M=
UST do an ICE restart, and it MUST calculate a new tie-breaker value?

>>>

>>> Now both sides might do a simultaneous restart. Is that going =
to work?

>>

>> We could say that the initiating agent MUST do the restart.

>

> In this scenario, don't both sides believe they are the initiating=
 peer, hence the need for the tiebreaker?



Probably...



But, then I don't see what we could do. If both agents send a check, an=
d receive 487, we can't define a procedure for one of the agents.



Perhaps we should then change the must-not-change-the-value-unless-res=
tart and say that an agent changes the tie-breaker value and try again.<=
/u>






=C2=A0






As you say, the problem is inherently that the situa=
tion is symmetrical.






=C2=A0






At this point in the design process, I don't thi=
nk it's worth trying to actually make the call succeed; a 2^{-64} failu=
re rate is much lower than organic call failure rates from
 other causes, even in non-3PCC scenarios. Rather, I think the spec should =
just prescribe a clean failure mode via a new error code, rather than havin=
g both sides wildly oscillate between controlled and controlling<=
/u>






=C2=A0






-Ekr






=C2=A0








Regards,



Christer






=C2=A0






=C2=A0






_____________________=
__________________________

Ice mailing list

Ice@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/ice






=C2=A0














=C2=A0
















=C2=A0











_______________________________________________

Ice mailing list

Ice@ietf.org

https://www.ietf.org/mailman/listinfo/ice





--001a113cc70c9a81a3056622be06--


From nobody Mon Feb 26 11:59:23 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F91126CC7 for ; Mon, 26 Feb 2018 11:59:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.319
X-Spam-Level: 
X-Spam-Status: No, score=-4.319 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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kv7eyE96Enir for ; Mon, 26 Feb 2018 11:59:18 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28DFA1242EA for ; Mon, 26 Feb 2018 11:59:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519675155; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jd/ZzEzQsvY8qAdYiThPd+8GswCHv9o299QD2NgK8Rs=; b=Hc8u7HGtzCPrPTSCsnoZoe+d9DigFdGKpbfHUYUG1rGCKZQWbgaxJkqrpA5GIOU3 IFfolBsl1pW4Jc8c8zE0Cw4VO6JvjvdNSlnWjzHIQTcku53WL2WMk8rbabY7VIIi W1S4TeFLGDBPSz71ZnWkN/K5pmFvNQWI3mTG8XVtPhc=;
X-AuditID: c1b4fb25-083ff70000002d5f-03-5a946713eafa
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0A.E0.11615.317649A5; Mon, 26 Feb 2018 20:59:15 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Mon, 26 Feb 2018 20:59:14 +0100
From: Christer Holmberg 
To: Ted Hardie 
CC: "ice@ietf.org" , Ben Campbell , "ice-chairs@ietf.org" 
Thread-Topic: [Ice] ICE change in role conflict ([was: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) - Role conflict issue)
Thread-Index: AdOuH3YziFMqGJv8S0OuiisPdqGWggBElyuAAAJtsRA=
Date: Mon, 26 Feb 2018 19:59:14 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1ABB3E@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C19C590@ESESSMB109.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.170]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C1ABB3EESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUyM2K7sa5w+pQog3UfZSzmd55mt7g4azKb xbcLtRaNc+0cWDx2zrrL7rFkyU8mj1k7n7AEMEdx2aSk5mSWpRbp2yVwZdyY1slY8GQNS8XP nXuYGhjXzGPpYuTkkBAwkfh46hhrFyMXh5DAYUaJMx03GCGcxYwSG37MAnI4ONgELCS6/2mD NIgIKEvsvbKDDcRmFiiQ2Pp3IRtIvbDAQUaJo3tbmCGKDjFK/DvCDmFbSfw+twJsG4uAqsS1 jfeYQGxeAV+JtklTWCCWTQFq/r+YESTBKRAoMatvJyuIzSggJvH91BomiG3iEreezGeCOFtA Ysme88wQtqjEy8f/WCFsJYkzm56zQNTnSzSsuswIsUxQ4uTMJywTGEVmIRk1C0nZLCRls4B+ ZhbQlFi/Sx+iRFFiSvdDdghbQ6J1zlx2ZPEFjOyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2 MQLj7uCW36o7GC+/cTzEKMDBqMTDK+M1JUqINbGsuDIXGFAczEoivCsXT44S4k1JrKxKLcqP LyrNSS0+xCjNwaIkzjtHuD1KSCA9sSQ1OzW1ILUIJsvEwSnVwCi/v6tx7b68UF+RL+cTFnxY vFlP/uMSqbnXN3XXHX+qFaLedSB2kcLMv5b7O7eLy3+cMa/72+blIsFzIm1z085uvFVdVsw6 UVttVezc6akxPSwNT+bvn9G27PoEITcur9wZCv5cHd4La3Z8Ll/NcO5UXNHK9bEGIumP/jr2 lIft8v39W5fbeLISS3FGoqEWc1FxIgD9XD1UtwIAAA==
Archived-At: 
Subject: Re: [Ice] ICE change in role conflict ([was: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) - Role conflict issue)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 19:59:22 -0000

--_000_7594FB04B1934943A5C02806D1A2204B6C1ABB3EESESSMB109erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgVGVkLA0KDQpJQ0UgcmUtc3RhcnQgd2FzIHN1Z2dlc3RlZCBlYXJsaWVyLCBidXQgcGVvcGxl
IGRpZG7igJl0IGxpa2UgaXQuDQoNCkkgZG9u4oCZdCB0aGluayB0aGUgc29sdXRpb24gYWRkcyB2
ZXJ5IG11Y2ggY29tcGxleGl0eS4gSXTigJlzIG1vcmUgb3IgbGVzcyBzdXBwb3J0ZWQgYWxyZWFk
eSwgdGhlIG9ubHkgZGlmZmVyZW5jZSBpcyB0aGF0IHdlIGNoYW5nZSDigJxNQVkgcGljayBhIG5l
dyB0aWUtYnJlYWtlciB2YWx1ZeKAnSB0byDigJxNVVNUIHBpY2sgYSBuZXcgdGllLWJyZWFrZXIg
dmFsdWXigJ0uDQoNCkFuZCwgZXZlbiBpZiBvbmx5IG9uZSBvZiB0aGUgZW5kcG9pbnRzIGFjdHVh
bGx5IGRvIHBpY2sgYSBuZXcgdmFsdWUsIGFuZCB0aGUgb3RoZXIga2VlcHMgdGhlIG9sZCB2YWx1
ZSwgdGhpbmdzIHdpbGwgc3RpbGwgd29yayA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpG
cm9tOiBUZWQgSGFyZGllIFttYWlsdG86dGVkLmlldGZAZ21haWwuY29tXQ0KU2VudDogMjYgRmVi
cnVhcnkgMjAxOCAyMTo0NA0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVy
Z0Blcmljc3Nvbi5jb20+DQpDYzogaWNlQGlldGYub3JnOyBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0
cnVtLmNvbT47IGljZS1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbSWNlXSBJQ0UgY2hh
bmdlIGluIHJvbGUgY29uZmxpY3QgKFt3YXM6IEVyaWMgUmVzY29ybGEncyBObyBPYmplY3Rpb24g
b24gZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpcy0xNzogKHdpdGggQ09NTUVOVCkgKGV4Y2x1ZGlu
ZyBTZWN1cml0eSBDb25zaWRlcmF0aW9ucykgLSBSb2xlIGNvbmZsaWN0IGlzc3VlKQ0KDQpIaSBD
aHJpc3RlciwNCg0KT24gU3VuLCBGZWIgMjUsIDIwMTggYXQgMjowOCBBTSwgQ2hyaXN0ZXIgSG9s
bWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9s
bWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KSSBhc2sgdGhlIGNvbW11bml0eSB0
byB0YWtlIGEgbG9vayBhdCB0aGUgc3VnZ2VzdGVkIGNoYW5nZSBiZWxvdywgYW5kIGluZGljYXRl
IHdoZXRoZXIgeW91IGhhdmUgYW55IGlzc3Vlcy4NCg0KTlVUU0hFTEw6DQoNCldoYXTigJlzIHRo
ZSBwcm9ibGVtPw0KDQpJbiBjYXNlIGJvdGggYWdlbnRzIGFzc3VtZSB0aGUgc2FtZSByb2xlICht
aWdodCBoYXBwZW4gaW4gY2VydGFpbiAzUENDIHNjZW5hcmlvcyksIEFORCB1c2UgdGhlIHNhbWUg
dGllLWJyZWFrZXIgdmFsdWUgKHVubGlrZWx5IHRvIGhhcHBlbiwgYnV0IHBvc3NpYmxlIGluIHRo
ZW9yeSksIHdoaWNoIG1heSBjYXVzZSBib3RoIGVuZHBvaW50cyB0byBzZW5kIGEgNDg3IHJlc3Bv
bnNlLg0KDQpUaGUgNDg3IHJlc3BvbnNlIHdpbGwgY2F1c2UgYm90aCBlbmRwb2ludHMgYW5kIGNo
YW5nZSB0aGVpciByb2xlcywgYW5kIHRyeSBhZ2Fpbi4gQnV0LCB1bmxlc3MgdGhleSBhbHNvIGNo
YW5nZSB0aGUgdGllLWJyZWFrZXIgdmFsdWUsIHRoZSByZXN1bHQgd2lsbCBiZSB0aGUgc2FtZTog
Ym90aCB3aWxsIGFzc3VtZSB0aGUgc2FtZSByb2xlIChzaW5jZSBib3RoIHJlY2VpdmVkIDQ4Nyks
IGFuZCBtaWdodCB1c2UgdGhlIHNhbWUgdGllLWJyZWFrZXIgdmFsdWVzLg0KDQoNCldoYXTigJlz
IHRoZSBzb2x1dGlvbj8NCg0KU3BlY2lmeSB0aGF0LCB3aGVuIGFuIGVuZHBvaW50IHJlY2VpdmVz
IDQ4NywgYW5kIGNoYW5nZXMgaXRzIHJvbGUsIGl0IE1VU1QgYWxzbyBjaGFuZ2UgdGhlIHRpZS1i
cmVha2VyIHZhbHVlLiBUaGF0IHdheSwgd2hlbiBib3RoIGVuZHBvaW50cyBhZ2FpbiB0cnksIHVu
bGVzcyB0aGUgZW5kcG9pbnRzIGFnYWluIGNob29zZSB0aGUgc2FtZSB0aWUtYnJlYWtlciB2YWx1
ZSAoZXZlbiBtb3JlIHVubGlrZWx5KSBvbmx5IG9uZSBzaG91bGQgc2VuZCBhIDQ4NywgYW5kIHRo
ZSByb2xlIGNvbmZsaWN0IHdpbGwgYmUgc29sdmVkLg0KDQoNClNvLCBJIHByb3Bvc2Ugc29tZXRo
aW5nIGV2ZW4gc2ltcGxlci4gIEluIHRoZSB2ZXJ5IHJhcmUgY2FzZSB0aGF0IHRoZSBwZWVycyBz
ZWUgdGhhdCB0aGUgdGllLWJyZWFrZXIgdmFsdWVzIGFyZSB0aGUgc2FtZSwgYm90aCBzaWRlcyBz
aG91bGQgcmVzdGFydCBJQ0UuICBSZXN0YXJ0aW5nIElDRSByZXN1bHRzIGluIG5ldyB0aWUtYnJl
YWtlciB2YWx1ZXMgYmVpbmcgc2VsZWN0ZWQgaW4gYW55IGNhc2UuDQpNeSBsb2dpYyBoZXJlIGlz
IHRoaXM6ICB0aGlzIG9jY3VycyBwcmV0dHkgcmFyZWx5IHRvIHN0YXJ0IHdpdGgsIGVzc2VudGlh
bGx5IG9ubHkgaW4gdGhlIGNhc2Ugb2YgdGhpcmQtcGFydHkgY2FsbCBjb250cm9sLiAgSW4gdGhh
dCBzdWJzZXQgb2YgY2FzZXMsIHRoZSB0d28gc2lkZXMgaGF2ZSB0byBzZWxlY3QgdGhlIHNhbWUg
dmFsdWUgb3V0IG9mIGEgNC1iaWxsaW9uIG9kZCByYW5nZS4gICBTbywgYXQgbGVhc3QgaG9wZWZ1
bGx5LCB0aGlzIGlzIG5vdCBhIGNvbW1vbiBvY2N1cnJlbmNlLiAgQ29kZSBjb3ZlcmluZyB1bmNv
bW1vbiBvY2N1cnJlbmNlcyB0ZW5kcyB0byBiaXQgcm90LiAgVXNpbmcgInJlLXN0YXJ0IElDRSIg
bWVhbnMgcmUtdXNpbmcgY29kZSB0aGF0IHdpbGwgYmUgbWFpbnRhaW5lZCBmb3Igb3RoZXIgcmVh
c29ucywgd2hlcmUgcmUtc3RhcnQgd2l0aCBhIG5ldyB0aWUtYnJlYWtlciB2YWx1ZSB3aWxsIG5v
dCBiZS4NCkkgYW0gd2lsbGluZyB0byBhY2NlcHQgeW91ciBjdXJyZW50IHNvbHV0aW9uLCB0aG91
Z2gsIGlmIG90aGVyIGZvbGtzIGFyZSBub3QgY29uY2VybmVkIGFib3V0IHRoZSBjb21wbGV4aXR5
Lg0KVGVkDQoNCg0KDQoNCldoYXQgaWYgSSBkb27igJl0IGxpa2UgdGhlIHN1Z2dlc3RlZCBzb2x1
dGlvbj8NCg0KU3VnZ2VzdCBzb21ldGhpbmcgYmV0dGVyIChyZWFkOiBwcm92aWRlIGFjdHVhbCB0
ZXh0IGNoYW5nZS9yZW1vdmFsL2FkZGl0aW9ucykuDQoNCg0KREVUQUlMUzoNCg0KUGxlYXNlIHNl
ZSBkaXNjdXNzaW9uIHRocmVhZCBiZWxvdy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoN
CkZyb206IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZt
LmNvbT5dDQpTZW50OiAyNCBGZWJydWFyeSAyMDE4IDIyOjUzDQpUbzogQ2hyaXN0ZXIgSG9sbWJl
cmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl
cmdAZXJpY3Nzb24uY29tPj4NCkNjOiBUYXlsb3IgQnJhbmRzdGV0dGVyIDxkZWFkYmVlZkBnb29n
bGUuY29tPG1haWx0bzpkZWFkYmVlZkBnb29nbGUuY29tPj47IEJlbiBDYW1wYmVsbCA8YmVuQG5v
c3RydW0uY29tPG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+PjsgaWNlLWNoYWlyc0BpZXRmLm9yZzxt
YWlsdG86aWNlLWNoYWlyc0BpZXRmLm9yZz47IGljZUBpZXRmLm9yZzxtYWlsdG86aWNlQGlldGYu
b3JnPjsgZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpc0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0
Zi1pY2UtcmZjNTI0NWJpc0BpZXRmLm9yZz47IHB0aGF0Y2hlckBnb29nbGUuY29tPG1haWx0bzpw
dGhhdGNoZXJAZ29vZ2xlLmNvbT47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPG1haWx0bzppZXNn
QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbSWNlXSBFcmljIFJlc2NvcmxhJ3MgTm8gT2JqZWN0
aW9uIG9uIGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXMtMTc6ICh3aXRoIENPTU1FTlQpIChleGNs
dWRpbmcgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMpIC0gUm9sZSBjb25mbGljdCBpc3N1ZQ0KDQoN
Cg0KT24gU2F0LCBGZWIgMjQsIDIwMTggYXQgMTI6MzcgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxj
aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVy
aWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNCkkgaGFkIGEgY2xvc2VyIGxvb2sgYXQgdGhlIHJv
bGUgY29uZmxpY3QgaXNzdWUuDQoNCkZpcnN0LCB0aGUgZHJhZnQgYWxyZWFkeSBjb3ZlcnMgdGhl
IGNhc2Ugd2hlbiB0aGUgdGllLWJyZWFrZXIgdmFsdWVzIGFyZSBpZGVudGljYWwuIEl0IGlzIGRl
c2NyaWJlZCBpbiBzZWN0aW9uIDcuMy4xLjE8aHR0cDovLzcuMy4xLjE+Og0KDQogICDigJxJZiB0
aGUgYWdlbnQncyB0aWUtYnJlYWtlciB2YWx1ZSBpcyBsYXJnZXIgdGhhbiBvciBlcXVhbCB0b+KA
puKAnQ0KDQpZZXMuIE15IHBvaW50IGlzIHRoYXQgdGhpcyBpcyBicm9rZW4uDQoNCg0KDQrigKZ0
aGUgYWdlbnQgc2VuZHMgNDg3Lg0KDQpUaGVuLCBhY2NvcmRpbmcgdG8gc2VjdGlvbiA3LjIuNS4x
Liwgd2hlbiBhbiBhZ2VudCByZWNlaXZlcyB0aGUgNDg3IHJlc3BvbnNlIGl0IHdpbGwgY2hhbmdl
IGl0cyByb2xlLg0KDQpOb3csIGlmIEJPVEggYWdlbnRzIHNlbmQgNDg3LCBpdCBtZWFucyBCT1RI
IGFnZW50cyB3aWxsIHN3aXRjaCB0aGVpciByb2xlcywgYW5kIHRyeSBhZ2Fpbi4gTm93LCBzaW5j
ZSBib3RoIGFnZW50cyBzd2l0Y2ggdGhlaXIgcm9sZSwgYW5kIGtlZXAgdGhlIHNhbWUgdGllLWJy
ZWFrZXIgdmFsdWUsIHRoZSByZXN1bHQgd2lsbCBhZ2FpbiBiZSB0aGUgc2FtZSAob25seSB3aXRo
IGRpZmZlcmVudCByb2xlcykuDQoNClllcywgc28gdGhleSBvc2NpbGxhdGUgYmFjayBhbmQgZm9y
dGguDQoNCg0KDQpTZWN0aW9uIDcuMi41LjE8aHR0cDovLzcuMi41LjE+Og0KPT09PT09PT09PT09
PQ0KDQpPTEQ6DQoNCk9uY2UgdGhlIGFnZW50IGhhcyBzd2l0Y2hlZCBpdHMgcm9sZSwgdGhlIGFn
ZW50IE1VU1QgYWRkIHRoZQ0KY2FuZGlkYXRlIHBhaXIgd2hvc2UgY2hlY2sgZ2VuZXJhdGVkIHRo
ZSA0ODcgZXJyb3IgcmVzcG9uc2UgdG8gdGhlDQp0cmlnZ2VyZWQgY2hlY2sgcXVldWUgYXNzb2Np
YXRlZCB3aXRoIHRoZSBjaGVjayBsaXN0IHRvIHdoaWNoIHRoZQ0KcGFpciBiZWxvbmdzLCBhbmQg
c2V0IHRoZSBjYW5kaWRhdGUgcGFpciBzdGF0ZSB0byBXYWl0aW5nLiAgV2hlbiB0aGUNCnRyaWdn
ZXJlZCBjb25uZWN0aXZpdHkgY2hlY2sgaXMgbGF0ZXIgcGVyZm9ybWVkLCB0aGUgSUNFLUNPTlRS
T0xMSU5HLw0KSUNFLUNPTlRST0xMRUQgYXR0cmlidXRlIG9mIHRoZSBCaW5kaW5nIHJlcXVlc3Qg
d2lsbCBpbmRpY2F0ZSB0aGUNCmFnZW50J3MgbmV3IHJvbGUuICBUaGUgYWdlbnQgTUFZIGNoYW5n
ZSB0aGUgdGllLWJyZWFrZXIgdmFsdWUuDQoNCg0KTkVXOg0KDQpPbmNlIHRoZSBhZ2VudCBoYXMg
c3dpdGNoZWQgaXRzIHJvbGUsIHRoZSBhZ2VudCBNVVNUIGFkZCB0aGUNCmNhbmRpZGF0ZSBwYWly
IHdob3NlIGNoZWNrIGdlbmVyYXRlZCB0aGUgNDg3IGVycm9yIHJlc3BvbnNlIHRvIHRoZQ0KdHJp
Z2dlcmVkIGNoZWNrIHF1ZXVlIGFzc29jaWF0ZWQgd2l0aCB0aGUgY2hlY2sgbGlzdCB0byB3aGlj
aCB0aGUNCnBhaXIgYmVsb25ncywgYW5kIHNldCB0aGUgY2FuZGlkYXRlIHBhaXIgc3RhdGUgdG8g
V2FpdGluZy4gIFdoZW4gdGhlDQp0cmlnZ2VyZWQgY29ubmVjdGl2aXR5IGNoZWNrIGlzIGxhdGVy
IHBlcmZvcm1lZCwgdGhlIElDRS1DT05UUk9MTElORy8NCklDRS1DT05UUk9MTEVEIGF0dHJpYnV0
ZSBvZiB0aGUgQmluZGluZyByZXF1ZXN0IHdpbGwgaW5kaWNhdGUgdGhlDQphZ2VudCdzIG5ldyBy
b2xlLiAgVGhlIGFnZW50IE1VU1QgY2hhbmdlIHRoZSB0aWUtYnJlYWtlciB2YWx1ZS4NCg0KDQpT
ZWN0aW9uIDE2LjE6DQo9PT09PT09PT09PQ0KDQpPTEQ6DQoNCkFuIElDRSBhZ2VudCBNVVNUIHVz
ZSB0aGUgc2FtZSBudW1iZXIgZm9yIGFsbA0KQmluZGluZyByZXF1ZXN0cywgZm9yIGFsbCBzdHJl
YW1zLCB3aXRoaW4gYW4gSUNFIHNlc3Npb24uIFRoZSBhZ2VudA0KTUFZIGNoYW5nZSB0aGUgbnVt
YmVyIHdoZW4gYW4gSUNFIHJlc3RhcnQgb2NjdXJzLg0KDQpORVc6DQoNCkFuIElDRSBhZ2VudCBN
VVNUIHVzZSB0aGUgc2FtZSBudW1iZXIgZm9yIGFsbA0KQmluZGluZyByZXF1ZXN0cywgZm9yIGFs
bCBzdHJlYW1zLCB3aXRoaW4gYW4gSUNFIHNlc3Npb24sIHVubGVzcw0KaXQgcmVjZWl2ZXMgYSA0
ODcgcmVzcG9uc2UsIGluIHdoaWNoIGNhc2UgaXQgTVVTVCBjaGFuZ2UgdGhlDQpudW1iZXIgKFNl
Y3Rpb24gNy4yLjUuMSkuIFRoZSBhZ2VudCBNQVkgY2hhbmdlIHRoZSBudW1iZXIgd2hlbg0KYW4g
SUNFIHJlc3RhcnQgb2NjdXJzLg0KDQpQcm9ibGVtIHNvbHZlZD8gOikNCg0KVGhpcyB3b3VsZCBi
ZSBmaW5lIHdpdGggbWUsIGJ1dCBwcmVzdW1hYmx5IG5lZWRzIFdHIHNpZ25vZmYuDQoNCi1Fa3IN
Cg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KRnJvbTogRXJpYyBSZXNjb3JsYSBbbWFp
bHRvOmVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPl0NClNlbnQ6IDIxIEZlYnJ1YXJ5
IDIwMTggMDE6MDcNClRvOiBUYXlsb3IgQnJhbmRzdGV0dGVyIDxkZWFkYmVlZkBnb29nbGUuY29t
PG1haWx0bzpkZWFkYmVlZkBnb29nbGUuY29tPj4NCkNjOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hy
aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj
c3Nvbi5jb20+PjsgQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb208bWFpbHRvOmJlbkBub3N0
cnVtLmNvbT4+OyBpY2UtY2hhaXJzQGlldGYub3JnPG1haWx0bzppY2UtY2hhaXJzQGlldGYub3Jn
PjsgaWNlQGlldGYub3JnPG1haWx0bzppY2VAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWljZS1yZmM1
MjQ1YmlzQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYub3Jn
PjsgcHRoYXRjaGVyQGdvb2dsZS5jb208bWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tPjsgVGhl
IElFU0cgPGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6
IFtJY2VdIEVyaWMgUmVzY29ybGEncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1pY2UtcmZj
NTI0NWJpcy0xNzogKHdpdGggQ09NTUVOVCkgKGV4Y2x1ZGluZyBTZWN1cml0eSBDb25zaWRlcmF0
aW9ucykNCg0KSSB3b3VsZG4ndCBvYmplY3QgaWYgc29tZW9uZSBwcm9kdWNlZCBhIHByaW5jaXBs
ZWQgZml4LiBJIGp1c3QgZG9uJ3Qgd2FudCB0byBjcmVhdGUgYSBsb3Qgb2Ygd29yayBmb3IgcGVv
cGxlDQoNCg0KT24gVHVlLCBGZWIgMjAsIDIwMTggYXQgMjo1MSBQTSwgVGF5bG9yIEJyYW5kc3Rl
dHRlciA8ZGVhZGJlZWZAZ29vZ2xlLmNvbTxtYWlsdG86ZGVhZGJlZWZAZ29vZ2xlLmNvbT4+IHdy
b3RlOg0KVGhlIHRpZS1icmVha2VyIGNvbGxpc2lvbiBwcm9ibGVtIGhhcyBjb21lIHVwIGEgZmV3
IHRpbWVzIGJlZm9yZSwgYWN0dWFsbHkuIEFzIEkndmUgc2FpZCwgSSBiZWxpZXZlIGl0IGNvdWxk
IGJlIGZpeGVkIHZlcnkgZWFzaWx5IGJ5IHNheWluZyAicGljayBhIG5ldyB0aWUtYnJlYWtlciBp
ZiB0aGlzIGhhcHBlbnMuIg0KDQpBcyBmb3IgdGhlICJNVVNUIG5vdCBjaGFuZ2UgdGllLWJyZWFr
ZXIiIHJ1bGUgaW4gc2VjdGlvbiAxNi4xLCByZXF1aXJpbmcgYW4gSUNFIHJlc3RhcnQgaXMgb3Zl
cmtpbGwuIFdlIGNhbiBqdXN0IGNoYW5nZSBpdCB0byAiTVVTVCBub3QgY2hhbmdlIHRpZS1icmVh
a2VyIHVubGVzcyB0aGVyZSdzIGEgY29sbGlzaW9uLiINCg0KT24gTW9uLCBGZWIgMTksIDIwMTgg
YXQgMTA6MzMgQU0sIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0u
Y29tPj4gd3JvdGU6DQoNCg0KT24gTW9uLCBGZWIgMTksIDIwMTggYXQgMTA6MjkgQU0sIENocmlz
dGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlz
dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGksDQoNCi4uLg0KDQo+Pj4+IElG
IHdlIHJlYWxseSB3YW50IHRvIHNvbHZlIHRoaXMsIG9uZSBzaW1wbGUgc29sdXRpb24gYmUgdG8g
c2F5IHRoYXQsIGlmIHRoaXMgaGFwcGVucywgYW5kIGVuZHBvaW50IHNpbXBseSBjYWxjdWxhdGVz
IGENCj4+Pj4gbmV3IHRpZS1icmVha2VyIHZhbHVlLCBhbmQgdHJpZXMgYWdhaW4/IEJVVCwgdGhl
biB3ZSB3b3VsZCBoYXZlIHRvIGNoYW5nZSBzZWN0aW9uIDE2LjEsIHdoaWNoIHNheXMgdGhhdCBh
IG5ldyB2YWx1ZSBjYW4gb25seSBiZSBjYWxjdWxhdGVkIGF0IGFuIElDRSByZXN0YXJ0Lg0KPj4+
Pg0KPj4+PiBTbywgY291bGQgd2Ugc2ltcGx5IHNheSB0aGF0LCBpZiB0aGlzIGhhcHBlbnMsIHRo
ZSBhZ2VudCBNVVNUIGRvIGFuIElDRSByZXN0YXJ0LCBhbmQgaXQgTVVTVCBjYWxjdWxhdGUgYSBu
ZXcgdGllLWJyZWFrZXIgdmFsdWU/DQo+Pj4NCj4+PiBOb3cgYm90aCBzaWRlcyBtaWdodCBkbyBh
IHNpbXVsdGFuZW91cyByZXN0YXJ0LiBJcyB0aGF0IGdvaW5nIHRvIHdvcms/DQo+Pg0KPj4gV2Ug
Y291bGQgc2F5IHRoYXQgdGhlIGluaXRpYXRpbmcgYWdlbnQgTVVTVCBkbyB0aGUgcmVzdGFydC4N
Cj4NCj4gSW4gdGhpcyBzY2VuYXJpbywgZG9uJ3QgYm90aCBzaWRlcyBiZWxpZXZlIHRoZXkgYXJl
IHRoZSBpbml0aWF0aW5nIHBlZXIsIGhlbmNlIHRoZSBuZWVkIGZvciB0aGUgdGllYnJlYWtlcj8N
Cg0KUHJvYmFibHkuLi4NCg0KQnV0LCB0aGVuIEkgZG9uJ3Qgc2VlIHdoYXQgd2UgY291bGQgZG8u
IElmIGJvdGggYWdlbnRzIHNlbmQgYSBjaGVjaywgYW5kIHJlY2VpdmUgNDg3LCB3ZSBjYW4ndCBk
ZWZpbmUgYSBwcm9jZWR1cmUgZm9yIG9uZSBvZiB0aGUgYWdlbnRzLg0KDQpQZXJoYXBzIHdlIHNo
b3VsZCB0aGVuIGNoYW5nZSB0aGUgbXVzdC1ub3QtY2hhbmdlLXRoZS12YWx1ZS11bmxlc3MtcmVz
dGFydCBhbmQgc2F5IHRoYXQgYW4gYWdlbnQgY2hhbmdlcyB0aGUgdGllLWJyZWFrZXIgdmFsdWUg
YW5kIHRyeSBhZ2Fpbi4NCg0KQXMgeW91IHNheSwgdGhlIHByb2JsZW0gaXMgaW5oZXJlbnRseSB0
aGF0IHRoZSBzaXR1YXRpb24gaXMgc3ltbWV0cmljYWwuDQoNCkF0IHRoaXMgcG9pbnQgaW4gdGhl
IGRlc2lnbiBwcm9jZXNzLCBJIGRvbid0IHRoaW5rIGl0J3Mgd29ydGggdHJ5aW5nIHRvIGFjdHVh
bGx5IG1ha2UgdGhlIGNhbGwgc3VjY2VlZDsgYSAyXnstNjR9IGZhaWx1cmUgcmF0ZSBpcyBtdWNo
IGxvd2VyIHRoYW4gb3JnYW5pYyBjYWxsIGZhaWx1cmUgcmF0ZXMgZnJvbSBvdGhlciBjYXVzZXMs
IGV2ZW4gaW4gbm9uLTNQQ0Mgc2NlbmFyaW9zLiBSYXRoZXIsIEkgdGhpbmsgdGhlIHNwZWMgc2hv
dWxkIGp1c3QgcHJlc2NyaWJlIGEgY2xlYW4gZmFpbHVyZSBtb2RlIHZpYSBhIG5ldyBlcnJvciBj
b2RlLCByYXRoZXIgdGhhbiBoYXZpbmcgYm90aCBzaWRlcyB3aWxkbHkgb3NjaWxsYXRlIGJldHdl
ZW4gY29udHJvbGxlZCBhbmQgY29udHJvbGxpbmcNCg0KLUVrcg0KDQoNClJlZ2FyZHMsDQoNCkNo
cmlzdGVyDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCkljZSBtYWlsaW5nIGxpc3QNCkljZUBpZXRmLm9yZzxtYWlsdG86SWNlQGlldGYub3JnPg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UNCg0KDQoNCg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkljZSBtYWlsaW5nIGxp
c3QNCkljZUBpZXRmLm9yZzxtYWlsdG86SWNlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9pY2UNCg0K

--_000_7594FB04B1934943A5C02806D1A2204B6C1ABB3EESESSMB109erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K
CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K
CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl
OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N
CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t
W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt
YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N
CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh
PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv
ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBUZWQsPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JQ0UgcmUtc3RhcnQgd2FzIHN1Z2dlc3RlZCBl
YXJsaWVyLCBidXQgcGVvcGxlIGRpZG7igJl0IGxpa2UgaXQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt
c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh
cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgZG9u4oCZdCB0aGluayB0aGUgc29sdXRpb24gYWRkcyB2
ZXJ5IG11Y2ggY29tcGxleGl0eS4gSXTigJlzIG1vcmUgb3IgbGVzcyBzdXBwb3J0ZWQgYWxyZWFk
eSwgdGhlIG9ubHkgZGlmZmVyZW5jZSBpcyB0aGF0IHdlIGNoYW5nZSDigJxNQVkNCiBwaWNrIGEg
bmV3IHRpZS1icmVha2VyIHZhbHVl4oCdIHRvIOKAnE1VU1QgcGljayBhIG5ldyB0aWUtYnJlYWtl
ciB2YWx1ZeKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFuZCwg
ZXZlbiBpZiBvbmx5IG9uZSBvZiB0aGUgZW5kcG9pbnRzIGFjdHVhbGx5IGRvIHBpY2sgYSBuZXcg
dmFsdWUsIGFuZCB0aGUgb3RoZXIga2VlcHMgdGhlIG9sZCB2YWx1ZSwgdGhpbmdzIHdpbGwgc3Rp
bGwgd29yayA6KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJk
cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRD
b21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn
ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVGVkIEhhcmRpZSBbbWFpbHRvOnRlZC5pZXRm
QGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyNiBGZWJydWFyeSAyMDE4IDIxOjQ0PGJy
Pg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp
Y3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gaWNlQGlldGYub3JnOyBCZW4gQ2FtcGJlbGwg
Jmx0O2JlbkBub3N0cnVtLmNvbSZndDs7IGljZS1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq
ZWN0OjwvYj4gUmU6IFtJY2VdIElDRSBjaGFuZ2UgaW4gcm9sZSBjb25mbGljdCAoW3dhczogRXJp
YyBSZXNjb3JsYSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzLTE3
OiAod2l0aCBDT01NRU5UKSAoZXhjbHVkaW5nIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zKSAtIFJv
bGUgY29uZmxpY3QgaXNzdWUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
SGkgQ2hyaXN0ZXIsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pk9uIFN1biwgRmViIDI1LCAyMDE4IGF0IDI6MDggQU0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8
YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9i
bGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48
L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s
aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu
OHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSw8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGFzayB0aGUgY29tbXVuaXR5IHRvIHRha2Ug
YSBsb29rIGF0IHRoZSBzdWdnZXN0ZWQgY2hhbmdlIGJlbG93LCBhbmQgaW5kaWNhdGUgd2hldGhl
ciB5b3UgaGF2ZSBhbnkNCiBpc3N1ZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzFGNDk3RCI+TlVUU0hFTEw6PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldoYXTigJlzIHRoZSBwcm9ibGVtPzwvc3Bhbj48L2I+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbiBjYXNlIGJvdGggYWdl
bnRzIGFzc3VtZSB0aGUgc2FtZSByb2xlIChtaWdodCBoYXBwZW4gaW4gY2VydGFpbiAzUENDIHNj
ZW5hcmlvcyksIEFORCB1c2UgdGhlIHNhbWUNCiB0aWUtYnJlYWtlciB2YWx1ZSAodW5saWtlbHkg
dG8gaGFwcGVuLCBidXQgcG9zc2libGUgaW4gdGhlb3J5KSwgd2hpY2ggbWF5IGNhdXNlIGJvdGgg
ZW5kcG9pbnRzIHRvIHNlbmQgYSA0ODcgcmVzcG9uc2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIDQ4NyByZXNwb25zZSB3aWxsIGNhdXNlIGJvdGgg
ZW5kcG9pbnRzIGFuZCBjaGFuZ2UgdGhlaXIgcm9sZXMsIGFuZCB0cnkgYWdhaW4uIEJ1dCwgdW5s
ZXNzIHRoZXkNCiBhbHNvIGNoYW5nZSB0aGUgdGllLWJyZWFrZXIgdmFsdWUsIHRoZSByZXN1bHQg
d2lsbCBiZSB0aGUgc2FtZTogYm90aCB3aWxsIGFzc3VtZSB0aGUgc2FtZSByb2xlIChzaW5jZSBi
b3RoIHJlY2VpdmVkIDQ4NyksIGFuZCBtaWdodCB1c2UgdGhlIHNhbWUgdGllLWJyZWFrZXIgdmFs
dWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldoYXTigJlzIHRoZSBzb2x1dGlvbj88L3NwYW4+PC9i
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U3BlY2lmeSB0aGF0LCB3
aGVuIGFuIGVuZHBvaW50IHJlY2VpdmVzIDQ4NywgYW5kIGNoYW5nZXMgaXRzIHJvbGUsIGl0IE1V
U1QgYWxzbyBjaGFuZ2UgdGhlIHRpZS1icmVha2VyDQogdmFsdWUuIFRoYXQgd2F5LCB3aGVuIGJv
dGggZW5kcG9pbnRzIGFnYWluIHRyeSwgdW5sZXNzIHRoZSBlbmRwb2ludHMgYWdhaW4gY2hvb3Nl
IHRoZSBzYW1lIHRpZS1icmVha2VyIHZhbHVlIChldmVuIG1vcmUgdW5saWtlbHkpIG9ubHkgb25l
IHNob3VsZCBzZW5kIGEgNDg3LCBhbmQgdGhlIHJvbGUgY29uZmxpY3Qgd2lsbCBiZSBzb2x2ZWQu
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1ib3R0b206MTIuMHB0Ij5TbywgSSBwcm9wb3NlIHNvbWV0aGluZyBldmVuIHNpbXBsZXIu
Jm5ic3A7IEluIHRoZSB2ZXJ5IHJhcmUgY2FzZSB0aGF0IHRoZSBwZWVycyBzZWUgdGhhdCB0aGUg
dGllLWJyZWFrZXIgdmFsdWVzIGFyZSB0aGUgc2FtZSwgYm90aCBzaWRlcyBzaG91bGQgcmVzdGFy
dCBJQ0UuJm5ic3A7IFJlc3RhcnRpbmcgSUNFIHJlc3VsdHMgaW4gbmV3IHRpZS1icmVha2VyIHZh
bHVlcyBiZWluZw0KIHNlbGVjdGVkIGluIGFueSBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0
Ij5NeSBsb2dpYyBoZXJlIGlzIHRoaXM6Jm5ic3A7IHRoaXMgb2NjdXJzIHByZXR0eSByYXJlbHkg
dG8gc3RhcnQgd2l0aCwgZXNzZW50aWFsbHkgb25seSBpbiB0aGUgY2FzZSBvZiB0aGlyZC1wYXJ0
eSBjYWxsIGNvbnRyb2wuJm5ic3A7IEluIHRoYXQgc3Vic2V0IG9mIGNhc2VzLCB0aGUgdHdvIHNp
ZGVzIGhhdmUgdG8gc2VsZWN0IHRoZSBzYW1lIHZhbHVlIG91dCBvZiBhIDQtYmlsbGlvbg0KIG9k
ZCByYW5nZS4gJm5ic3A7IFNvLCBhdCBsZWFzdCBob3BlZnVsbHksIHRoaXMgaXMgbm90IGEgY29t
bW9uIG9jY3VycmVuY2UuJm5ic3A7IENvZGUgY292ZXJpbmcgdW5jb21tb24gb2NjdXJyZW5jZXMg
dGVuZHMgdG8gYml0IHJvdC4mbmJzcDsgVXNpbmcgJnF1b3Q7cmUtc3RhcnQgSUNFJnF1b3Q7IG1l
YW5zIHJlLXVzaW5nIGNvZGUgdGhhdCB3aWxsIGJlIG1haW50YWluZWQgZm9yIG90aGVyIHJlYXNv
bnMsIHdoZXJlIHJlLXN0YXJ0IHdpdGggYSBuZXcgdGllLWJyZWFrZXIgdmFsdWUgd2lsbA0KIG5v
dCBiZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSBhbSB3aWxsaW5nIHRvIGFjY2VwdCB5b3Vy
IGN1cnJlbnQgc29sdXRpb24sIHRob3VnaCwgaWYgb3RoZXIgZm9sa3MgYXJlIG5vdCBjb25jZXJu
ZWQgYWJvdXQgdGhlIGNvbXBsZXhpdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5UZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg
I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0
O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj5XaGF0IGlmIEkgZG9u4oCZdCBsaWtlIHRoZSBzdWdnZXN0ZWQgc29sdXRpb24/PC9zcGFu
PjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlN1Z2dlc3Qgc29t
ZXRoaW5nIGJldHRlciAocmVhZDogcHJvdmlkZSBhY3R1YWwgdGV4dCBjaGFuZ2UvcmVtb3ZhbC9h
ZGRpdGlvbnMpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkRFVEFJTFM6PC9zcGFuPjwvYj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBsZWFzZSBzZWUgZGlzY3Vzc2lvbiB0
aHJlYWQgYmVsb3cuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij5DaHJpc3Rlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEg
bmFtZT0ibV8tNTIyNjczMTIwODI0NzkxNDUwOF9fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t
Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEVyaWMNCiBSZXNjb3Js
YSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5l
a3JAcnRmbS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDI0IEZlYnJ1YXJ5IDIwMTggMjI6
NTM8YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86
Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIu
aG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IFRheWxvciBCcmFu
ZHN0ZXR0ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpkZWFkYmVlZkBnb29nbGUuY29tIiB0YXJnZXQ9
Il9ibGFuayI+ZGVhZGJlZWZAZ29vZ2xlLmNvbTwvYT4mZ3Q7OyBCZW4gQ2FtcGJlbGwgJmx0Ozxh
IGhyZWY9Im1haWx0bzpiZW5Abm9zdHJ1bS5jb20iIHRhcmdldD0iX2JsYW5rIj5iZW5Abm9zdHJ1
bS5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzppY2UtY2hhaXJzQGlldGYub3JnIiB0YXJn
ZXQ9Il9ibGFuayI+aWNlLWNoYWlyc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzppY2VA
aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmljZUBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1h
aWx0bzpkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+
DQpkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRv
OnB0aGF0Y2hlckBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+DQpwdGhhdGNoZXJAZ29vZ2xl
LmNvbTwvYT47IFRoZSBJRVNHICZsdDs8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyIgdGFy
Z2V0PSJfYmxhbmsiPmllc2dAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS
ZTogW0ljZV0gRXJpYyBSZXNjb3JsYSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWljZS1y
ZmM1MjQ1YmlzLTE3OiAod2l0aCBDT01NRU5UKSAoZXhjbHVkaW5nIFNlY3VyaXR5IENvbnNpZGVy
YXRpb25zKSAtIFJvbGUgY29uZmxpY3QgaXNzdWU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPk9uIFNhdCwgRmViIDI0LCAyMDE4IGF0IDEyOjM3IFBNLCBDaHJpc3RlciBIb2xtYmVy
ZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSIgdGFy
Z2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3Rl
OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s
ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t
bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPkkgaGFkIGEgY2xvc2VyIGxvb2sgYXQgdGhlIHJvbGUgY29uZmxpY3Qg
aXNzdWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Rmly
c3QsIHRoZSBkcmFmdCBhbHJlYWR5IGNvdmVycyB0aGUgY2FzZSB3aGVuIHRoZSB0aWUtYnJlYWtl
ciB2YWx1ZXMgYXJlIGlkZW50aWNhbC4gSXQgaXMgZGVzY3JpYmVkDQogaW4gc2VjdGlvbiA8YSBo
cmVmPSJodHRwOi8vNy4zLjEuMSIgdGFyZ2V0PSJfYmxhbmsiPjcuMy4xLjE8L2E+Ojwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyDigJxJ
ZiB0aGUgYWdlbnQncyB0aWUtYnJlYWtlciB2YWx1ZSBpcyBsYXJnZXIgdGhhbg0KPGI+b3IgZXF1
YWwgdG88L2I+4oCm4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMuIE15IHBv
aW50IGlzIHRoYXQgdGhpcyBpcyBicm9rZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND
Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPuKApnRoZSBhZ2VudCBzZW5kcyA0ODcu
DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGVuLCBh
Y2NvcmRpbmcgdG8gc2VjdGlvbiA3LjIuNS4xLiwgd2hlbiBhbiBhZ2VudCByZWNlaXZlcyB0aGUg
NDg3IHJlc3BvbnNlIGl0IHdpbGwgY2hhbmdlIGl0cyByb2xlLjwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk5vdywgaWYgQk9USCBhZ2VudHMgc2VuZCA0ODcs
IGl0IG1lYW5zIEJPVEggYWdlbnRzIHdpbGwgc3dpdGNoIHRoZWlyIHJvbGVzLCBhbmQgdHJ5IGFn
YWluLiBOb3csIHNpbmNlDQogYm90aCBhZ2VudHMgc3dpdGNoIHRoZWlyIHJvbGUsIGFuZCBrZWVw
IHRoZSBzYW1lIHRpZS1icmVha2VyIHZhbHVlLCB0aGUgcmVzdWx0IHdpbGwgYWdhaW4gYmUgdGhl
IHNhbWUgKG9ubHkgd2l0aCBkaWZmZXJlbnQgcm9sZXMpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+WWVzLCBzbyB0aGV5IG9zY2lsbGF0ZSBiYWNrIGFuZCBmb3J0aC48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw
dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNlY3Rpb24NCjxhIGhyZWY9Imh0dHA6Ly83
LjIuNS4xIiB0YXJnZXQ9Il9ibGFuayI+Ny4yLjUuMTwvYT46PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
PT09PT09PT09PT09PTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPk9MRDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5P
bmNlIHRoZSBhZ2VudCBoYXMgc3dpdGNoZWQgaXRzIHJvbGUsIHRoZSBhZ2VudCBNVVNUIGFkZCB0
aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5jYW5kaWRhdGUgcGFpciB3aG9zZSBjaGVjayBnZW5lcmF0
ZWQgdGhlIDQ4NyBlcnJvciByZXNwb25zZSB0byB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj50cmln
Z2VyZWQgY2hlY2sgcXVldWUgYXNzb2NpYXRlZCB3aXRoIHRoZSBjaGVjayBsaXN0IHRvIHdoaWNo
IHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnBhaXIgYmVsb25ncywgYW5kIHNldCB0aGUgY2FuZGlk
YXRlIHBhaXIgc3RhdGUgdG8gV2FpdGluZy4mbmJzcDsgV2hlbiB0aGU8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj50cmlnZ2VyZWQgY29ubmVjdGl2aXR5IGNoZWNrIGlzIGxhdGVyIHBlcmZvcm1lZCwgdGhl
IElDRS1DT05UUk9MTElORy88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JQ0UtQ09OVFJPTExFRCBhdHRy
aWJ1dGUgb2YgdGhlIEJpbmRpbmcgcmVxdWVzdCB3aWxsIGluZGljYXRlIHRoZTwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPmFnZW50J3MgbmV3IHJvbGUuJm5ic3A7IFRoZSBhZ2VudA0KPGI+TUFZPC9iPiBj
aGFuZ2UgdGhlIHRpZS1icmVha2VyIHZhbHVlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk5FVzo8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PbmNlIHRoZSBhZ2VudCBo
YXMgc3dpdGNoZWQgaXRzIHJvbGUsIHRoZSBhZ2VudCBNVVNUIGFkZCB0aGU8L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj
MUY0OTdEIj5jYW5kaWRhdGUgcGFpciB3aG9zZSBjaGVjayBnZW5lcmF0ZWQgdGhlIDQ4NyBlcnJv
ciByZXNwb25zZSB0byB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj50cmlnZ2VyZWQgY2hlY2sgcXVl
dWUgYXNzb2NpYXRlZCB3aXRoIHRoZSBjaGVjayBsaXN0IHRvIHdoaWNoIHRoZTwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPnBhaXIgYmVsb25ncywgYW5kIHNldCB0aGUgY2FuZGlkYXRlIHBhaXIgc3RhdGUg
dG8gV2FpdGluZy4mbmJzcDsgV2hlbiB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj50cmlnZ2VyZWQg
Y29ubmVjdGl2aXR5IGNoZWNrIGlzIGxhdGVyIHBlcmZvcm1lZCwgdGhlIElDRS1DT05UUk9MTElO
Ry88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JQ0UtQ09OVFJPTExFRCBhdHRyaWJ1dGUgb2YgdGhlIEJp
bmRpbmcgcmVxdWVzdCB3aWxsIGluZGljYXRlIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmFnZW50
J3MgbmV3IHJvbGUuJm5ic3A7IFRoZSBhZ2VudA0KPGI+TVVTVDwvYj4gY2hhbmdlIHRoZSB0aWUt
YnJlYWtlciB2YWx1ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0
OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TZWN0aW9uIDE2LjE6PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+PT09PT09PT09PT08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj5PTEQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG
NDk3RCI+QW4gSUNFIGFnZW50IE1VU1QgdXNlIHRoZSBzYW1lIG51bWJlciBmb3IgYWxsPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+QmluZGluZyByZXF1ZXN0cywgZm9yIGFsbCBzdHJlYW1zLCB3aXRoaW4g
YW4gSUNFIHNlc3Npb24uIFRoZSBhZ2VudDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk1BWSBjaGFuZ2Ug
dGhlIG51bWJlciB3aGVuIGFuIElDRSByZXN0YXJ0IG9jY3Vycy48L3NwYW4+PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ORVc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW4gSUNFIGFnZW50IE1VU1QgdXNlIHRoZSBzYW1lIG51
bWJlciBmb3IgYWxsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmluZGluZyByZXF1ZXN0cywgZm9yIGFs
bCBzdHJlYW1zLCB3aXRoaW4gYW4gSUNFIHNlc3Npb248Yj4sIHVubGVzcw0KPC9iPjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPml0IHJlY2VpdmVzIGEgNDg3IHJlc3BvbnNlLCBpbiB3aGljaCBjYXNl
IGl0IE1VU1QgY2hhbmdlIHRoZTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5udW1iZXIgKFNl
Y3Rpb24gNy4yLjUuMSkuPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
DQogVGhlIGFnZW50IE1BWSBjaGFuZ2UgdGhlIG51bWJlciB3aGVuIDwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPmFuIElDRSByZXN0YXJ0IG9jY3Vycy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj5Qcm9ibGVtIHNvbHZlZD8gOik8L3NwYW4+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPlRoaXMgd291bGQgYmUgZmluZSB3aXRoIG1lLCBidXQgcHJlc3VtYWJseSBuZWVk
cyBXRyBzaWdub2ZmLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv
dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk
ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw
Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1fLTUyMjY3MzEyMDgyNDc5MTQ1MDhfbV8tNjE1NTE5
MDgxOTAyNDIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9h
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJF
Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZiI+IEVyaWMNCiBSZXNjb3JsYSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5j
b20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+
IDIxIEZlYnJ1YXJ5IDIwMTggMDE6MDc8YnI+DQo8Yj5Ubzo8L2I+IFRheWxvciBCcmFuZHN0ZXR0
ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpkZWFkYmVlZkBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFu
ayI+ZGVhZGJlZWZAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBDaHJpc3RlciBI
b2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv
bSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7
OyBCZW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiZW5Abm9zdHJ1bS5jb20iIHRhcmdl
dD0iX2JsYW5rIj5iZW5Abm9zdHJ1bS5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzppY2Ut
Y2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWNlLWNoYWlyc0BpZXRmLm9yZzwvYT47
IDxhIGhyZWY9Im1haWx0bzppY2VAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmljZUBpZXRm
Lm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYu
b3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYub3Jn
PC9hPjsgPGEgaHJlZj0ibWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFu
ayI+DQpwdGhhdGNoZXJAZ29vZ2xlLmNvbTwvYT47IFRoZSBJRVNHICZsdDs8YSBocmVmPSJtYWls
dG86aWVzZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmllc2dAaWV0Zi5vcmc8L2E+Jmd0Ozxi
cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0ljZV0gRXJpYyBSZXNjb3JsYSdzIE5vIE9iamVjdGlv
biBvbiBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzLTE3OiAod2l0aCBDT01NRU5UKSAoZXhjbHVk
aW5nIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPkkgd291bGRuJ3Qgb2JqZWN0IGlmIHNvbWVvbmUgcHJvZHVjZWQgYSBwcmluY2lwbGVk
IGZpeC4gSSBqdXN0IGRvbid0IHdhbnQgdG8gY3JlYXRlIGEgbG90IG9mIHdvcmsgZm9yIHBlb3Bs
ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIEZlYiAyMCwgMjAxOCBhdCAy
OjUxIFBNLCBUYXlsb3IgQnJhbmRzdGV0dGVyICZsdDs8YSBocmVmPSJtYWlsdG86ZGVhZGJlZWZA
Z29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRlYWRiZWVmQGdvb2dsZS5jb208L2E+Jmd0OyB3
cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy
Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMjti
YWNrZ3JvdW5kOndoaXRlIj5UaGUgdGllLWJyZWFrZXIgY29sbGlzaW9uIHByb2JsZW0gaGFzIGNv
bWUgdXAgYSBmZXcgdGltZXMgYmVmb3JlLCBhY3R1YWxseS4gQXMgSSd2ZSBzYWlkLCBJIGJlbGll
dmUmbmJzcDs8L3NwYW4+aXQNCiBjb3VsZCBiZSBmaXhlZCB2ZXJ5IGVhc2lseSBieSBzYXlpbmcg
JnF1b3Q7cGljayBhIG5ldyB0aWUtYnJlYWtlciBpZiB0aGlzIGhhcHBlbnMuJnF1b3Q7PG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgZm9yIHRoZSAm
cXVvdDtNVVNUIG5vdCBjaGFuZ2UgdGllLWJyZWFrZXImcXVvdDsgcnVsZSBpbiBzZWN0aW9uIDE2
LjEsIHJlcXVpcmluZyBhbiBJQ0UgcmVzdGFydCBpcyBvdmVya2lsbC4gV2UgY2FuIGp1c3QgY2hh
bmdlIGl0IHRvICZxdW90O01VU1Qgbm90IGNoYW5nZSB0aWUtYnJlYWtlcjxpPiB1bmxlc3MgdGhl
cmUncyBhIGNvbGxpc2lvbjwvaT4uJnF1b3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgRmViIDE5
LCAyMDE4IGF0IDEwOjMzIEFNLCBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWty
QHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2
LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5PbiBNb24sIEZlYiAxOSwgMjAxOCBhdCAxMDoyOSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0
OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0i
X2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpw
PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz
b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6
NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSw8YnI+DQo8YnI+DQouLi48YnI+DQo8YnI+
DQomZ3Q7Jmd0OyZndDsmZ3Q7IElGIHdlIHJlYWxseSB3YW50IHRvIHNvbHZlIHRoaXMsIG9uZSBz
aW1wbGUgc29sdXRpb24gYmUgdG8gc2F5IHRoYXQsIGlmIHRoaXMgaGFwcGVucywgYW5kIGVuZHBv
aW50IHNpbXBseSBjYWxjdWxhdGVzIGE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IG5ldyB0aWUtYnJl
YWtlciB2YWx1ZSwgYW5kIHRyaWVzIGFnYWluPyBCVVQsIHRoZW4gd2Ugd291bGQgaGF2ZSB0byBj
aGFuZ2Ugc2VjdGlvbiAxNi4xLCB3aGljaCBzYXlzIHRoYXQgYSBuZXcgdmFsdWUgY2FuIG9ubHkg
YmUgY2FsY3VsYXRlZCBhdCBhbiBJQ0UgcmVzdGFydC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0OyBTbywgY291bGQgd2Ugc2ltcGx5IHNheSB0aGF0LCBpZiB0aGlz
IGhhcHBlbnMsIHRoZSBhZ2VudCBNVVNUIGRvIGFuIElDRSByZXN0YXJ0LCBhbmQgaXQgTVVTVCBj
YWxjdWxhdGUgYSBuZXcgdGllLWJyZWFrZXIgdmFsdWU/PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsmZ3Q7IE5vdyBib3RoIHNpZGVzIG1pZ2h0IGRvIGEgc2ltdWx0YW5lb3VzIHJlc3Rh
cnQuIElzIHRoYXQgZ29pbmcgdG8gd29yaz88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFdl
IGNvdWxkIHNheSB0aGF0IHRoZSBpbml0aWF0aW5nIGFnZW50IE1VU1QgZG8gdGhlIHJlc3RhcnQu
PGJyPg0KJmd0Ozxicj4NCiZndDsgSW4gdGhpcyBzY2VuYXJpbywgZG9uJ3QgYm90aCBzaWRlcyBi
ZWxpZXZlIHRoZXkgYXJlIHRoZSBpbml0aWF0aW5nIHBlZXIsIGhlbmNlIHRoZSBuZWVkIGZvciB0
aGUgdGllYnJlYWtlcj88YnI+DQo8YnI+DQpQcm9iYWJseS4uLjxicj4NCjxicj4NCkJ1dCwgdGhl
biBJIGRvbid0IHNlZSB3aGF0IHdlIGNvdWxkIGRvLiBJZiBib3RoIGFnZW50cyBzZW5kIGEgY2hl
Y2ssIGFuZCByZWNlaXZlIDQ4Nywgd2UgY2FuJ3QgZGVmaW5lIGEgcHJvY2VkdXJlIGZvciBvbmUg
b2YgdGhlIGFnZW50cy48YnI+DQo8YnI+DQpQZXJoYXBzIHdlIHNob3VsZCB0aGVuIGNoYW5nZSB0
aGUgbXVzdC1ub3QtY2hhbmdlLXRoZS12YWx1ZS11bmxlc3MtcmVzdGFydCBhbmQgc2F5IHRoYXQg
YW4gYWdlbnQgY2hhbmdlcyB0aGUgdGllLWJyZWFrZXIgdmFsdWUgYW5kIHRyeSBhZ2Fpbi48bzpw
PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj5BcyB5b3Ugc2F5LCB0aGUgcHJvYmxlbSBpcyBpbmhlcmVudGx5IHRoYXQgdGhlIHNpdHVh
dGlvbiBpcyBzeW1tZXRyaWNhbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPkF0IHRoaXMgcG9pbnQgaW4gdGhlIGRlc2lnbiBwcm9jZXNz
LCBJIGRvbid0IHRoaW5rIGl0J3Mgd29ydGggdHJ5aW5nIHRvIGFjdHVhbGx5IG1ha2UgdGhlIGNh
bGwgc3VjY2VlZDsgYSAyXnstNjR9IGZhaWx1cmUgcmF0ZSBpcyBtdWNoIGxvd2VyIHRoYW4gb3Jn
YW5pYyBjYWxsIGZhaWx1cmUgcmF0ZXMgZnJvbQ0KIG90aGVyIGNhdXNlcywgZXZlbiBpbiBub24t
M1BDQyBzY2VuYXJpb3MuIFJhdGhlciwgSSB0aGluayB0aGUgc3BlYyBzaG91bGQganVzdCBwcmVz
Y3JpYmUgYSBjbGVhbiBmYWlsdXJlIG1vZGUgdmlhIGEgbmV3IGVycm9yIGNvZGUsIHJhdGhlciB0
aGFuIGhhdmluZyBib3RoIHNpZGVzIHdpbGRseSBvc2NpbGxhdGUgYmV0d2VlbiBjb250cm9sbGVk
IGFuZCBjb250cm9sbGluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7
cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w
cHQiPjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KQ2hyaXN0ZXI8bzpwPjwvbzpwPjwvcD4NCjwv
YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJY2UgbWFpbGluZyBs
aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkljZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPklj
ZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2ljZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vaWNlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4N
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWNl
IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpJY2VAaWV0Zi5vcmciPkljZUBpZXRm
Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2ljZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vaWNlPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_7594FB04B1934943A5C02806D1A2204B6C1ABB3EESESSMB109erics_--


From nobody Mon Feb 26 12:03:42 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE94E12D80E; Mon, 26 Feb 2018 12:03:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 XmQfaGSNs3SJ; Mon, 26 Feb 2018 12:03:25 -0800 (PST)
Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (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 9E6B9126CC7; Mon, 26 Feb 2018 12:03:25 -0800 (PST)
Received: by mail-ot0-x229.google.com with SMTP id h8so1443648oti.6; Mon, 26 Feb 2018 12:03:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zOUOgDMX4E7hXHXEy82iRQwGUzg7WqrrnM55xNP36ss=; b=MRH8dtuNOStUr6gwzLY6qCYGRyL+HBlxWSjf2xMoc0/VuX9hw78ldkSKKCNR0jB/9j TyNnVwYKwGZM+mtwz2Bjl5SWmiMjgwvd4fTZbgv/u46oPzU4mY1p6F7nRMv8lh2t/MS2 JuRc6SzkvVmSoeflIqHWozBPjEsL/HpZW5Z/1KFTe0Dx+dJ1O+XjQq3U/dT34OnD3gjj dVGqS75QXdcm+ij9+MyJefPG/H6ODLlw42VIAEk/6UCwThndtmxijiO7vA9v7zZy2H8B n3QFQf5nuZ/m7y+Bq0VxKg+leYo6rMfSJ8mxLwuM8m96Y8Yr/9RPjxtR1173H8vC1UWC HwFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zOUOgDMX4E7hXHXEy82iRQwGUzg7WqrrnM55xNP36ss=; b=qrDxLRz3P9WyBsPvfJ+tUcEnj02DQdriGpznRJMbP/KkJCZTcPPhVf5W2LGT4fBtP3 Rte7JdXH0IGdv7f0mRPe3CkF6JrPxfkkQNIyHB0WCCcN9GcXgpkERw6gWiboMde4vRwy wm3UH0I+tqIewbQEMfLc/UTk7rnBjZVKQgV5vcjzuZ90oOOBz6PHw1AdsGqz/OpvSTep 3nzuKayU1udifLEC+gfF5jCLeq5TVoIXf/DQdl1pRULKlwa0e8Y5H1fZXImSlDIyABs/ A7mREZrZoVV7MOMFnFt9NzlPvksX5votUXxZkNOd2tqv/IUjulTkNyY2sJkcYKzJ/PAE zDvw==
X-Gm-Message-State: APf1xPAfU7lACK4c0Xaywl6gaLm2mLvUsxCLnvSAcfLcHYLkhtfFPBVI 09sLZPEvlImgVvB1HIb+PdfEsQ60Wu+FB81rG/k=
X-Google-Smtp-Source: AG47ELsfoQKAWgmXnxIx7SZZPQXGXN8pgx3UOwfLIknZ+Qt+iF8CsKHW0fW/+96ae9XBcPSwhZ6h2RRRYwOC/FANsPA=
X-Received: by 10.157.24.48 with SMTP id b45mr9128336ote.195.1519675404557; Mon, 26 Feb 2018 12:03:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.74.3.71 with HTTP; Mon, 26 Feb 2018 12:02:53 -0800 (PST)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1ABB3E@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C19C590@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C1ABB3E@ESESSMB109.ericsson.se>
From: Ted Hardie 
Date: Mon, 26 Feb 2018 12:02:53 -0800
Message-ID: 
To: Christer Holmberg 
Cc: "ice@ietf.org" , Ben Campbell ,  "ice-chairs@ietf.org" 
Content-Type: multipart/alternative; boundary="001a113d6d86a9a393056623004f"
Archived-At: 
Subject: Re: [Ice] ICE change in role conflict ([was: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) - Role conflict issue)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 20:03:34 -0000

--001a113d6d86a9a393056623004f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 26, 2018 at 11:59 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi Ted,
>
>
>
> ICE re-start was suggested earlier, but people didn=E2=80=99t like it.
>
>
I missed that, my apologies for re-raising it then.


>
>
> I don=E2=80=99t think the solution adds very much complexity. It=E2=80=99=
s more or less
> supported already, the only difference is that we change =E2=80=9CMAY pic=
k a new
> tie-breaker value=E2=80=9D to =E2=80=9CMUST pick a new tie-breaker value=
=E2=80=9D.
>
>
>
> And, even if only one of the endpoints actually do pick a new value, and
> the other keeps the old value, things will still work :)
>
>
>

It sounds like this is the preferred way forward, and given the rarity, it
seems like an acceptable risk.

Move me into the "sounds okay" column,

thanks,

Ted


> Regards,
>
>
>
> Christer
>
>
>
> *From:* Ted Hardie [mailto:ted.ietf@gmail.com]
> *Sent:* 26 February 2018 21:44
> *To:* Christer Holmberg 
> *Cc:* ice@ietf.org; Ben Campbell ; ice-chairs@ietf.org
> *Subject:* Re: [Ice] ICE change in role conflict ([was: Eric Rescorla's
> No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding
> Security Considerations) - Role conflict issue)
>
>
>
> Hi Christer,
>
>
>
> On Sun, Feb 25, 2018 at 2:08 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> Hi,
>
>
>
> I ask the community to take a look at the suggested change below, and
> indicate whether you have any issues.
>
>
>
> *NUTSHELL:*
>
>
>
> *What=E2=80=99s the problem?*
>
>
>
> In case both agents assume the same role (might happen in certain 3PCC
> scenarios), AND use the same tie-breaker value (unlikely to happen, but
> possible in theory), which may cause both endpoints to send a 487 respons=
e.
>
>
>
> The 487 response will cause both endpoints and change their roles, and tr=
y
> again. But, unless they also change the tie-breaker value, the result wil=
l
> be the same: both will assume the same role (since both received 487), an=
d
> might use the same tie-breaker values.
>
>
>
>
>
> *What=E2=80=99s the solution?*
>
>
>
> Specify that, when an endpoint receives 487, and changes its role, it MUS=
T
> also change the tie-breaker value. That way, when both endpoints again tr=
y,
> unless the endpoints again choose the same tie-breaker value (even more
> unlikely) only one should send a 487, and the role conflict will be solve=
d.
>
>
>
>
>
> So, I propose something even simpler.  In the very rare case that the
> peers see that the tie-breaker values are the same, both sides should
> restart ICE.  Restarting ICE results in new tie-breaker values being
> selected in any case.
>
> My logic here is this:  this occurs pretty rarely to start with,
> essentially only in the case of third-party call control.  In that subset
> of cases, the two sides have to select the same value out of a 4-billion
> odd range.   So, at least hopefully, this is not a common occurrence.  Co=
de
> covering uncommon occurrences tends to bit rot.  Using "re-start ICE" mea=
ns
> re-using code that will be maintained for other reasons, where re-start
> with a new tie-breaker value will not be.
>
> I am willing to accept your current solution, though, if other folks are
> not concerned about the complexity.
>
> Ted
>
>
>
>
>
>
>
>
> *What if I don=E2=80=99t like the suggested solution?*
>
>
>
> Suggest something better (read: provide actual text
> change/removal/additions).
>
>
>
>
>
> *DETAILS:*
>
>
>
> Please see discussion thread below.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> *From:* Eric Rescorla [mailto:ekr@rtfm.com]
> *Sent:* 24 February 2018 22:53
> *To:* Christer Holmberg 
> *Cc:* Taylor Brandstetter ; Ben Campbell <
> ben@nostrum.com>; ice-chairs@ietf.org; ice@ietf.org;
> draft-ietf-ice-rfc5245bis@ietf.org; pthatcher@google.com; The IESG <
> iesg@ietf.org>
> *Subject:* Re: [Ice] Eric Rescorla's No Objection on
> draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security
> Considerations) - Role conflict issue
>
>
>
>
>
>
>
> On Sat, Feb 24, 2018 at 12:37 PM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> Hi,
>
>
>
> I had a closer look at the role conflict issue.
>
>
>
> First, the draft already covers the case when the tie-breaker values are
> identical. It is described in section 7.3.1.1:
>
>
>
>    =E2=80=9CIf the agent's tie-breaker value is larger than *or equal to*=
=E2=80=A6=E2=80=9D
>
>
>
> Yes. My point is that this is broken.
>
>
>
>
>
>
>
> =E2=80=A6the agent sends 487.
>
>
>
> Then, according to section 7.2.5.1., when an agent receives the 487
> response it will change its role.
>
>
>
> Now, if BOTH agents send 487, it means BOTH agents will switch their
> roles, and try again. Now, since both agents switch their role, and keep
> the same tie-breaker value, the result will again be the same (only with
> different roles).
>
>
>
> Yes, so they oscillate back and forth.
>
>
>
>
>
>
>
> Section 7.2.5.1:
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
>
> OLD:
>
>
>
> Once the agent has switched its role, the agent MUST add the
>
> candidate pair whose check generated the 487 error response to the
>
> triggered check queue associated with the check list to which the
>
> pair belongs, and set the candidate pair state to Waiting.  When the
>
> triggered connectivity check is later performed, the ICE-CONTROLLING/
>
> ICE-CONTROLLED attribute of the Binding request will indicate the
>
> agent's new role.  The agent *MAY* change the tie-breaker value.
>
>
>
>
>
> NEW:
>
>
>
> Once the agent has switched its role, the agent MUST add the
>
> candidate pair whose check generated the 487 error response to the
>
> triggered check queue associated with the check list to which the
>
> pair belongs, and set the candidate pair state to Waiting.  When the
>
> triggered connectivity check is later performed, the ICE-CONTROLLING/
>
> ICE-CONTROLLED attribute of the Binding request will indicate the
>
> agent's new role.  The agent *MUST* change the tie-breaker value.
>
>
>
>
>
> Section 16.1:
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
>
> OLD:
>
>
>
> An ICE agent MUST use the same number for all
>
> Binding requests, for all streams, within an ICE session. The agent
>
> MAY change the number when an ICE restart occurs.
>
>
>
> NEW:
>
>
>
> An ICE agent MUST use the same number for all
>
> Binding requests, for all streams, within an ICE session*, unless *
>
> *it receives a 487 response, in which case it MUST change the*
>
> *number (Section 7.2.5.1).* The agent MAY change the number when
>
> an ICE restart occurs.
>
>
>
> Problem solved? :)
>
>
>
> This would be fine with me, but presumably needs WG signoff.
>
>
>
> -Ekr
>
>
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> *From:* Eric Rescorla [mailto:ekr@rtfm.com]
> *Sent:* 21 February 2018 01:07
> *To:* Taylor Brandstetter 
> *Cc:* Christer Holmberg ; Ben Campbell <
> ben@nostrum.com>; ice-chairs@ietf.org; ice@ietf.org;
> draft-ietf-ice-rfc5245bis@ietf.org; pthatcher@google.com; The IESG <
> iesg@ietf.org>
> *Subject:* Re: [Ice] Eric Rescorla's No Objection on
> draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security
> Considerations)
>
>
>
> I wouldn't object if someone produced a principled fix. I just don't want
> to create a lot of work for people
>
>
>
>
>
> On Tue, Feb 20, 2018 at 2:51 PM, Taylor Brandstetter 
> wrote:
>
> The tie-breaker collision problem has come up a few times before,
> actually. As I've said, I believe it could be fixed very easily by saying
> "pick a new tie-breaker if this happens."
>
>
>
> As for the "MUST not change tie-breaker" rule in section 16.1, requiring
> an ICE restart is overkill. We can just change it to "MUST not change
> tie-breaker* unless there's a collision*."
>
>
>
> On Mon, Feb 19, 2018 at 10:33 AM, Eric Rescorla  wrote:
>
>
>
>
>
> On Mon, Feb 19, 2018 at 10:29 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
>
> Hi,
>
> ...
>
> >>>> IF we really want to solve this, one simple solution be to say that,
> if this happens, and endpoint simply calculates a
> >>>> new tie-breaker value, and tries again? BUT, then we would have to
> change section 16.1, which says that a new value can only be calculated a=
t
> an ICE restart.
> >>>>
> >>>> So, could we simply say that, if this happens, the agent MUST do an
> ICE restart, and it MUST calculate a new tie-breaker value?
> >>>
> >>> Now both sides might do a simultaneous restart. Is that going to work=
?
> >>
> >> We could say that the initiating agent MUST do the restart.
> >
> > In this scenario, don't both sides believe they are the initiating peer=
,
> hence the need for the tiebreaker?
>
> Probably...
>
> But, then I don't see what we could do. If both agents send a check, and
> receive 487, we can't define a procedure for one of the agents.
>
> Perhaps we should then change the must-not-change-the-value-unless-restar=
t
> and say that an agent changes the tie-breaker value and try again.
>
>
>
> As you say, the problem is inherently that the situation is symmetrical.
>
>
>
> At this point in the design process, I don't think it's worth trying to
> actually make the call succeed; a 2^{-64} failure rate is much lower than
> organic call failure rates from other causes, even in non-3PCC scenarios.
> Rather, I think the spec should just prescribe a clean failure mode via a
> new error code, rather than having both sides wildly oscillate between
> controlled and controlling
>
>
>
> -Ekr
>
>
>
>
> Regards,
>
> Christer
>
>
>
>
>
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice
>
>
>
>
>
>
>
>
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice
>
>
>

--001a113d6d86a9a393056623004f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Mon, Feb 26, 2018 at 11:59 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:











Hi Ted,


=C2=A0


ICE re-start was suggested earlier, b=
ut people didn=E2=80=99t like it.




I missed that, my apologies for re-raising it the=
n.
=C2=A0
=C2=A0


I don=E2=80=99t think the solution ad=
ds very much complexity. It=E2=80=99s more or less supported already, the o=
nly difference is that we change =E2=80=9CMAY
 pick a new tie-breaker value=E2=80=9D to =E2=80=9CMUST pick a new tie-brea=
ker value=E2=80=9D.


=C2=A0


And, even if only one of the endpoint=
s actually do pick a new value, and the other keeps the old value, things w=
ill still work :)


=C2=A0

It sounds like this is the preferred way forwa=
rd, and given the rarity, it seems like an acceptable risk.

Move me into the "sounds okay" column,

thank=
s,

Ted
=C2=A0
<=
/u>


Regards,


=C2=A0


Christer


<=
span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c=
olor:#1f497d">=C2=A0


From: =
Ted Hardie [mailto:=
ted.ietf@gmail.com]


Sent: 26 February 2018 21:44

To: Christer Holmberg <christer.holmberg@ericsson.com>

Cc: ice@ietf.org; Ben Campbell <b=
en@nostrum.com>; ice-chairs@ietf.org

Subject: Re: [Ice] ICE change in role conflict ([was: Eric Rescorla&=
#39;s No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excludi=
ng Security Considerations) - Role conflict issue)
=



=C2=A0




Hi Christer,






=C2=A0




On Sun, Feb 25, 2018 at 2:08 AM, Christer Holmberg &=
lt;chri=
ster.holmberg@ericsson.com> wrote:








Hi,


=C2=A0


I ask the community to take a look at=
 the suggested change below, and indicate whether you have any
 issues.


=C2=A0


NUTSHELL:=



=C2=A0


What=E2=80=99s the problem?=



=C2=A0


In case both agents assume the same r=
ole (might happen in certain 3PCC scenarios), AND use the same
 tie-breaker value (unlikely to happen, but possible in theory), which may =
cause both endpoints to send a 487 response.


=C2=A0


The 487 response will cause both endp=
oints and change their roles, and try again. But, unless they
 also change the tie-breaker value, the result will be the same: both will =
assume the same role (since both received 487), and might use the same tie-=
breaker values.


=C2=A0


=C2=A0


What=E2=80=99s the solution?


=C2=A0


Specify that, when an endpoint receiv=
es 487, and changes its role, it MUST also change the tie-breaker
 value. That way, when both endpoints again try, unless the endpoints again=
 choose the same tie-breaker value (even more unlikely) only one should sen=
d a 487, and the role conflict will be solved.


=C2=A0










=C2=A0




So, I propose somethi=
ng even simpler.=C2=A0 In the very rare case that the peers see that the ti=
e-breaker values are the same, both sides should restart ICE.=C2=A0 Restart=
ing ICE results in new tie-breaker values being
 selected in any case.






My logic here is this=
:=C2=A0 this occurs pretty rarely to start with, essentially only in the ca=
se of third-party call control.=C2=A0 In that subset of cases, the two side=
s have to select the same value out of a 4-billion
 odd range. =C2=A0 So, at least hopefully, this is not a common occurrence.=
=C2=A0 Code covering uncommon occurrences tends to bit rot.=C2=A0 Using &qu=
ot;re-start ICE" means re-using code that will be maintained for other=
 reasons, where re-start with a new tie-breaker value will
 not be.






I am willing to accep=
t your current solution, though, if other folks are not concerned about the=
 complexity.






Ted






=C2=A0










=C2=A0










=C2=A0


What if I don=E2=80=99t like the s=
uggested solution?


=C2=A0


Suggest something better (read: provi=
de actual text change/removal/additions).


=C2=A0


=C2=A0


DETAILS:<=
/p>

=C2=A0


Please see discussion thread below.


=C2=A0


Regards,


=C2=A0


Christer


=C2=A0


=C2=A0


=C2=A0


From: =
Eric
 Rescorla [mailto:ekr@rtf=
m.com]


Sent: 24 February 2018 22:53

To: Christer Holmberg <christer.holmberg@ericsson.com>

Cc: Taylor Brandstetter <deadbeef@google.com>; Ben Campbell <ben@nostrum.com>;
ice-chairs@ietf.or=
g; 
ice@ietf.org; 
draft-ietf-ice-rfc5245bis@ietf.org; 
pthatcher@google.com; The IESG <iesg@ietf.org>

Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ic=
e-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) - Role =
conflict issue


=C2=A0




=C2=A0




=C2=A0




On Sat, Feb 24, 2018 at 12:37 PM, Christer Holmberg =
<chr=
ister.holmberg@ericsson.com> wrote:








Hi,


=C2=A0


I had a closer look at the role confl=
ict issue.


=C2=A0


First, the draft already covers the c=
ase when the tie-breaker values are identical. It is described
 in section 7.3.1.1:


=C2=A0


=C2=A0=C2=A0 =E2=80=9CIf the agent=
9;s tie-breaker value is larger than
or equal to=E2=80=A6=E2=80=9D










=C2=A0






Yes. My point is that this is broken.<=
/p>





=C2=A0






=C2=A0










=C2=A0


=E2=80=A6the agent sends 487.



=C2=A0


Then, according to section 7.2.5.1., =
when an agent receives the 487 response it will change its role.<=
/u>


=C2=A0


Now, if BOTH agents send 487, it mean=
s BOTH agents will switch their roles, and try again. Now, since
 both agents switch their role, and keep the same tie-breaker value, the re=
sult will again be the same (only with different roles).










=C2=A0






Yes, so they oscillate back and forth.=







=C2=A0






=C2=A0






=C2=A0










Section
7.2.5.1:<=
/u>


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D


=C2=A0


OLD:


=C2=A0


Once the agent has switched its role,=
 the agent MUST add the


candidate pair whose check generated =
the 487 error response to the


triggered check queue associated with=
 the check list to which the


pair belongs, and set the candidate p=
air state to Waiting.=C2=A0 When the


triggered connectivity check is later=
 performed, the ICE-CONTROLLING/


ICE-CONTROLLED attribute of the Bindi=
ng request will indicate the


agent's new role.=C2=A0 The agent
MAY change the tie-breaker value.


=C2=A0


=C2=A0


NEW:


=C2=A0


Once the agent has switched its role,=
 the agent MUST add the


candidate pair whose check generated =
the 487 error response to the


triggered check queue associated with=
 the check list to which the


pair belongs, and set the candidate p=
air state to Waiting.=C2=A0 When the


triggered connectivity check is later=
 performed, the ICE-CONTROLLING/


ICE-CONTROLLED attribute of the Bindi=
ng request will indicate the


agent's new role.=C2=A0 The agent
MUST change the tie-breaker value.


=C2=A0


=C2=A0


Section 16.1:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


=C2=A0


OLD:


=C2=A0


An ICE agent MUST use the same number=
 for all


Binding requests, for all streams, wi=
thin an ICE session. The agent


MAY change the number when an ICE res=
tart occurs.


=C2=A0


NEW:


=C2=A0


An ICE agent MUST use the same number=
 for all


Binding requests, for all streams, wi=
thin an ICE session, unless



it receives a 487 response, in whi=
ch case it MUST change the


number (Section 7.2.5.1).
 The agent MAY change the number when 


an ICE restart occurs.<=
u>


=C2=A0


Problem solved? :)










=C2=A0






This would be fine with me, but presumably needs WG =
signoff.






=C2=A0






-Ekr






=C2=A0










=C2=A0


Regards,


=C2=A0


Christer


=C2=A0


=C2=A0


=C2=A0


From: =
Eric
 Rescorla [mailto:ekr@rtf=
m.com]


Sent: 21 February 2018 01:07

To: Taylor Brandstetter <deadbeef@google.com>

Cc: Christer Holmberg <christer.holmberg@ericsson.com>; Ben =
Campbell <ben@nostr=
um.com>;
ice-chairs@ietf.or=
g; 
ice@ietf.org; 
draft-ietf-ice-rfc5245bis@ietf.org; 
pthatcher@google.com; The IESG <iesg@ietf.org>

Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ic=
e-rfc5245bis-17: (with COMMENT) (excluding Security Considerations)<=
u>


=C2=A0


I wouldn't object if someone produced a principl=
ed fix. I just don't want to create a lot of work for people<=
/u>


=C2=A0=C2=A0


=C2=A0




On Tue, Feb 20, 2018 at 2:51 PM, Taylor Brandstetter=
 <deadbeef@goog=
le.com> wrote:






The tie-breaker collision problem has c=
ome up a few times before, actually. As I've said, I believe=C2=A0it
 could be fixed very easily by saying "pick a new tie-breaker if this =
happens."




=C2=A0






As for the "MUST not change tie-breaker" r=
ule in section 16.1, requiring an ICE restart is overkill. We can just chan=
ge it to "MUST not change tie-breaker unless there's a collisio=
n."








=C2=A0








On Mon, Feb 19, 2018 at 10:33 AM, Eric Rescorla <=
ekr@rtfm.com> wrot=
e:














=C2=A0




=C2=A0




On Mon, Feb 19, 2018 at 10:29 AM, Christer Holmberg =
<chr=
ister.holmberg@ericsson.com> wrote:




Hi,



...



>>>> IF we really want to solve this, one simple solution be to=
 say that, if this happens, and endpoint simply calculates a

>>>> new tie-breaker value, and tries again? BUT, then we would=
 have to change section 16.1, which says that a new value can only be calcu=
lated at an ICE restart.

>>>>

>>>> So, could we simply say that, if this happens, the agent M=
UST do an ICE restart, and it MUST calculate a new tie-breaker value?

>>>

>>> Now both sides might do a simultaneous restart. Is that going =
to work?

>>

>> We could say that the initiating agent MUST do the restart.

>

> In this scenario, don't both sides believe they are the initiating=
 peer, hence the need for the tiebreaker?



Probably...



But, then I don't see what we could do. If both agents send a check, an=
d receive 487, we can't define a procedure for one of the agents.



Perhaps we should then change the must-not-change-the-value-unless-res=
tart and say that an agent changes the tie-breaker value and try again.<=
/u>






=C2=A0






As you say, the problem is inherently that the situa=
tion is symmetrical.






=C2=A0






At this point in the design process, I don't thi=
nk it's worth trying to actually make the call succeed; a 2^{-64} failu=
re rate is much lower than organic call failure rates from
 other causes, even in non-3PCC scenarios. Rather, I think the spec should =
just prescribe a clean failure mode via a new error code, rather than havin=
g both sides wildly oscillate between controlled and controlling<=
/u>






=C2=A0






-Ekr






=C2=A0








Regards,



Christer






=C2=A0






=C2=A0






_____________________=
__________________________

Ice mailing list

Ice@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/ice






=C2=A0














=C2=A0
















=C2=A0












_______________________________________________

Ice mailing list

Ice@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/ice






=C2=A0
















--001a113d6d86a9a393056623004f--


From nobody Mon Feb 26 12:07:49 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AFA12D87F for ; Mon, 26 Feb 2018 12:07:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu9ZUb51s6AT for ; Mon, 26 Feb 2018 12:07:46 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E946012D82F for ; Mon, 26 Feb 2018 12:07:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519675663; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bZBiA6Saf+gknq85BwjjJExxRauvbrH30AnwxXbrJ6g=; b=LTQfljGpfLAvdaIpuFgjk/6eGXvAA4spGOg3phhu0J2PUs6i9hXNH6FNskn5VWyO OWzc04KhhubxX4YgO8iGdMdQ1pAG895Ln3nrDft5Kdu1wEpoCeCCfYv+cBq8RB6Q O8LYSGv30G3NNnDreyW/ku20lgGMZWLlTorB/bUkPko=;
X-AuditID: c1b4fb25-06bff70000002d5f-94-5a94690f086e
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 30.F1.11615.F09649A5; Mon, 26 Feb 2018 21:07:43 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Mon, 26 Feb 2018 21:07:42 +0100
From: Christer Holmberg 
To: Ted Hardie 
CC: "ice@ietf.org" , Ben Campbell , "ice-chairs@ietf.org" 
Thread-Topic: [Ice] ICE change in role conflict ([was: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) - Role conflict issue)
Thread-Index: AdOuH3YziFMqGJv8S0OuiisPdqGWggBElyuAAAJtsRD///G7gP//7j3w
Date: Mon, 26 Feb 2018 20:07:41 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1ABBBD@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C19C590@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C1ABB3E@ESESSMB109.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.170]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGbFdVJc/c0qUwc6b0hbzO0+zW1ycNZnN 4tuFWovGuXYOLB47Z91l91iy5CeTx6ydT1gCmKO4bFJSczLLUov07RK4MjoPHWUruBBX0TZ3 BnsD44yYLkZODgkBE4lTy96zg9hCAocZJa6t0e9i5AKyFzNKLF76mrGLkYODTcBCovufNkiN iICyxN4rO9hAbGaBAomtfxeygdQLCxxklDi6t4UZougQo8S/I+wQtpvEkjVLmEBsFgFViW/7 lzOC2LwCvhKtF66yQyybzyQx8cMzsASnQKDEpAnHWUBsRgExie+n1jBBbBOXuPVkPhPE1QIS S/acZ4awRSVePv7HCmErSZzZ9JwF5GhmAU2J9bv0IVoVJaZ0P2SH2CsocXLmE5YJjKKzkEyd hdAxC0nHLCQdCxhZVjGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIExs/BLb9VdzBefuN4iFGA g1GJh3dOxpQoIdbEsuLKXGB4cDArifCuXDw5Sog3JbGyKrUoP76oNCe1+BCjNAeLkjjvHOH2 KCGB9MSS1OzU1ILUIpgsEwenVANj94OE+O4Dwr2Gz+fyFu1/r9VxXPPj3d2XbR/MufRGcFJU X6RKzfZb3NUF21v/hq06c728u/3YyomPFz87dXnlwzXb01cYrFx/5OJFm7rwr2tSWP69mWpp WSetdiTz0GVP7Zu+V6/ueFG36PKjdx6zuuLn51r6ZByeK9v5f+2Gjbq8Rw9+s/m4fLISS3FG oqEWc1FxIgBzXhcwmwIAAA==
Archived-At: 
Subject: Re: [Ice] ICE change in role conflict ([was: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) - Role conflict issue)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 20:07:48 -0000

SGksDQoNCj4+IElDRSByZS1zdGFydCB3YXMgc3VnZ2VzdGVkIGVhcmxpZXIsIGJ1dCBwZW9wbGUg
ZGlkbuKAmXQgbGlrZSBpdC4gDQo+DQo+IEkgbWlzc2VkIHRoYXQsIG15IGFwb2xvZ2llcyBmb3Ig
cmUtcmFpc2luZyBpdCB0aGVuLg0KwqANCkRvbid0IHdvcnJ5IC0gaXQncyBuaWNlIHRvIHNlZSB0
aGF0IHRoZXJlIGFyZSBzdGlsbCBwZW9wbGUgYXJvdW5kIHdobyBhY3R1YWxseSBjYXJlIGFib3V0
IHRoZSBkcmFmdCA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQrCoA0KRnJvbTogVGVkIEhh
cmRpZSBbbWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbV0gDQpTZW50OiAyNiBGZWJydWFyeSAyMDE4
IDIxOjQ0DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u
LmNvbT4NCkNjOiBpY2VAaWV0Zi5vcmc7IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPjsg
aWNlLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJY2VdIElDRSBjaGFuZ2UgaW4gcm9s
ZSBjb25mbGljdCAoW3dhczogRXJpYyBSZXNjb3JsYSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1p
ZXRmLWljZS1yZmM1MjQ1YmlzLTE3OiAod2l0aCBDT01NRU5UKSAoZXhjbHVkaW5nIFNlY3VyaXR5
IENvbnNpZGVyYXRpb25zKSAtIFJvbGUgY29uZmxpY3QgaXNzdWUpDQrCoA0KSGkgQ2hyaXN0ZXIs
DQrCoA0KT24gU3VuLCBGZWIgMjUsIDIwMTggYXQgMjowOCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcg
PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQpIaSwNCsKgDQpJIGFzayB0
aGUgY29tbXVuaXR5IHRvIHRha2UgYSBsb29rIGF0IHRoZSBzdWdnZXN0ZWQgY2hhbmdlIGJlbG93
LCBhbmQgaW5kaWNhdGUgd2hldGhlciB5b3UgaGF2ZSBhbnkgaXNzdWVzLg0KwqANCk5VVFNIRUxM
Og0KwqANCldoYXTigJlzIHRoZSBwcm9ibGVtPw0KwqANCkluIGNhc2UgYm90aCBhZ2VudHMgYXNz
dW1lIHRoZSBzYW1lIHJvbGUgKG1pZ2h0IGhhcHBlbiBpbiBjZXJ0YWluIDNQQ0Mgc2NlbmFyaW9z
KSwgQU5EIHVzZSB0aGUgc2FtZSB0aWUtYnJlYWtlciB2YWx1ZSAodW5saWtlbHkgdG8gaGFwcGVu
LCBidXQgcG9zc2libGUgaW4gdGhlb3J5KSwgd2hpY2ggbWF5IGNhdXNlIGJvdGggZW5kcG9pbnRz
IHRvIHNlbmQgYSA0ODcgcmVzcG9uc2UuDQrCoA0KVGhlIDQ4NyByZXNwb25zZSB3aWxsIGNhdXNl
IGJvdGggZW5kcG9pbnRzIGFuZCBjaGFuZ2UgdGhlaXIgcm9sZXMsIGFuZCB0cnkgYWdhaW4uIEJ1
dCwgdW5sZXNzIHRoZXkgYWxzbyBjaGFuZ2UgdGhlIHRpZS1icmVha2VyIHZhbHVlLCB0aGUgcmVz
dWx0IHdpbGwgYmUgdGhlIHNhbWU6IGJvdGggd2lsbCBhc3N1bWUgdGhlIHNhbWUgcm9sZSAoc2lu
Y2UgYm90aCByZWNlaXZlZCA0ODcpLCBhbmQgbWlnaHQgdXNlIHRoZSBzYW1lIHRpZS1icmVha2Vy
IHZhbHVlcy4NCsKgDQrCoA0KV2hhdOKAmXMgdGhlIHNvbHV0aW9uPw0KwqANClNwZWNpZnkgdGhh
dCwgd2hlbiBhbiBlbmRwb2ludCByZWNlaXZlcyA0ODcsIGFuZCBjaGFuZ2VzIGl0cyByb2xlLCBp
dCBNVVNUIGFsc28gY2hhbmdlIHRoZSB0aWUtYnJlYWtlciB2YWx1ZS4gVGhhdCB3YXksIHdoZW4g
Ym90aCBlbmRwb2ludHMgYWdhaW4gdHJ5LCB1bmxlc3MgdGhlIGVuZHBvaW50cyBhZ2FpbiBjaG9v
c2UgdGhlIHNhbWUgdGllLWJyZWFrZXIgdmFsdWUgKGV2ZW4gbW9yZSB1bmxpa2VseSkgb25seSBv
bmUgc2hvdWxkIHNlbmQgYSA0ODcsIGFuZCB0aGUgcm9sZSBjb25mbGljdCB3aWxsIGJlIHNvbHZl
ZC4NCsKgDQrCoA0KU28sIEkgcHJvcG9zZSBzb21ldGhpbmcgZXZlbiBzaW1wbGVyLsKgIEluIHRo
ZSB2ZXJ5IHJhcmUgY2FzZSB0aGF0IHRoZSBwZWVycyBzZWUgdGhhdCB0aGUgdGllLWJyZWFrZXIg
dmFsdWVzIGFyZSB0aGUgc2FtZSwgYm90aCBzaWRlcyBzaG91bGQgcmVzdGFydCBJQ0UuwqAgUmVz
dGFydGluZyBJQ0UgcmVzdWx0cyBpbiBuZXcgdGllLWJyZWFrZXIgdmFsdWVzIGJlaW5nIHNlbGVj
dGVkIGluIGFueSBjYXNlLg0KTXkgbG9naWMgaGVyZSBpcyB0aGlzOsKgIHRoaXMgb2NjdXJzIHBy
ZXR0eSByYXJlbHkgdG8gc3RhcnQgd2l0aCwgZXNzZW50aWFsbHkgb25seSBpbiB0aGUgY2FzZSBv
ZiB0aGlyZC1wYXJ0eSBjYWxsIGNvbnRyb2wuwqAgSW4gdGhhdCBzdWJzZXQgb2YgY2FzZXMsIHRo
ZSB0d28gc2lkZXMgaGF2ZSB0byBzZWxlY3QgdGhlIHNhbWUgdmFsdWUgb3V0IG9mIGEgNC1iaWxs
aW9uIG9kZCByYW5nZS4gwqAgU28sIGF0IGxlYXN0IGhvcGVmdWxseSwgdGhpcyBpcyBub3QgYSBj
b21tb24gb2NjdXJyZW5jZS7CoCBDb2RlIGNvdmVyaW5nIHVuY29tbW9uIG9jY3VycmVuY2VzIHRl
bmRzIHRvIGJpdCByb3QuwqAgVXNpbmcgInJlLXN0YXJ0IElDRSIgbWVhbnMgcmUtdXNpbmcgY29k
ZSB0aGF0IHdpbGwgYmUgbWFpbnRhaW5lZCBmb3Igb3RoZXIgcmVhc29ucywgd2hlcmUgcmUtc3Rh
cnQgd2l0aCBhIG5ldyB0aWUtYnJlYWtlciB2YWx1ZSB3aWxsIG5vdCBiZS4NCkkgYW0gd2lsbGlu
ZyB0byBhY2NlcHQgeW91ciBjdXJyZW50IHNvbHV0aW9uLCB0aG91Z2gsIGlmIG90aGVyIGZvbGtz
IGFyZSBub3QgY29uY2VybmVkIGFib3V0IHRoZSBjb21wbGV4aXR5Lg0KVGVkDQrCoA0KDQrCoA0K
wqANCldoYXQgaWYgSSBkb27igJl0IGxpa2UgdGhlIHN1Z2dlc3RlZCBzb2x1dGlvbj8NCsKgDQpT
dWdnZXN0IHNvbWV0aGluZyBiZXR0ZXIgKHJlYWQ6IHByb3ZpZGUgYWN0dWFsIHRleHQgY2hhbmdl
L3JlbW92YWwvYWRkaXRpb25zKS4NCsKgDQrCoA0KREVUQUlMUzoNCsKgDQpQbGVhc2Ugc2VlIGRp
c2N1c3Npb24gdGhyZWFkIGJlbG93Lg0KwqANClJlZ2FyZHMsDQrCoA0KQ2hyaXN0ZXINCsKgDQrC
oA0KwqANCkZyb206IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dIA0KU2VudDog
MjQgRmVicnVhcnkgMjAxOCAyMjo1Mw0KVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5o
b2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogVGF5bG9yIEJyYW5kc3RldHRlciA8ZGVhZGJlZWZA
Z29vZ2xlLmNvbT47IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPjsgaWNlLWNoYWlyc0Bp
ZXRmLm9yZzsgaWNlQGlldGYub3JnOyBkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYub3Jn
OyBwdGhhdGNoZXJAZ29vZ2xlLmNvbTsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQpTdWJqZWN0
OiBSZTogW0ljZV0gRXJpYyBSZXNjb3JsYSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWlj
ZS1yZmM1MjQ1YmlzLTE3OiAod2l0aCBDT01NRU5UKSAoZXhjbHVkaW5nIFNlY3VyaXR5IENvbnNp
ZGVyYXRpb25zKSAtIFJvbGUgY29uZmxpY3QgaXNzdWUNCsKgDQrCoA0KwqANCk9uIFNhdCwgRmVi
IDI0LCAyMDE4IGF0IDEyOjM3IFBNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJl
cmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCkhpLA0KwqANCkkgaGFkIGEgY2xvc2VyIGxvb2sgYXQg
dGhlIHJvbGUgY29uZmxpY3QgaXNzdWUuDQrCoA0KRmlyc3QsIHRoZSBkcmFmdCBhbHJlYWR5IGNv
dmVycyB0aGUgY2FzZSB3aGVuIHRoZSB0aWUtYnJlYWtlciB2YWx1ZXMgYXJlIGlkZW50aWNhbC4g
SXQgaXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gNy4zLjEuMToNCsKgDQrCoMKgIOKAnElmIHRoZSBh
Z2VudCdzIHRpZS1icmVha2VyIHZhbHVlIGlzIGxhcmdlciB0aGFuIG9yIGVxdWFsIHRv4oCm4oCd
DQrCoA0KWWVzLiBNeSBwb2ludCBpcyB0aGF0IHRoaXMgaXMgYnJva2VuLg0KwqANCsKgDQrCoA0K
4oCmdGhlIGFnZW50IHNlbmRzIDQ4Ny4gDQrCoA0KVGhlbiwgYWNjb3JkaW5nIHRvIHNlY3Rpb24g
Ny4yLjUuMS4sIHdoZW4gYW4gYWdlbnQgcmVjZWl2ZXMgdGhlIDQ4NyByZXNwb25zZSBpdCB3aWxs
IGNoYW5nZSBpdHMgcm9sZS4NCsKgDQpOb3csIGlmIEJPVEggYWdlbnRzIHNlbmQgNDg3LCBpdCBt
ZWFucyBCT1RIIGFnZW50cyB3aWxsIHN3aXRjaCB0aGVpciByb2xlcywgYW5kIHRyeSBhZ2Fpbi4g
Tm93LCBzaW5jZSBib3RoIGFnZW50cyBzd2l0Y2ggdGhlaXIgcm9sZSwgYW5kIGtlZXAgdGhlIHNh
bWUgdGllLWJyZWFrZXIgdmFsdWUsIHRoZSByZXN1bHQgd2lsbCBhZ2FpbiBiZSB0aGUgc2FtZSAo
b25seSB3aXRoIGRpZmZlcmVudCByb2xlcykuDQrCoA0KWWVzLCBzbyB0aGV5IG9zY2lsbGF0ZSBi
YWNrIGFuZCBmb3J0aC4NCsKgDQrCoA0KwqANClNlY3Rpb24gNy4yLjUuMToNCj09PT09PT09PT09
PT0NCsKgDQpPTEQ6DQrCoA0KT25jZSB0aGUgYWdlbnQgaGFzIHN3aXRjaGVkIGl0cyByb2xlLCB0
aGUgYWdlbnQgTVVTVCBhZGQgdGhlDQpjYW5kaWRhdGUgcGFpciB3aG9zZSBjaGVjayBnZW5lcmF0
ZWQgdGhlIDQ4NyBlcnJvciByZXNwb25zZSB0byB0aGUNCnRyaWdnZXJlZCBjaGVjayBxdWV1ZSBh
c3NvY2lhdGVkIHdpdGggdGhlIGNoZWNrIGxpc3QgdG8gd2hpY2ggdGhlDQpwYWlyIGJlbG9uZ3Ms
IGFuZCBzZXQgdGhlIGNhbmRpZGF0ZSBwYWlyIHN0YXRlIHRvIFdhaXRpbmcuwqAgV2hlbiB0aGUN
CnRyaWdnZXJlZCBjb25uZWN0aXZpdHkgY2hlY2sgaXMgbGF0ZXIgcGVyZm9ybWVkLCB0aGUgSUNF
LUNPTlRST0xMSU5HLw0KSUNFLUNPTlRST0xMRUQgYXR0cmlidXRlIG9mIHRoZSBCaW5kaW5nIHJl
cXVlc3Qgd2lsbCBpbmRpY2F0ZSB0aGUNCmFnZW50J3MgbmV3IHJvbGUuwqAgVGhlIGFnZW50IE1B
WSBjaGFuZ2UgdGhlIHRpZS1icmVha2VyIHZhbHVlLg0KwqANCsKgDQpORVc6DQrCoA0KT25jZSB0
aGUgYWdlbnQgaGFzIHN3aXRjaGVkIGl0cyByb2xlLCB0aGUgYWdlbnQgTVVTVCBhZGQgdGhlDQpj
YW5kaWRhdGUgcGFpciB3aG9zZSBjaGVjayBnZW5lcmF0ZWQgdGhlIDQ4NyBlcnJvciByZXNwb25z
ZSB0byB0aGUNCnRyaWdnZXJlZCBjaGVjayBxdWV1ZSBhc3NvY2lhdGVkIHdpdGggdGhlIGNoZWNr
IGxpc3QgdG8gd2hpY2ggdGhlDQpwYWlyIGJlbG9uZ3MsIGFuZCBzZXQgdGhlIGNhbmRpZGF0ZSBw
YWlyIHN0YXRlIHRvIFdhaXRpbmcuwqAgV2hlbiB0aGUNCnRyaWdnZXJlZCBjb25uZWN0aXZpdHkg
Y2hlY2sgaXMgbGF0ZXIgcGVyZm9ybWVkLCB0aGUgSUNFLUNPTlRST0xMSU5HLw0KSUNFLUNPTlRS
T0xMRUQgYXR0cmlidXRlIG9mIHRoZSBCaW5kaW5nIHJlcXVlc3Qgd2lsbCBpbmRpY2F0ZSB0aGUN
CmFnZW50J3MgbmV3IHJvbGUuwqAgVGhlIGFnZW50IE1VU1QgY2hhbmdlIHRoZSB0aWUtYnJlYWtl
ciB2YWx1ZS4NCsKgDQrCoA0KU2VjdGlvbiAxNi4xOg0KPT09PT09PT09PT0NCsKgDQpPTEQ6DQrC
oA0KQW4gSUNFIGFnZW50IE1VU1QgdXNlIHRoZSBzYW1lIG51bWJlciBmb3IgYWxsDQpCaW5kaW5n
IHJlcXVlc3RzLCBmb3IgYWxsIHN0cmVhbXMsIHdpdGhpbiBhbiBJQ0Ugc2Vzc2lvbi4gVGhlIGFn
ZW50DQpNQVkgY2hhbmdlIHRoZSBudW1iZXIgd2hlbiBhbiBJQ0UgcmVzdGFydCBvY2N1cnMuDQrC
oA0KTkVXOg0KwqANCkFuIElDRSBhZ2VudCBNVVNUIHVzZSB0aGUgc2FtZSBudW1iZXIgZm9yIGFs
bA0KQmluZGluZyByZXF1ZXN0cywgZm9yIGFsbCBzdHJlYW1zLCB3aXRoaW4gYW4gSUNFIHNlc3Np
b24sIHVubGVzcyANCml0IHJlY2VpdmVzIGEgNDg3IHJlc3BvbnNlLCBpbiB3aGljaCBjYXNlIGl0
IE1VU1QgY2hhbmdlIHRoZQ0KbnVtYmVyIChTZWN0aW9uIDcuMi41LjEpLiBUaGUgYWdlbnQgTUFZ
IGNoYW5nZSB0aGUgbnVtYmVyIHdoZW4gDQphbiBJQ0UgcmVzdGFydCBvY2N1cnMuDQrCoA0KUHJv
YmxlbSBzb2x2ZWQ/IDopDQrCoA0KVGhpcyB3b3VsZCBiZSBmaW5lIHdpdGggbWUsIGJ1dCBwcmVz
dW1hYmx5IG5lZWRzIFdHIHNpZ25vZmYuDQrCoA0KLUVrcg0KwqANCsKgDQpSZWdhcmRzLA0KwqAN
CkNocmlzdGVyDQrCoA0KwqANCsKgDQpGcm9tOiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0
Zm0uY29tXSANClNlbnQ6IDIxIEZlYnJ1YXJ5IDIwMTggMDE6MDcNClRvOiBUYXlsb3IgQnJhbmRz
dGV0dGVyIDxkZWFkYmVlZkBnb29nbGUuY29tPg0KQ2M6IENocmlzdGVyIEhvbG1iZXJnIDxjaHJp
c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNv
bT47IGljZS1jaGFpcnNAaWV0Zi5vcmc7IGljZUBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1pY2UtcmZj
NTI0NWJpc0BpZXRmLm9yZzsgcHRoYXRjaGVyQGdvb2dsZS5jb207IFRoZSBJRVNHIDxpZXNnQGll
dGYub3JnPg0KU3ViamVjdDogUmU6IFtJY2VdIEVyaWMgUmVzY29ybGEncyBObyBPYmplY3Rpb24g
b24gZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpcy0xNzogKHdpdGggQ09NTUVOVCkgKGV4Y2x1ZGlu
ZyBTZWN1cml0eSBDb25zaWRlcmF0aW9ucykNCsKgDQpJIHdvdWxkbid0IG9iamVjdCBpZiBzb21l
b25lIHByb2R1Y2VkIGEgcHJpbmNpcGxlZCBmaXguIEkganVzdCBkb24ndCB3YW50IHRvIGNyZWF0
ZSBhIGxvdCBvZiB3b3JrIGZvciBwZW9wbGUNCsKgwqANCsKgDQpPbiBUdWUsIEZlYiAyMCwgMjAx
OCBhdCAyOjUxIFBNLCBUYXlsb3IgQnJhbmRzdGV0dGVyIDxkZWFkYmVlZkBnb29nbGUuY29tPiB3
cm90ZToNClRoZSB0aWUtYnJlYWtlciBjb2xsaXNpb24gcHJvYmxlbSBoYXMgY29tZSB1cCBhIGZl
dyB0aW1lcyBiZWZvcmUsIGFjdHVhbGx5LiBBcyBJJ3ZlIHNhaWQsIEkgYmVsaWV2ZcKgaXQgY291
bGQgYmUgZml4ZWQgdmVyeSBlYXNpbHkgYnkgc2F5aW5nICJwaWNrIGEgbmV3IHRpZS1icmVha2Vy
IGlmIHRoaXMgaGFwcGVucy4iDQrCoA0KQXMgZm9yIHRoZSAiTVVTVCBub3QgY2hhbmdlIHRpZS1i
cmVha2VyIiBydWxlIGluIHNlY3Rpb24gMTYuMSwgcmVxdWlyaW5nIGFuIElDRSByZXN0YXJ0IGlz
IG92ZXJraWxsLiBXZSBjYW4ganVzdCBjaGFuZ2UgaXQgdG8gIk1VU1Qgbm90IGNoYW5nZSB0aWUt
YnJlYWtlciB1bmxlc3MgdGhlcmUncyBhIGNvbGxpc2lvbi4iDQrCoA0KT24gTW9uLCBGZWIgMTks
IDIwMTggYXQgMTA6MzMgQU0sIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4gd3JvdGU6DQrC
oA0KwqANCk9uIE1vbiwgRmViIDE5LCAyMDE4IGF0IDEwOjI5IEFNLCBDaHJpc3RlciBIb2xtYmVy
ZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3cm90ZToNCkhpLA0KDQouLi4NCg0K
Pj4+PiBJRiB3ZSByZWFsbHkgd2FudCB0byBzb2x2ZSB0aGlzLCBvbmUgc2ltcGxlIHNvbHV0aW9u
IGJlIHRvIHNheSB0aGF0LCBpZiB0aGlzIGhhcHBlbnMsIGFuZCBlbmRwb2ludCBzaW1wbHkgY2Fs
Y3VsYXRlcyBhDQo+Pj4+IG5ldyB0aWUtYnJlYWtlciB2YWx1ZSwgYW5kIHRyaWVzIGFnYWluPyBC
VVQsIHRoZW4gd2Ugd291bGQgaGF2ZSB0byBjaGFuZ2Ugc2VjdGlvbiAxNi4xLCB3aGljaCBzYXlz
IHRoYXQgYSBuZXcgdmFsdWUgY2FuIG9ubHkgYmUgY2FsY3VsYXRlZCBhdCBhbiBJQ0UgcmVzdGFy
dC4NCj4+Pj4NCj4+Pj4gU28sIGNvdWxkIHdlIHNpbXBseSBzYXkgdGhhdCwgaWYgdGhpcyBoYXBw
ZW5zLCB0aGUgYWdlbnQgTVVTVCBkbyBhbiBJQ0UgcmVzdGFydCwgYW5kIGl0IE1VU1QgY2FsY3Vs
YXRlIGEgbmV3IHRpZS1icmVha2VyIHZhbHVlPw0KPj4+DQo+Pj4gTm93IGJvdGggc2lkZXMgbWln
aHQgZG8gYSBzaW11bHRhbmVvdXMgcmVzdGFydC4gSXMgdGhhdCBnb2luZyB0byB3b3JrPw0KPj4N
Cj4+IFdlIGNvdWxkIHNheSB0aGF0IHRoZSBpbml0aWF0aW5nIGFnZW50IE1VU1QgZG8gdGhlIHJl
c3RhcnQuDQo+DQo+IEluIHRoaXMgc2NlbmFyaW8sIGRvbid0IGJvdGggc2lkZXMgYmVsaWV2ZSB0
aGV5IGFyZSB0aGUgaW5pdGlhdGluZyBwZWVyLCBoZW5jZSB0aGUgbmVlZCBmb3IgdGhlIHRpZWJy
ZWFrZXI/DQoNClByb2JhYmx5Li4uDQoNCkJ1dCwgdGhlbiBJIGRvbid0IHNlZSB3aGF0IHdlIGNv
dWxkIGRvLiBJZiBib3RoIGFnZW50cyBzZW5kIGEgY2hlY2ssIGFuZCByZWNlaXZlIDQ4Nywgd2Ug
Y2FuJ3QgZGVmaW5lIGEgcHJvY2VkdXJlIGZvciBvbmUgb2YgdGhlIGFnZW50cy4NCg0KUGVyaGFw
cyB3ZSBzaG91bGQgdGhlbiBjaGFuZ2UgdGhlIG11c3Qtbm90LWNoYW5nZS10aGUtdmFsdWUtdW5s
ZXNzLXJlc3RhcnQgYW5kIHNheSB0aGF0IGFuIGFnZW50IGNoYW5nZXMgdGhlIHRpZS1icmVha2Vy
IHZhbHVlIGFuZCB0cnkgYWdhaW4uDQrCoA0KQXMgeW91IHNheSwgdGhlIHByb2JsZW0gaXMgaW5o
ZXJlbnRseSB0aGF0IHRoZSBzaXR1YXRpb24gaXMgc3ltbWV0cmljYWwuDQrCoA0KQXQgdGhpcyBw
b2ludCBpbiB0aGUgZGVzaWduIHByb2Nlc3MsIEkgZG9uJ3QgdGhpbmsgaXQncyB3b3J0aCB0cnlp
bmcgdG8gYWN0dWFsbHkgbWFrZSB0aGUgY2FsbCBzdWNjZWVkOyBhIDJeey02NH0gZmFpbHVyZSBy
YXRlIGlzIG11Y2ggbG93ZXIgdGhhbiBvcmdhbmljIGNhbGwgZmFpbHVyZSByYXRlcyBmcm9tIG90
aGVyIGNhdXNlcywgZXZlbiBpbiBub24tM1BDQyBzY2VuYXJpb3MuIFJhdGhlciwgSSB0aGluayB0
aGUgc3BlYyBzaG91bGQganVzdCBwcmVzY3JpYmUgYSBjbGVhbiBmYWlsdXJlIG1vZGUgdmlhIGEg
bmV3IGVycm9yIGNvZGUsIHJhdGhlciB0aGFuIGhhdmluZyBib3RoIHNpZGVzIHdpbGRseSBvc2Np
bGxhdGUgYmV0d2VlbiBjb250cm9sbGVkIGFuZCBjb250cm9sbGluZw0KwqANCi1Fa3INCsKgDQoN
ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQrCoA0KwqANCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQpJY2UgbWFpbGluZyBsaXN0DQpJY2VAaWV0Zi5vcmcNCmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlDQrCoA0KwqANCsKgDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJY2UgbWFpbGlu
ZyBsaXN0DQpJY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vaWNlDQrCoA0KDQo=


From nobody Mon Feb 26 13:09:58 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB51127201 for ; Mon, 26 Feb 2018 13:09:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 MF8o_B_X_KQ4 for ; Mon, 26 Feb 2018 13:09:55 -0800 (PST)
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 4894A126DFB for ; Mon, 26 Feb 2018 13:09:55 -0800 (PST)
Received: by mail-io0-x236.google.com with SMTP id f1so4918994iob.0 for ; Mon, 26 Feb 2018 13:09:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=cd1AbKoECoQPIS8YsadyGZqgelpTlThvhOUqPWMdrv8=; b=ZJe6Vu6K7x5dSBOj8MpkqXr/YyBu/vHbIUov/lEj/GIF8qw0XIMM8Zdwwk6+oKjAVH vI/EJZSuMxi32atuED+GM7yMraR8ftgNxPNq+o1AGyWlJHMnPhvZqyXqZBSdx7Xy2sYL lr6d5N3Bh/wxOLBWmdXYVnEkoXW4lcluggL3o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=cd1AbKoECoQPIS8YsadyGZqgelpTlThvhOUqPWMdrv8=; b=gJ4a7+zffqzCZlEOQ/zJ/zWfAJKfZXM977VhWDbzi9HsqEm2X1siYoiPVLNCTAg8MY 43DR2LpeQ9ChWkATQDndwp/AQ0OsS2J+GSiJXuNMXUr1Zzc4KDo12X4Wjqc0s2IV0d+i UiRBN8I45xDtr6cR2MWSGAah4VflhHSexny0B+2Wm2RxsG7nsB93ua9F8/f9FHYFq6U6 CVmHl4KWt9cq1eiactcuSyZXgd8IXDJYZZ9F+cA4XGotlwBYJqXCJRQrlp7aUTJAhBf/ UQAJcgJNK4TvFdazPmjv6GNVBz2LANUyuxEn1Y2kKMea9z7CpJelmpdGzdYSCl4EIjK/ +shA==
X-Gm-Message-State: APf1xPBZGlnSttuHRWhE5w2zbuuClISo9VWZPqpXNeTHTKU6/t3ZaJVN wsA1qMPNkDytsT6Zyl7dNBXnDw==
X-Google-Smtp-Source: AG47ELu8Y/ttS5mOzR6iZmr4dBD9sFa3gTsELibIlXxl3SiQwMy5GFSBHYbkMn0qQCg2lWkxXpS0lA==
X-Received: by 10.107.200.69 with SMTP id y66mr13238319iof.116.1519679394567;  Mon, 26 Feb 2018 13:09:54 -0800 (PST)
Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id 27sm4427233iog.17.2018.02.26.13.09.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 13:09:53 -0800 (PST)
To: Christer Holmberg , Ted Hardie 
Cc: Ben Campbell , "ice-chairs@ietf.org" , "ice@ietf.org" 
References: <7594FB04B1934943A5C02806D1A2204B6C19C590@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C1ABB3E@ESESSMB109.ericsson.se>
From: Peter Saint-Andre 
Message-ID: 
Date: Mon, 26 Feb 2018 14:10:05 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1ABB3E@ESESSMB109.ericsson.se>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IKXvpjYmIn2v8fXV6pUIXDAMx00OI0wV9"
Archived-At: 
Subject: Re: [Ice] ICE change in role conflict ([was: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) - Role conflict issue)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 21:09:56 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--IKXvpjYmIn2v8fXV6pUIXDAMx00OI0wV9
Content-Type: multipart/mixed; boundary="Y994x6cYosS9L26jlWO0WiVo6YSFwZSlg";
 protected-headers="v1"
From: Peter Saint-Andre 
To: Christer Holmberg ,
 Ted Hardie 
Cc: Ben Campbell , "ice-chairs@ietf.org"
 , "ice@ietf.org" 
Message-ID: 
Subject: Re: [Ice] ICE change in role conflict ([was: Eric Rescorla's No
 Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security
 Considerations) - Role conflict issue)
References: <7594FB04B1934943A5C02806D1A2204B6C19C590@ESESSMB109.ericsson.se>
 
 <7594FB04B1934943A5C02806D1A2204B6C1ABB3E@ESESSMB109.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1ABB3E@ESESSMB109.ericsson.se>

--Y994x6cYosS9L26jlWO0WiVo6YSFwZSlg
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2/26/18 12:59 PM, Christer Holmberg wrote:
> Hi Ted,
>=20
> =C2=A0
>=20
> ICE re-start was suggested earlier, but people didn=E2=80=99t like it.
>=20
> =C2=A0
>=20
> I don=E2=80=99t think the solution adds very much complexity. It=E2=80=99=
s more or less
> supported already, the only difference is that we change =E2=80=9CMAY p=
ick a new
> tie-breaker value=E2=80=9D to =E2=80=9CMUST pick a new tie-breaker valu=
e=E2=80=9D.

I was fine with the restart proposal, but what you've written up seems
good to me.

Peter


--Y994x6cYosS9L26jlWO0WiVo6YSFwZSlg--

--IKXvpjYmIn2v8fXV6pUIXDAMx00OI0wV9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqUd60ACgkQZWGMGH9o
FKkr7hAA38KjQNfbbjskmhAtoSeBvg8r8tp2gozmm9d82DxQV3ykDuAt6DCrxH2y
NA3Kii8naOw9IBc9Q6Tw9n+EtbH1+oQnxgph3un5JYEvcYgJEM+qh6H4XhKj8fHD
hb/UR2tWqxElo+aX1Q2rJaIJiz3xoMCO9OR96JBblrixD6CrUUUvFD5I+8S9zAYy
if6dxrRdHwbDM7hKmMCLrRMU0S4NkdwkPGCcEw8iMgkTuripNrsm12evJU/p6jZi
YuXrST8lk5eNkBCanApNL4jE/3lgr01AGJyIfqombi+TRvsHDW2CvjXK/7OF2+FQ
LiJGHVqqOiM7EauG6JhsEx6xjDnD+KykjWpQ2TYe4TJefrJ9Qm9nrYx1L8KDKggj
eZNr1jmoXZieZwEwjGsaBKTtfsqevvwN8UXHAJWtp8BAex20+vRAKCo9jqhPkeBk
DeJy2YLEoLCv46oDYxQ5iRTdLVyQzN3Gi5bymyI0IhD259kS0azBampSDUN2mTaH
AjlRIrgdBgUlfldO5Jtv3/Zs/2tz6/f/v+OtnobmesEWKC/ybEzY2S3KK0Me+enz
r8K9CZZlfAkvoqUVZYre1e9ngPI1+vY9B3uwU0zyFmqRbX+WpYfZssa+6NljnChs
y/WH3rU4zVPUTDkiPEJwVfW2IPeq8S5xqktA7pN/Jvj1By1I//g=
=/n58
-----END PGP SIGNATURE-----

--IKXvpjYmIn2v8fXV6pUIXDAMx00OI0wV9--


From nobody Mon Feb 26 15:11:08 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7438612D94A for ; Mon, 26 Feb 2018 15:11:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 EXiOeSlBKJjd for ; Mon, 26 Feb 2018 15:11:03 -0800 (PST)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 D840D12D943 for ; Mon, 26 Feb 2018 15:11:02 -0800 (PST)
Received: by mail-pf0-x229.google.com with SMTP id d26so7160748pfn.5 for ; Mon, 26 Feb 2018 15:11:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=o0hEsBsO94aM1sdCK7JFNB6/1Ho1ktTltur16yDxJWc=; b=SKVuuEduSTY7P8kSFWqqZ65LEwcML3gep5Y2HFX66aQeySL/0bDEu1jtNB08d2NHzx 8/lzypEcet5mA1b2Kb+3PrVeEN9R1E2pJj8TF26cMVtqzwJj9kvYHy61dgFZRMyd5PMH 7wx9BXfLNloHqxrRTe9WagX3SGwJb83uk+yZ4=
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=o0hEsBsO94aM1sdCK7JFNB6/1Ho1ktTltur16yDxJWc=; b=mmvIdvWQ10Uu2y1HLe/5/9yfr5itgTeiY2amwLRqf9vtienhhlCYXkE6NjknApO2lz s2yr1HBlcEVezPbFAAXRUKnKrKUgIiI2V/rQD/lQ8K5ZPx1uJG7J2PS5Ob3t1pvFs2yr /6UeMaze3E7KgMHZr4MVXOEOJapHClfDhq0AoL30AgDE4l3U7W36InyHHVJWIRCh5I0X 5nP1HuT/LMch1xSlJ01csJp7H/+gfpwUloDmOBlzTWlejIpsgAiHFXhTrH2LlzxynLyD nVS8ZKK/Lg+yZ44aunSJupp1hphzGmQqYFPoqeFfimTLCtKTw9qrzEsGYjTQUUb1YrJR VIFQ==
X-Gm-Message-State: APf1xPDlEMe8jhB8gkCI85RXpPMxj5+De+IDFdY8pvNHzvf+8+SlD1rO K9ugpV2JZGfVR5NfKKVCk0wqKg==
X-Google-Smtp-Source: AH8x227QQyTHW3sIdGUEx6V8QowOVOMTTfXrfzNh1/kp+lJA1P+5jIKSEO0T2m0kkD6yo7CZo/jt0Q==
X-Received: by 10.101.78.143 with SMTP id b15mr9790675pgs.229.1519686662276; Mon, 26 Feb 2018 15:11:02 -0800 (PST)
Received: from ?IPv6:2620:101:80fc:224:151e:363e:a38f:5571? ([2620:101:80fc:224:151e:363e:a38f:5571]) by smtp.gmail.com with ESMTPSA id r28sm19793879pfl.9.2018.02.26.15.11.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 15:11:00 -0800 (PST)
From: Nils Ohlmeier 
Message-Id: <143496D8-1304-49C3-B12F-5EF3A116E1BD@mozilla.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_3DFD7FEF-276C-4CA7-BEEC-3CB359370F95"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 26 Feb 2018 15:10:55 -0800
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1A8CC5@ESESSMB109.ericsson.se>
Cc: "Black, David" , "ice@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , "jri@google.com" 
To: Christer Holmberg 
References: <7594FB04B1934943A5C02806D1A2204B6C19C90C@ESESSMB109.ericsson.se>    <7594FB04B1934943A5C02806D1A2204B6C1A8CC5@ESESSMB109.ericsson.se>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [Ice] 5245bis: STUN/TURN transaction timeout timer
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 23:11:06 -0000

--Apple-Mail=_3DFD7FEF-276C-4CA7-BEEC-3CB359370F95
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_45EDC6DB-7CF3-450C-9FC3-675181E18FE3"


--Apple-Mail=_45EDC6DB-7CF3-450C-9FC3-675181E18FE3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Feb 26, 2018, at 07:48, Christer Holmberg =
 wrote:
>=20
> Maybe adding the following note to the existing Timer HTO definition:
>=20
> Timer HTO:  The timeout timer for a given STUN or TURN transaction.
>=20
>   =E2=80=9CNOTE: When STUN and TURN are used with ICE, timer HTO is =
used instead of timer Ti [RFC5389] as transaction timeout timer.=E2=80=9D

My initial thought was: yes sounds good.

But one of the side effects know from real world deployments is that =
results in the end-of-candidates indication coming in after a long time =
if one of the STUN or TURN servers is not reachable.
I don=E2=80=99t want to make this a last minute change, but your =
indication that Ti explicitly got made shorter made me wonder if =
everyone in WG is aware of this usage of the long HTO value.

Best
  Nils Ohlmeier

>=20
> Regards,
>=20
> Christer
> =C2=A0 <>
> From: Black, David [mailto:David.Black@dell.com]
> Sent: 26 February 2018 16:54
> To: Christer Holmberg ; ice@ietf.org; =
draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org
> Cc: jri@google.com; Black, David 
> Subject: RE: 5245bis: STUN/TURN transaction timeout timer
>=20
> That would be a fine thing to do, Thanks, --David
>=20
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com =
]
> Sent: Monday, February 26, 2018 9:22 AM
> To: Black, David >; =
ice@ietf.org ; draft-ietf-ice-rfc5245bis@ietf.org =
; ice-chairs@ietf.org =

> Cc: jri@google.com 
> Subject: Re: 5245bis: STUN/TURN transaction timeout timer
>=20
> Hi,
>=20
> >> But, still, is there a reason we couldn=E2=80=99t use =E2=80=98Ti=E2=80=
=99 also in 5245bis, and point out the big value difference when used =
with ICE?
> >
> >Given the nearly 2-orders-of-magnitude difference in the time =
periods, I=E2=80=99d be concerned that using the same name risks leaving =
an incorrect impression on an implementer who
> >is familiar with one protocol, but new to the other.   Different =
names may also improve clarity in other documents that describe how STUN =
and ICE work together.
>=20
> Fair enough. But, should we then point out that Ti isn=E2=80=99t used =
with ICE?
>=20
> Regards,
>=20
> Christer
>=20
>=20
>=20
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com =
]
> Sent: Sunday, February 25, 2018 8:00 AM
> To: ice@ietf.org ; =
draft-ietf-ice-rfc5245bis@ietf.org =
; ice-chairs@ietf.org =

> Cc: Black, David >; =
jri@google.com 
> Subject: 5245bis: STUN/TURN transaction timeout timer
>=20
> Hi,
>=20
> In draft-5245bis, the name of the STUN/TURN transaction timeout timer =
is =E2=80=98HTO=E2=80=99.
>=20
> As part of the IESG review, I have been asked what the =E2=80=98H=E2=80=99=
 stands for. After some digging in the mail archives (2016-09-14), I =
figured out it stands for =E2=80=9Chandshake=E2=80=9D:
>=20
> https://www.ietf.org/mail-archive/web/ice/current/msg00378.html =

>=20
>       =E2=80=9C2.  A timeout for request packets, call it handshake =
timeout or HTO which SHOULD be 2*RTT if the RTT is known and 500ms =
otherwise.=E2=80=9D
>=20
> Now, in RFC 5389, the transaction timeout timer is called =E2=80=98Ti=E2=
=80=99. However, the default value for that SHOULD be 39,5 seconds =E2=80=93=
 which is quite different from 500ms.
>=20
> But, still, is there a reason we couldn=E2=80=99t use =E2=80=98Ti=E2=80=99=
 also in 5245bis, and point out the big value difference when used with =
ICE?
>=20
> Regards,
>=20
> Christer
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice


--Apple-Mail=_45EDC6DB-7CF3-450C-9FC3-675181E18FE3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On =
Feb 26, 2018, at 07:48, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Maybe adding the following note to the existing Timer HTO =
definition:
 
Timer =
HTO:  The timeout timer for a given STUN or TURN transaction.
 
  =
=E2=80=9CNOTE: When STUN and TURN are used with ICE, timer HTO is used =
instead of timer Ti [RFC5389] as transaction timeout timer.=E2=80=9D

My initial thought was: yes sounds =
good.

But one of the side effects =
know from real world deployments is that results in the =
end-of-candidates indication coming in after a long time if one of the =
STUN or TURN servers is not reachable.
I don=E2=80=99t want to =
make this a last minute change, but your indication that Ti explicitly =
got made shorter made me wonder if everyone in WG is aware of this usage =
of the long HTO value.

Best
  Nils Ohlmeier

 
Regards,
 
Christer
 
From: Black, =
David [mailto:David.Black@dell.com] 
Sent: 26 =
February 2018 16:54
To: Christer Holmberg <christer.holmberg@ericsson.com>; ice@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org
Cc: jri@google.com; Black, =
David <David.Black@dell.com>
Subject: RE: 5245bis: STUN/TURN =
transaction timeout timer
 
That would be a fine thing to do, Thanks, --David
 
From: Christer =
Holmberg [mailto:christer.holmberg@ericsson.com] 
Sent: Monday, February 26, 2018 =
9:22 AM
To: Black, David <david.black@emc.com>; ice@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org
Cc: jri@google.com
Subject: Re: 5245bis: STUN/TURN =
transaction timeout timer
 
Hi,
 
>> But, still, is there a reason we couldn=E2=80=99t =
use =E2=80=98Ti=E2=80=99 also in 5245bis, and point out the big value =
difference when used with ICE?
> 
>Given the nearly 2-orders-of-magnitude difference in the =
time periods, I=E2=80=99d be concerned that using the same name risks =
leaving an incorrect impression on an implementer who
>is familiar with one protocol, but new to =
the other.   Different names may also improve clarity in other =
documents that describe how STUN and ICE work together.
 
Fair enough. But, should we then =
point out that Ti isn=E2=80=99t used with ICE?
 
Regards,
 
Christer
 
 
 
From: Christer =
Holmberg [mailto:christer.holmberg@ericsson.com] 
Sent: Sunday, February 25, 2018 =
8:00 AM
To: ice@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org
Cc: Black, David <david.black@emc.com>; jri@google.com
Subject: 5245bis: STUN/TURN =
transaction timeout timer
 
Hi,
 
In =
draft-5245bis, the name of the STUN/TURN transaction timeout timer is =
=E2=80=98HTO=E2=80=99.
 
As part of =
the IESG review, I have been asked what the =E2=80=98H=E2=80=99 stands =
for. After some digging in the mail archives (2016-09-14), I figured out =
it stands for =E2=80=9Chandshake=E2=80=9D:
 
https://www.ietf.org/mail-archive/web/ice/current/msg00378.html=

 
      =
=E2=80=9C2.  A timeout for request packets, call it handshake =
timeout or HTO which SHOULD be 2*RTT if the RTT is known and 500ms =
otherwise.=E2=80=9D
 
Now, in RFC 5389, the transaction =
timeout timer is called =E2=80=98Ti=E2=80=99. However, the default value =
for that SHOULD be 39,5 seconds =E2=80=93 which is quite different from =
500ms.
 
But, still, is there a reason we =
couldn=E2=80=99t use =E2=80=98Ti=E2=80=99 also in 5245bis, and point out =
the big value difference when used with ICE?
 
Regards,
 
Christer
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice

=

--Apple-Mail=_45EDC6DB-7CF3-450C-9FC3-675181E18FE3--

--Apple-Mail=_3DFD7FEF-276C-4CA7-BEEC-3CB359370F95
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-----

iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlqUk/8ACgkQY2o/VmzJ
+KFozw/8DQJkBESODJktqy6g9UZylVg6X24nUTwonqdSs6lD+Z2XRlDq5d1Lm9zw
K93yKkABBHg1Yzpa73uQNgzNVSV2SwwvDJ5fPYvDtmve8kpLCYosUKVTFcsUqLL0
N1jugw/wnGoNNEZsC/QdcZvSsf3KtEig10bVQ5ii9WYVT1bzB6of6KVlLqThn5S2
oYUMDNYhwyLl2eMDErfnrSkVpFF95e5RqyksPYJeQFfHmHkbphkvSTkUs2rDiQyU
2m9IjQDNarwU7VY019Z3evGS37GNiIjmv5rxMQxWwORcYpqDIKldzUn/qE/6VbpB
xhMjXBMK7kWao6MN2t3RQfm5UhRJHx/5DMC2lt9B8iM5xk3oRUDIgIwwcvwJPL0P
4ezSViV0xROAEDROjwXrUzYU4G7FONHnPcUZX3+QRTu6NHSKr7CaWnAYb+PURvQN
inFKzLXZnzJffevTKBigBCvsDx54yR67UeZ8bjgI6ESwvfnrtJ0RDi+OhwwimWFf
Z1n1HHbh0qlIdoX+aaxXalYP6FI5TKcJpvJweRfVe6y47etrbH4dnaEuN0ghgIU4
nffyqegxfUoVmTr5VHKt1NFpIGKJN8qvzcvSTrSNyS+Hxoip7SwMpCWQjFO5zDZh
n81oqlXrKWOJNKlsHfivQY+eRA1lgPbz6IQGFhPipReJG2BJvaA=
=SxLU
-----END PGP SIGNATURE-----

--Apple-Mail=_3DFD7FEF-276C-4CA7-BEEC-3CB359370F95--


From nobody Mon Feb 26 15:15:55 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64ADB12D946; Mon, 26 Feb 2018 15:15:52 -0800 (PST)
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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=p+uAddpD; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=GKlB6InD
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 5E3U4fjCpUEV; Mon, 26 Feb 2018 15:15:50 -0800 (PST)
Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 B4F2312D88B; Mon, 26 Feb 2018 15:15:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1519686949; x=1551222949; h=from:cc:to:subject:date:message-id:references: in-reply-to:mime-version; bh=MkWSAFkBdsCGxh8Hl6HF00axWV9RkpGomIagMS9d7Ao=; b=p+uAddpDdOkfPz8ZN3cpAGECTZnKVHmX14Ydk0Lw88CeHpdCKwxPCbYi ZhMxkQjnRjamzs53ufR9u2RURlhn/Mxz1aaN1whmTuH8g6O2j1BEdVrrF bqmDXOla/vjFhmoWchA72l4k1mIyg2i+FfFkjEZ4eYEpZOZP18Bi9iHCO w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HCAABzlJRah2Oa6EReGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJaIiKBBxBwKAqDCEKYIIICgRaWBYE3AxlAAwoYAQqFEAIagit?= =?us-ascii?q?WFgECAQEBAQEBAgECEAEBAQoLCQgoL4I4JAEOLxwhBgYBAQEBAQEmAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBFwI9ARICGAEBAQMBAQEKFwoTHw8LAQ8CAQYCDgMEAQELFgE?= =?us-ascii?q?GAwICAiULFAkIAgQBEgiEJFwIAQ+ORJ1ugieDCoVoghQBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEVAwWGUHKBWIFlgy2DLgEBAYFQAQEgDB8JglcxgjSLL4YEkDMDBgK?= =?us-ascii?q?mfpJrgl0CBAIEBQIagS8lB1ANgR9wT4JDCYJKggd3AYocgSKBFwEBAQ?=
X-IPAS-Result: =?us-ascii?q?A2HCAABzlJRah2Oa6EReGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?aIiKBBxBwKAqDCEKYIIICgRaWBYE3AxlAAwoYAQqFEAIagitWFgECAQEBAQEBA?= =?us-ascii?q?gECEAEBAQoLCQgoL4I4JAEOLxwhBgYBAQEBAQEmAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BFwI9ARICGAEBAQMBAQEKFwoTHw8LAQ8CAQYCDgMEAQELFgEGAwICAiULFAkIA?= =?us-ascii?q?gQBEgiEJFwIAQ+ORJ1ugieDCoVoghQBAQEBAQEBAQEBAQEBAQEBAQEBAQEVAwW?= =?us-ascii?q?GUHKBWIFlgy2DLgEBAYFQAQEgDB8JglcxgjSLL4YEkDMDBgKmfpJrgl0CBAIEB?= =?us-ascii?q?QIagS8lB1ANgR9wT4JDCYJKggd3AYocgSKBFwEBAQ?=
Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 17:15:48 -0600
From: "Black, David" 
Cc: "ice@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , "jri@google.com" , "Black, David" 
Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2018 05:15:47 +0600
Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w1QNFkfX011123 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Feb 2018 18:15:46 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com w1QNFkfX011123
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1519686946; bh=8Rgy/NhqEwR1Wza3SzqG8J3IMtU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=GKlB6InDIjXYJFEe7DOdeirWeeEcLFCormUG4J+2RLhYzIx4dzdIv3xsx2tgKzn0d d2bQXWxfT4VVCKi1KzkrmZ9Q3re1Vx7kO3Br+2hq1AAyLyh7SlsHCg/ONQ6kDyKXke XRVgyTxAFLWv+OIo8cEmK3I5Qmsd6ix00gi5siyU=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com w1QNFkfX011123
Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd55.lss.emc.com (RSA Interceptor); Mon, 26 Feb 2018 18:15:34 -0500
Received: from MXHUB302.corp.emc.com (MXHUB302.corp.emc.com [10.146.3.28]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id w1QNFYPw013178 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 26 Feb 2018 18:15:35 -0500
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB302.corp.emc.com ([10.146.3.28]) with mapi id 14.03.0352.000; Mon, 26 Feb 2018 18:15:34 -0500
To: Nils Ohlmeier , Christer Holmberg 
Thread-Topic: [Ice] 5245bis: STUN/TURN transaction timeout timer
Thread-Index: AdOuOI+oEAiBXZOTQm+Dl/LRxGi/pAA0o/rgAAMPdYAAAXfKMAACL39QABa+/YAAClovQA==
Date: Mon, 26 Feb 2018 23:15:33 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B6C19C90C@ESESSMB109.ericsson.se>    <7594FB04B1934943A5C02806D1A2204B6C1A8CC5@ESESSMB109.ericsson.se> <143496D8-1304-49C3-B12F-5EF3A116E1BD@mozilla.com>
In-Reply-To: <143496D8-1304-49C3-B12F-5EF3A116E1BD@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.238.44.138]
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D2432779493630024378MX307CL04corpem_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com
X-RSA-Classifications: public
Archived-At: 
Subject: Re: [Ice] 5245bis: STUN/TURN transaction timeout timer
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 23:15:52 -0000

--_000_CE03DB3D7B45C245BCA0D2432779493630024378MX307CL04corpem_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SXNu4oCZdCBpdCB0aGUgb3RoZXIgd2F5IGFyb3VuZCDigJMgSUNFIEhUTyBpcyBtdWNoIHNob3J0
ZXIgdGhhbiBTVFVOIG9yIFRVUk4gVGk/DQoNClRoYW5rcywgLS1EYXZpZA0KDQpGcm9tOiBOaWxz
IE9obG1laWVyIFttYWlsdG86bm9obG1laWVyQG1vemlsbGEuY29tXQ0KU2VudDogTW9uZGF5LCBG
ZWJydWFyeSAyNiwgMjAxOCA2OjExIFBNDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVy
LmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNjOiBCbGFjaywgRGF2aWQgPGRhdmlkLmJsYWNrQGVt
Yy5jb20+OyBpY2VAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXNAaWV0Zi5vcmc7
IGljZS1jaGFpcnNAaWV0Zi5vcmc7IGpyaUBnb29nbGUuY29tDQpTdWJqZWN0OiBSZTogW0ljZV0g
NTI0NWJpczogU1RVTi9UVVJOIHRyYW5zYWN0aW9uIHRpbWVvdXQgdGltZXINCg0KDQpPbiBGZWIg
MjYsIDIwMTgsIGF0IDA3OjQ4LCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdA
ZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90
ZToNCg0KTWF5YmUgYWRkaW5nIHRoZSBmb2xsb3dpbmcgbm90ZSB0byB0aGUgZXhpc3RpbmcgVGlt
ZXIgSFRPIGRlZmluaXRpb246DQoNClRpbWVyIEhUTzogIFRoZSB0aW1lb3V0IHRpbWVyIGZvciBh
IGdpdmVuIFNUVU4gb3IgVFVSTiB0cmFuc2FjdGlvbi4NCg0KICDigJxOT1RFOiBXaGVuIFNUVU4g
YW5kIFRVUk4gYXJlIHVzZWQgd2l0aCBJQ0UsIHRpbWVyIEhUTyBpcyB1c2VkIGluc3RlYWQgb2Yg
dGltZXIgVGkgW1JGQzUzODldIGFzIHRyYW5zYWN0aW9uIHRpbWVvdXQgdGltZXIu4oCdDQoNCk15
IGluaXRpYWwgdGhvdWdodCB3YXM6IHllcyBzb3VuZHMgZ29vZC4NCg0KQnV0IG9uZSBvZiB0aGUg
c2lkZSBlZmZlY3RzIGtub3cgZnJvbSByZWFsIHdvcmxkIGRlcGxveW1lbnRzIGlzIHRoYXQgcmVz
dWx0cyBpbiB0aGUgZW5kLW9mLWNhbmRpZGF0ZXMgaW5kaWNhdGlvbiBjb21pbmcgaW4gYWZ0ZXIg
YSBsb25nIHRpbWUgaWYgb25lIG9mIHRoZSBTVFVOIG9yIFRVUk4gc2VydmVycyBpcyBub3QgcmVh
Y2hhYmxlLg0KSSBkb27igJl0IHdhbnQgdG8gbWFrZSB0aGlzIGEgbGFzdCBtaW51dGUgY2hhbmdl
LCBidXQgeW91ciBpbmRpY2F0aW9uIHRoYXQgVGkgZXhwbGljaXRseSBnb3QgbWFkZSBzaG9ydGVy
IG1hZGUgbWUgd29uZGVyIGlmIGV2ZXJ5b25lIGluIFdHIGlzIGF3YXJlIG9mIHRoaXMgdXNhZ2Ug
b2YgdGhlIGxvbmcgSFRPIHZhbHVlLg0KDQpCZXN0DQogIE5pbHMgT2hsbWVpZXINCg0KDQoNClJl
Z2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IEJsYWNrLCBEYXZpZCBbbWFpbHRvOkRhdmlkLkJs
YWNrQGRlbGwuY29tXQ0KU2VudDogMjYgRmVicnVhcnkgMjAxOCAxNjo1NA0KVG86IENocmlzdGVy
IEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVy
LmhvbG1iZXJnQGVyaWNzc29uLmNvbT4+OyBpY2VAaWV0Zi5vcmc8bWFpbHRvOmljZUBpZXRmLm9y
Zz47IGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXNAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYt
aWNlLXJmYzUyNDViaXNAaWV0Zi5vcmc+OyBpY2UtY2hhaXJzQGlldGYub3JnPG1haWx0bzppY2Ut
Y2hhaXJzQGlldGYub3JnPg0KQ2M6IGpyaUBnb29nbGUuY29tPG1haWx0bzpqcmlAZ29vZ2xlLmNv
bT47IEJsYWNrLCBEYXZpZCA8RGF2aWQuQmxhY2tAZGVsbC5jb208bWFpbHRvOkRhdmlkLkJsYWNr
QGRlbGwuY29tPj4NClN1YmplY3Q6IFJFOiA1MjQ1YmlzOiBTVFVOL1RVUk4gdHJhbnNhY3Rpb24g
dGltZW91dCB0aW1lcg0KDQpUaGF0IHdvdWxkIGJlIGEgZmluZSB0aGluZyB0byBkbywgVGhhbmtz
LCAtLURhdmlkDQoNCkZyb206IENocmlzdGVyIEhvbG1iZXJnIFttYWlsdG86Y2hyaXN0ZXIuaG9s
bWJlcmdAZXJpY3Nzb24uY29tXQ0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAyNiwgMjAxOCA5OjIy
IEFNDQpUbzogQmxhY2ssIERhdmlkIDxkYXZpZC5ibGFja0BlbWMuY29tPG1haWx0bzpkYXZpZC5i
bGFja0BlbWMuY29tPj47IGljZUBpZXRmLm9yZzxtYWlsdG86aWNlQGlldGYub3JnPjsgZHJhZnQt
aWV0Zi1pY2UtcmZjNTI0NWJpc0BpZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1pY2UtcmZjNTI0
NWJpc0BpZXRmLm9yZz47IGljZS1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmljZS1jaGFpcnNAaWV0
Zi5vcmc+DQpDYzoganJpQGdvb2dsZS5jb208bWFpbHRvOmpyaUBnb29nbGUuY29tPg0KU3ViamVj
dDogUmU6IDUyNDViaXM6IFNUVU4vVFVSTiB0cmFuc2FjdGlvbiB0aW1lb3V0IHRpbWVyDQoNCkhp
LA0KDQo+PiBCdXQsIHN0aWxsLCBpcyB0aGVyZSBhIHJlYXNvbiB3ZSBjb3VsZG7igJl0IHVzZSDi
gJhUaeKAmSBhbHNvIGluIDUyNDViaXMsIGFuZCBwb2ludCBvdXQgdGhlIGJpZyB2YWx1ZSBkaWZm
ZXJlbmNlIHdoZW4gdXNlZCB3aXRoIElDRT8NCj4NCj5HaXZlbiB0aGUgbmVhcmx5IDItb3JkZXJz
LW9mLW1hZ25pdHVkZSBkaWZmZXJlbmNlIGluIHRoZSB0aW1lIHBlcmlvZHMsIEnigJlkIGJlIGNv
bmNlcm5lZCB0aGF0IHVzaW5nIHRoZSBzYW1lIG5hbWUgcmlza3MgbGVhdmluZyBhbiBpbmNvcnJl
Y3QgaW1wcmVzc2lvbiBvbiBhbiBpbXBsZW1lbnRlciB3aG8NCj5pcyBmYW1pbGlhciB3aXRoIG9u
ZSBwcm90b2NvbCwgYnV0IG5ldyB0byB0aGUgb3RoZXIuICAgRGlmZmVyZW50IG5hbWVzIG1heSBh
bHNvIGltcHJvdmUgY2xhcml0eSBpbiBvdGhlciBkb2N1bWVudHMgdGhhdCBkZXNjcmliZSBob3cg
U1RVTiBhbmQgSUNFIHdvcmsgdG9nZXRoZXIuDQoNCkZhaXIgZW5vdWdoLiBCdXQsIHNob3VsZCB3
ZSB0aGVuIHBvaW50IG91dCB0aGF0IFRpIGlzbuKAmXQgdXNlZCB3aXRoIElDRT8NCg0KUmVnYXJk
cywNCg0KQ2hyaXN0ZXINCg0KDQoNCkZyb206IENocmlzdGVyIEhvbG1iZXJnIFttYWlsdG86Y2hy
aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tXQ0KU2VudDogU3VuZGF5LCBGZWJydWFyeSAyNSwg
MjAxOCA4OjAwIEFNDQpUbzogaWNlQGlldGYub3JnPG1haWx0bzppY2VAaWV0Zi5vcmc+OyBkcmFm
dC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWljZS1yZmM1
MjQ1YmlzQGlldGYub3JnPjsgaWNlLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86aWNlLWNoYWlyc0Bp
ZXRmLm9yZz4NCkNjOiBCbGFjaywgRGF2aWQgPGRhdmlkLmJsYWNrQGVtYy5jb208bWFpbHRvOmRh
dmlkLmJsYWNrQGVtYy5jb20+PjsganJpQGdvb2dsZS5jb208bWFpbHRvOmpyaUBnb29nbGUuY29t
Pg0KU3ViamVjdDogNTI0NWJpczogU1RVTi9UVVJOIHRyYW5zYWN0aW9uIHRpbWVvdXQgdGltZXIN
Cg0KSGksDQoNCkluIGRyYWZ0LTUyNDViaXMsIHRoZSBuYW1lIG9mIHRoZSBTVFVOL1RVUk4gdHJh
bnNhY3Rpb24gdGltZW91dCB0aW1lciBpcyDigJhIVE/igJkuDQoNCkFzIHBhcnQgb2YgdGhlIElF
U0cgcmV2aWV3LCBJIGhhdmUgYmVlbiBhc2tlZCB3aGF0IHRoZSDigJhI4oCZIHN0YW5kcyBmb3Iu
IEFmdGVyIHNvbWUgZGlnZ2luZyBpbiB0aGUgbWFpbCBhcmNoaXZlcyAoMjAxNi0wOS0xNCksIEkg
ZmlndXJlZCBvdXQgaXQgc3RhbmRzIGZvciDigJxoYW5kc2hha2XigJ06DQoNCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaWNlL2N1cnJlbnQvbXNnMDAzNzguaHRtbA0KDQog
ICAgICDigJwyLiAgQSB0aW1lb3V0IGZvciByZXF1ZXN0IHBhY2tldHMsIGNhbGwgaXQgaGFuZHNo
YWtlIHRpbWVvdXQgb3IgSFRPIHdoaWNoIFNIT1VMRCBiZSAyKlJUVCBpZiB0aGUgUlRUIGlzIGtu
b3duIGFuZCA1MDBtcyBvdGhlcndpc2Uu4oCdDQoNCk5vdywgaW4gUkZDIDUzODksIHRoZSB0cmFu
c2FjdGlvbiB0aW1lb3V0IHRpbWVyIGlzIGNhbGxlZCDigJhUaeKAmS4gSG93ZXZlciwgdGhlIGRl
ZmF1bHQgdmFsdWUgZm9yIHRoYXQgU0hPVUxEIGJlIDM5LDUgc2Vjb25kcyDigJMgd2hpY2ggaXMg
cXVpdGUgZGlmZmVyZW50IGZyb20gNTAwbXMuDQoNCkJ1dCwgc3RpbGwsIGlzIHRoZXJlIGEgcmVh
c29uIHdlIGNvdWxkbuKAmXQgdXNlIOKAmFRp4oCZIGFsc28gaW4gNTI0NWJpcywgYW5kIHBvaW50
IG91dCB0aGUgYmlnIHZhbHVlIGRpZmZlcmVuY2Ugd2hlbiB1c2VkIHdpdGggSUNFPw0KDQpSZWdh
cmRzLA0KDQpDaHJpc3Rlcg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCkljZSBtYWlsaW5nIGxpc3QNCkljZUBpZXRmLm9yZzxtYWlsdG86SWNlQGlldGYu
b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UNCg0K

--_000_CE03DB3D7B45C245BCA0D2432779493630024378MX307CL04corpem_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs
LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3
IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu
LmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQt
c3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw
bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9
DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp
emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt
YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl
OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86
c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu
ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk
aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+
PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1
ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzFGNDk3RCI+SXNu4oCZdCBpdCB0aGUgb3RoZXIgd2F5IGFyb3VuZCDigJMgSUNFIEhUTyBp
cyBtdWNoIHNob3J0ZXIgdGhhbiBTVFVOIG9yIFRVUk4gVGk/PG86cD48L286cD48L3NwYW4+PC9h
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcywgLS1EYXZpZDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g
MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv
cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj4gTmlscyBPaGxtZWllciBbbWFpbHRvOm5vaGxtZWllckBtb3ppbGxhLmNvbV0N
Cjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDI2LCAyMDE4IDY6MTEgUE08YnI+
DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmlj
c3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBCbGFjaywgRGF2aWQgJmx0O2RhdmlkLmJsYWNr
QGVtYy5jb20mZ3Q7OyBpY2VAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaWNlLXJmYzUyNDViaXNAaWV0
Zi5vcmc7IGljZS1jaGFpcnNAaWV0Zi5vcmc7IGpyaUBnb29nbGUuY29tPGJyPg0KPGI+U3ViamVj
dDo8L2I+IFJlOiBbSWNlXSA1MjQ1YmlzOiBTVFVOL1RVUk4gdHJhbnNhY3Rpb24gdGltZW91dCB0
aW1lcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u
IEZlYiAyNiwgMjAxOCwgYXQgMDc6NDgsIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJt
YWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Bl
cmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5NYXliZSBhZGRp
bmcgdGhlIGZvbGxvd2luZyBub3RlIHRvIHRoZSBleGlzdGluZyBUaW1lciBIVE8gZGVmaW5pdGlv
bjo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPlRpbWVyIEhUTzombmJzcDsgVGhlIHRpbWVvdXQgdGltZXIgZm9yIGEgZ2l2ZW4g
U1RVTiBvciBUVVJOIHRyYW5zYWN0aW9uLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7IOKAnE5PVEU6IFdoZW4gU1RV
TiBhbmQgVFVSTiBhcmUgdXNlZCB3aXRoIElDRSwgdGltZXIgSFRPIGlzIHVzZWQgaW5zdGVhZCBv
ZiB0aW1lciBUaSBbUkZDNTM4OV0gYXMgdHJhbnNhY3Rpb24gdGltZW91dCB0aW1lci7igJ08L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgaW5pdGlh
bCB0aG91Z2h0IHdhczogeWVzIHNvdW5kcyBnb29kLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgb25lIG9mIHRoZSBzaWRlIGVmZmVjdHMg
a25vdyBmcm9tIHJlYWwgd29ybGQgZGVwbG95bWVudHMgaXMgdGhhdCByZXN1bHRzIGluIHRoZSBl
bmQtb2YtY2FuZGlkYXRlcyBpbmRpY2F0aW9uIGNvbWluZyBpbiBhZnRlciBhIGxvbmcgdGltZSBp
ZiBvbmUgb2YgdGhlIFNUVU4gb3IgVFVSTiBzZXJ2ZXJzIGlzIG5vdCByZWFjaGFibGUuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbuKAmXQg
d2FudCB0byBtYWtlIHRoaXMgYSBsYXN0IG1pbnV0ZSBjaGFuZ2UsIGJ1dCB5b3VyIGluZGljYXRp
b24gdGhhdCBUaSBleHBsaWNpdGx5IGdvdCBtYWRlIHNob3J0ZXIgbWFkZSBtZSB3b25kZXIgaWYg
ZXZlcnlvbmUgaW4gV0cgaXMgYXdhcmUgb2YgdGhpcyB1c2FnZSBvZiB0aGUgbG9uZyBIVE8gdmFs
dWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkJlc3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOyBOaWxzIE9obG1laWVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+
UmVnYXJkcyw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPkNocmlzdGVyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g
MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy
b206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5CbGFjaywNCiBE
YXZpZCBbPGEgaHJlZj0ibWFpbHRvOkRhdmlkLkJsYWNrQGRlbGwuY29tIj5tYWlsdG86RGF2aWQu
QmxhY2tAZGVsbC5jb208L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk
LXNwYWNlIj4mbmJzcDs8L3NwYW4+MjYgRmVicnVhcnkgMjAxOCAxNjo1NDxicj4NCjxiPlRvOjwv
Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Q2hyaXN0
ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv
bi5jb20iPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0i
bWFpbHRvOmljZUBpZXRmLm9yZyI+aWNlQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRy
YWZ0LWlldGYtaWNlLXJmYzUyNDViaXNAaWV0Zi5vcmciPg0KZHJhZnQtaWV0Zi1pY2UtcmZjNTI0
NWJpc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzppY2UtY2hhaXJzQGlldGYub3JnIj5p
Y2UtY2hhaXJzQGlldGYub3JnPC9hPjxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmpyaUBnb29nbGUu
Y29tIj5qcmlAZ29vZ2xlLmNvbTwvYT47IEJsYWNrLCBEYXZpZCAmbHQ7PGEgaHJlZj0ibWFpbHRv
OkRhdmlkLkJsYWNrQGRlbGwuY29tIj5EYXZpZC5CbGFja0BkZWxsLmNvbTwvYT4mZ3Q7PGJyPg0K
PGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7
PC9zcGFuPlJFOiA1MjQ1YmlzOiBTVFVOL1RVUk4gdHJhbnNhY3Rpb24gdGltZW91dCB0aW1lcjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojOTkzMzY2Ij5UaGF0IHdvdWxkIGJlIGEgZmluZSB0aGluZyB0byBkbywgVGhhbmtz
LCAtLURhdmlkPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiM5OTMzNjYiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg
Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw
dCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+
Q2hyaXN0ZXINCiBIb2xtYmVyZyBbPGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVy
aWNzc29uLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPm1haWx0bzpjaHJpc3Rlci5o
b2xtYmVyZ0Blcmljc3Nvbi5jb208L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy
dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFw
cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1vbmRheSwgRmVicnVhcnkgMjYsIDIw
MTggOToyMiBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw
YWNlIj4mbmJzcDs8L3NwYW4+QmxhY2ssIERhdmlkICZsdDs8YSBocmVmPSJtYWlsdG86ZGF2aWQu
YmxhY2tAZW1jLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmRhdmlkLmJsYWNrQGVt
Yy5jb208L3NwYW4+PC9hPiZndDs7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+
Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppY2VAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJj
b2xvcjojOTU0RjcyIj5pY2VAaWV0Zi5vcmc8L3NwYW4+PC9hPjs8c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYt
aWNlLXJmYzUyNDViaXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5kcmFm
dC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYub3JnPC9zcGFuPjwvYT47PHNwYW4gY2xhc3M9ImFw
cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppY2UtY2hh
aXJzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aWNlLWNoYWlyc0BpZXRm
Lm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20iPjxz
cGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5qcmlAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+PGJyPg0K
PGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7
PC9zcGFuPlJlOiA1MjQ1YmlzOiBTVFVOL1RVUk4gdHJhbnNhY3Rpb24gdGltZW91dCB0aW1lcjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPkhpLDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsgQnV0LCBzdGlsbCwgaXMgdGhl
cmUgYSByZWFzb24gd2UgY291bGRu4oCZdCB1c2Ug4oCYVGnigJkgYWxzbyBpbiA1MjQ1YmlzLCBh
bmQgcG9pbnQgb3V0IHRoZSBiaWcgdmFsdWUgZGlmZmVyZW5jZSB3aGVuIHVzZWQgd2l0aCBJQ0U/
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmd0O0dpdmVuIHRo
ZSBuZWFybHkgMi1vcmRlcnMtb2YtbWFnbml0dWRlIGRpZmZlcmVuY2UgaW4gdGhlIHRpbWUgcGVy
aW9kcywgSeKAmWQgYmUgY29uY2VybmVkIHRoYXQgdXNpbmcgdGhlIHNhbWUgbmFtZSByaXNrcyBs
ZWF2aW5nIGFuIGluY29ycmVjdCBpbXByZXNzaW9uIG9uIGFuDQogaW1wbGVtZW50ZXIgd2hvPC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmlzIGZhbWls
aWFyIHdpdGggb25lIHByb3RvY29sLCBidXQgbmV3IHRvIHRoZSBvdGhlci4mbmJzcDsmbmJzcDsg
RGlmZmVyZW50IG5hbWVzIG1heSBhbHNvIGltcHJvdmUNCiBjbGFyaXR5IGluIG90aGVyIGRvY3Vt
ZW50cyB0aGF0IGRlc2NyaWJlIGhvdyBTVFVOIGFuZCBJQ0Ugd29yayB0b2dldGhlci48L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5GYWlyIGVub3VnaC4gQnV0LCBzaG91bGQg
d2UgdGhlbiBwb2ludCBvdXQgdGhhdCBUaSBpc27igJl0IHVzZWQgd2l0aCBJQ0U/PC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi
PlJlZ2FyZHMsPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWYiPkNocmlzdGVyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE
Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp
dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw
dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmIj5DaHJpc3Rlcg0KIEhvbG1iZXJnIFs8YSBocmVmPSJtYWlsdG86Y2hyaXN0
ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+bWFp
bHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvc3Bhbj48L2E+XTxzcGFuIGNsYXNz
PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48
c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+U3VuZGF5LCBG
ZWJydWFyeSAyNSwgMjAxOCA4OjAwIEFNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBs
ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86aWNlQGlldGYu
b3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aWNlQGlldGYub3JnPC9zcGFuPjwvYT47
PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9
Im1haWx0bzpkcmFmdC1pZXRmLWljZS1yZmM1MjQ1YmlzQGlldGYub3JnIj48c3BhbiBzdHlsZT0i
Y29sb3I6Izk1NEY3MiI+ZHJhZnQtaWV0Zi1pY2UtcmZjNTI0NWJpc0BpZXRmLm9yZzwvc3Bhbj48
L2E+OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBo
cmVmPSJtYWlsdG86aWNlLWNoYWlyc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRG
NzIiPmljZS1jaGFpcnNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPkNjOjwvYj48c3BhbiBj
bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QmxhY2ssIERhdmlkICZs
dDs8YSBocmVmPSJtYWlsdG86ZGF2aWQuYmxhY2tAZW1jLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9y
OiM5NTRGNzIiPmRhdmlkLmJsYWNrQGVtYy5jb208L3NwYW4+PC9hPiZndDs7PHNwYW4gY2xhc3M9
ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpqcmlA
Z29vZ2xlLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmpyaUBnb29nbGUuY29tPC9z
cGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk
LXNwYWNlIj4mbmJzcDs8L3NwYW4+NTI0NWJpczogU1RVTi9UVVJOIHRyYW5zYWN0aW9uIHRpbWVv
dXQgdGltZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWYiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj5JbiBkcmFmdC01MjQ1YmlzLCB0aGUgbmFtZSBvZiB0aGUgU1RVTi9UVVJOIHRyYW5zYWN0
aW9uIHRpbWVvdXQgdGltZXIgaXMg4oCYSFRP4oCZLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmIj5BcyBwYXJ0IG9mIHRoZSBJRVNHIHJldmlldywgSSBoYXZlIGJl
ZW4gYXNrZWQgd2hhdCB0aGUg4oCYSOKAmSBzdGFuZHMgZm9yLiBBZnRlciBzb21lIGRpZ2dpbmcg
aW4gdGhlIG1haWwgYXJjaGl2ZXMgKDIwMTYtMDktMTQpLCBJIGZpZ3VyZWQgb3V0IGl0IHN0YW5k
cyBmb3Ig4oCcaGFuZHNoYWtl4oCdOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi
L2ljZS9jdXJyZW50L21zZzAwMzc4Lmh0bWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2ljZS9jdXJyZW50L21zZzAwMzc4
Lmh0bWw8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcMi4mbmJzcDsgQSB0aW1lb3V0
IGZvciByZXF1ZXN0IHBhY2tldHMsIGNhbGwgaXQgaGFuZHNoYWtlIHRpbWVvdXQgb3IgSFRPIHdo
aWNoIFNIT1VMRCBiZSAyKlJUVCBpZiB0aGUgUlRUIGlzIGtub3duIGFuZCA1MDBtcyBvdGhlcndp
c2Uu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk5vdywg
aW4gUkZDIDUzODksIHRoZSB0cmFuc2FjdGlvbiB0aW1lb3V0IHRpbWVyIGlzIGNhbGxlZCDigJhU
aeKAmS4gSG93ZXZlciwgdGhlIGRlZmF1bHQgdmFsdWUgZm9yIHRoYXQgU0hPVUxEIGJlIDM5LDUg
c2Vjb25kcyDigJMgd2hpY2ggaXMgcXVpdGUgZGlmZmVyZW50IGZyb20gNTAwbXMuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJ1dCwgc3RpbGwsIGlzIHRoZXJl
IGEgcmVhc29uIHdlIGNvdWxkbuKAmXQgdXNlIOKAmFRp4oCZIGFsc28gaW4gNTI0NWJpcywgYW5k
IHBvaW50IG91dCB0aGUgYmlnIHZhbHVlIGRpZmZlcmVuY2Ugd2hlbiB1c2VkIHdpdGggSUNFPzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaHJpc3RlcjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkljZSBtYWlsaW5nIGxpc3Q8YnI+DQo8
YSBocmVmPSJtYWlsdG86SWNlQGlldGYub3JnIj5JY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_CE03DB3D7B45C245BCA0D2432779493630024378MX307CL04corpem_--


From nobody Mon Feb 26 16:00:08 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B59F1201F8 for ; Mon, 26 Feb 2018 16:00:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 O-Pv2NPLK6FE for ; Mon, 26 Feb 2018 16:00:05 -0800 (PST)
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 1653512D94E for ; Mon, 26 Feb 2018 16:00:05 -0800 (PST)
Received: by mail-io0-x236.google.com with SMTP id m22so19203782iob.12 for ; Mon, 26 Feb 2018 16:00:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=BgWl5bE3ZarNma0JI36yzZei0l57cUP83g2XEypUa4Y=; b=OxDZnrEgEeL0UGOPMUJQcwF29YRpBlRl+PnRf4bDflPSDcQDQ9Me45VCNehAPaee91 hhYYrKlq+vWTbAhc37xnXuLLaYe4I72KEKmIG6icTpLinOLgAOZBP2qphnMysjW1Gb+l lgKYjM4FfLhTc838p3AGEgolHeM4bDXSsjH+A=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=BgWl5bE3ZarNma0JI36yzZei0l57cUP83g2XEypUa4Y=; b=J9rfYaugfi4/bG+UuRk24LvBxZJhMIS5lU0MlAcSph9+B0i5aWXkHwkW5QqIqrWU2R MJvxi1ebhIHdgpdEcxtjvOiRg84adsVKvzHd1o+x85VFokhvzJbGB0E7SWpdtIv+3vEw D66yTyAowFtHmAIEQMpPp1WqW9kf/aQo4wse0u3wJLHfJYLmRqmTnCXSqLvNQ5Ykcuc3 nvz66/w7EKo8immPkRZsGUxN/hQ+pK7Q1BfndcnwkYtppv1LzaChqD4HD7Hb133W5miD +vEprPZ1wIkvqUu08g9D5xRq1Wtsoy/JrixOawDuU+U60oo5aOSWVqY1wvQK+62lOiyR ykNA==
X-Gm-Message-State: APf1xPCT/EOETSZ86cF/z3nbbxvYlq2CA0XSAh80Fj8Tg53+0Dk6cEZX pGPymVPO9Rtq17byFlrnfhjY7w==
X-Google-Smtp-Source: AG47ELtNkje2spUyzfRF0WRfM9C9ktQvEYm23U+bX/zL4csaKnjB05LprqcJoUPPA1FSPaJXna4/Dw==
X-Received: by 10.107.11.169 with SMTP id 41mr13741454iol.25.1519689604372; Mon, 26 Feb 2018 16:00:04 -0800 (PST)
Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id o201sm6241547itb.7.2018.02.26.16.00.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 16:00:03 -0800 (PST)
To: ice@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se>
From: Peter Saint-Andre 
Message-ID: 
Date: Mon, 26 Feb 2018 17:00:02 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="181fAehl3rgiSLZnKr7KeLxzATqfVo82M"
Archived-At: 
Subject: Re: [Ice] Trickle: A couple of questions on section 7
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 00:00:07 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--181fAehl3rgiSLZnKr7KeLxzATqfVo82M
Content-Type: multipart/mixed; boundary="TYOo4Tr07RblU4yBgsqKe5tH5V8XtEwTx";
 protected-headers="v1"
From: Peter Saint-Andre 
To: ice@ietf.org
Message-ID: 
Subject: Re: [Ice] Trickle: A couple of questions on section 7
References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se>

--TYOo4Tr07RblU4yBgsqKe5tH5V8XtEwTx
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2/25/18 12:41 PM, Christer Holmberg wrote:
> Hi,
>=20
> =A0
>=20
> While catching some breath between trying to address IESG comments on
> 5245bis, I took a look at trickle-16, and I have a couple of questions.=


Ah, there's nothing as relaxing as reviewing Internet-Drafts! ;-)

> *Q1:*
>=20
> =A0
>=20
> Section 7.1 says:
>=20
> =A0
>=20
> =A0=A0 =93The ICE specification [rfc5245bis], Section 6.1.4.2, specifie=
s that
>=20
> =A0=A0 an agent will terminate the timer for a triggered check in relat=
ion
>=20
> =A0=A0 to a check list once the agent has exhausted all frozen pairs in=
 the
>=20
> =A0=A0 check list.=A0 This will not work with Trickle ICE, because more=
 pairs
>=20
> =A0=A0 will be added to the check list incrementally.=94
>=20
> =A0
>=20
> Exactly what procedure in 5245bis dos this text refer to?

Hmm, good question. Emil wrote that text so we might want to check with
him, but looking at 5245bis I'd say it refers to the last sentence in
Step 4 of =A76.1.4.2:

   4.  If this step is reached, no check could be performed for the
       picked check list.  So, without waiting for timer Ta to expire
       again, select the next check list in the Running state and return
       to step #1.  If this happens for every single check list in the
       Running state, meaning there are no remaining candidate pairs to
       perform connectivity checks for, abort these steps.

However, that refers to exhausting all the candidate pairs to be checked
for all check lists, not to "terminat[ing] the timer for a triggered
check in relation to a check list once the agent has exhausted all
frozen pairs in the check list". So we might want to ping Emil.

> *Q2:*
>=20
> =A0
>=20
> Section 7.2 says:
>=20
> =A0
>=20
> =A0=A0 =93When a check list is set to Failed as described above,=20

Note: this "described above" is a summary of the definition from
=A76.1.2.1 of 5245bis.

> regular ICE
>=20
> =A0=A0 requires the agent to update all other check lists, placing one =
pair
>=20
> =A0=A0 from each check list into the Waiting state and thereby effectiv=
ely
>=20
> =A0=A0 placing all remaining check lists into the Running state.=94
>=20
> =A0
>=20
> Exactly what procedure in 5245bis dos this text refer to?

Here again Emil wrote this text. My best guess is that this refers to
Step 4 in =A76.1.4.2 of 5245bis:

   4.  If this step is reached, no check could be performed for the
       picked check list.
       [PSA: i.e., the check list is set to Failed.]
       So, without waiting for timer Ta to expire
       again, select the next check list in the Running state and return
       to step #1.

If we don't hear from Emil in the next few days I will ping him offlist.

Peter


--TYOo4Tr07RblU4yBgsqKe5tH5V8XtEwTx--

--181fAehl3rgiSLZnKr7KeLxzATqfVo82M
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqUn4IACgkQZWGMGH9o
FKniPQ//boI1hbUAfZD81MIC9WGXnPooL5MxqJjIqDLdTo/msd8HA6LcDwafCa2O
OHa8/q02VB1msgVhRzwfVZZ1AvJRceacWfxHalMB3CRDZ0oGjHGFDx6EUpNNPB8D
3e1m4e5H/b7/6cy3lGZxzQL3nq877a46cw1FBPY0g5z+cimKqoOO2Ajn2gXTJHXa
avgrm9eCB6/D2MNJrb/PI741PcC+PyzU3Hi+7XcSfa0+P7MAfCVy8IUG+vzaitGD
2ZtPaQsvrCysguxt/0Ke0B/RKQRRnQoj/0ARHbiXGipIWXBJbz8zruiaQJGNFWB3
yaqFBvFhQth0BVHCYVRGYrJVgrnFo4DV7c+Bgp9VLANTnBjMBYsKJ7rfWjoVWl6g
r1yDOBSSb03TG+xapZEZpWddgW+emW02CEQ/wGOa79zh/cPbjPhmS11LwK9Sa+Rs
00WTrpBEq/AG9GZRUvt5WAs8lJKi54QkM4et8FHPBfa2ZJF/9F3Sr6SjNLMu/Ifk
0OvO2TP6rE0oSa8hyxORXbfxYNTnRcz+sw+iT+NzVcACSkk2awAdRw4g5cO901hQ
chkanJbeoeurXC16bF6h1iyrDDBxY41pTnbzbhPJ+A9kxwcwh6Q5K1vutyN+kTkP
dbERCBjnKiZ3WLk7LXdFZp2/DErhVUCesaPCp1YMMTb0qa2BcG4=
=WkY9
-----END PGP SIGNATURE-----

--181fAehl3rgiSLZnKr7KeLxzATqfVo82M--


From nobody Mon Feb 26 16:11:15 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CA2124235 for ; Mon, 26 Feb 2018 16:11:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 DhCHPanvujw5 for ; Mon, 26 Feb 2018 16:11:09 -0800 (PST)
Received: from mail-pl0-x236.google.com (mail-pl0-x236.google.com [IPv6:2607:f8b0:400e:c01::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 AD5AE1201F8 for ; Mon, 26 Feb 2018 16:11:09 -0800 (PST)
Received: by mail-pl0-x236.google.com with SMTP id bb3so10290613plb.2 for ; Mon, 26 Feb 2018 16:11:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pF+WRmPhLsIZFllORPQRWcz4LMXi+bKUYudKyRt6kYQ=; b=XS801REAiX+7zguKDzc8de34/teZDBYWAGdL+6rt9cxC3EnVjcvQvyRN4xYO+zpN8A j+bvl4zXYhB9CJLn83/oYFWBa5PkNa8+7x2bxtBQEu0aIkp4q5eLRJbAzCVSEm5Yjsv1 Cs/uFxKhiqbJuOTxAQM5Ig7P6KYBE0VwzfkvM=
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=pF+WRmPhLsIZFllORPQRWcz4LMXi+bKUYudKyRt6kYQ=; b=tmNYVO520R16MFIJXqT52bcLq02XRDCPKCHJdN3BhgH8JLmfhzIPB6whWTSdKqq43g TIKNH0qv9JLSY5CJjqcFGH/sAr+mP3xTDNWuD3ZWiSZmfC32JZW3Hn74fC9SAW7Ym9Hv fsurBK6B2XCrnu9iHk5mfDoMkbRfWx8mY6Z2B+1Tk3zfX8F8b2dsITe3AitH2ss9Eg6v q1UNboQfst/cfRoNHqHTLyyBD2Lm1tU+SqxZyTi1rbTjaUe8wfJ1/r0cFtfhR9UhTewk Pb/hVkfJ2Bi+ug9BLQsoRMnlwLI7Bk7hK5/o9bwULvCJE85mAyr9nKghfzD0e9SEB28l zPTQ==
X-Gm-Message-State: APf1xPB2/bZlyY9Mxk90hmoukJ8asFIKpjFsiRyY++x7mqU0PhZ54PL8 bGoB6SAto5dopT1bXl129WP9cQ==
X-Google-Smtp-Source: AG47ELtCrJR7pYZYNMLw910onexg38zGAhVhaE2anqb/0kfXJPQMW2dPBKn82ubBVOg6dkPcsGvxIg==
X-Received: by 2002:a17:902:3124:: with SMTP id w33-v6mr7906358plb.119.1519690268903;  Mon, 26 Feb 2018 16:11:08 -0800 (PST)
Received: from ?IPv6:2620:101:80fc:224:151e:363e:a38f:5571? ([2620:101:80fc:224:151e:363e:a38f:5571]) by smtp.gmail.com with ESMTPSA id q6sm13909710pga.37.2018.02.26.16.11.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 16:11:07 -0800 (PST)
From: Nils Ohlmeier 
Message-Id: <1B5E5109-06DF-480A-B32F-43943524B836@mozilla.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_0B71BC6E-0AF6-48DB-BA04-7572F8B2907F"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 26 Feb 2018 16:11:02 -0800
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1ABB3E@ESESSMB109.ericsson.se>
Cc: Ted Hardie , Ben Campbell , "ice-chairs@ietf.org" , "ice@ietf.org" 
To: Christer Holmberg 
References: <7594FB04B1934943A5C02806D1A2204B6C19C590@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C1ABB3E@ESESSMB109.ericsson.se>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [Ice] ICE change in role conflict ([was: Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security Considerations) - Role conflict issue)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 00:11:13 -0000

--Apple-Mail=_0B71BC6E-0AF6-48DB-BA04-7572F8B2907F
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_ECD377ED-1E9D-4F8D-A69B-BBC82CF9F5E6"


--Apple-Mail=_ECD377ED-1E9D-4F8D-A69B-BBC82CF9F5E6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Feb 26, 2018, at 11:59, Christer Holmberg =
 wrote:
>=20
> Hi Ted,
>=20
> ICE re-start was suggested earlier, but people didn=E2=80=99t like it.
>=20
> I don=E2=80=99t think the solution adds very much complexity. It=E2=80=99=
s more or less supported already, the only difference is that we change =
=E2=80=9CMAY pick a new tie-breaker value=E2=80=9D to =E2=80=9CMUST pick =
a new tie-breaker value=E2=80=9D.
>=20
> And, even if only one of the endpoints actually do pick a new value, =
and the other keeps the old value, things will still work :)

Firefox has actually encountered endpoints in the wild which kept using =
0 or 1 (I=E2=80=99m not sure any more) as it=E2=80=99s tie breaker =
value.

I=E2=80=99m not a fan of the ICE restart solution, because it would need =
another round of negotiation, which is slow. Thus I like you proposed =
solution better, although it means more code.

Best
  Nils Ohlmeier

>=20
> Regards,
>=20
> Christer
> =C2=A0 <>
> From: Ted Hardie [mailto:ted.ietf@gmail.com]
> Sent: 26 February 2018 21:44
> To: Christer Holmberg 
> Cc: ice@ietf.org; Ben Campbell ; ice-chairs@ietf.org
> Subject: Re: [Ice] ICE change in role conflict ([was: Eric Rescorla's =
No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding =
Security Considerations) - Role conflict issue)
>=20
> Hi Christer,
>=20
> On Sun, Feb 25, 2018 at 2:08 AM, Christer Holmberg =
> =
wrote:
> Hi,
>=20
> I ask the community to take a look at the suggested change below, and =
indicate whether you have any issues.
>=20
> NUTSHELL:
>=20
> What=E2=80=99s the problem?
>=20
> In case both agents assume the same role (might happen in certain 3PCC =
scenarios), AND use the same tie-breaker value (unlikely to happen, but =
possible in theory), which may cause both endpoints to send a 487 =
response.
>=20
> The 487 response will cause both endpoints and change their roles, and =
try again. But, unless they also change the tie-breaker value, the =
result will be the same: both will assume the same role (since both =
received 487), and might use the same tie-breaker values.
>=20
>=20
> What=E2=80=99s the solution?
>=20
> Specify that, when an endpoint receives 487, and changes its role, it =
MUST also change the tie-breaker value. That way, when both endpoints =
again try, unless the endpoints again choose the same tie-breaker value =
(even more unlikely) only one should send a 487, and the role conflict =
will be solved.
>=20
>=20
> So, I propose something even simpler.  In the very rare case that the =
peers see that the tie-breaker values are the same, both sides should =
restart ICE.  Restarting ICE results in new tie-breaker values being =
selected in any case.
>=20
> My logic here is this:  this occurs pretty rarely to start with, =
essentially only in the case of third-party call control.  In that =
subset of cases, the two sides have to select the same value out of a =
4-billion odd range.   So, at least hopefully, this is not a common =
occurrence.  Code covering uncommon occurrences tends to bit rot.  Using =
"re-start ICE" means re-using code that will be maintained for other =
reasons, where re-start with a new tie-breaker value will not be.
>=20
> I am willing to accept your current solution, though, if other folks =
are not concerned about the complexity.
>=20
> Ted
>=20
>=20
>=20
>=20
> What if I don=E2=80=99t like the suggested solution?
>=20
> Suggest something better (read: provide actual text =
change/removal/additions).
>=20
>=20
> DETAILS:
>=20
> Please see discussion thread below.
>=20
> Regards,
>=20
> Christer
>=20
>=20
> =C2=A0 <>
> From: Eric Rescorla [mailto:ekr@rtfm.com ]
> Sent: 24 February 2018 22:53
> To: Christer Holmberg >
> Cc: Taylor Brandstetter >; Ben Campbell >; ice-chairs@ietf.org =
; ice@ietf.org ; =
draft-ietf-ice-rfc5245bis@ietf.org =
; pthatcher@google.com =
; The IESG >
> Subject: Re: [Ice] Eric Rescorla's No Objection on =
draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security =
Considerations) - Role conflict issue
>=20
>=20
>=20
> On Sat, Feb 24, 2018 at 12:37 PM, Christer Holmberg =
> =
wrote:
> Hi,
>=20
> I had a closer look at the role conflict issue.
>=20
> First, the draft already covers the case when the tie-breaker values =
are identical. It is described in section 7.3.1.1 :
>=20
>    =E2=80=9CIf the agent's tie-breaker value is larger than or equal =
to=E2=80=A6=E2=80=9D
>=20
> Yes. My point is that this is broken.
>=20
>=20
>=20
> =E2=80=A6the agent sends 487.
>=20
> Then, according to section 7.2.5.1., when an agent receives the 487 =
response it will change its role.
>=20
> Now, if BOTH agents send 487, it means BOTH agents will switch their =
roles, and try again. Now, since both agents switch their role, and keep =
the same tie-breaker value, the result will again be the same (only with =
different roles).
>=20
> Yes, so they oscillate back and forth.
>=20
>=20
>=20
> Section 7.2.5.1 :
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> OLD:
>=20
> Once the agent has switched its role, the agent MUST add the
> candidate pair whose check generated the 487 error response to the
> triggered check queue associated with the check list to which the
> pair belongs, and set the candidate pair state to Waiting.  When the
> triggered connectivity check is later performed, the ICE-CONTROLLING/
> ICE-CONTROLLED attribute of the Binding request will indicate the
> agent's new role.  The agent MAY change the tie-breaker value.
>=20
>=20
> NEW:
>=20
> Once the agent has switched its role, the agent MUST add the
> candidate pair whose check generated the 487 error response to the
> triggered check queue associated with the check list to which the
> pair belongs, and set the candidate pair state to Waiting.  When the
> triggered connectivity check is later performed, the ICE-CONTROLLING/
> ICE-CONTROLLED attribute of the Binding request will indicate the
> agent's new role.  The agent MUST change the tie-breaker value.
>=20
>=20
> Section 16.1:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>=20
> OLD:
>=20
> An ICE agent MUST use the same number for all
> Binding requests, for all streams, within an ICE session. The agent
> MAY change the number when an ICE restart occurs.
>=20
> NEW:
>=20
> An ICE agent MUST use the same number for all
> Binding requests, for all streams, within an ICE session, unless
> it receives a 487 response, in which case it MUST change the
> number (Section 7.2.5.1). The agent MAY change the number when
> an ICE restart occurs.
>=20
> Problem solved? :)
>=20
> This would be fine with me, but presumably needs WG signoff.
>=20
> -Ekr
>=20
>=20
> Regards,
>=20
> Christer
>=20
>=20
> =C2=A0 <>
> From: Eric Rescorla [mailto:ekr@rtfm.com ]
> Sent: 21 February 2018 01:07
> To: Taylor Brandstetter >
> Cc: Christer Holmberg >; Ben Campbell >; ice-chairs@ietf.org =
; ice@ietf.org ; =
draft-ietf-ice-rfc5245bis@ietf.org =
; pthatcher@google.com =
; The IESG >
> Subject: Re: [Ice] Eric Rescorla's No Objection on =
draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security =
Considerations)
>=20
> I wouldn't object if someone produced a principled fix. I just don't =
want to create a lot of work for people
>=20
>=20
> On Tue, Feb 20, 2018 at 2:51 PM, Taylor Brandstetter =
> wrote:
> The tie-breaker collision problem has come up a few times before, =
actually. As I've said, I believe it could be fixed very easily by =
saying "pick a new tie-breaker if this happens."
>=20
> As for the "MUST not change tie-breaker" rule in section 16.1, =
requiring an ICE restart is overkill. We can just change it to "MUST not =
change tie-breaker unless there's a collision."
>=20
> On Mon, Feb 19, 2018 at 10:33 AM, Eric Rescorla > wrote:
>=20
>=20
> On Mon, Feb 19, 2018 at 10:29 AM, Christer Holmberg =
> =
wrote:
> Hi,
>=20
> ...
>=20
> >>>> IF we really want to solve this, one simple solution be to say =
that, if this happens, and endpoint simply calculates a
> >>>> new tie-breaker value, and tries again? BUT, then we would have =
to change section 16.1, which says that a new value can only be =
calculated at an ICE restart.
> >>>>
> >>>> So, could we simply say that, if this happens, the agent MUST do =
an ICE restart, and it MUST calculate a new tie-breaker value?
> >>>
> >>> Now both sides might do a simultaneous restart. Is that going to =
work?
> >>
> >> We could say that the initiating agent MUST do the restart.
> >
> > In this scenario, don't both sides believe they are the initiating =
peer, hence the need for the tiebreaker?
>=20
> Probably...
>=20
> But, then I don't see what we could do. If both agents send a check, =
and receive 487, we can't define a procedure for one of the agents.
>=20
> Perhaps we should then change the =
must-not-change-the-value-unless-restart and say that an agent changes =
the tie-breaker value and try again.
>=20
> As you say, the problem is inherently that the situation is =
symmetrical.
>=20
> At this point in the design process, I don't think it's worth trying =
to actually make the call succeed; a 2^{-64} failure rate is much lower =
than organic call failure rates from other causes, even in non-3PCC =
scenarios. Rather, I think the spec should just prescribe a clean =
failure mode via a new error code, rather than having both sides wildly =
oscillate between controlled and controlling
>=20
> -Ekr
>=20
>=20
> Regards,
>=20
> Christer
>=20
>=20
>=20
> _______________________________________________
> Ice mailing list
> Ice@ietf.org 
> https://www.ietf.org/mailman/listinfo/ice =

>=20
>=20
>=20
>=20
> _______________________________________________
> Ice mailing list
> Ice@ietf.org 
> https://www.ietf.org/mailman/listinfo/ice =

>=20
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice


--Apple-Mail=_ECD377ED-1E9D-4F8D-A69B-BBC82CF9F5E6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On =
Feb 26, 2018, at 11:59, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi =
Ted,
 
ICE re-start was =
suggested earlier, but people didn=E2=80=99t like it.
 
I don=E2=80=99t think =
the solution adds very much complexity. It=E2=80=99s more or less =
supported already, the only difference is that we change =E2=80=9CMAY =
pick a new tie-breaker value=E2=80=9D to =E2=80=9CMUST pick a new =
tie-breaker value=E2=80=9D.
 
And, even if only one of the endpoints actually do pick a new =
value, and the other keeps the old value, things will still work :)

Firefox has actually encountered endpoints in the wild =
which kept using 0 or 1 (I=E2=80=99m not sure any more) as it=E2=80=99s =
tie breaker value.

I=E2=80=99m not a =
fan of the ICE restart solution, because it would need another round of =
negotiation, which is slow. Thus I like you proposed solution better, =
although it means more code.

Best
  Nils Ohlmeier

 
Regards,
 
Christer
 
From: Ted Hardie =
[mailto:ted.ietf@gmail.com] 
Sent: 26 =
February 2018 21:44
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: ice@ietf.org; Ben Campbell =
<ben@nostrum.com>;=
 ice-chairs@ietf.org
Subject: Re: [Ice] ICE change in =
role conflict ([was: Eric Rescorla's No Objection on =
draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding Security =
Considerations) - Role conflict issue)
 
Hi Christer,
 
On Sun, Feb 25, 2018 at 2:08 AM, Christer Holmberg =
<christer.holmberg@ericsson.com> wrote:
Hi,
 
I ask the community to =
take a look at the suggested change below, and indicate whether you have =
any issues.
 
NUTSHELL:
 
What=E2=80=99s the problem?
 
In case both agents =
assume the same role (might happen in certain 3PCC scenarios), AND use =
the same tie-breaker value (unlikely to happen, but possible in theory), =
which may cause both endpoints to send a 487 response.
 
The 487 response will =
cause both endpoints and change their roles, and try again. But, unless =
they also change the tie-breaker value, the result will be the same: =
both will assume the same role (since both received 487), and might use =
the same tie-breaker values.
 
 
What=E2=80=99s the solution?
 
Specify that, when an =
endpoint receives 487, and changes its role, it MUST also change the =
tie-breaker value. That way, when both endpoints again try, unless the =
endpoints again choose the same tie-breaker value (even more unlikely) =
only one should send a 487, and the role conflict will be =
solved.
 
 
So, I propose something even simpler.  In the =
very rare case that the peers see that the tie-breaker values are the =
same, both sides should restart ICE.  Restarting ICE results in new =
tie-breaker values being selected in any case.
My logic here is this:  this occurs pretty =
rarely to start with, essentially only in the case of third-party call =
control.  In that subset of cases, the two sides have to select the =
same value out of a 4-billion odd range.   So, at least hopefully, =
this is not a common occurrence.  Code covering uncommon =
occurrences tends to bit rot.  Using "re-start ICE" means re-using =
code that will be maintained for other reasons, where re-start with a =
new tie-breaker value will not be.
I am =
willing to accept your current solution, though, if other folks are not =
concerned about the complexity.
Ted
 

 
 
What if I don=E2=80=99t like the suggested =
solution?
 
Suggest something better (read: provide actual text =
change/removal/additions).
 
 
DETAILS:
 
Please see discussion thread below.
 
Regards,
 
Christer
 
 
From: Eric Rescorla [mailto:ekr@rtfm.com] 
Sent: 24 =
February 2018 22:53
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Taylor Brandstetter <deadbeef@google.com>; Ben Campbell <ben@nostrum.com>; ice-chairs@ietf.org; ice@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; pthatcher@google.com; =
The IESG <iesg@ietf.org>
Subject: Re: [Ice] Eric Rescorla's =
No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding =
Security Considerations) - Role conflict issue
 
 
 
On Sat, Feb 24, 2018 at =
12:37 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,
 
I had a closer look at =
the role conflict issue.
 
First, the draft already covers the case when the tie-breaker =
values are identical. It is described in section 7.3.1.1:
 
   =E2=80=9CIf the agent's tie-breaker value is =
larger than or equal to=E2=80=A6=E2=80=9D
 
Yes. My point is that this is broken.
 
 
 
=E2=80=A6the agent =
sends 487.
 
Then, according to =
section 7.2.5.1., when an agent receives the 487 response it will change =
its role.
 
Now, if BOTH agents =
send 487, it means BOTH agents will switch their roles, and try again. =
Now, since both agents switch their role, and keep the same tie-breaker =
value, the result will again be the same (only with different =
roles).
 
Yes, so they oscillate back and forth.
 
 
 
Section 7.2.5.1:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
 
OLD:
 
Once the agent has =
switched its role, the agent MUST add the
candidate pair whose =
check generated the 487 error response to the
triggered check queue =
associated with the check list to which the
pair belongs, and set =
the candidate pair state to Waiting.  When the
triggered connectivity =
check is later performed, the ICE-CONTROLLING/
ICE-CONTROLLED =
attribute of the Binding request will indicate the
agent's new role.  =
The agent MAY change the tie-breaker =
value.
 
 
NEW:
 
Once the agent has =
switched its role, the agent MUST add the
candidate pair whose =
check generated the 487 error response to the
triggered check queue =
associated with the check list to which the
pair belongs, and set =
the candidate pair state to Waiting.  When the
triggered connectivity =
check is later performed, the ICE-CONTROLLING/
ICE-CONTROLLED =
attribute of the Binding request will indicate the
agent's new role.  =
The agent MUST change the tie-breaker =
value.
 
 
Section =
16.1:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
 
OLD:
 
An ICE agent MUST use =
the same number for all
Binding requests, for all streams, within an ICE session. The =
agent
MAY change the number =
when an ICE restart occurs.
 
NEW:
 
An =
ICE agent MUST use the same number for all
Binding requests, for =
all streams, within an ICE session, unless
it receives a =
487 response, in which case it MUST change the
number =
(Section 7.2.5.1). The agent =
MAY change the number when 
an ICE restart =
occurs.
 
Problem solved? =
:)
 
This would be fine with me, but presumably needs WG =
signoff.
 
-Ekr
 
 
Regards,
 
Christer
 
 
From: Eric Rescorla [mailto:ekr@rtfm.com] 
Sent: 21 =
February 2018 01:07
To: Taylor Brandstetter <deadbeef@google.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>; Ben Campbell <ben@nostrum.com>; ice-chairs@ietf.org; ice@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; pthatcher@google.com; =
The IESG <iesg@ietf.org>
Subject: Re: [Ice] Eric Rescorla's =
No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (excluding =
Security Considerations)
 
I wouldn't object if someone produced a principled fix. I =
just don't want to create a lot of work for people
  
 
On Tue, Feb =
20, 2018 at 2:51 PM, Taylor Brandstetter <deadbeef@google.com> wrote:
The tie-breaker =
collision problem has come up a few times before, actually. As I've =
said, I believe it could be fixed very easily by saying =
"pick a new tie-breaker if this happens."
 
As for the "MUST not change tie-breaker" rule in =
section 16.1, requiring an ICE restart is overkill. We can just change =
it to "MUST not change tie-breaker unless there's a =
collision."
 
On Mon, Feb =
19, 2018 at 10:33 AM, Eric Rescorla <ekr@rtfm.com> wrote:
 
 
On Mon, Feb 19, 2018 at =
10:29 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

...

>>>> IF we =
really want to solve this, one simple solution be to say that, if this =
happens, and endpoint simply calculates a
>>>> =
new tie-breaker value, and tries again? BUT, then we would have to =
change section 16.1, which says that a new value can only be calculated =
at an ICE restart.
>>>>
>>>> So, could we simply say that, if this =
happens, the agent MUST do an ICE restart, and it MUST calculate a new =
tie-breaker value?
>>>
>>> =
Now both sides might do a simultaneous restart. Is that going to =
work?
>>
>> We could say that =
the initiating agent MUST do the restart.
>
> In this scenario, don't both sides believe they are the =
initiating peer, hence the need for the tiebreaker?

Probably...

But, then I don't =
see what we could do. If both agents send a check, and receive 487, we =
can't define a procedure for one of the agents.

Perhaps we should then change the =
must-not-change-the-value-unless-restart and say that an agent changes =
the tie-breaker value and try again.
 
As you say, the problem is inherently that the =
situation is symmetrical.
 
At this point in the design process, I don't think =
it's worth trying to actually make the call succeed; a 2^{-64} failure =
rate is much lower than organic call failure rates from other causes, =
even in non-3PCC scenarios. Rather, I think the spec should just =
prescribe a clean failure mode via a new error code, rather than having =
both sides wildly oscillate between controlled and controlling
 
-Ekr
 

Regards,

Christer
 
 
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
 
 
 

_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
 
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice
=

--Apple-Mail=_ECD377ED-1E9D-4F8D-A69B-BBC82CF9F5E6--

--Apple-Mail=_0B71BC6E-0AF6-48DB-BA04-7572F8B2907F
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-----

iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlqUohYACgkQY2o/VmzJ
+KHfjxAAl+PnhNyG1pNKjA1fDAvXmK5trRzQHcEYLAT0bhWtp8lWbEvTEOWaFZnK
uNLBnTD0kvaQZ/GwS+OXNJ4ouvi5+hstIDu74yrU+GvK+gRGM7KOHTDdSs18VZ3D
ea3SraWTHu+o8nKOULTVSXJlWuiQn7hmtdD7LKCKxrrn8tS0It95UUE+IbR3Bf8X
6Vtt41zd4h7RjS4yRkCveV4tdr+YMmCmtfdxqBUrgOh9jMoMLi2dmvKe7PR6eZkg
mUZ1KmDj7xkpffZNlgfRspzrKJrwjqFYnP8WObcMB/vwRzkkjFT9UeYMG1kh212L
VtZcqa/M3WSyLWqrS3zhQVOcvghm68ERU410oPbNIhwQAvpW+YvqXIcesDfMQGpc
ZwGgmM3J9BlAwwck6+9b5D1qwgXvgVpCNgB3Jp7mgd/VGiRyPIBbh7+rblwKN9ks
5p5LZRCxUepnDgKbcQ9izOH8ij0tkLRhm/NHSY89U3PcL+qgic0ybdUppnVP1AAD
W9WaKCNu8F1niGumST3Qt9Dja6XK3YCqoiavrsHcGFJu+m5aRG1yFEuFW7ysXFIl
0lTWJrInQnkOdVxtxYI2Cg3CUkujhca2ByXYLd/0Xt9mwC4J3SwSz1q4gipE7ExY
JqMTih9hSmaCHm4wfCMX6eHtUFw9rBOSpr6Wes/qFX9i2GPz1h4=
=a5SY
-----END PGP SIGNATURE-----

--Apple-Mail=_0B71BC6E-0AF6-48DB-BA04-7572F8B2907F--


From nobody Mon Feb 26 16:25:27 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D8012D951 for ; Mon, 26 Feb 2018 16:25:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 ShM1k_w7W_-2 for ; Mon, 26 Feb 2018 16:25:23 -0800 (PST)
Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (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 89A2612D94E for ; Mon, 26 Feb 2018 16:25:20 -0800 (PST)
Received: by mail-pl0-x22e.google.com with SMTP id s13so10304282plq.6 for ; Mon, 26 Feb 2018 16:25:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=h+mZYltF6UaR9C5MbcAIbykd03UeFfqaGoT0xEOtLbs=; b=eVK1mbQDRIjvuxn1Q9Blm0Lkrf9Av28YEeiIY32nXW40BS5lM8NjCn7CmJlt+SN8Qg efBDaaKu1a8b73YSaNWjTzxz5xgvsemTMw69HO+kgZTRFp6LJcoAQ3KkFdj/tf5MQeTT KwWJVURq3UgMSptxFIAsPBBnla4sl0XCW4P2g=
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=h+mZYltF6UaR9C5MbcAIbykd03UeFfqaGoT0xEOtLbs=; b=I6kb3sGUFevUP29cQSNW7mgmZBN2I/i8ydd5GSKIXgZunG0VmU7Bn3p3gKETfQyzQo dbIg3gpxffLew5KouVM60hIZ/CC5hiAGjPdnDMK7KPrA1RPElZLiwWG880LS3QT1vS3X 1+Taw0/DdWzZCUOwAKGD/+4I65TPowslDR+v1KuUQzkuoVvXZL5iA0V2/uncr0QaAcou rzGU8MiSSb0Vrr3j97+AykRy5qAEi2lhVyErqr2I1qqnqPh/d193LPiFFM8LJZmydbHn xOC4ASf+L7qIPvfGCcS8V1VQYGXEhzYhyV62tVbpZfvUs/0UpM6w1MoaR+5vuMD2t1S3 Qmew==
X-Gm-Message-State: APf1xPD4eOHD0YT/sQfbAVbZyiLHItQ6UuLhfEKM8RdJ5iAHYrkuXK7q vNcgnKkakclrNulU+IlJ7k2MtA==
X-Google-Smtp-Source: AH8x227MGrniEKiwq0Q80wV127+djvMO5QGmT0uW6+/xlPKF4eAv6cW97NQ5j2HlgfzvFUb24n86YQ==
X-Received: by 2002:a17:902:7182:: with SMTP id b2-v6mr12200009pll.331.1519691119793;  Mon, 26 Feb 2018 16:25:19 -0800 (PST)
Received: from ?IPv6:2620:101:80fc:224:151e:363e:a38f:5571? ([2620:101:80fc:224:151e:363e:a38f:5571]) by smtp.gmail.com with ESMTPSA id s127sm21571305pfb.178.2018.02.26.16.25.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 16:25:18 -0800 (PST)
From: Nils Ohlmeier 
Message-Id: <1A521409-0DF9-42B7-B1D9-0F8FB6FA7008@mozilla.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_6FE05742-F8AA-41DC-A8D0-A42686F17C90"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 26 Feb 2018 16:25:13 -0800
In-Reply-To: 
Cc: Christer Holmberg , "ice@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , "jri@google.com" 
To: "Black, David" 
References: <7594FB04B1934943A5C02806D1A2204B6C19C90C@ESESSMB109.ericsson.se>    <7594FB04B1934943A5C02806D1A2204B6C1A8CC5@ESESSMB109.ericsson.se> <143496D8-1304-49C3-B12F-5EF3A116E1BD@mozilla.com> 
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [Ice] 5245bis: STUN/TURN transaction timeout timer
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 00:25:25 -0000

--Apple-Mail=_6FE05742-F8AA-41DC-A8D0-A42686F17C90
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_3D643F7F-4B12-45ED-B7FC-312D9E63B0CD"


--Apple-Mail=_3D643F7F-4B12-45ED-B7FC-312D9E63B0CD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes you are right. Somehow I managed to read Christer=E2=80=99s Note the =
opposite way of what I now think he intends to point out.

Sorry for the confusion.

  Nils


> On Feb 26, 2018, at 15:15, Black, David  wrote:
>=20
> Isn=E2=80=99t it the other way around =E2=80=93 ICE HTO is much =
shorter than STUN or TURN Ti? <>
>=20
> Thanks, --David
>=20
> From: Nils Ohlmeier [mailto:nohlmeier@mozilla.com]
> Sent: Monday, February 26, 2018 6:11 PM
> To: Christer Holmberg 
> Cc: Black, David ; ice@ietf.org; =
draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org; jri@google.com
> Subject: Re: [Ice] 5245bis: STUN/TURN transaction timeout timer
>=20
>=20
> On Feb 26, 2018, at 07:48, Christer Holmberg =
> =
wrote:
>=20
> Maybe adding the following note to the existing Timer HTO definition:
>=20
> Timer HTO:  The timeout timer for a given STUN or TURN transaction.
>=20
>   =E2=80=9CNOTE: When STUN and TURN are used with ICE, timer HTO is =
used instead of timer Ti [RFC5389] as transaction timeout timer.=E2=80=9D
>=20
> My initial thought was: yes sounds good.
>=20
> But one of the side effects know from real world deployments is that =
results in the end-of-candidates indication coming in after a long time =
if one of the STUN or TURN servers is not reachable.
> I don=E2=80=99t want to make this a last minute change, but your =
indication that Ti explicitly got made shorter made me wonder if =
everyone in WG is aware of this usage of the long HTO value.
>=20
> Best
>   Nils Ohlmeier
>=20
>=20
>=20
> Regards,
>=20
> Christer
>=20
> From: Black, David [mailto:David.Black@dell.com =
]
> Sent: 26 February 2018 16:54
> To: Christer Holmberg >;ice@ietf.org =
; draft-ietf-ice-rfc5245bis@ietf.org =
; ice-chairs@ietf.org =

> Cc: jri@google.com ; Black, David =
>
> Subject: RE: 5245bis: STUN/TURN transaction timeout timer
>=20
> That would be a fine thing to do, Thanks, --David
>=20
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com =
]
> Sent: Monday, February 26, 2018 9:22 AM
> To: Black, David >; =
ice@ietf.org ; draft-ietf-ice-rfc5245bis@ietf.org =
; ice-chairs@ietf.org =

> Cc: jri@google.com 
> Subject: Re: 5245bis: STUN/TURN transaction timeout timer
>=20
> Hi,
>=20
> >> But, still, is there a reason we couldn=E2=80=99t use =E2=80=98Ti=E2=80=
=99 also in 5245bis, and point out the big value difference when used =
with ICE?
> >
> >Given the nearly 2-orders-of-magnitude difference in the time =
periods, I=E2=80=99d be concerned that using the same name risks leaving =
an incorrect impression on an implementer who
> >is familiar with one protocol, but new to the other.   Different =
names may also improve clarity in other documents that describe how STUN =
and ICE work together.
>=20
> Fair enough. But, should we then point out that Ti isn=E2=80=99t used =
with ICE?
>=20
> Regards,
>=20
> Christer
>=20
>=20
>=20
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com =
]
> Sent: Sunday, February 25, 2018 8:00 AM
> To: ice@ietf.org ; =
draft-ietf-ice-rfc5245bis@ietf.org =
; ice-chairs@ietf.org =

> Cc: Black, David >; =
jri@google.com 
> Subject: 5245bis: STUN/TURN transaction timeout timer
>=20
> Hi,
>=20
> In draft-5245bis, the name of the STUN/TURN transaction timeout timer =
is =E2=80=98HTO=E2=80=99.
>=20
> As part of the IESG review, I have been asked what the =E2=80=98H=E2=80=99=
 stands for. After some digging in the mail archives (2016-09-14), I =
figured out it stands for =E2=80=9Chandshake=E2=80=9D:
>=20
> https://www.ietf.org/mail-archive/web/ice/current/msg00378.html =

>=20
>       =E2=80=9C2.  A timeout for request packets, call it handshake =
timeout or HTO which SHOULD be 2*RTT if the RTT is known and 500ms =
otherwise.=E2=80=9D
>=20
> Now, in RFC 5389, the transaction timeout timer is called =E2=80=98Ti=E2=
=80=99. However, the default value for that SHOULD be 39,5 seconds =E2=80=93=
 which is quite different from 500ms.
>=20
> But, still, is there a reason we couldn=E2=80=99t use =E2=80=98Ti=E2=80=99=
 also in 5245bis, and point out the big value difference when used with =
ICE?
>=20
> Regards,
>=20
> Christer
> _______________________________________________
> Ice mailing list
> Ice@ietf.org 
> https://www.ietf.org/mailman/listinfo/ice =


--Apple-Mail=_3D643F7F-4B12-45ED-B7FC-312D9E63B0CD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yes =
you are right. Somehow I managed to read Christer=E2=80=99s Note the =
opposite way of what I now think he intends to point out.

Sorry for the =
confusion.

  Nils


On Feb =
26, 2018, at 15:15, Black, David <David.Black@dell.com> wrote:

Isn=E2=80=99t it the =
other way around =E2=80=93 ICE HTO is much shorter than STUN or TURN =
Ti?
 
Thanks, --David
 
From: Nils Ohlmeier [mailto:nohlmeier@mozilla.com] 
Sent: Monday, February 26, 2018 =
6:11 PM
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Black, David <david.black@emc.com>; ice@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org; =
jri@google.com
Subject: Re: [Ice] 5245bis: =
STUN/TURN transaction timeout timer
 
 
On Feb 26, 2018, at 07:48, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
 
Maybe adding the following note to the =
existing Timer HTO definition:
 
Timer HTO:  The timeout timer for a given STUN or TURN =
transaction.
 
  =E2=80=9CNOTE: When STUN and TURN are used with ICE, =
timer HTO is used instead of timer Ti [RFC5389] as transaction timeout =
timer.=E2=80=9D
 
My initial thought was: yes sounds =
good.
 
But one of the side effects know from =
real world deployments is that results in the end-of-candidates =
indication coming in after a long time if one of the STUN or TURN =
servers is not reachable.
I don=E2=80=99=
t want to make this a last minute change, but your indication that Ti =
explicitly got made shorter made me wonder if everyone in WG is aware of =
this usage of the long HTO value.
 
Best
  Nils =
Ohlmeier


 
Regards,
 
Christer
 
From: Black, David [mailto:David.Black@dell.com] 
Sent: 26 =
February 2018 16:54
To: Christer Holmberg <christer.holmberg@ericsson.com>;ice@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org
Cc: jri@google.com; Black, David <David.Black@dell.com>
Subject: RE: 5245bis: STUN/TURN =
transaction timeout timer
 
That would be a fine thing to do, Thanks, --David
 
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] 
Sent: Monday, February 26, 2018 =
9:22 AM
To: Black, David <david.black@emc.com>; ice@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org
Cc: jri@google.com
Subject: Re: 5245bis: STUN/TURN =
transaction timeout timer
 
Hi,
 
>> But, still, is there a reason we =
couldn=E2=80=99t use =E2=80=98Ti=E2=80=99 also in 5245bis, and point out =
the big value difference when used with ICE?
> 
>Given the nearly 2-orders-of-magnitude difference in the =
time periods, I=E2=80=99d be concerned that using the same name risks =
leaving an incorrect impression on an implementer who
>is =
familiar with one protocol, but new to the other.   Different =
names may also improve clarity in other documents that describe how STUN =
and ICE work together.
 
Fair enough. But, should we then point out that =
Ti isn=E2=80=99t used with ICE?
 
Regards,
 
Christer
 
 
 
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] 
Sent: Sunday, February 25, 2018 =
8:00 AM
To: ice@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org
Cc: Black, David <david.black@emc.com>; jri@google.com
Subject: 5245bis: STUN/TURN =
transaction timeout timer
 
Hi,
 
In draft-5245bis, the name =
of the STUN/TURN transaction timeout timer is =E2=80=98HTO=E2=80=99.
 
As part of the IESG =
review, I have been asked what the =E2=80=98H=E2=80=99 stands for. After =
some digging in the mail archives (2016-09-14), I figured out it stands =
for =E2=80=9Chandshake=E2=80=9D:
 
https://www.ietf.org/mail-archive/web/ice/current/msg00378.html=

 
      =E2=80=9C2.  A timeout =
for request packets, call it handshake timeout or HTO which SHOULD be =
2*RTT if the RTT is known and 500ms otherwise.=E2=80=9D
 
Now, in RFC 5389, the =
transaction timeout timer is called =E2=80=98Ti=E2=80=99. However, the =
default value for that SHOULD be 39,5 seconds =E2=80=93 which is quite =
different from 500ms.
 
But, still, is there a reason we couldn=E2=80=99t use =
=E2=80=98Ti=E2=80=99 also in 5245bis, and point out the big value =
difference when used with ICE?
 
Regards,
 
Christer
_______________________________________________
Ice mailing list
Ice@ietf.org
https://www.ietf.org/mailman/listinfo/ice

=

--Apple-Mail=_3D643F7F-4B12-45ED-B7FC-312D9E63B0CD--

--Apple-Mail=_6FE05742-F8AA-41DC-A8D0-A42686F17C90
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-----

iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlqUpWkACgkQY2o/VmzJ
+KGoFQ/9FXDIWFqZsjYo+57NhXc9addVc/n9coJ9iav1JqqCjDb9jVJYrrA48SW/
UQZ+juPDitnB5JswUiI93oQ678udBrZsHhAqCLKcTTyRvcLE2HVgFSaCuiNgL7sd
FPISatzcvCD3O13zW2usCmjQDlZVn9whdB7lymJcR4xX8Lza22ib+Q6UMDDfAUOT
iadCKUqT9/Q6qSi52oz5O9Ho2b9TUBJohyyG7RznDFgLZ/hJzwfDmXJ5BOklfekv
As6v0k63BVYWAzmGn4V/1bJbiW2RIQ1F49ek8YlqqFbX+JDxRnTR/kdayWi5GL1C
TlQVSRNOtOqVOamGeGCjf5iR7/LzbOAwMe59A6yLxV5Quz09/Woht7yU1NOm0HFO
Nk6329In/akmtySyn537fVNwO43gyavGE/G0/kBkx0aQv0Isc/uft7ao0Ou92sZP
/uJ0SIdkjyn5O0z15qLmgnIrlAM+5I+n8ENtBb+zNaDTJZmXdNOQSGiY1i2Uwk8Z
DS9tVFm0FSYKA6uadj5HEv9MHKxnoCocZGzYQ7B31wyTnph6hKARpJ/xbH2od8Lz
cn9RA/Z6kp1nMrK4BWyV4wlyj/e1r0qDRp3+wUQcuKvKc3e9/+HcjbjHCDGhegtP
U6Hxf2Q9Zo9Hmn4p/0Onu8qIf5D1O1FPUcLOHedrgfJ1QaiDECo=
=Prc+
-----END PGP SIGNATURE-----

--Apple-Mail=_6FE05742-F8AA-41DC-A8D0-A42686F17C90--


From nobody Mon Feb 26 23:42:58 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB61124B18 for ; Mon, 26 Feb 2018 23:42:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKaLBJ74SY32 for ; Mon, 26 Feb 2018 23:42:55 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 BAA691200B9 for ; Mon, 26 Feb 2018 23:42:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519717372; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aWvd+DT0fB3g8ORykliKzQ64iio5Mzw/eDJYCpwv0zI=; b=CaXAmZjvV6B396CsYY/Z1JZFNSg9HmvmHC9H3vbEXkiDFcixs7W1JjvoNvUyBrjL v2+DwmuEeycEILUK2mrAGPzGUGEL0TGSzO9TW0Ov6+YecbQr0p8wRcuC1ZrYzFkp OzaMm0WswVCEGwbqycOz0+lduBMPpZEvlc7EzF8k6Xk=;
X-AuditID: c1b4fb30-399ff70000004778-a4-5a950bfc4fcd
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 29.DA.18296.CFB059A5; Tue, 27 Feb 2018 08:42:52 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Tue, 27 Feb 2018 08:42:51 +0100
From: Christer Holmberg 
To: Peter Saint-Andre , "ice@ietf.org" 
Thread-Topic: [Ice] Trickle: A couple of questions on section 7
Thread-Index: AdOucJgg+M5x/JnqQAe0nEYDsAIfMAA5PBQAABTM7oA=
Date: Tue, 27 Feb 2018 07:42:51 +0000
Message-ID: 
References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <71A306C411407548ADDDE08D1F705A07@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7qO4f7qlRBjeOqFl8u1Br8WzlKUYH Jo8lS34yefQd6GINYIrisklJzcksSy3St0vgytjdbl7QKV9xqW0NWwPjd/EuRk4OCQETiYXn vrN2MXJxCAkcZpRYsfMlM4SzmFHi9uRTjF2MHBxsAhYS3f+0QRpEBLwkZu65zwRiCwvYScw6 9YcFIm4vsa33GpRtJTH93m4wm0VAVWLNhXtg9bwC1hKTt99hh5jfxCjR+f4tWBEnUHP/gguM IDajgJjE91NrwBqYBcQlbj2ZzwRxqYDEkj3nmSFsUYmXj/+xgtiiAnoSG07cZoeIK0q0P21g hOjVk7gxdQobhG0tMeXPLShbW2LZwtfMEAcJSpyc+YRlAqPYLCTrZiFpn4WkfRaS9llI2hcw sq5iFC1OLU7KTTcy0kstykwuLs7P08tLLdnECIyqg1t+G+xgfPnc8RCjAAejEg/vYcapUUKs iWXFlbmHGCU4mJVEeFcunhwlxJuSWFmVWpQfX1Sak1p8iFGag0VJnPekJ2+UkEB6Yklqdmpq QWoRTJaJg1OqgbFpR0LWp9NNfwIm5Bxz1/m/wP1wY7jg9agTkjdqqxylHfPn3r51rs/mR+Ud 5eN/brA0SE7L/PDn1JFnofvl77axV7dfaPC7WLrwsfPKa4nHlB7tn3xWkfWwb63+nKY8kXQD G/YGv73MM2aYa64xWWFstUFritWka4WdFntCzxzs3CTVspHdR0uJpTgj0VCLuag4EQANrZgd pgIAAA==
Archived-At: 
Subject: Re: [Ice] Trickle: A couple of questions on section 7
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 07:42:57 -0000

Hi,

>>While catching some breath between trying to address IESG comments on
>> 5245bis, I took a look at trickle-16, and I have a couple of questions.
>
>Ah, there's nothing as relaxing as reviewing Internet-Drafts! ;-)

I=B9m not into the whining-about-meeting-venue-location thing, so I had to
come up with something else :)

In general, since there have been quite a bit of changes in 5245bis, I
think all reference to 5245bis should be double checked. Also, there
should always be a reference to the specific section of 5245bis. That way
it is easier to double check, and also identity impacts if that section of
5245bis is updated in future (in a draft or an errata).

>> *Q1:*
>>=20
>> =20
>>=20
>> Section 7.1 says:
>>=20
>> =20
>>=20
>>    =B3The ICE specification [rfc5245bis], Section 6.1.4.2, specifies tha=
t
>>=20
>>    an agent will terminate the timer for a triggered check in relation
>>=20
>>    to a check list once the agent has exhausted all frozen pairs in the
>>=20
>>    check list.  This will not work with Trickle ICE, because more pairs
>>=20
>>    will be added to the check list incrementally.=B2
>>=20
>> =20
>>=20
>> Exactly what procedure in 5245bis dos this text refer to?
>
>Hmm, good question. Emil wrote that text so we might want to check with
>him, but looking at 5245bis I'd say it refers to the last sentence in
>Step 4 of =A76.1.4.2:
>
>   4.  If this step is reached, no check could be performed for the
>       picked check list.  So, without waiting for timer Ta to expire
>       again, select the next check list in the Running state and return
>       to step #1.  If this happens for every single check list in the
>       Running state, meaning there are no remaining candidate pairs to
>       perform connectivity checks for, abort these steps.
>
>However, that refers to exhausting all the candidate pairs to be checked
>for all check lists, not to "terminat[ing] the timer for a triggered
>check in relation to a check list once the agent has exhausted all
>frozen pairs in the check list". So we might want to ping Emil.

I think =B3terminate the timer=B2 is misleading wording. Timer Ta is not
terminated as long as there is at least one check list in =B3Running=B2 mod=
e.

It is true that, whenever timer Ta fires, check lists that are not in the
=B3Running=B2 mode will not be checked. But, even with legacy ICE, a check
list may put back in =B3Running=B2 mode if e.g., a triggered check changes
that status of a failed pair, and if that pair state change affects the
state of the check list.

So, unless I=B9ve missed something, I don=B9t think that trickle changes ho=
w
check lists are checked when Ta fires. If additional candidates have been
gathered, and added to a check list, step 4) in section 6.1.4.2 will not
be reached.

---

>> *Q2:*
>>=20
>> =20
>>=20
>> Section 7.2 says:
>>=20
>> =20
>>=20
>>    =B3When a check list is set to Failed as described above,
>
>Note: this "described above" is a summary of the definition from
>=A76.1.2.1 of 5245bis.
>
>> regular ICE
>>=20
>>    requires the agent to update all other check lists, placing one pair
>>=20
>>    from each check list into the Waiting state and thereby effectively
>>=20
>>    placing all remaining check lists into the Running state.=B2
>>=20
>> =20
>>=20
>> Exactly what procedure in 5245bis dos this text refer to?
>
>Here again Emil wrote this text. My best guess is that this refers to
>Step 4 in =A76.1.4.2 of 5245bis:
>
>   4.  If this step is reached, no check could be performed for the
>       picked check list.
>       [PSA: i.e., the check list is set to Failed.]
>       So, without waiting for timer Ta to expire
>       again, select the next check list in the Running state and return
>       to step #1.
>
>If we don't hear from Emil in the next few days I will ping him offlist.

Thanks!

Regards,

Christer


From nobody Tue Feb 27 04:23:58 2018
Return-Path: 
X-Original-To: ice@ietf.org
Delivered-To: ice@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 965A7129C5D; Tue, 27 Feb 2018 04:23:56 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: ice@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.73.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151973423657.29249.10036606150732328108@ietfa.amsl.com>
Date: Tue, 27 Feb 2018 04:23:56 -0800
Archived-At: 
Subject: [Ice] I-D Action: draft-ietf-ice-rfc5245bis-18.txt
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 12:23:57 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interactive Connectivity Establishment WG of the IETF.

        Title           : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal
        Authors         : Ari Keranen
                          Christer Holmberg
                          Jonathan Rosenberg
	Filename        : draft-ietf-ice-rfc5245bis-18.txt
	Pages           : 99
	Date            : 2018-02-27

Abstract:
   This document describes a protocol for Network Address Translator
   (NAT) traversal for UDP-based communication.  This protocol is called
   Interactive Connectivity Establishment (ICE).  ICE makes use of the
   Session Traversal Utilities for NAT (STUN) protocol and its
   extension, Traversal Using Relay NAT (TURN).

   This document obsoletes RFC 5245.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ice-rfc5245bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-18
https://datatracker.ietf.org/doc/html/draft-ietf-ice-rfc5245bis-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ice-rfc5245bis-18


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Feb 27 04:58:14 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DF9129C6E for ; Tue, 27 Feb 2018 04:32:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.319
X-Spam-Level: 
X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-6ciTETjWzM for ; Tue, 27 Feb 2018 04:32:33 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 A5E72129C70 for ; Tue, 27 Feb 2018 04:32:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519734750; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=rUlUIcptodGCsHzH7HS3zhDZz+WQeZ5B9VUIADrLq9c=; b=d/oMIW7ne5FaHFVJHXoDjwfXjPZ5XhDSyy5wmVX8DYFophJwBwS+GuADLSken/OT 3Iy2GFLN6hXYTE4L9AKdnS3WjMCiCN2ovAT9Dx2oHZJ14B3iCB5xmFln4QqhVuzR kN2KJdIQmwCbBHvA7mVfIskES4t47aY2fsUWqXGUeIk=;
X-AuditID: c1b4fb3a-728f89c0000067b4-99-5a954fdd796b
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id DE.24.26548.DDF459A5; Tue, 27 Feb 2018 13:32:30 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0352.000; Tue, 27 Feb 2018 13:32:18 +0100
From: Christer Holmberg 
To: The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice-chairs@ietf.org" , "ice@ietf.org" , Ben Campbell 
CC: Adam Roach , Benjamin Kaduk , "Suresh Krishnan" , "Mirja Kuehlewind (IETF)" , Eric Rescorla 
Thread-Topic: Draft new version: draft-ietf-ice-rfc5245bis-18
Thread-Index: AQHTr8cBAguuWHZTIE6ntPN2JlGwNw==
Date: Tue, 27 Feb 2018 12:32:17 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_D6BB1DD72BAF2christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrIIsWRmVeSWpSXmKPExsUyM2J7lO49/6lRBtu/MFvs+buI3WJ+52kg cfI6s8WK1+fYLS7Omsxm8e1CrcWMPxOZLV5c/8hssXzjTCaLbV2nWBy4PJYs+cnkcf7KDHaP lo8LWT2azhxl9pi18wmLx+THbcwBbFFcNimpOZllqUX6dglcGVub5rIVXBKuuPPwK3sD4w2B LkZODgkBE4muDZNYuxi5OIQEDjNKfH14hA3CWcwoseTAG/YuRg4ONgELie5/2iBxEYGbjBL/ 3/1mAnGYBXYzSkxuO84MMkoYqOjS/5uMILaIgK3El4V7WCFsPYnNV6+zg9gsAqoSB9e3sIDY vALWEvdOHAOzGQXEJL6fWsMEYjMLiEvcejKfCeI8AYkle84zQ9iiEi8f/wObKQo0c8OJ2+wQ cUWJq9OXQ/UmSOw+do0dYr6gxMmZT1gmMArPQjJ2FpKyWUjKIOIGEu/PzWeGsLUlli18DWXr S2z8cpYRwraW+HZuEyOymgWMHKsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYxAiP64JbfVjsY Dz53PMQowMGoxMO7zX5qlBBrYllxZe4hRgkOZiUR3pWLJ0cJ8aYkVlalFuXHF5XmpBYfYpTm YFES53VKs4gSEkhPLEnNTk0tSC2CyTJxcEo1MNarTCyes0T1lr/C1ASB6SkL9yQavV4aefyP h0xborioVdsk3pD8JtvDmfKOTj12r+Wm85ycmSpXkGG3zi6s0uaGm0zccfWq/wp3eLf9afCr yzQ4LmH4uiCP2fBc4Ym6zvvzlszn3cuTO3uT39lP319KHajUbOe/0LzvH8ckUT5Dz3ZBt8av SizFGYmGWsxFxYkAuoN5Z+QCAAA=
Archived-At: 
X-Mailman-Approved-At: Tue, 27 Feb 2018 04:58:13 -0800
Subject: [Ice] Draft new version: draft-ietf-ice-rfc5245bis-18
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 12:32:34 -0000

--_000_D6BB1DD72BAF2christerholmbergericssoncom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

Since the pull request with the IESG review changes got quite big and hard =
to read, in order to make it easier (hopefully) for people to check whether=
 their comments have been addressed, I have submitted a new version (-18) o=
f draft-ietf-ice-rfc5245bis-18.

All comments, except Ekr=92s comments on the Security Considerations and An=
nex B, should now have been addressed and implemented. Please let me know i=
f I=92ve missed something, or if I have misunderstood how the comments was =
to be addressed.

Version =9618 is based on the following pull request, and some minor xml2rf=
c nits:

https://github.com/ice-wg/rfc5245bis/pull/59

Regards,

Christer



--_000_D6BB1DD72BAF2christerholmbergericssoncom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Hi,







Since the pull request with the IESG review changes got quite big and =
hard to read, in order to make it easier (hopefully) for people to check wh=
ether their comments have been addressed, I have submitted a new version (-=
18) of draft-ietf-ice-rfc5245bis-18.







All comments, except Ekr=92s comments on the Security Considerations a=
nd Annex B, should now have been addressed and implemented. Please let me k=
now if I=92ve missed something, or if I have misunderstood how the comments=
 was to be addressed.







Version =9618 is based on the following pull request, and some minor x=
ml2rfc nits:













Regards,







Christer




























--_000_D6BB1DD72BAF2christerholmbergericssoncom_--


From nobody Tue Feb 27 11:04:34 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFA0124BFA for ; Tue, 27 Feb 2018 11:04:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 3gpmDjRY1xIt for ; Tue, 27 Feb 2018 11:04:30 -0800 (PST)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 2034E126D05 for ; Tue, 27 Feb 2018 11:04:30 -0800 (PST)
Received: by mail-io0-x22f.google.com with SMTP id l12so395452ioc.10 for ; Tue, 27 Feb 2018 11:04:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=PydBT8xSZ+XFI7B4LqhbYSEWrbCs3Zb3wV+/MSHbLkk=; b=C49wjfzg5z1VY0kiGno7se6NYXx8pdJBJPTtUP9mZFrjRFQIc+CI48sbr3szRHPAV+ m8NidDeMqsCOGDtWivC6GboxXVHg+12mINRc2FL3puIFwirAZO3wtjPCpO9E2XJ8mVjf oLji5tofTNS6SUUF1lCn3/w/h72BFWm+ENxwQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=PydBT8xSZ+XFI7B4LqhbYSEWrbCs3Zb3wV+/MSHbLkk=; b=hppiUZMtTBtk7vBaaT13c5lkNHIycKyG+3tB3j5gP4raD5+LQnkgQ6hcVfX5aSBdiD 1ytIxLbTLYizLVzMAzLwuMesbzHE3OFPhzHFAFSbfXB51CswxypZs4A/+ZaVkyoZ+o+x Z5x1GDEpOigcwnTE5xWDEvitHLpPbrtElFaAjJB6LPaSh8ibUbkfXvCkNwIQisloPJDW 5AvtohJsBwJFPlF/ObQi5JB0HEbny8x5sqaxuRKFfzwcUdZDK2l73c1hUm3ttolwiVzt DUPyXQgLqlMTSRm8/MskxYYGSgKFm/4ahly+ciW28c49irJTRY8/jo3JG7ZR+91tlxST fLfg==
X-Gm-Message-State: APf1xPC5kJaBimEVbtu0VL0m+epK7VANirtiEzYCoi3QpsmQo18mG6Ez I+8xkz1YVpBc4Ert3WzLZWG/Sg==
X-Google-Smtp-Source: AG47ELs2oJOEUTIMpo/qnATBytduUB8IVgBX4r5nqf8IrPfLanTLd/49ilezttIHb9ODsZojW98d+A==
X-Received: by 10.107.16.22 with SMTP id y22mr16746601ioi.213.1519758269370; Tue, 27 Feb 2018 11:04:29 -0800 (PST)
Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id g12sm4616537iob.18.2018.02.27.11.04.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 11:04:28 -0800 (PST)
To: Christer Holmberg , "ice@ietf.org" 
References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se>  
From: Peter Saint-Andre 
Message-ID: 
Date: Tue, 27 Feb 2018 12:04:27 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ijC7BiUGMnKbDUM6rJpjmNS6UB5tE0fEm"
Archived-At: 
Subject: Re: [Ice] Trickle: A couple of questions on section 7
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 19:04:33 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ijC7BiUGMnKbDUM6rJpjmNS6UB5tE0fEm
Content-Type: multipart/mixed; boundary="Ar0hS1BUf92ds9FSVzf8Sc339sBXYIdUR";
 protected-headers="v1"
From: Peter Saint-Andre 
To: Christer Holmberg ,
 "ice@ietf.org" 
Message-ID: 
Subject: Re: [Ice] Trickle: A couple of questions on section 7
References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se>
 
 
In-Reply-To: 

--Ar0hS1BUf92ds9FSVzf8Sc339sBXYIdUR
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2/27/18 12:42 AM, Christer Holmberg wrote:
> Hi,
>=20
>>> While catching some breath between trying to address IESG comments on=

>>> 5245bis, I took a look at trickle-16, and I have a couple of question=
s.
>>
>> Ah, there's nothing as relaxing as reviewing Internet-Drafts! ;-)
>=20
> I=C2=B9m not into the whining-about-meeting-venue-location thing, so I =
had to
> come up with something else :)
>=20
> In general, since there have been quite a bit of changes in 5245bis, I
> think all reference to 5245bis should be double checked. Also, there
> should always be a reference to the specific section of 5245bis. That w=
ay
> it is easier to double check, and also identity impacts if that section=
 of
> 5245bis is updated in future (in a draft or an errata).

Agreed on all points.

>>> *Q1:*
>>>
>>> =20
>>>
>>> Section 7.1 says:
>>>
>>> =20
>>>
>>>    =C2=B3The ICE specification [rfc5245bis], Section 6.1.4.2, specifi=
es that
>>>
>>>    an agent will terminate the timer for a triggered check in relatio=
n
>>>
>>>    to a check list once the agent has exhausted all frozen pairs in t=
he
>>>
>>>    check list.  This will not work with Trickle ICE, because more pai=
rs
>>>
>>>    will be added to the check list incrementally.=C2=B2
>>>
>>> =20
>>>
>>> Exactly what procedure in 5245bis dos this text refer to?
>>
>> Hmm, good question. Emil wrote that text so we might want to check wit=
h
>> him, but looking at 5245bis I'd say it refers to the last sentence in
>> Step 4 of =C2=A76.1.4.2:
>>
>>   4.  If this step is reached, no check could be performed for the
>>       picked check list.  So, without waiting for timer Ta to expire
>>       again, select the next check list in the Running state and retur=
n
>>       to step #1.  If this happens for every single check list in the
>>       Running state, meaning there are no remaining candidate pairs to=

>>       perform connectivity checks for, abort these steps.
>>
>> However, that refers to exhausting all the candidate pairs to be check=
ed
>> for all check lists, not to "terminat[ing] the timer for a triggered
>> check in relation to a check list once the agent has exhausted all
>> frozen pairs in the check list". So we might want to ping Emil.
>=20
> I think =C2=B3terminate the timer=C2=B2 is misleading wording. Timer Ta=
 is not
> terminated as long as there is at least one check list in =C2=B3Running=
=C2=B2 mode.
>=20
> It is true that, whenever timer Ta fires, check lists that are not in t=
he
> =C2=B3Running=C2=B2 mode will not be checked. But, even with legacy ICE=
, a check
> list may put back in =C2=B3Running=C2=B2 mode if e.g., a triggered chec=
k changes
> that status of a failed pair, and if that pair state change affects the=

> state of the check list.
>=20
> So, unless I=C2=B9ve missed something, I don=C2=B9t think that trickle =
changes how
> check lists are checked when Ta fires. If additional candidates have be=
en
> gathered, and added to a check list, step 4) in section 6.1.4.2 will no=
t
> be reached.

I suspect that Emil might have been thinking about trickling of
candidates after nomination of a candidate pair, but we'll drag him into
the conversation one way or another. ;-)

Peter


--Ar0hS1BUf92ds9FSVzf8Sc339sBXYIdUR--

--ijC7BiUGMnKbDUM6rJpjmNS6UB5tE0fEm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqVq7sACgkQZWGMGH9o
FKmmxxAAtxmm/GYa22OQZdoiBzfiGXrA3l7CmIsMcbZCL/yzuJiImFLqQbiaHopY
CvcPpMR4SwGPpvUk2relqnXh7c1mfoHB6QOzmaT45zKSLvIpUz+eOtE0NXpb3NY4
8LdSNdxMz5lcI48o6COqIOVIT70VLFNrBTuuPJfOGdW/qW3gE2Ulr4RmUwQp4x/D
xmmP0HNAi9JbX5n4Q3G5dUvrUMRdt26p2YcPQEVEpC59mbOS0Ftmb3hOq2hJzxuS
p+NvOwSae+SVBF03hpR47w7EUrOHA1xsAJ7oKG1wPuyLCasOViPpkwtmqzxN/AXN
gKoQWLKpmAiXPNbwA/3jl7SSBgHDuHCuuJsPTbSHHxdiT7rFUIFQ0fGsAvlQux2n
RKF6mLFih07X6JhbaK6ousP9U2mJmKyi9eUmNb3Ctvppv5NPee88YviP6WcMVAJd
OGuOKYcM0cnhtDqM0ZUHTKyqNhQxH2eKWICGBHHK7+TwSQaKdWCpQPD6myOXEPll
YlFe08W4iKq7RRkQDQlP71U/r40KQzm4XK9yra+2gtT6qjTWQObVFa0vmZXvWQL3
kSVr1vK+K91TeHsM0Gv8PhvuKBL2W/Ed4MafOyGdAUv43VzjE8qlEbaY+6gzACw/
vGKvJJ9UuTvvinWDUTviR3hzh6+NHQi/Xj+wiOByoJnSK/LHalw=
=3uA5
-----END PGP SIGNATURE-----

--ijC7BiUGMnKbDUM6rJpjmNS6UB5tE0fEm--


From nobody Tue Feb 27 11:29:31 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624D8126C3D for ; Tue, 27 Feb 2018 11:29:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTEnM1vgs6ha for ; Tue, 27 Feb 2018 11:29:29 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 B663F124BFA for ; Tue, 27 Feb 2018 11:29:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519759766; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=R9vTMWCu/qsPoSOEayJrKF9o8qWgFC/3IEtK68Rd+rk=; b=fHukxoiwCdIEsOAnqMzICjejTIFr3o3oASMt8iRfe9jyWggDjirkJmeKTJWNbSWg ce6eLD+Ry7rp1U1rDhV0sdHmchuoxwTdRkwoQw5FcM+ZmpGE8dncDdcT00tLHO65 ScgV3vqEt1IHGdTb7MyN/JdY4Ngu29YqfFhM+GYK1cw=;
X-AuditID: c1b4fb2d-87c029c000005540-69-5a95b196ec9f
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E1.2F.21824.691B59A5; Tue, 27 Feb 2018 20:29:26 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0352.000; Tue, 27 Feb 2018 20:29:04 +0100
From: Christer Holmberg 
To: Peter Saint-Andre , "ice@ietf.org" 
Thread-Topic: [Ice] Trickle: A couple of questions on section 7
Thread-Index: AdOucJgg+M5x/JnqQAe0nEYDsAIfMAA5PBQAABTM7oAAEyrzgAACkKBQ
Date: Tue, 27 Feb 2018 19:29:04 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1AFE71@ESESSMB109.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.162]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7lu60jVOjDJ7usLT4dqHW4tnKU4wO TB5Llvxk8ug70MUawBTFZZOSmpNZllqkb5fAlXF6/hG2glPqFYuXrGRqYDyh1sXIySEhYCKx ceEJ5i5GLg4hgcOMEldv3oJyFjNKzHnyjL2LkYODTcBCovufNkiDiICXxMw995lAbGEBO4ne 82vYIeL2Ett6r7FA2G4S7ZNegtWwCKhKvP58ESzOK+ArMW/TIxaI+S8ZJaa+nscMkuAEam7d N5ERxGYUEJP4fmoNWDOzgLjErSfzmSAuFZBYsuc8M4QtKvHy8T9WCFtJ4un/JUwgdzILaEqs 36UP0aooMaX7ITvEXkGJkzOfsExgFJmFZOoshI5ZSDpmIelYwMiyilG0OLW4ODfdyFgvtSgz ubg4P08vL7VkEyMwFg5u+a27g3H1a8dDjAIcjEo8vJ8WTI0SYk0sK67MPcQowcGsJMK7cvHk KCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8Jz15o4QE0hNLUrNTUwtSi2CyTBycUg2MLsvf3WcI v/TOd21NbSHD9b2716f/VHBjCpsvePbu20ubLtVEr9rwTMjH1Icjeq1rMUPocavDPD5rF3PU P4xYpBn0c8ectJnZm1v8Z4l9fqXQuP/r8SXXjfzcdi0r50jVstH4ozbbOWm+xDydENVEmVQv D+XljP9NAq7NP2Hdtl4v0P2Lm2qXEktxRqKhFnNRcSIAu+yeG4ECAAA=
Archived-At: 
Subject: Re: [Ice] Trickle: A couple of questions on section 7
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 19:29:30 -0000

SGksDQoNCj4+Pj4gV2hpbGUgY2F0Y2hpbmcgc29tZSBicmVhdGggYmV0d2VlbiB0cnlpbmcgdG8g
YWRkcmVzcyBJRVNHIGNvbW1lbnRzIA0KPj4+PiBvbiA1MjQ1YmlzLCBJIHRvb2sgYSBsb29rIGF0
IHRyaWNrbGUtMTYsIGFuZCBJIGhhdmUgYSBjb3VwbGUgb2YgcXVlc3Rpb25zLg0KPj4+DQo+Pj4g
QWgsIHRoZXJlJ3Mgbm90aGluZyBhcyByZWxheGluZyBhcyByZXZpZXdpbmcgSW50ZXJuZXQtRHJh
ZnRzISA7LSkNCj4+IA0KPj4gScK5bSBub3QgaW50byB0aGUgd2hpbmluZy1hYm91dC1tZWV0aW5n
LXZlbnVlLWxvY2F0aW9uIHRoaW5nLCBzbyBJIGhhZCANCj4+IHRvIGNvbWUgdXAgd2l0aCBzb21l
dGhpbmcgZWxzZSA6KQ0KPj4gDQo+PiBJbiBnZW5lcmFsLCBzaW5jZSB0aGVyZSBoYXZlIGJlZW4g
cXVpdGUgYSBiaXQgb2YgY2hhbmdlcyBpbiA1MjQ1YmlzLCBJIA0KPj4gdGhpbmsgYWxsIHJlZmVy
ZW5jZSB0byA1MjQ1YmlzIHNob3VsZCBiZSBkb3VibGUgY2hlY2tlZC4gQWxzbywgdGhlcmUgDQo+
PiBzaG91bGQgYWx3YXlzIGJlIGEgcmVmZXJlbmNlIHRvIHRoZSBzcGVjaWZpYyBzZWN0aW9uIG9m
IDUyNDViaXMuIFRoYXQgDQo+PiB3YXkgaXQgaXMgZWFzaWVyIHRvIGRvdWJsZSBjaGVjaywgYW5k
IGFsc28gaWRlbnRpdHkgaW1wYWN0cyBpZiB0aGF0IA0KPj4gc2VjdGlvbiBvZiA1MjQ1YmlzIGlz
IHVwZGF0ZWQgaW4gZnV0dXJlIChpbiBhIGRyYWZ0IG9yIGFuIGVycmF0YSkuDQo+DQo+IEFncmVl
ZCBvbiBhbGwgcG9pbnRzLg0KPg0KPj4+PiAqUTE6Kg0KPj4+Pg0KPj4+PiBTZWN0aW9uIDcuMSBz
YXlzOg0KPj4+Pg0KPj4+PiAgICAiVGhlIElDRSBzcGVjaWZpY2F0aW9uIFtyZmM1MjQ1YmlzXSwg
U2VjdGlvbiA2LjEuNC4yLCBzcGVjaWZpZXMgDQo+Pj4+ICAgICB0aGF0IGFuIGFnZW50IHdpbGwg
dGVybWluYXRlIHRoZSB0aW1lciBmb3IgYSB0cmlnZ2VyZWQgY2hlY2sgaW4gDQo+Pj4+ICAgICBy
ZWxhdGlvbiB0byBhIGNoZWNrIGxpc3Qgb25jZSB0aGUgYWdlbnQgaGFzIGV4aGF1c3RlZCBhbGwg
ZnJvemVuIHBhaXJzIGluIA0KPj4+PiAgICAgdGhlIGNoZWNrIGxpc3QuICBUaGlzIHdpbGwgbm90
IHdvcmsgd2l0aCBUcmlja2xlIElDRSwgYmVjYXVzZSBtb3JlIA0KPj4+PiAgICAgcGFpcnMgd2ls
bCBiZSBhZGRlZCB0byB0aGUgY2hlY2sgbGlzdCBpbmNyZW1lbnRhbGx5LiINCj4+Pj4NCj4+Pj4g
RXhhY3RseSB3aGF0IHByb2NlZHVyZSBpbiA1MjQ1YmlzIGRvcyB0aGlzIHRleHQgcmVmZXIgdG8/
DQo+Pj4NCj4+PiBIbW0sIGdvb2QgcXVlc3Rpb24uIEVtaWwgd3JvdGUgdGhhdCB0ZXh0IHNvIHdl
IG1pZ2h0IHdhbnQgdG8gY2hlY2sgDQo+Pj4gd2l0aCBoaW0sIGJ1dCBsb29raW5nIGF0IDUyNDVi
aXMgSSdkIHNheSBpdCByZWZlcnMgdG8gdGhlIGxhc3QgDQo+Pj4gc2VudGVuY2UgaW4gU3RlcCA0
IG9mIMKnNi4xLjQuMjoNCj4+Pg0KPj4+ICAgNC4gIElmIHRoaXMgc3RlcCBpcyByZWFjaGVkLCBu
byBjaGVjayBjb3VsZCBiZSBwZXJmb3JtZWQgZm9yIHRoZQ0KPj4+ICAgICAgIHBpY2tlZCBjaGVj
ayBsaXN0LiAgU28sIHdpdGhvdXQgd2FpdGluZyBmb3IgdGltZXIgVGEgdG8gZXhwaXJlDQo+Pj4g
ICAgICAgYWdhaW4sIHNlbGVjdCB0aGUgbmV4dCBjaGVjayBsaXN0IGluIHRoZSBSdW5uaW5nIHN0
YXRlIGFuZCByZXR1cm4NCj4+PiAgICAgICB0byBzdGVwICMxLiAgSWYgdGhpcyBoYXBwZW5zIGZv
ciBldmVyeSBzaW5nbGUgY2hlY2sgbGlzdCBpbiB0aGUNCj4+PiAgICAgICBSdW5uaW5nIHN0YXRl
LCBtZWFuaW5nIHRoZXJlIGFyZSBubyByZW1haW5pbmcgY2FuZGlkYXRlIHBhaXJzIHRvDQo+Pj4g
ICAgICAgcGVyZm9ybSBjb25uZWN0aXZpdHkgY2hlY2tzIGZvciwgYWJvcnQgdGhlc2Ugc3RlcHMu
DQo+Pj4NCj4+PiBIb3dldmVyLCB0aGF0IHJlZmVycyB0byBleGhhdXN0aW5nIGFsbCB0aGUgY2Fu
ZGlkYXRlIHBhaXJzIHRvIGJlIA0KPj4+IGNoZWNrZWQgZm9yIGFsbCBjaGVjayBsaXN0cywgbm90
IHRvICJ0ZXJtaW5hdFtpbmddIHRoZSB0aW1lciBmb3IgYSANCj4+PiB0cmlnZ2VyZWQgY2hlY2sg
aW4gcmVsYXRpb24gdG8gYSBjaGVjayBsaXN0IG9uY2UgdGhlIGFnZW50IGhhcyANCj4+PiBleGhh
dXN0ZWQgYWxsIGZyb3plbiBwYWlycyBpbiB0aGUgY2hlY2sgbGlzdCIuIFNvIHdlIG1pZ2h0IHdh
bnQgdG8gcGluZyBFbWlsLg0KPj4gDQo+PiBJIHRoaW5rICJ0ZXJtaW5hdGUgdGhlIHRpbWVyIiBp
cyBtaXNsZWFkaW5nIHdvcmRpbmcuIFRpbWVyIFRhIGlzIG5vdCANCj4+IHRlcm1pbmF0ZWQgYXMg
bG9uZyBhcyB0aGVyZSBpcyBhdCBsZWFzdCBvbmUgY2hlY2sgbGlzdCBpbiAiUnVubmluZyIgbW9k
ZS4NCj4+IA0KPj4gSXQgaXMgdHJ1ZSB0aGF0LCB3aGVuZXZlciB0aW1lciBUYSBmaXJlcywgY2hl
Y2sgbGlzdHMgdGhhdCBhcmUgbm90IGluIA0KPj4gdGhlICJSdW5uaW5nIiBtb2RlIHdpbGwgbm90
IGJlIGNoZWNrZWQuIEJ1dCwgZXZlbiB3aXRoIGxlZ2FjeSBJQ0UsIGEgDQo+PiBjaGVjayBsaXN0
IG1heSBwdXQgYmFjayBpbiAiUnVubmluZyIgbW9kZSBpZiBlLmcuLCBhIHRyaWdnZXJlZCBjaGVj
ayANCj4+IGNoYW5nZXMgdGhhdCBzdGF0dXMgb2YgYSBmYWlsZWQgcGFpciwgYW5kIGlmIHRoYXQg
cGFpciBzdGF0ZSBjaGFuZ2UgDQo+PiBhZmZlY3RzIHRoZSBzdGF0ZSBvZiB0aGUgY2hlY2sgbGlz
dC4NCj4+IA0KPj4gU28sIHVubGVzcyBJwrl2ZSBtaXNzZWQgc29tZXRoaW5nLCBJIGRvbsK5dCB0
aGluayB0aGF0IHRyaWNrbGUgY2hhbmdlcyANCj4+IGhvdyBjaGVjayBsaXN0cyBhcmUgY2hlY2tl
ZCB3aGVuIFRhIGZpcmVzLiBJZiBhZGRpdGlvbmFsIGNhbmRpZGF0ZXMgDQo+PiBoYXZlIGJlZW4g
Z2F0aGVyZWQsIGFuZCBhZGRlZCB0byBhIGNoZWNrIGxpc3QsIHN0ZXAgNCkgaW4gc2VjdGlvbiAN
Cj4+IDYuMS40LjIgd2lsbCBub3QgYmUgcmVhY2hlZC4NCj4NCj4gSSBzdXNwZWN0IHRoYXQgRW1p
bCBtaWdodCBoYXZlIGJlZW4gdGhpbmtpbmcgYWJvdXQgdHJpY2tsaW5nIG9mIGNhbmRpZGF0ZXMg
YWZ0ZXIgbm9taW5hdGlvbiBvZiBhIA0KPiBjYW5kaWRhdGUgcGFpciwgYnV0IHdlJ2xsIGRyYWcg
aGltIGludG8gdGhlIGNvbnZlcnNhdGlvbiBvbmUgd2F5IG9yIGFub3RoZXIuIDstKQ0KDQpJIHRo
aW5rIHlvdSByYWlzZSBhbiBpbXBvcnRhbnQgcG9pbnQuIE9uY2UgeW91IGhhdmUgbm9taW5hdGVk
IGEgcGFpciwgeW91IGNhbid0IG5vbWluYXRlIGFub3RoZXIgcGFpciAodGhhdCB3b3VsZCBiZSAi
Y29udGludW91cyBub21pbmF0aW9uIiwgd2hpY2ggaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdHJp
Y2tsZSkuIEkgdGhpbmsgeW91IHNob3VsZCBhZGQgdGV4dCBhYm91dCB0aGF0LCBiZWNhdXNlIEkg
ZG9uJ3QgdGhpbmsgaXQgaXMgY3VycmVudGx5IG1lbnRpb25lZC4gVGhlIGRyYWZ0IGRvZXMgc2F5
IHRoYXQgIklDRSBwcm9jZXNzaW5nIiBtaWdodCBlbmQgYmVmb3JlIGVuZC1vZi1jYW5kaWRhdGVz
IGhhdmUgYmVlbiBjb252ZXllZCwgYnV0IHRoYXQncyBhIHNlcGFyYXRlIHRoaW5nLiBJIGd1ZXNz
IG5vbWluYXRpb24gd291bGQgYWxzbyBpbXBsaWNpdGx5IG1lYW4gZW5kLW9mLWNhbmRpZGF0ZXMs
IGFuZCBuZWl0aGVyIGFnZW50IHNob3VsZCB0cmlja2xlIGFueSBtb3JlIGNhbmRpZGF0ZXMgYWZ0
ZXIgbm9taW5hdGlvbiBpcyBkb25lLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg==


From nobody Tue Feb 27 13:11:38 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAC112D96D for ; Tue, 27 Feb 2018 13:11:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.319
X-Spam-Level: 
X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 DFNJg2stRXbO for ; Tue, 27 Feb 2018 13:11:34 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 64E1912D7FC for ; Tue, 27 Feb 2018 13:11:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519765892; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xJsk9bCfREMRH176mZuKfuA20e4Mak61Jcm2h6L1KiM=; b=Ru9vqoSOODNf2Po4gEK7awXqqqvRtIgThU+2d5veBH4ZLcyj2lvO9nNUjWUQtelP 1zEHjNRXmv5+o7bnS0A6DjPaOepDRTXAb/E7J0wuRImbtOnPGg7jInPB6GWPh1fu 2kMrQYPi97Gq9NIWB+e6o3gyPT2rPMMKtzlegAvWCKo=;
X-AuditID: c1b4fb3a-35fff700000067b4-dd-5a95c9847ba3
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A2.9F.26548.489C59A5; Tue, 27 Feb 2018 22:11:32 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0352.000; Tue, 27 Feb 2018 22:11:32 +0100
From: Christer Holmberg 
To: "ice@ietf.org" 
Thread-Topic: 5245bis: Clarify that re-nomination is not allowed
Thread-Index: AdOwD3K09dqkpOFaT/2bJIXf1MdgTw==
Date: Tue, 27 Feb 2018 21:11:31 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C1B0321@ESESSMB109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.162]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6C1B0321ESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM2K7rm7LyalRBq9uyVp8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6M6y/3MBUskqxYsuYLUwPjTrEuRg4OCQETifWfkrsYuTiEBA4z Spx7/IMJwlnMKPHnxy8mkCI2AQuJ7n/aXYycHCICihIzW54xg9jCAtYSfxYtY4KIO0i8ObeC DcLWk1h65DSYzSKgKrGp7xtYPa+Ar8TLthVgNqOAmMT3U2vAepkFxCVuPZkPZksICEgs2XOe GcIWlXj5+B8rhK0k8fT/Eqj6fInexTtYIGYKSpyc+YRlAqPgLCSjZiEpm4WkDCKuI7Fg9yc2 CFtbYtnC18ww9pkDj5mQxRcwsq9iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECAz7g1t+W+1g PPjc8RCjAAejEg9v8fapUUKsiWXFlbmHGCU4mJVEeFcunhwlxJuSWFmVWpQfX1Sak1p8iFGa g0VJnNcpzSJKSCA9sSQ1OzW1ILUIJsvEwSnVwLiqNWf7kp0952U3nOiyMmxvyshfNWkX1985 MsXmZwuYQnlv3t719qPondh7LtHX3ppMPvdF3uzeYq+QSy+C3F/wuP6d2vh6zzq7LU/CNm1X e868/O3ZOxbaG1L3bj6Z8eLrz9UPTnjs4goyDT2tslj5fWX+27d56d8zVs8Ma3v6br1HqOKT gK/vlViKMxINtZiLihMBpfm613cCAAA=
Archived-At: 
Subject: [Ice] 5245bis: Clarify that re-nomination is not allowed
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 21:11:36 -0000

--_000_7594FB04B1934943A5C02806D1A2204B6C1B0321ESESSMB109erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

As part of the discussion of draft-trickle-ice, I realized that 5245bis doe=
s not very explicitly say that re-nomination is not allowed (without an ICE=
 restart).

I have created a pull request that clarifies that:

https://github.com/ice-wg/rfc5245bis/pull/60

Regards,

Christer

--_000_7594FB04B1934943A5C02806D1A2204B6C1B0321ESESSMB109erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


As part of the discussion of draft-trickle-ice, I re=
alized that 5245bis does not very explicitly say that re-nomination is not =
allowed (without an ICE restart).


 


I have created a pull request that clarifies that:


 


https://github.com/ice-wg/rfc5245bis/pull/60


 


Regards,


 


Christer






--_000_7594FB04B1934943A5C02806D1A2204B6C1B0321ESESSMB109erics_--


From nobody Tue Feb 27 13:25:13 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732BA12DA17 for ; Tue, 27 Feb 2018 13:25:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 53cE5ojL_kn5 for ; Tue, 27 Feb 2018 13:25:09 -0800 (PST)
Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 92F6112D80F for ; Tue, 27 Feb 2018 13:25:09 -0800 (PST)
Received: by mail-it0-x231.google.com with SMTP id w63so924918ita.3 for ; Tue, 27 Feb 2018 13:25:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=2fvSfvJswXMJAP1qd/3oD0v2kH9e6emHkx4dC3NTr24=; b=EvUyRCm85YWWKtH6TICupvS0WDetwYZhhInAjphGc2NAu3FJaC1D32PwLzKSxa4OMi S82Zi503EOkrFyCfTbe71acfHbog7wb5Yi3/tWxR7l3Q5Rh5PsRwMwUP38Dsl3OFwhWI GGOLFdkTW2x48t1rbBb69/6/D6IDKIVZnr9a8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=2fvSfvJswXMJAP1qd/3oD0v2kH9e6emHkx4dC3NTr24=; b=IbJgpz9y/JpsFLigPvMIAKzaSvcrBMDGvH+OMJ6NLfMgQcO+vK5dVpnyFcGX/dW/FR TUq1LnvJ/kzO7z+tIySJFt/eY1e/zLx7fT4ViME0xugv0XXgwS9PeeGh3ooTpFaNWAfu 0xFu3nGK9RuxfTvpp4Qjbpu1bt6Fdt7sf2SuQs4KitpQ7U2eO3Vwqh+aIuxS6HsLtn93 w4y8PKRXCH5oh3Bo/7aJFlJ/4gpjacUZOYttglGioKBQlbUokxWAmHgqxpfi5cnJEPzs uMSPZHbsnjuyfy3izqZuaRuzEEV8VLCN86pTzI84WeR7WmAyJ4MRhsGrcKnm8C9+f0uD 0oBw==
X-Gm-Message-State: AElRT7H3+dZiphJ/fB2WTyp5TxbAfCABZLpZSRJjF3KqkzRFATYOzI7z hQzM8kSrUdTvjdwt6wf6BTYSwQ==
X-Google-Smtp-Source: AG47ELtI0KzSnOKn7DXNnRpSU0a/ifg78mbJR71oNLJEXW1deaCQnaBjZf/eSfgAJC8Ua/hABqaIBg==
X-Received: by 10.36.5.149 with SMTP id 143mr3549338itl.138.1519766708819; Tue, 27 Feb 2018 13:25:08 -0800 (PST)
Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id p187sm60025iop.44.2018.02.27.13.25.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 13:25:08 -0800 (PST)
To: Christer Holmberg , "ice@ietf.org" 
References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se>    <7594FB04B1934943A5C02806D1A2204B6C1AFE71@ESESSMB109.ericsson.se>
From: Peter Saint-Andre 
Message-ID: 
Date: Tue, 27 Feb 2018 14:25:06 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1AFE71@ESESSMB109.ericsson.se>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Q0lRhvciEcovuQAkfvCzuZYzCBW3PhklF"
Archived-At: 
Subject: Re: [Ice] Trickle: A couple of questions on section 7
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 21:25:11 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Q0lRhvciEcovuQAkfvCzuZYzCBW3PhklF
Content-Type: multipart/mixed; boundary="ZwLkjpRZytSoys1ssyRiHCyB2qtZT5Kx8";
 protected-headers="v1"
From: Peter Saint-Andre 
To: Christer Holmberg ,
 "ice@ietf.org" 
Message-ID: 
Subject: Re: [Ice] Trickle: A couple of questions on section 7
References: <7594FB04B1934943A5C02806D1A2204B6C19E021@ESESSMB109.ericsson.se>
 
 
 
 <7594FB04B1934943A5C02806D1A2204B6C1AFE71@ESESSMB109.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1AFE71@ESESSMB109.ericsson.se>

--ZwLkjpRZytSoys1ssyRiHCyB2qtZT5Kx8
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2/27/18 12:29 PM, Christer Holmberg wrote:
> Hi,
>=20
>>>>> While catching some breath between trying to address IESG comments =

>>>>> on 5245bis, I took a look at trickle-16, and I have a couple of que=
stions.
>>>>
>>>> Ah, there's nothing as relaxing as reviewing Internet-Drafts! ;-)
>>>
>>> I=C2=B9m not into the whining-about-meeting-venue-location thing, so =
I had=20
>>> to come up with something else :)
>>>
>>> In general, since there have been quite a bit of changes in 5245bis, =
I=20
>>> think all reference to 5245bis should be double checked. Also, there =

>>> should always be a reference to the specific section of 5245bis. That=
=20
>>> way it is easier to double check, and also identity impacts if that=20
>>> section of 5245bis is updated in future (in a draft or an errata).
>>
>> Agreed on all points.
>>
>>>>> *Q1:*
>>>>>
>>>>> Section 7.1 says:
>>>>>
>>>>>    "The ICE specification [rfc5245bis], Section 6.1.4.2, specifies =

>>>>>     that an agent will terminate the timer for a triggered check in=
=20
>>>>>     relation to a check list once the agent has exhausted all froze=
n pairs in=20
>>>>>     the check list.  This will not work with Trickle ICE, because m=
ore=20
>>>>>     pairs will be added to the check list incrementally."
>>>>>
>>>>> Exactly what procedure in 5245bis dos this text refer to?
>>>>
>>>> Hmm, good question. Emil wrote that text so we might want to check=20
>>>> with him, but looking at 5245bis I'd say it refers to the last=20
>>>> sentence in Step 4 of =C2=A76.1.4.2:
>>>>
>>>>   4.  If this step is reached, no check could be performed for the
>>>>       picked check list.  So, without waiting for timer Ta to expire=

>>>>       again, select the next check list in the Running state and ret=
urn
>>>>       to step #1.  If this happens for every single check list in th=
e
>>>>       Running state, meaning there are no remaining candidate pairs =
to
>>>>       perform connectivity checks for, abort these steps.
>>>>
>>>> However, that refers to exhausting all the candidate pairs to be=20
>>>> checked for all check lists, not to "terminat[ing] the timer for a=20
>>>> triggered check in relation to a check list once the agent has=20
>>>> exhausted all frozen pairs in the check list". So we might want to p=
ing Emil.
>>>
>>> I think "terminate the timer" is misleading wording. Timer Ta is not =

>>> terminated as long as there is at least one check list in "Running" m=
ode.
>>>
>>> It is true that, whenever timer Ta fires, check lists that are not in=
=20
>>> the "Running" mode will not be checked. But, even with legacy ICE, a =

>>> check list may put back in "Running" mode if e.g., a triggered check =

>>> changes that status of a failed pair, and if that pair state change=20
>>> affects the state of the check list.
>>>
>>> So, unless I=C2=B9ve missed something, I don=C2=B9t think that trickl=
e changes=20
>>> how check lists are checked when Ta fires. If additional candidates=20
>>> have been gathered, and added to a check list, step 4) in section=20
>>> 6.1.4.2 will not be reached.
>>
>> I suspect that Emil might have been thinking about trickling of candid=
ates after nomination of a=20
>> candidate pair, but we'll drag him into the conversation one way or an=
other. ;-)
>=20
> I think you raise an important point. Once you have nominated a pair, y=
ou can't nominate another pair (that would be "continuous nomination", wh=
ich is outside the scope of trickle). I think you should add text about t=
hat, because I don't think it is currently mentioned. The draft does say =
that "ICE processing" might end before end-of-candidates have been convey=
ed, but that's a separate thing. I guess nomination would also implicitly=
 mean end-of-candidates, and neither agent should trickle any more candid=
ates after nomination is done.

Although my speculation about what Emil was thinking when he wrote that
text is likely incorrect, you are right that it would be good to clarify
this point in trickle spec.

Peter



--ZwLkjpRZytSoys1ssyRiHCyB2qtZT5Kx8--

--Q0lRhvciEcovuQAkfvCzuZYzCBW3PhklF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqVzLIACgkQZWGMGH9o
FKmz4w//af376bkcVXqQkl/rCi1OOp3QsFkVYXTvr6Y3121YPSAz7eA4/7io5atM
gaGRoWSBv3SIe7yKbeIXqttpPS7yP98Qs6ZwWNC0Y5rIguikUENgEhOYmGltdSFT
LlZyO0YgX+zw2A4NJzmErlPRPNa2lWtMwtMuWk0EXnLmns5lBHRR52q3kjDLOr0V
+G2F0TlQ9RidX8ZSEeLGKaWcBbzR09nn6O8cZci9QOcDUDtyejKeTtGX7+wxGDse
941wXbWCGx26hPLRHVLj94Nplb9RbOhAhDqr4KBQURZywWE0L0rrktGanlPOF6xW
IwJuTiqOUv8NlYvy2G81fIfYxrmr2mF5AyhtpJMd08hEwStd0GbIzXZksEsvY2xr
FLZTZV5MeYeOZtapW39KCcfaxQBE/KkzeHDLitP0XnGcEW9KkZ2yaoU/7jiq15oZ
RTFDyPu5eFpOuoc8SJd+X3gMgkiTbLYcWLx5osidP+s1e6k6830hjhSNwHzKK6Ik
C8Gm98Tox9SIPrSwvKnU3PZ3Tb8NqzdPdqcsDfkmxte0r6jEP0C3WGjyAAYCKpOx
0QgseJkCwnnHe6i5QayhCCSwXNLMmxL+7RQyGtAQ55/VYJM88llQIJw66ZVbcGQO
oekxu8BoIvtxoW0Kj6QhqUGLEqS0j0lduEFxU50Kn9cBecPuyuk=
=DWUZ
-----END PGP SIGNATURE-----

--Q0lRhvciEcovuQAkfvCzuZYzCBW3PhklF--


From nobody Tue Feb 27 15:03:27 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C89212E8C8 for ; Tue, 27 Feb 2018 15:03:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_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=mozilla.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 87C70bdwjLTQ for ; Tue, 27 Feb 2018 15:03:24 -0800 (PST)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 479EE126C2F for ; Tue, 27 Feb 2018 15:03:24 -0800 (PST)
Received: by mail-it0-x22d.google.com with SMTP id k135so1216524ite.2 for ; Tue, 27 Feb 2018 15:03:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=JuOlLN/dxMrFgr7Fyc7yWJbCZCIdqJot8VEb/+ba07M=; b=F3BHhwtfswwrCoQrqntEOzQO08BqT9tGtHq3f0nyJeOWlDlojiwybwhK/5+L7upNGy mZPIEwmlb4+84GaqmkRhpZ2C5Tzimy/G58Rfi/mWMPzVKM2wLsVTnCWtPpDhXYtfQuHi q8gO3twdDOUjdNry04PM8whQwOpyd2Crfb+K0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=JuOlLN/dxMrFgr7Fyc7yWJbCZCIdqJot8VEb/+ba07M=; b=ZK5bwtwePtnkRkl/brg+Nkj6DU87VX8fEarV5s2vqMw0vDl8pq5MMxowBaxnB8LR4M Nue18iQE/AMYjIKkTWtrYwQ8UxugINzG1bXk6Ik3XDXgMCuh+JJAtZuXbYoZhhIlBThz XaYswJguhLfgAup3SIsLMIPhGN/Lpys2iGbHD8rvmJI77KyCldfsCIrSuUXMeyUC4uWr UC81ax2gCvpZ1dDp6FIwqLSEJcNT7EIrT3/dU9cbmXkEZoHEMjyIRSKHSly5P7avm0fk tc7CqbAY8c/5wO2yG7XZdkegrIN/Lv7IpMaFUF45TuY4jFPtI1BeHU8QurL/boKNocmP BxsQ==
X-Gm-Message-State: APf1xPC89Pmtrnp26Po8mcXoeAJRVYPJmgDQMmL6L9XF0hJuixb279D6 waxlwdyhLQfbiU5UabsskCHCa4TjaVI=
X-Google-Smtp-Source: AG47ELt4/ceAr66oAa+sKDphzOmSYZYqHgZ4Umn6shUIJlfKCIqwYtagIiTlE0rDPXQ19SqO26AHqQ==
X-Received: by 10.36.164.14 with SMTP id z14mr2409233ite.106.1519772603635; Tue, 27 Feb 2018 15:03:23 -0800 (PST)
Received: from dragon.local ([76.25.3.152]) by smtp.gmail.com with ESMTPSA id o187sm156189iof.66.2018.02.27.15.03.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 15:03:22 -0800 (PST)
To: Christer Holmberg , "ice@ietf.org" 
References: <7594FB04B1934943A5C02806D1A2204B6C1B0321@ESESSMB109.ericsson.se>
From: Peter Saint-Andre 
Message-ID: 
Date: Tue, 27 Feb 2018 16:03:21 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1B0321@ESESSMB109.ericsson.se>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Wgnl4BBw28dEIT4nYpaTV48LcXQ9udEp2"
Archived-At: 
Subject: Re: [Ice] 5245bis: Clarify that re-nomination is not allowed
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 23:03:26 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Wgnl4BBw28dEIT4nYpaTV48LcXQ9udEp2
Content-Type: multipart/mixed; boundary="5jE0CwHVafbDr0aOzWn30l5TwDrBKhgvR";
 protected-headers="v1"
From: Peter Saint-Andre 
To: Christer Holmberg ,
 "ice@ietf.org" 
Message-ID: 
Subject: Re: [Ice] 5245bis: Clarify that re-nomination is not allowed
References: <7594FB04B1934943A5C02806D1A2204B6C1B0321@ESESSMB109.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C1B0321@ESESSMB109.ericsson.se>

--5jE0CwHVafbDr0aOzWn30l5TwDrBKhgvR
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 2/27/18 2:11 PM, Christer Holmberg wrote:
> Hi,
>=20
> =A0
>=20
> As part of the discussion of draft-trickle-ice, I realized that 5245bis=

> does not very explicitly say that re-nomination is not allowed (without=

> an ICE restart).
>=20
> =A0
>=20
> I have created a pull request that clarifies that:
>=20
> =A0
>=20
> https://github.com/ice-wg/rfc5245bis/pull/60

LGTM.

Peter



--5jE0CwHVafbDr0aOzWn30l5TwDrBKhgvR--

--Wgnl4BBw28dEIT4nYpaTV48LcXQ9udEp2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEENVUj07j078lgnb70ZWGMGH9oFKkFAlqV47kACgkQZWGMGH9o
FKmDUxAAmw0Jfn06H2h5vsmIC05Cv2A5pMB+stF60H7yGjZpgLH0Y8Gi5ATVGwZJ
09TgEux7I4smcW1X9jPnPTwOiC0ohFdGnPm7Gvsg2Ziv2nTz5riVuim48bvBUni3
j/G6KSoXcrGENDaFYt0brRSUx7obYwj4VI+dHIX634aQcN6VDvThWDI3pA9a1FRP
I6XEjBbmkfYLyz2OFrh/EuYSFR1/OTBfwBu5jCz2rKDqc9VJaUFL/3By6ziddoeb
s/Z8TekZBXDGekYAtOJwJ7g9PpUECCIuPz61fHHboKVM8dVtRov3wSlEN8A85SGj
C/ckkh0Tdod/U6E4Uy7aF3ULB7RrStFrareZYRAHsPYXd6OvaYCuy0FHl+FfaxN/
64DMAC8ibYib+DY3G0R+mSsn4xXfFl6Co/+jbUvKAX5VtDWfWjL9B0fVQKKVb3ZN
ejfjdHc9yn+jo0kLRCcI+I/8hlICRxCU1msOG+xYi8DByhcHQBnnuTZJnw3n1JHE
Kn3LEAO4pT10axc0/17Tp/OxVwM8J0c9ueavUCLCG+K2dwSrpJql8get1qsThTrY
C+fw2CRXA9tpWHcYwkORKqUsuyocIBnT2ZTlDoXai+LSSN8Yv/YMqfOE72zv1/FX
gUNLgachjsGlCDdn7SrdI2ztP2jnzrR5WotzLrFzFzzOWdEGnQ8=
=KBJF
-----END PGP SIGNATURE-----

--Wgnl4BBw28dEIT4nYpaTV48LcXQ9udEp2--


From nobody Tue Feb 27 15:22:50 2018
Return-Path: 
X-Original-To: ice@ietf.org
Delivered-To: ice@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3402212EA98; Tue, 27 Feb 2018 15:11:30 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
Cc: ben@nostrum.com, ice@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.73.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151977309020.5200.17066936070957432186.idtracker@ietfa.amsl.com>
Date: Tue, 27 Feb 2018 15:11:30 -0800
Archived-At: 
Subject: [Ice] ice - Requested session has been scheduled for IETF 101
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 23:11:34 -0000

Dear Peter Thatcher,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

ice Session 1 (1:00:00)
    Tuesday, Afternoon Session I 1330-1530
    Room Name: Palace C size: 50
    ---------------------------------------------
    


Request Information:


---------------------------------------------------------
Working Group Name: Interactive Connectivity Establishment
Area Name: Applications and Real-Time Area
Session Requester: Peter Thatcher

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 35
Conflicts to Avoid: 
 First Priority: payload core rtcweb avtcore t2trg tls tsvarea tsvwg tram mmusic dispatch tcpm quic
 Second Priority: perc httpbis rmcat netvc sipbrandy stir
 Third Priority: ace 6lo lwig clue xrblock sipcore cbor


People who must be present:
  Ben Campbell
  Ari Keranen
  Peter Thatcher

Resources Requested:

Special Requests:
  
---------------------------------------------------------


From nobody Tue Feb 27 17:47:15 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27BE127863 for ; Tue, 27 Feb 2018 17:47:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 Vsv6n8AblaXf for ; Tue, 27 Feb 2018 17:47:12 -0800 (PST)
Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 33A42127775 for ; Tue, 27 Feb 2018 17:47:12 -0800 (PST)
Received: by mail-pf0-x22c.google.com with SMTP id q13so378569pff.0 for ; Tue, 27 Feb 2018 17:47:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LryfNbrswpemX0GvaV1war8ZrbFlH6gEeMZ6s+ZGnI4=; b=IMnBdCBVjwoyFW74ndwQPwzBsgCp+DxL8xV2tef4ujhNq9xFMIJPyaLSHqxHxhzLLW N2amh5MK6cjfpBQNV9YuD+Jr8lXRVmeOTlZMNuH+h0zTETh4aIj5o7WD2iKnx9TBbZ6X d3vPcurR9fcIkOEdZ2WOuju49ZPVdcUBf+ujk=
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=LryfNbrswpemX0GvaV1war8ZrbFlH6gEeMZ6s+ZGnI4=; b=TQN2c6MpuCrETq//Xa2BxZxVyK6cB5Q9g57Cit93yvgvzSMqmwZvUHoqA19OJSoSNj fF5iX0uuAy49BE6NZoce+ZhNV9YtG/hAoyOB0Q3l0ZUjysyXDSL9jCpTKYveJZ/++X5J RPs5E57ju58eY3z6ejRfcMFtyKR157nKE+JmpV622y9GocA7sIGY3sUYfyG+RwXDIygr 3y/hcNYk0C/gmeN9rASCXlEB3duWjTJn2hX/lxjkIY9bfwSX7+7ke7WwF5M69sd237Cg hu2Ym6Bep3HAYY7yZcBJ9AnzSx8HP4JzhGRkaQLu5i1yEvbLfZEZvqmqpiQCbgcAoiX5 NmKw==
X-Gm-Message-State: APf1xPCNqtKbWY9lhG/csjTKFxsTvgAIf6MpHn9PVFZGmDy/x25aWQF3 XK/ywnmOZIJJ0YrtwJz9JwI69A==
X-Google-Smtp-Source: AH8x227fqQOOZClALI+gHaSRoIeQVJqMv6PiShUsYaMz172kz45pr/ojugjoRJVWwFUAB+D+cz0mSw==
X-Received: by 10.99.109.79 with SMTP id i76mr12407862pgc.402.1519782431285; Tue, 27 Feb 2018 17:47:11 -0800 (PST)
Received: from ?IPv6:2601:647:4600:3f31:40f3:9f95:a05c:e16f? ([2601:647:4600:3f31:40f3:9f95:a05c:e16f]) by smtp.gmail.com with ESMTPSA id p9sm442266pgs.89.2018.02.27.17.47.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 17:47:09 -0800 (PST)
From: Nils Ohlmeier 
Message-Id: 
Content-Type: multipart/signed; boundary="Apple-Mail=_435D74ED-1BC9-4808-B006-448741FB5A72"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Tue, 27 Feb 2018 17:47:07 -0800
In-Reply-To: 
Cc: Christer Holmberg , "ice@ietf.org" 
To: Peter Saint-Andre 
References: <7594FB04B1934943A5C02806D1A2204B6C1B0321@ESESSMB109.ericsson.se> 
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [Ice] 5245bis: Clarify that re-nomination is not allowed
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Feb 2018 01:47:14 -0000

--Apple-Mail=_435D74ED-1BC9-4808-B006-448741FB5A72
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Feb 27, 2018, at 15:03, Peter Saint-Andre  =
wrote:
>=20
> On 2/27/18 2:11 PM, Christer Holmberg wrote:
>> Hi,
>>=20
>>=20
>>=20
>> As part of the discussion of draft-trickle-ice, I realized that =
5245bis
>> does not very explicitly say that re-nomination is not allowed =
(without
>> an ICE restart).
>>=20
>>=20
>>=20
>> I have created a pull request that clarifies that:
>>=20
>>=20
>>=20
>> https://github.com/ice-wg/rfc5245bis/pull/60
>=20
> LGTM.

LGTM

FYI I=E2=80=99m aware of implementations out there which actually count =
on being able to re-nominate on the fly.

Best
  Nils Ohlmeier


--Apple-Mail=_435D74ED-1BC9-4808-B006-448741FB5A72
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-----

iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlqWChsACgkQY2o/VmzJ
+KHu5g//b1lEpJ7+LpcNxp0RqRLAtaPhX13F11BKMP2CxEuLX6nLX3GkQe1leCQ7
Qi+G5pUvcZoDbVAsWlpGlfYi5POhlFRAOOdp2Qfj6kJPF0zI4SmY4mcwIYKI9GHT
dZJ4RaVsn1w2JRPIIDQIF6bmx+qYFCN+ONRrABQLOgwOYX1wUKlGyuPvORZDNw6B
sHqTx2yaM6auel5J6ROZSkKY2d43tFPMownUEFw/gqfcrQdRu9LWPT74NnpYW65d
BqoQv/1v+dIRtpSu+o5tb4Z1yZRNx7YB78Oa4xFPIifZ1GfbDzT6wG9y1cw+Sk+x
IyhHVWrscENSQyddAtx2xT56/B3GclK8SiXYyfQSMo6v9roWvdMXXmPRXs+sCytP
I1MzlYqxeGx01vqk3dH2gX8qQ6retrI258ErdvGkrwa/c0LLkJ3OG1wd6enp18c2
ztL5Hvpt5uxYxoajj9MWl2c7jmJQyOnfcXjNZztxTc0DEC3HrOcWk67ytFXoEAkj
+hOSXjpkYeVK/uLX8fjiu2mxIqkuu4aGUe+7qortMtQf3SZNmzHlgCtas5Qd7DTz
MesL9Q4W6YM3/ClgS2WJ6KG051nmoSlGVFssFh8fmBeDTOB4xKrx7lZnT18pO/TN
tOLD+ZpunjBtsaPT58LvKos/gNb2BX8ZltJWCXFkGIgFnGfpAmQ=
=3cmC
-----END PGP SIGNATURE-----

--Apple-Mail=_435D74ED-1BC9-4808-B006-448741FB5A72--


From nobody Tue Feb 27 23:02:53 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBD712DA48 for ; Tue, 27 Feb 2018 23:02:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ev14AP3gWVwO for ; Tue, 27 Feb 2018 23:02:50 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 2995112DA26 for ; Tue, 27 Feb 2018 23:02:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519801368; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=I+Yo6h8VOBM4oOzOHHalL8/EekciyjnmEL0Ehy89FRI=; b=Q1poNQeykxB9yuUhrcIro2F1yAa1RzVU1DrFcfxe9FF8udsw5uzQw+/8ih+Z3mMw O6u3GxxDN2eyMvXVCkBYBq/s+5/omK9NVIGoI1MUtxsxc1TkBRvfDi4rY/BiBVD2 jeyJDlz/VyhnXQyKUGXXRnCiAnE/KOZxLMiUGmv5BDs=;
X-AuditID: c1b4fb2d-499ff70000005540-c4-5a9654178351
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8A.23.21824.714569A5; Wed, 28 Feb 2018 08:02:47 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Wed, 28 Feb 2018 08:02:47 +0100
From: Christer Holmberg 
To: "ice@ietf.org" 
Thread-Topic: Trickle: Example in Section 17
Thread-Index: AQHTsGIj+N6AZJgq6Eqdtmvv+qQzDg==
Date: Wed, 28 Feb 2018 07:02:47 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.16]
Content-Type: multipart/alternative; boundary="_000_D6BC23B32BBF7christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7uq54yLQog0lLbSy+Xah1YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGgUcHmQuOclds/fKPrYHxHWcXIyeHhICJxKWWI+xdjFwcQgKH GSUuvVoO5SxmlPg1cTJLFyMHB5uAhUT3P22QBhEBRYmZLc+YQWxhAXWJNf8PMELEdSQ2vt3B DmHrSfxZuIUJxGYRUJVoXrgJrJ5XwFpizYeHYDWMAmIS30+tAathFhCXuPVkPhPEQQISS/ac Z4awRSVePv7HCmKLAs3ccOI2O0RcUWLn2XZmiN4Eib97D7JDzBeUODnzCcsERqFZSMbOQlI2 C0kZRNxA4v25+cwQtrbEsoWvoWx9iY1fzjLOAvqeGejsZQcikZUsYORYxShanFpcnJtuZKyX WpSZXFycn6eXl1qyiREYJwe3/Nbdwbj6teMhRgEORiUeXh+faVFCrIllxZW5hxglOJiVRHj3 SgGFeFMSK6tSi/Lji0pzUosPMUpzsCiJ85705I0SEkhPLEnNTk0tSC2CyTJxcEo1MCoZ7snR 07V88pU3eQXH6o6LXTOm1EadbXxVfnnyGta7r1VOfrEJzjvP252w41FFy57Pd0KY0yeyOr84 KF9Wu+/smY2zDbZumJjqdrnp9t51J7ZdWNasdeeWW2dgpsy2M0WiJS1WOcUND8+evb1/ppVG q+ZlW2lXYb0nB6/di3R/plX9VSbdu1iJpTgj0VCLuag4EQBeicKBjwIAAA==
Archived-At: 
Subject: [Ice] Trickle: Example in Section 17
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Feb 2018 07:02:51 -0000

--_000_D6BC23B32BBF7christerholmbergericssoncom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi,

I think the example in Section 17 should be more detailed. Currently I woul=
dn=92t even consider the flow an example =96 it=92s just a high-level visua=
lisation of trickle :)

Perhaps using the example in Section 15 of 5245bis as base, and then add so=
me trickle stuff there?

Regards,

Christer

--_000_D6BC23B32BBF7christerholmbergericssoncom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <130CD339500FC445BFC95C2A01C3FCEE@ericsson.com>
Content-Transfer-Encoding: quoted-printable







Hi,







I think the example in Section 17 should be more detailed. Currently I=
 wouldn=92t even consider the flow an example =96 it=92s just a high-level =
visualisation of trickle :)







Perhaps using the example in Section 15 of 5245bis as base, and then a=
dd some trickle stuff there?







Regards,







Christer




--_000_D6BC23B32BBF7christerholmbergericssoncom_--


From nobody Tue Feb 27 23:13:59 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F19D12DA14 for ; Tue, 27 Feb 2018 23:13:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8Wf8bwtINq8 for ; Tue, 27 Feb 2018 23:13:56 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E4A120725 for ; Tue, 27 Feb 2018 23:13:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519802034; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SWfjROglrssLqlDhy/IR4I8jHsK2ejXecNqbCiSJNtY=; b=SYYs/+FflMrfa2N43gphwlTeD7S+q1TbMMjdfGMwyj3QGb5j0Qui3x0EeDTJYmIr 3OlO3nc+KJuS3K6fjRFdnHoFbpAI6vZPP93TOljoTt5c4Skv0KtLBcpd4GEYSwZp 5ZaJpFyE10vu7qz6uqfcnKnGvFyg9uajsyMMAaD42Tc=;
X-AuditID: c1b4fb25-06bff70000002d5f-77-5a9656b1bb16
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 78.E9.11615.1B6569A5; Wed, 28 Feb 2018 08:13:54 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Wed, 28 Feb 2018 08:13:53 +0100
From: Christer Holmberg 
To: "ice@ietf.org" 
Thread-Topic: Trickle: What is Section 16 about?
Thread-Index: AQHTsGOwLjmDpDpE6ESJTIumIw+YtQ==
Date: Wed, 28 Feb 2018 07:13:53 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <8CFD3864762B4F41834B5B250866D67F@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7iu6msGlRBlsXcFl8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6Mo/0HmAoec1S8WDWBsYHxI1sXIyeHhICJxNLV2xhBbCGBw4wS Z05ydDFyAdmLGSUaj0xn7mLk4GATsJDo/qcNUiMioCgxs+UZM4gtLKAt8X3GLxaIuIHE409X WCFsPYl5F7aB1bAIqEpsPnwRbD6vgLXExCsPwWoYBcQkvp9awwRiMwuIS9x6Mp8J4h4BiSV7 zjND2KISLx//A6sXBZq54cRtdoi4osTHV/sYIXr1JG5MncIGYVtL3Lizjh3C1pZYtvA1M8Re QYmTM5+wTGAUmYVk3Swk7bOQtM9C0j4LSfsCRtZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWb GIHxcHDLb9UdjJffOB5iFOBgVOLhFfOZFiXEmlhWXJl7iFGCg1lJhHevFFCINyWxsiq1KD++ qDQntfgQozQHi5I47xzh9ighgfTEktTs1NSC1CKYLBMHp1QDY/Z0Bxn1iRd5LWZe3FsazcEp 1hx9Xuyy22TZvUxe9+b+f9q2dKLXiwjbSqv5e33WRF62n9TryhrGYtSa+Ea9o7eibO/O3MqC kHN9KUef1Grd0dprYfb4sd1U9Rm7zfY+7Uy+quKj8j2M6cr1oy0Nrq/8TMwv2FlyfDJkLWv4 2MLxex37pFlTlViKMxINtZiLihMB+9jcYIMCAAA=
Archived-At: 
Subject: [Ice] Trickle: What is Section 16 about?
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Feb 2018 07:13:57 -0000

Hi,

Section 16 says the following:

   "To achieve this, when trickling candidates, agents MUST respect the
   order in which the components and streams appear (implicitly or
   explicitly) as they have been negotiated by means of the relevant
   candidate information.=B2

I can=B9t parse this sentence. What =B3order=B2 is the text talking about?

   "Therefore candidates for a given component MUST NOT be conveyed prior
to=20
    candidates for a component with a lower ID number within the same
foundation.=B2

Does it mean that, when an agent gathers a new candidate, it must not send
it to the peer in case there will later be a candidate with a lower ID
within the same foundation? I thought the whole idea of trickle was to
provide candidates to the peer in =B3real-time=B2, once they become availab=
le.

If the order in which candidates are placed in SDP matters, that should be
described in trickle-ice-sdp.

My suggestion would be to remove Section 16 completely, but I would like
someone to tell me why we need it, and what exactly it is trying to say :)

Regards,

Christer


From nobody Tue Feb 27 23:18:05 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E31112DA14 for ; Tue, 27 Feb 2018 23:18:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bj-oOTuX663 for ; Tue, 27 Feb 2018 23:18:02 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 4A3E9120725 for ; Tue, 27 Feb 2018 23:18:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519802280; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=T7ZDh7xpT7Wv6ItMNk9bzjf2D0d+mNMtooJm8/Ufee8=; b=Im4NF40LmxPg3sDt2Nrtr6OPAxBTwivf2ZxM889FBt/F+ttWjPWwJwF/PPljKyHr ucI9Wu7d7dYufbwykVZsyhmgsX1alp6HAV2JBe5EPkEnvRfKa3IdKhtZl56LWhlP CfSNyJO45doTEBrtwGgqSpzZp2Y7/pa/bEBTQuRrT7M=;
X-AuditID: c1b4fb2d-499ff70000005540-29-5a9657a8bf56
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 28.66.21824.8A7569A5; Wed, 28 Feb 2018 08:18:00 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0352.000; Wed, 28 Feb 2018 08:17:59 +0100
From: Christer Holmberg 
To: "ice@ietf.org" 
Thread-Topic: Trickle: Section 12
Thread-Index: AQHTsGRCjPQHAyWYq0uKYbqHoqQ22A==
Date: Wed, 28 Feb 2018 07:17:58 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <85C8A3DFF80BDE4DB8BA51F7395575E5@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7n+6K8GlRBjPXq1t8u1DrwOixZMlP pgDGKC6blNSczLLUIn27BK6Mnef6GQt2s1Rs613H1MB4mLmLkZNDQsBEYtG762xdjFwcQgKH GSX2nlzLCuEsZpRofnmMqYuRg4NNwEKi+582SIOIgKLEzJZnYM3CAjISbUfeMcHEGx88ZIaw 9SS2zZ/BBmKzCKhK/Hp/ih1kDK+AtcSUxVogYUYBMYnvp9aAtTILiEvcejKfCeIeAYkle85D 3SYq8fLxP1YQWxRo5IYTt9kh4ooSH1/tY4To1ZO4MXUKG4RtLXFz/mdmCFtbYtnC12A2r4Cg xMmZT1gmMIrMQrJuFpL2WUjaZyFpn4WkfQEj6ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2M wHg4uOW37g7G1a8dDzEKcDAq8fD6+EyLEmJNLCuuzD3EKMHBrCTCu1cKKMSbklhZlVqUH19U mpNafIhRmoNFSZz3pCdvlJBAemJJanZqakFqEUyWiYNTqoFxYm6JWVhK67nrBU8cL0Worszc bnQxZ2r+6tgTN03NFgpvOxgo2F4yWdvwvPGb7vWT/R+vYTj8q+Pan5dt5nyKfz4wx0v0dJSc 2q50KKmb4Uf9zMKvDgLq2l9kKmdOqH2qFnam6anRF7ETHdvkhRyS9F2kdp8rXHP47u9eI5ZU z5WLlyt0zHdXYinOSDTUYi4qTgQAUsIu04MCAAA=
Archived-At: 
Subject: [Ice] Trickle: Section 12
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Feb 2018 07:18:03 -0000

Hi,

The text says:

   "This specification does not directly modify the procedures for ending
   ICE processing described in Section 8 of [rfc5245bis], and Trickle
   ICE implementations follow the same rules.=B2

If this text is to be kept, I suggest removing =B3directly=B2.

But, in general I think that the draft doesn=B9t need to mention 5245bis
procedures that are unchanged. Instead there could be a generic statement
in the beginning of the document, saying that unless otherwise stated the
procedures in 5245bis apply.

Regards,

Christer



From nobody Tue Feb 27 23:42:22 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426B11243F3 for ; Tue, 27 Feb 2018 23:42:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylEiCxVqX0yJ for ; Tue, 27 Feb 2018 23:42:08 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 8C4FA120725 for ; Tue, 27 Feb 2018 23:42:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519803724; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=G6PiHKfexwhz2ll6D6llqf2PgocDY9j2/5BHssofoyM=; b=Qef808kXB9B2s4T1IrkuQFSOMkA9+0ydK3Shna1bdRAobvbieAEbl87O1XHBVlSk FXF0JCFj14NAXH+a6vFNx+kmREAx7KKFe++SNE5QHeARzL4xYr7B5bLKhlLxrLGh RPZj6gNpQTdcjSv3AN+CI618qa8qemi/y1BwPhWs6Io=;
X-AuditID: c1b4fb2d-4b1ff70000005540-76-5a965d4c12bc
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C1.DB.21824.C4D569A5; Wed, 28 Feb 2018 08:42:04 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0352.000; Wed, 28 Feb 2018 08:42:03 +0100
From: Christer Holmberg 
To: The IESG , "draft-ietf-ice-rfc5245bis@ietf.org" , "ice@ietf.org" 
Thread-Topic: [Ice] 5245bis: Clarify that re-nomination is not allowed
Thread-Index: AQHTsGef9dqkpOFaT/2bJIXf1MdgTw==
Date: Wed, 28 Feb 2018 07:42:03 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.18]
Content-Type: multipart/mixed; boundary="_004_D6BC2C9D2BC1Fchristerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFIsWRmVeSWpSXmKPExsUyM2J7iK5P7LQog//H5Szmn7zObPHtQq3F jD8TmR2YPZYs+ckUwBjFZZOSmpNZllqkb5fAldF1+QpLwV3dii+N65kaGF9odDFyckgImEjs /X+VuYuRi0NI4DCjxJwZ89khnMWMEme2LmDtYuTgYBOwkOj+pw3SICLQwSix+LwZiC0s4CrR sr2PDSLuJrF9/wp2kHIRAT2JDVPCQcIsAqoS76e0sYDYvALWEu3zrjOB2IwCYhLfT60Bs5kF xCVuPZnPBHGPiMTDi6fZIGxRiZeP/7GC2KIgI0/cZoeIK0p8fLWPEaI3SuL0/PPsEPMFJU7O fMIygVFoFpKxs5CUzUJSBhFPkNiz4wMjhK0jsWD3JzYIW1ti2cLXzDD2mQOPgeZwANnWEs3X MzCV6EocOX+MHcJWlGjb3gw0hgvIXsEocWF3D9R8a4knG98zwhRN6X7IvoCRbxWjaHFqcXFu upGxXmpRZnJxcX6eXl5qySZGYCwf3PJbdwfj6teOhxgFOBiVeHh9fKZFCbEmlhVX5h5iVAGa 82jD6guMUix5+XmpSiK8e6WA0rwpiZVVqUX58UWlOanFhxilOViUxHlPevJGCQmkJ5akZqem FqQWwWSZODilGhgjK6M/N02J/iQwPcPa/1xV6tuilWt/pFVN1F4rqFrl8TzoXfMhDvOSX0LP 5+947VfhaLByWkD/5Dur7O8es1oj6sm/2GzSSUvL6OOHRWcebW6aIsDK94CZW+XGrsVTxA7f sONQXWG6aYW80Zawrw8Y9BeE75725PbB34+b/9SuEeAv2r7WM8tEiaU4I9FQi7moOBEA4y1B Iu0CAAA=
Archived-At: 
Subject: [Ice] FW:  5245bis: Clarify that re-nomination is not allowed
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Feb 2018 07:42:11 -0000

--_004_D6BC2C9D2BC1Fchristerholmbergericssoncom_
Content-Type: multipart/alternative;
 boundary="_000_D6BC2C9D2BC1Fchristerholmbergericssoncom_"

--_000_D6BC2C9D2BC1Fchristerholmbergericssoncom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

FYI to the IESG individuals reviewing draft-ietf-ice-rfc5245bis.

Regards,

Christer

From: Ice > on behalf of =
Christer Holmberg >
Date: Tuesday 27 February 2018 at 23:11
To: "ice@ietf.org" >
Subject: [Ice] 5245bis: Clarify that re-nomination is not allowed

Hi,

As part of the discussion of draft-trickle-ice, I realized that 5245bis doe=
s not very explicitly say that re-nomination is not allowed (without an ICE=
 restart).

I have created a pull request that clarifies that:

https://github.com/ice-wg/rfc5245bis/pull/60

Regards,

Christer

--_000_D6BC2C9D2BC1Fchristerholmbergericssoncom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <0B9554D0F9D2E64EA25A18D01D19FD49@ericsson.com>
Content-Transfer-Encoding: quoted-printable







FYI to the IESG individuals reviewing draft-ietf-ice-rfc5245bis.







Regards,







Christer









From: Ice <ice-bounces@ietf.org> on behalf of Christer Holmb=
erg <christer.holmberg=
@ericsson.com>

Date: Tuesday 27 February 2018 at 2=
3:11

To: "ice@ietf.org" <ice@ietf.=
org>

Subject: [Ice] 5245bis: Clarify tha=
t re-nomination is not allowed

















Hi,


 


As part of the discussion of draft-trickle-ice, I re=
alized that 5245bis does not very explicitly say that re-nomination is not =
allowed (without an ICE restart).


 


I have created a pull request that clarifies that:


 


https://github.com/ice-wg/rfc5245bis/pull/60


 


Regards,


 


Christer











--_000_D6BC2C9D2BC1Fchristerholmbergericssoncom_--

--_004_D6BC2C9D2BC1Fchristerholmbergericssoncom_
Content-Type: text/plain; name="ATT00001.txt"
Content-Description: ATT00001.txt
Content-Disposition: attachment; filename="ATT00001.txt"; size=124;
 creation-date="Wed, 28 Feb 2018 07:42:03 GMT";
 modification-date="Wed, 28 Feb 2018 07:42:03 GMT"
Content-ID: <9750832E2E5F5848B99E7EC6067AFE6F@ericsson.com>
Content-Transfer-Encoding: base64

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkljZSBtYWls
aW5nIGxpc3QNCkljZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9pY2UNCg==

--_004_D6BC2C9D2BC1Fchristerholmbergericssoncom_--


From nobody Wed Feb 28 02:52:29 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299EE12EAF4 for ; Wed, 28 Feb 2018 02:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iBMWyUJ-Vue for ; Wed, 28 Feb 2018 02:52:21 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 A8D0B12EAFA for ; Wed, 28 Feb 2018 02:52:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519815137; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SiMRk15VIkauTPbEDOuvO8HMP+k126P08zTJoIqzvjI=; b=eFD5ue2X4Gs+Usqu7hDDAeJ/B8zMLdnTHj6AhP03QV9Kl7K2aEjhm5A4hJjvMwMy PVPXyxlCHWcCwZ/+drtiIlzOVaPf/FIF6yUCInfai0ajriVI1QPck/IRcvY7nu7H ryr6t71ONd8uILuBM6Llw6wdDgZWJ/6gBAzCEn28wfw=;
X-AuditID: c1b4fb3a-728f89c0000067b4-19-5a9689e10525
Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 58.0C.26548.1E9869A5; Wed, 28 Feb 2018 11:52:17 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0352.000; Wed, 28 Feb 2018 11:51:34 +0100
From: Christer Holmberg 
To: Christer Holmberg , Eric Rescorla 
CC: "ice@ietf.org" , "ice-chairs@ietf.org" , "draft-ietf-ice-rfc5245bis@ietf.org" , The IESG , "pthatcher@google.com" 
Thread-Topic: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (Security Considerations) - Pull request
Thread-Index: AQHTsIIZzcywmu1hEkCaDPJDJipt1w==
Date: Wed, 28 Feb 2018 10:51:34 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.7.170905
x-originating-ip: [153.88.183.146]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7k+7DzmlRBrdf8VvMP3md2WLF63Ps FhdnTWaz+Hah1mLGn4nMFteWv2Z1YPNYsKnUY8mSn0wekx+3MQcwR3HZpKTmZJalFunbJXBl fPwyhbXgtHvFy9bvTA2M6yy6GDk5JARMJI5uWMnSxcjFISRwmFHi77cPzBDOYkaJa5umsXcx cnCwCVhIdP/TBjFFBMIkrm3mAilhFnjBKHH030NWEEdYoIdR4mLvRrBJIgK9jBJTL9xlBlkh IqAn0dI7gw3EZhFQlZi5YAUTiM0rYC3xcX0XI4jNKCAm8f3UGrA4s4C4xK0n85kgzhOQWLLn PDOELSrx8vE/VhBbFGjmhhO32SHiShI/NlxigejVk7gxdQobhG0t8WbzGaiZ2hLLFr5mhtgr KHFy5hOWCYyis5Csm4WkfRaS9llI2mchaV/AyLqKUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQT IzDiDm75bbWD8eBzx0OMAhyMSjy8En7TooRYE8uKK3MPMUpwMCuJ8KaVAIV4UxIrq1KL8uOL SnNSiw8xSnOwKInzOqVZRAkJpCeWpGanphakFsFkmTg4pRoYi/6r3/vPPTW7dfuNgrqDrVxx zVF77epc9/UFepR803vwUWdV7T7rukfL7nmfENu2orhO85L00roHhz8ubzd92v4osOyEWJJe U99Cq2cHPZ6qMfGJtUaxWQguPj3rigbrNRauqcrflW+4HbikIhUlcS/7WAB74K5Scfnqfd68 TuG569maJr5UYinOSDTUYi4qTgQA3aNeFrQCAAA=
Archived-At: 
Subject: Re: [Ice] Eric Rescorla's No Objection on draft-ietf-ice-rfc5245bis-17: (with COMMENT) (Security Considerations) - Pull request
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Feb 2018 10:52:22 -0000

Hi,

Based on Ekr=B9s comments on the Security Considerations and Annex B, I hav=
e
created the following pull request:

https://github.com/ice-wg/rfc5245bis/pull/61


Regards,

Christer



On 25/02/18 11:48, "Ice on behalf of Christer Holmberg"
 wrote:

>Hi,
>
>>>>   something incorrect about the results of the connectivity checks.
>>>>   The possible false conclusions an attacker can try and cause are:
>>>> IMPORTANT: This section would be a lot stronger if it was factored by
>>>>attacker capabilities as well. As-is it is very hard to understand.
>>>
>>> In some cases the attacker only needs to be able to capture the
>>>binding request, and discard it.
>>>
>>> In other cases the attacker also needs to have access to the security
>>>credentials, in order to generate/modify messages.
>>>
>> It seems to me that there are (at least) the following classes of
>>attacker
>>
>> - Off-path attackers
>> - On-path attackers
>> - Attackers who control an endpoint (legitimate callers)
>> - Attackers who control an endpoint via WebRTC.
>
>What about the following modification:
>
>OLD:
>
>   "An attacker might attempt to disrupt the STUN connectivity checks.
>   Ultimately, all of these attacks fool an ICE agent into thinking
>   something incorrect about the results of the connectivity checks.
>   The possible false conclusions an attacker can try and cause are:"
>
>NEW:
>
>   "An attacker might attempt to disrupt the STUN connectivity checks.
>   Ultimately, all of these attacks fool an ICE agent into thinking
>   something incorrect about the results of the connectivity checks.
>   Depending on the type of attack, the attacker needs to have different
>   capabilities. In some cases the attacker needs to be on the path of the
>   connectivity checks. In other cases the attacker does not need to be on
>   the path, as long as it is able to generate STUN connectivity checks.
>   While attacks on connectivity checks are typically performed by network
>   entities, if an attacker is able to control an endpoint it can might
>be able
>   to trigger connectivity check attacks. The possible false conclusions
>an attacker=20
>   can try and cause are:"
>=20
>---
>
>>>>   possible attack.  Fortunately, this attack is mitigated completely
>>>>   through the STUN short-term credential mechanism.  The attacker
>>>>needs
>>>>   to inject a fake response, and in order for this response to be
>>>>
>>>> This text is a bit confusing. If you can generate a drop, then you
>>>>can mount this attack.
>>>
>>> Not sure I understand.
>>
>> If you want to simulate check failure, you only need to be able to drop
>>packets.=20
>
>Aaah... now I get it. I only had the case in mind where the attacker
>generates a fake response.
>=20
>So, I suggest the following changes:
>
>OLD:
>
>   "To force the false invalid result, the attacker has to wait for the
>   connectivity check from one of the agents to be sent.  When it is,
>   the attacker needs to inject a fake response with an unrecoverable
>   error response, such as a 400."
>
>NEW:
>
>   "To force the false invalid result, the attacker has to wait for the
>   connectivity check from one of the agents to be sent.  When it is,
>   the attacker needs to inject a fake response with an unrecoverable
>   error response (such as a 400), or drop the response so that it never
>   reaches the agent."
>
>...and:
>
>OLD:
>
>   "Fortunately, this attack is mitigated completely
>   through the STUN short-term credential mechanism.  The attacker needs
>   to inject a fake response, and in order for this response to be
>   processed, the attacker needs the password.  If the candidate
>   exchange signaling is secured, the attacker will not have the
>   password and its response will be discarded."
>
>NEW:
>
>   "The ability for the attacker to generate a fake response is mitigated
>   through the STUN short-term credential mechanism. In order for this
>   response to be processed, the attacker needs the password.  If the
>candidate
>   exchange signaling is secured, the attacker will not have the
>   password and its response will be discarded."
>
>---
>
>>>>   invalid attack, this attack is mitigated by the STUN short-term
>>>>   credential mechanism in conjunction with a secure candidate
>>>>exchange.
>>>>
>>>> This also isn't quite correct. Consider the case where A is behind a
>>>>filtering element (e.g., a firewall) and
>>>> shares a broadcast network with the attacker. The attacker then
>>>>captures an outgoing message that would
>>>> have been filtered and tunnels it to B, and then tunnels the response
>>>>back. This can cause B and A to think
>>>> they have a valid path when they do not. It seems like this attack is
>>>>described several paragraphs down, but
>>>> in sort of a confusing way.
>>>
>>> Ok, I see what you mean.
>>>
>>> Perhaps we should just remove the "Fortunately, this attack..."
>>>sentence?
>>>
>>> Then, the rest of the paragraph could be separate paragraph, and
>>>modified as:
>>>
>>> OLD:
>>>
>>>   "The attacker needs to inject a fake response, and in order for this
>>>response to be
>>>    processed, the attacker needs the password.  If the candidate
>>>exchange signaling is secured,
>>>    the attacker will not have the password and its response will be
>>>discarded."
>>>
>>> NEW:
>>>
>>>  "Due to the STUN short-term credential mechanism, in order for the
>>>attacker
>>>    to inject a fake response, and in order for this response to be
>>>processed, the
>>>    attacker needs the password.  If the candidate exchange signaling
>>>is secured,
>>>    the attacker will not have the password and its response will be
>>>discarded."
>>
>> My point is that an on-path attacker can actually simulate success for
>>paths that would fail, and that the credentials don't help.
>
>What about the following:
>
>OLD:
>
>   "Forcing the fake valid result works in a similar way.  The agent
>   needs to wait for the Binding request from each agent, and inject a
>   fake success response.  The attacker won't need to worry about
>   disrupting the actual response since, if the candidate is not valid,
>   it presumably wouldn't be received anyway.  However, like the fake
>   invalid attack, this attack is mitigated by the STUN short-term
>   credential mechanism in conjunction with a secure candidate exchange."
>
>NEW:
>
>   "Forcing the fake valid result works in a similar way.  The agent
>   needs to wait for the Binding request from each agent, and inject a
>   fake success response, or route (e.g., using a tunnelling mechanism) a
>   success response that  normally would be dropped or rejected by the
>   network to the agent. Again, due to the STUN short-term credential
>   mechanism, in order for the attacker to inject a valid success
>response, the
>   attacker needs the password."
>=20
>---
>
>>>>19.4.1.  STUN Amplification Attack
>>>>It's probably worth noting that this form of attack is a lot worse
>>>>when WebRTC is involved.
>>>
>>> Why is that?
>>
>> Because the attacker can force endpoints to make calls for him and can
>>supply any candidates he chooses
>
>To the following text:
>
>   "The attacker sends an a large number of candidates, say, 50.  The
>   responding agent receives the candidate information, and starts its
>   checks, which are directed at the target, and consequently, never
>   generate a response."
>
>...I could append the following:
>
>   "In the case of WebRTC the user might not even be aware that this
>attack is ongoing, since it might be triggered in the background by
>malicious=20
>    JavaScript code that the user has fetched."
>
>---
>
>>>> (Appendix B.1 - not security related)
>>>>
>>>>  rate at which they will create new bindings.  Experiments have shown
>>>>  that once every 5 ms is well supported.  This is why Ta has a lower
>>>>  bound of 5 ms.  Furthermore, transmission of these packets on the
>>>>
>>>> Citation needed.
>>>
>>> I don't really have any. This was the outcome of long WG discussions...
>>>
>>> Well, you can't really claim "Experiments have shown" if you can't
>>>cite those experiemnts
>
>RFC 5245 had the same text, but with 20ms.
>
>I see a couple of alternatives:
>
>Alt #1. Modify the text and say something like:
>
>OLD:
>
>"Experiments have shown that once every 5 ms is well supported.  This is
>why Ta has a lower bound of 5 ms."
>
>NEW:
>
>"Discussions in the IETF ICE WG during the work on this specification
>concluded that, that once every 5
>ms is will supported. This is why Ta has a lover bound of 5 ms."
>
>Does that help? It doesn't really provide a citation, but at least it
>gives some guidance where the number comes from.
>
>Alt #2. Remove the text.
>
>---
>
>Regards,
>
>Christer
>
>_______________________________________________
>Ice mailing list
>Ice@ietf.org
>https://www.ietf.org/mailman/listinfo/ice


From nobody Wed Feb 28 07:56:44 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E1F12EB23 for ; Wed, 28 Feb 2018 07:56:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level: 
X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 OHSa5RweyXH8 for ; Wed, 28 Feb 2018 07:56:40 -0800 (PST)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 7B64112EB22 for ; Wed, 28 Feb 2018 07:56:40 -0800 (PST)
Received: by mail-wm0-x233.google.com with SMTP id w128so6005470wmw.0 for ; Wed, 28 Feb 2018 07:56:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=QoEfrA+9hFoNadwx9qCrR7+vuhX0SOx5YyE6dfo8AlE=; b=Lasd/A0ITxAKjlcFljnFZm0Dki/eb5rrkb2CV4MyphPlaId69bwYLrjgQYotCN3A/w mtp1avoFsH1j95suFcgL5reVdlZx3JWMO0H7KQwhWgSgOh1tAFJ0kn+H4JTfl5qy70Nd qYCwjxMBOfRhntafYimDmot7jp5q4k8EGqAu0bvRPiU7OXVRNYkQvbWcPM0dPhHuHY4G 9UY+TPPigTvfvAL7JnQnIxLPM17nXQaiktE70XeNIbKB23DKLMB17HC3ceWC+cXCLioe RUhZ7e/Tbs0EjrPeJHSYFL7RdXc9GhPXH5vrkADsq+PYh6yBGbln8pIoXHt7nSzj4wPP uS0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=QoEfrA+9hFoNadwx9qCrR7+vuhX0SOx5YyE6dfo8AlE=; b=SEG5BxqMsHVccaHP6tGKZXvnsaFsE8Aakgx36iZ1d+BjhfEuUvO+INXOMQ6YEUVZbL Ji4Y3NPjfb2x4qu0R6eV/xJg+/PqqirtMl41ujnUIQwezqF1/OlCgRAiL6u3NTTfDg5Y QjPB47HUk1lJ1KCtsehr4l3QlWd7RmjAPi/SzTOjL9fD/fmyimaIhPp9r5VJyouw9JDl WwMj5LijlwNtev8p5YTG4aSAlLMGeKauUCfYPxcRpy5eHYLojLjd57KyBm7k3AfSZD8o Yp7rHyxFgfSE6rFclti5tpq8VTiK8+91bODMs3uWCQxT743TzE29qMcsoXiY8uQQ160M GBrA==
X-Gm-Message-State: APf1xPCmejb3MGIL9SAL4aQ/k9ZJ9I0z9ulgMqnzanHOnPel+vWwtTsk bO3l11JTEe29wAGmNUqlU2S+NP4cfCK/LPQZJCUWuGSu
X-Google-Smtp-Source: AG47ELt0l11eSb1/YYTIc+Xs6Xw/BwQIz5SqpaVw89+IKnjdtfAFmvI28OivXkIbCOUqV54jDxC1F0HkqAJrlQRXgJ0=
X-Received: by 10.28.224.65 with SMTP id x62mr15727929wmg.6.1519833398341; Wed, 28 Feb 2018 07:56:38 -0800 (PST)
MIME-Version: 1.0
From: Peter Thatcher 
Date: Wed, 28 Feb 2018 15:56:26 +0000
Message-ID: 
To: ICE WG 
Content-Type: multipart/alternative; boundary="001a114a5712d42169056647c908"
Archived-At: 
Subject: [Ice] Plan for ICE WG in IETF 101
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Feb 2018 15:56:42 -0000

--001a114a5712d42169056647c908
Content-Type: text/plain; charset="UTF-8"

You may have seen the IETF 101 agenda.  We have a meeting scheduled for
Tuesday.  But if there are no issues come up (especially from the ICEBis
review) that require face-to-face time, we will cancel the meeting.

--001a114a5712d42169056647c908
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


You may have seen the IETF 101 agenda.=C2=A0 We have a mee=
ting scheduled for Tuesday.=C2=A0 But if there are no issues come up (espec=
ially from the ICEBis review) that require face-to-face time, we will cance=
l the meeting.=C2=A0=C2=A0


--001a114a5712d42169056647c908--


From nobody Wed Feb 28 10:34:30 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F78A120727 for ; Wed, 28 Feb 2018 10:34:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Level: 
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 eURTVFyN6eBv for ; Wed, 28 Feb 2018 10:34:26 -0800 (PST)
Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 798081200E5 for ; Wed, 28 Feb 2018 10:34:26 -0800 (PST)
Received: by mail-vk0-x235.google.com with SMTP id u200so2098748vke.4 for ; Wed, 28 Feb 2018 10:34:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gbi/a9EFTIefhbW6bZ+ozj7F9xViUxH6kFp6px5XT5E=; b=eZ8ya6utTsrRPkiYbuIf4SYe51TCep48HLn2lUiy7IPh/d0JtW3X2mnfz8xMROKhsg 6WhpLO5QdSlV+Hjl9LODf/pRBhhrGko13P8RY+pnOb1Xr9dOsxys60xVvV120pA1psRn mRS0Jd2EqbDnQnToGXWgJdGQSg1wk6QhdAh+GXkRlAA/e34odaJRiVJFL2QM00MOdTcG NUsm+2B08jfbwKQF9crwqt8zjdstNv+K0Br+VXH39oa8ENJ6nlAZrBO/9bDJLjkrHIus qoZ6NfPOJ5VfZW5LY3eX2iPIbZhCsApBSRYNtTXqNtX+lEK+SqXdHp79SOdm5FR3H0/E cVFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gbi/a9EFTIefhbW6bZ+ozj7F9xViUxH6kFp6px5XT5E=; b=aNCyL0uLuvW3M1njbKArJWvJG7lP3ACrQ9Q6YA2BuZ2f7S4uLLPBg39TZa1qwBR2JN 3WJMmQYNH1YRWqTW7gn3qozh+CFyPu2CTD0pCwWsQm1lg5S0A/U/Zafwpdo40Cq/SC4E wKoxi/OGrwnY1U+a6yMy3OKxNTCnUg50FJ+GMjgXyR6ppvGwMXxAthLVC6x/SUTPEXbe NvrLGyrWpC4xPgMXGe4g++jB+LXM/74GqlqurRTIOMcudGny+okHOYDkTNfEg8dFXaIc TI8fwAw7tTeh0M89E7VFBOBWKVJpawwFe8ktx45BxawzIVwvnhSGTamFYsQJ1bD7TnRl zVoQ==
X-Gm-Message-State: APf1xPDAyC4lPLpNdST91obt9xuaM4LFP9p3CdYnA94UPvKSH+63dZl4 ewdKr/HcG8z1ziQZiqijQIT+FhLGfb2dxg6TyB113w==
X-Google-Smtp-Source: AG47ELtJ/bG7FXQwRR2PgD78NjxnDf4/w8AVx6LC8ZXtQmHatbmpGponhV2fy+wH+sA6QCp04wbCJLV0Ax12YVj7PGU=
X-Received: by 10.31.107.145 with SMTP id k17mr13855343vki.198.1519842864900;  Wed, 28 Feb 2018 10:34:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.114.66 with HTTP; Wed, 28 Feb 2018 10:34:23 -0800 (PST)
In-Reply-To: 
References: 
From: Taylor Brandstetter 
Date: Wed, 28 Feb 2018 10:34:23 -0800
Message-ID: 
To: Christer Holmberg 
Cc: "ice@ietf.org" 
Content-Type: multipart/alternative; boundary="001a11478e44143099056649febe"
Archived-At: 
Subject: Re: [Ice] Trickle: What is Section 16 about?
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Feb 2018 18:34:29 -0000

--001a11478e44143099056649febe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> Does it mean that, when an agent gathers a new candidate, it must not sen=
d
> it to the peer in case there will later be a candidate with a lower ID
> within the same foundation?
>

That's how I interpret it; the example below explains how an RTCP candidate
for a particular foundation must be conveyed after (or simultaneously with)
the RTP candidate.

As for "why", I think that's explained by the paragraph above:

   One important aspect of regular ICE is that connectivity checks for a
>    specific foundation and component are attempted simultaneously by
>    both agents, so that any firewalls or NATs fronting the agents would
>    whitelist both endpoints and allow all except for the first
>    ("suicide") packets to go through.  This is also important to
>    unfreezing candidates at the right time.  While not crucial,
>    preserving this behavior in Trickle ICE is likely to improve ICE
>    performance.
>
>
Trickling candidates in a specific order helps guarantee that pairs are
formed in the same order by both peers, so that they'll perform
connectivity checks for the same pairs simultaneously.

Though given the updates to section 8.1.1 (Inserting a New Pair in a Check
List), this may not be as important as it used to be. The rules in 8.1.1
guarantee that the "topmost" pair for each foundation will always be
unfrozen. So I believe if candidates were trickled out of order, the worst
that could happen is that one peer ends up with more pairs unfrozen than
the other. For example:

1. Bob trickles RTCP candidate, then RTP.
2. Alice trickles RTP candidate, then RTCP.
3. Alice receives Bob's candidates, forming RTCP pair first (unfreezing
it), then RTP pair (unfreezing it too, since it becomes the new "topmost"
pair).
4. Bob receives Alice's candidates, forming RTP pair first (unfreezing it),
then RTCP pair (leaving it frozen).
5. Alice now has both pairs unfrozen, while Bob only has the RTP pair
unfrozen.

On Tue, Feb 27, 2018 at 11:13 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> Section 16 says the following:
>
>    "To achieve this, when trickling candidates, agents MUST respect the
>    order in which the components and streams appear (implicitly or
>    explicitly) as they have been negotiated by means of the relevant
>    candidate information.=C2=B2
>
> I can=C2=B9t parse this sentence. What =C2=B3order=C2=B2 is the text talk=
ing about?
>
>    "Therefore candidates for a given component MUST NOT be conveyed prior
> to
>     candidates for a component with a lower ID number within the same
> foundation.=C2=B2
>
> Does it mean that, when an agent gathers a new candidate, it must not sen=
d
> it to the peer in case there will later be a candidate with a lower ID
> within the same foundation? I thought the whole idea of trickle was to
> provide candidates to the peer in =C2=B3real-time=C2=B2, once they become=
 available.
>
> If the order in which candidates are placed in SDP matters, that should b=
e
> described in trickle-ice-sdp.
>
> My suggestion would be to remove Section 16 completely, but I would like
> someone to tell me why we need it, and what exactly it is trying to say :=
)
>
> Regards,
>
> Christer
>
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice
>

--001a11478e44143099056649febe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Does it mean that, when an agent gathers =
a new candidate, it must not send
it to the peer in case there will later be a candidate with a lower=
 ID
within the same founda=
tion?

That's how I interpret it; the example below explains how an RTCP cand=
idate for a particular foundation must be conveyed after (or simultaneously=
 with) the RTP candidate.

As for "why", I think that's explained by the paragraph ab=
ove:


On Tue, Feb 27, 20=
18 at 11:13 PM, Christer Holmberg <christer.holmberg@ericsson=
.com> wrote:
Hi,



Section 16 says the following:



=C2=A0 =C2=A0"To achieve this, when trickling candidates, agents MUST =
respect the

=C2=A0 =C2=A0order in which the components and streams appear (implicitly o=
r

=C2=A0 =C2=A0explicitly) as they have been negotiated by means of the relev=
ant

=C2=A0 =C2=A0candidate information.=C2=B2



I can=C2=B9t parse this sentence. What =C2=B3order=C2=B2 is the text talkin=
g about?



=C2=A0 =C2=A0"Therefore candidates for a given component MUST NOT be c=
onveyed prior

to

=C2=A0 =C2=A0 candidates for a component with a lower ID number within the =
same

foundation.=C2=B2



Does it mean that, when an agent gathers a new candidate, it must not send<=
br>
it to the peer in case there will later be a candidate with a lower ID

within the same foundation? I thought the whole idea of trickle was to

provide candidates to the peer in =C2=B3real-time=C2=B2, once they become a=
vailable.



If the order in which candidates are placed in SDP matters, that should be<=
br>
described in trickle-ice-sdp.



My suggestion would be to remove Section 16 completely, but I would like
someone to tell me why we need it, and what exactly it is trying to say :)<=
br>


Regards,



Christer



_______________________________________________

Ice mailing list

Ice@ietf.org

https://www.ietf.org/mailman/listinfo/ice





--001a11478e44143099056649febe--


From nobody Wed Feb 28 23:47:38 2018
Return-Path: 
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1B11205D3 for ; Wed, 28 Feb 2018 23:47:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YpK7BZqBJg90 for ; Wed, 28 Feb 2018 23:47:35 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CE9712D7F5 for ; Wed, 28 Feb 2018 23:47:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519890452; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=c9v4vTQdfMpx7DyXKJrDB+xMfdKAfSNTG9CaeoSTuwg=; b=AYyKIzUAF6bqBb5ZyBHBzC7dI0RpMM84pURXJp/gBCMKM7eT4WNZBmX2B0T1enfi PjeZ1czfMc7syFdOZ0ElwmJaIHXxImWpuk7URuEHYVPuO5Y70ScV29kUY/01LqH4 9DR14GkcylNRQOloImf9UbMSwqN0jO0eZL+fXCzFzpU=;
X-AuditID: c1b4fb25-083ff70000002d5f-8e-5a97b0141d2c
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2A.76.11615.410B79A5; Thu,  1 Mar 2018 08:47:32 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.82]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Thu, 1 Mar 2018 08:47:32 +0100
From: =?utf-8?B?QXJpIEtlcsOkbmVu?= 
To: Christer Holmberg , "Black, David" , "ice@ietf.org" , "jri@google.com" , Nils Ohlmeier 
CC: "draft-ietf-ice-rfc5245bis@ietf.org" ,  "ice-chairs@ietf.org" 
Thread-Topic: [Ice] 5245bis: STUN/TURN transaction timeout timer
Thread-Index: AdOuOI+oEAiBXZOTQm+Dl/LRxGi/pAA0o/rgAAMPdYAAAXfKMAACL39QAAosVoAAACltgAACbt+AAHQHYYA=
Date: Thu, 1 Mar 2018 07:47:31 +0000
Message-ID: <748F125A-EE65-49B9-99D9-C64AB428CD3A@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B6C19C90C@ESESSMB109.ericsson.se>    <7594FB04B1934943A5C02806D1A2204B6C1A8CC5@ESESSMB109.ericsson.se> <143496D8-1304-49C3-B12F-5EF3A116E1BD@mozilla.com>  <1A521409-0DF9-42B7-B1D9-0F8FB6FA7008@mozilla.com>
In-Reply-To: <1A521409-0DF9-42B7-B1D9-0F8FB6FA7008@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [193.234.218.122]
Content-Type: multipart/signed; boundary="Apple-Mail=_21942CC5-508B-4B31-A609-D2CC0206CC7C"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUyM2K7ja7IhulRBnv2q1p8nLWYxWL+yevM FhdnTWaz+Hah1mLS0YUsFtfnTWZ0YPOYNHMGs8eCTaUeS5b8ZPLoO9DFGsASxWWTkpqTWZZa pG+XwJWx+OZxloJHURWTPzYyNTD2BXYxcnJICJhI3O97wwxiCwkcZpR4flG4i5ELyF7EKDFp xh9WkASbgK3Ek9Z9rCAJEYFTjBJXvm1hB0kwC9RIXLu7H6xbWMBeYsWENkYQW0TAQeLBngYm CDtJYubJGWA1LAIqEjd617GA2LxA9btWb2GF2PaTWeLy9HawBk6gxPlLx8AGMQqISXw/tYYJ Ypm4xK0n85kgzhaReHjxNBuELSrx8vE/VghbWWLdgyeMIEOZBaYwSmzpmMsGsU1Q4uTMJywT GEVmIZk1C1ndLCR1EEXaEssWvmaGsDUl9ncvh4qbSrw++pERwraWmPHrIBuErSgxpfsh+wJG jlWMosWpxUm56UbGeqlFmcnFxfl5enmpJZsYgfF6cMtv1R2Ml984HmIU4GBU4uFVXzo9Sog1 say4MvcQowrQnEcbVl9glGLJy89LVRLhPb19WpQQb0piZVVqUX58UWlOavEhRmkOFiVx3jnC 7VFCAumJJanZqakFqUUwWSYOTqkGxljfyZ+eX0lviHFXTL72696id2/3l5XqtEisFYx55/f+ X2huwtY7nb0f55mUe2asmJXvoizhvmRO+X7b5MXP/TijHqwV0lnyeOPzJwXveSZP7OVZbyAw +fuRxze8nL6LLK65d3+W54Q7H3+tbmv8ePRdRuOy0xMkrpQFPF+o681gznrhTCRb4XolluKM REMt5qLiRAACMJWv3wIAAA==
Archived-At: 
Subject: Re: [Ice] 5245bis: STUN/TURN transaction timeout timer
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 01 Mar 2018 07:47:37 -0000

--Apple-Mail=_21942CC5-508B-4B31-A609-D2CC0206CC7C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

I had a look at the Ti timer in 5389 =
(https://tools.ietf.org/search/rfc5389#section-7.2.2) and it seems that =
it is defined to be in line with the time it takes for (UDP) STUN =
transaction that includes all re-transmissions to timeout:
>    Reliability of STUN over TCP and TLS-over-TCP is handled by TCP
>    itself, and there are no retransmissions at the STUN protocol =
level.
>    However, for a request/response transaction, if the client has not
>    received a response by Ti seconds after it sent the SYN to =
establish
>    the connection, it considers the transaction to have timed out.


However the HTO timer is for transaction pacing and is roughly what one =
successful connectivity check should take (2*RTT).=20

Therefore these are two different things and I don't think it make sense =
to mention Ti here at all. I suggest we remove the note completely.


Cheers,
Ari (hat off)

> On 27 Feb 2018, at 2.25, Nils Ohlmeier  wrote:
>=20
> Yes you are right. Somehow I managed to read Christer=E2=80=99s Note =
the opposite way of what I now think he intends to point out.
>=20
> Sorry for the confusion.
>=20
>   Nils
>=20
>=20
>> On Feb 26, 2018, at 15:15, Black, David  wrote:
>>=20
>> Isn=E2=80=99t it the other way around =E2=80=93 ICE HTO is much =
shorter than STUN or TURN Ti?
>> =20
>> Thanks, --David
>> =20
>> From: Nils Ohlmeier [mailto:nohlmeier@mozilla.com]=20
>> Sent: Monday, February 26, 2018 6:11 PM
>> To: Christer Holmberg 
>> Cc: Black, David ; ice@ietf.org; =
draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org; jri@google.com
>> Subject: Re: [Ice] 5245bis: STUN/TURN transaction timeout timer
>> =20
>> =20
>> On Feb 26, 2018, at 07:48, Christer Holmberg =
 wrote:
>> =20
>> Maybe adding the following note to the existing Timer HTO definition:
>> =20
>> Timer HTO:  The timeout timer for a given STUN or TURN transaction.
>> =20
>>   =E2=80=9CNOTE: When STUN and TURN are used with ICE, timer HTO is =
used instead of timer Ti [RFC5389] as transaction timeout timer.=E2=80=9D
>> =20
>> My initial thought was: yes sounds good.
>> =20
>> But one of the side effects know from real world deployments is that =
results in the end-of-candidates indication coming in after a long time =
if one of the STUN or TURN servers is not reachable.
>> I don=E2=80=99t want to make this a last minute change, but your =
indication that Ti explicitly got made shorter made me wonder if =
everyone in WG is aware of this usage of the long HTO value.
>> =20
>> Best
>>   Nils Ohlmeier
>>=20
>>=20
>> =20
>> Regards,
>> =20
>> Christer
>> =20
>> From: Black, David [mailto:David.Black@dell.com]=20
>> Sent: 26 February 2018 16:54
>> To: Christer Holmberg ;ice@ietf.org; =
draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org
>> Cc: jri@google.com; Black, David 
>> Subject: RE: 5245bis: STUN/TURN transaction timeout timer
>> =20
>> That would be a fine thing to do, Thanks, --David
>> =20
>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20
>> Sent: Monday, February 26, 2018 9:22 AM
>> To: Black, David ; ice@ietf.org; =
draft-ietf-ice-rfc5245bis@ietf.org; ice-chairs@ietf.org
>> Cc: jri@google.com
>> Subject: Re: 5245bis: STUN/TURN transaction timeout timer
>> =20
>> Hi,
>> =20
>> >> But, still, is there a reason we couldn=E2=80=99t use =E2=80=98Ti=E2=
=80=99 also in 5245bis, and point out the big value difference when used =
with ICE?
>> >=20
>> >Given the nearly 2-orders-of-magnitude difference in the time =
periods, I=E2=80=99d be concerned that using the same name risks leaving =
an incorrect impression on an implementer who
>> >is familiar with one protocol, but new to the other.   Different =
names may also improve clarity in other documents that describe how STUN =
and ICE work together.
>> =20
>> Fair enough. But, should we then point out that Ti isn=E2=80=99t used =
with ICE?
>> =20
>> Regards,
>> =20
>> Christer
>> =20
>> =20
>> =20
>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20
>> Sent: Sunday, February 25, 2018 8:00 AM
>> To: ice@ietf.org; draft-ietf-ice-rfc5245bis@ietf.org; =
ice-chairs@ietf.org
>> Cc: Black, David ; jri@google.com
>> Subject: 5245bis: STUN/TURN transaction timeout timer
>> =20
>> Hi,
>> =20
>> In draft-5245bis, the name of the STUN/TURN transaction timeout timer =
is =E2=80=98HTO=E2=80=99.
>> =20
>> As part of the IESG review, I have been asked what the =E2=80=98H=E2=80=
=99 stands for. After some digging in the mail archives (2016-09-14), I =
figured out it stands for =E2=80=9Chandshake=E2=80=9D:
>> =20
>> https://www.ietf.org/mail-archive/web/ice/current/msg00378.html
>> =20
>>       =E2=80=9C2.  A timeout for request packets, call it handshake =
timeout or HTO which SHOULD be 2*RTT if the RTT is known and 500ms =
otherwise.=E2=80=9D
>> =20
>> Now, in RFC 5389, the transaction timeout timer is called =E2=80=98Ti=E2=
=80=99. However, the default value for that SHOULD be 39,5 seconds =E2=80=93=
 which is quite different from 500ms.
>> =20
>> But, still, is there a reason we couldn=E2=80=99t use =E2=80=98Ti=E2=80=
=99 also in 5245bis, and point out the big value difference when used =
with ICE?
>> =20
>> Regards,
>> =20
>> Christer
>> _______________________________________________
>> Ice mailing list
>> Ice@ietf.org
>> https://www.ietf.org/mailman/listinfo/ice
>=20


--Apple-Mail=_21942CC5-508B-4B31-A609-D2CC0206CC7C
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMwDCCBfYw
ggPeoAMCAQICEDcTcXMuXOfOJx3rdG/2/hgwDQYJKoZIhvcNAQELBQAwRzELMAkGA1UEBhMCU0Ux
ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYz
MB4XDTE3MTIwNDE0MTM0NFoXDTIwMTIwNDE0MTM0M1owZTERMA8GA1UECgwIRXJpY3Nzb24xFTAT
BgNVBAMMDEFyaSBLZXLDpG5lbjEnMCUGCSqGSIb3DQEJARYYYXJpLmtlcmFuZW5AZXJpY3Nzb24u
Y29tMRAwDgYDVQQFEwdlYXJpa2VyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAhSVX
rojnPX+oZh2GIgZ/K+/xppl7EN60UI+Vq5SHm6C2ns9/vKek9EgrUV5Zqgqz4gncT1H/3BMA8XOP
ONemPIcegFR2nxkG4v+S3rRxRMdMPgBJwkZQcSDLvT9R/ZgSPckmOtMFsWeoNxdZMUXWfZh52aFk
MF3NlAnXy2UiMmbGAAkHVyUjScSDWAGeGXyZV1Cn5qvoaO/Fd9G4DX646nFrfLjNSnMX6FouZoLh
rkBs6xE62vtRp3z+kLO6UC8CY9e8Qn/cm6xp9B+KrE2/Un99PpbuxLx0GMXq+/cuB4CdiPn+Ka2X
0E66sWiXRoiJz4COm182hV/akOGBjGfzTwIDAQABo4IBvjCCAbowSAYDVR0fBEEwPzA9oDugOYY3
aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDCB
ggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29t
MEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxp
bmRpdmlkdWFsY2F2My5jZXIwIwYDVR0RBBwwGoEYYXJpLmtlcmFuZW5AZXJpY3Nzb24uY29tMFUG
A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9y
eS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcD
AjAdBgNVHQ4EFgQU0dBcPI0/9JLIXr4Qwu+jTumFvcUwHwYDVR0jBBgwFoAUHHsZnpecdqwgPdjc
45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQBVWCBhZPB3PkGIx4FF
guinomjcmL1iZ+icJEWLJ/DyF7559hzn0jDNT14gFEVKJZ/zt6pxlkmNzBaMe6O7cy/NaynWoeeK
uzM61w2tR+UUGhjs3evX20b7PZsT9uONk+K25IiAKhfbwiAtkukhydiDueJZefBHfEaKmGwQ87eZ
Hent/5cu13L7WpT+sCNmhbfqZm5iTWVXqci30Z+G4fX/IhB3mnFMOPniPdM4u/8qsQrAIVBguSGj
rOs6JykmTsOSNgY0vCZoNNHG56ExAcoNb59eLXGLv95JxXRicQuPFca4TceiMSQsHw5999r/lMgJ
8E3YdMBJcnRixumcDE9PKMTGYrOXea51DPrHnA/pMeEzSyW1fzAdVASFTnDS7It9P3KpZVgpOr70
YjTZL2TMP67UBa1+1tYrYJAgZQATjd9pkasJyGRP5+djPlvU+nJ/kfjmv+myawD0nreIULOeKUqW
j0zjt9A8SyqkVa8N8TiN2hupKZBen9orty9igASFyPm86pH9s826bvBZ6BBl0Ox/Lfm9mXz6+1Gs
oCT/puZR9qJrOpCgar4MXU4vuxCVvUdsyaQluWusF/wKyHrB0RUV7Lq96AFIjC06eZwAU33Y2Uqn
bh/ysnEzXsz2lY0bo6yYIaHHKjiTUEefr2dddB9I3tB2oukZ+FB+kkvcuDCCBsIwggSqoAMCAQIC
EFO4foPhnJkok7CbSRzsuOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmEx
HzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUxMDI3
MTIxNjQ2WjBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNz
c29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDs
8t8AALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meisbhkqUXkL
7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdDdxhVW4Le
o0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RSBSAwqBsh
ZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujnwhljPA2/8b8v
9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W07nscEocyBmpC+zJA
mKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBRQGxulYhfAzqSYf8oLUML
ky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1fLPUZQ7FKrDXC6nl2ldvEtlj
HWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77/NHN1iyZyVP2s52B2BLdvo4yhzk6
nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioITKffYLtT9XuirKrHlh3VzkazG46pAVwID
AQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1
c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50
ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIB
ADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9z
aXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8v
Y3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1Ud
JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7GZ6X
nHasID3Y3OORauPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3
DQEBCwUAA4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEPRs5QtaZi
ObNHCZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vRlZrj0uKv
dASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2NZCQysshU
cqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1uJGx6ELP
OiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgbMgJ+xKtngmvE
A155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6LkIIoRlx0A5mi+K7j
ewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3TQYhNv+LsgF0uijiBmaz2
zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX2DxmHmZ1n5HM9OiaAIXP/Zo2
x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDkZGphvxyqp4Jo8qS94EnOqBvxOgft
Yug7OY9EKY+WkDGCAr0wggK5AgEBMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29u
MSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhA3E3FzLlznzicd63Rv9v4Y
MAkGBSsOAwIaBQCgggE3MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X
DTE4MDMwMTA3NDczMFowIwYJKoZIhvcNAQkEMRYEFKKYX7yow/HENbppPXfxWqXK9CZDMGoGCSsG
AQQBgjcQBDFdMFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxF
cmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhA3E3FzLlznzicd63Rv9v4YMGwGCyqGSIb3DQEJ
EAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNz
c29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEDcTcXMuXOfOJx3rdG/2/hgwDQYJKoZIhvcNAQEBBQAE
ggEAQmxm2VH8/G5NhBNMMyDeX+LsgXpVxKdKDTWAHOG4l2h9mmdjKHKnj+5J/vgSTJ7QhZMUKgYN
T0P4ef9lSRDEB4tIUynQjPL7ghGnGQv+LvpKlIJWqL30ui61HPbPZ7I96FXm/BuJl31XEAJe50Su
TQX01dkQIyRvosCYf0d8qEuNi/33yuPgrBJSd22bzJ3ekaNcLL1ddbdRoHtQRlM0KZV+9XPKNpi7
0B1bpAeoSNZeIU3CWqWSJSsYUv0nG7mStl3lo8zYE3qu/gqGPjIBvkT3efr2+uH+MtGTtz8wOSyQ
qw3pzzv7CeNS9pjT+sed2xZ+rhlDFN3PJ7Hs5/frdQAAAAAAAA==

--Apple-Mail=_21942CC5-508B-4B31-A609-D2CC0206CC7C--