From nobody Tue May 3 10:27:42 2016 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 67DD612D997; Tue, 3 May 2016 10:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 wntX-ymlVPnM; Tue, 3 May 2016 10:27:37 -0700 (PDT) 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 AF42512DB9F; Tue, 3 May 2016 10:25:58 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u43HPqA3064604 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 May 2016 12:25:52 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Pal Martinsen" Date: Tue, 03 May 2016 12:25:52 -0500 Message-ID: In-Reply-To: <86559E67-6412-4971-AB74-6680D079CAC8@cisco.com> References: <86559E67-6412-4971-AB74-6680D079CAC8@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "draft-ietf-ice-dualstack-fairness.all@ietf.org" , "ice@ietf.org" Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-dualstack-fairness-02 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 17:27:40 -0000 Hi, I apologize for the delay. My schedule over the last couple of weeks has been disrupted by some family issues. I am ramping back up now. So, TL;DR: I think the working group needs to have a little more discussion about the status and purpose of this draft, and how it relates to ICEBis. More details below. On 19 Apr 2016, at 6:37, Pal Martinsen (palmarti) wrote: > On 19 Apr 2016, at 08:36, Ben Campbell > > wrote: > > Hi, > > This is my AD Evaluation of draft-ietf-ice-dualstack-fairness-02. I > find the draft readable and understandable, but I have some comments > and questions. I'd like to resolve the major comments prior to IETF > last call. > > Major: > > The draft is now informational, but the milestone is for PS. I see the > minutes from Prague say the wg agreed to make the change, but that > doesn't say why, and I failed to find any discussion of that on the > list. Can anyone remind me of the reasoning? (This interacts with my > next comment…) > > Just for clarity I will summarise what I see as the key “events” > of the draft. (I might be wrong so of others see it differently please > correct me) > > - Started as an DualStack Happy Eyeballs solution that would give IPv6 > a head start. > - Several attempts to get a happy eyeballs algorithm working failed. > And we discovered that it would be very difficult to get right in all > the various scenarios. Think the “consensus in the hallways” was > to let each application deal with it as they would know more of what > was important to them. > (http://www.ietf.org/proceedings/92/minutes/minutes-92-mmusic#h.v0jtwu5re90f) > - > Since the draft only contains guidelines on how an application should > deal with dual-stack it made sense to make it informational. > (http://www.ietf.org/proceedings/93/minutes/minutes-93-mmusic#h.34ilx3y4vkbd) The right choice here depends on what the working group expects the draft to accomplish. I think informational works if we want to tell implementors about some things they can do if they care. If, on the other hand, we want to actually encourage implementors to implement this, then I'm not sure informational is the right choice. Did the WG consider BCP? > > > > I am confused about the relationships among this draft, RFC 5245, > 5245bis, and RFC 6724. Section 1 of this draft seems to say that it > recommends against following the requirement in 5245 that says dual > stack hosts SHOULD follow the precedence in 6724. Normally, that would > require this draft to update 5245, which would require it to be > standards track. > > But on the other hand, I am not entirely convinced anything here > really changes that SHOULD, since 6724 explicitly says: > > "The selection rules specified in this document MUST NOT be construed > to override an application or upper layer’s explicit choice of a > legal destination or source address." > > Unfortunately, I think this puts things in a grey area, due to > ambiguous wording in 5245. So I think this draft either needs to > update 5245, or it needs to explain why the guidance here does not > conflict with that SHOULD. > > This was at least discussed in IETF90, > http://www.ietf.org/proceedings/90/minutes/minutes-90-mmusic#h.6fijdpveanaa That discussion seemed to resolve to "we need to check to see if we are updating 2119 language" :-) > > So now my naive question is; do we care about 5245 with 5245bis soon > finished? The same language is currently in 5245bis. > > I think we have two possible solutions. > > 1. Make dual-stack fairness reference only 5245bis. Make sure text in > both draft harmonise. They will cross reference each other and thus > needs to be published at the same time? Would you expect ICEBis to normatively reference this? If so, that has implications about the PS/Informational/BCP decisions. If so, they would form a cluster in the RFC editor queue. Even if they were submitted at different times, they would be formally published more or less at the same time. > > 2. Explain why we are not braking the 5245 SHOULD and keep it as > informational . This is done by pointing out the appropriate text you > found in 6724. The current text is misleading, in the way it explicitly says that following the SHOULD in 5245/5245bis leads to "unfair" prioritization. As written, it does seem to relax the SHOULD. Language clarifying that 6724 allows application-specific choices would be helpful. > > And in either case: Is there an opportunity to make 5245 more clear in > 5245bis? > > > Absolutely. It must also point out that the formulas described in 5245 > section 4.1.2 have not changes so that the compatibility discussion in > section 5 of the dual-stack fairness draft is still valid. > > > That of course leads to the bombshell question: We are already in the > process of updating 5245. Why isn’t _this_ draft part of 5245bis? > > I think the main motivation for that was to keep the ICEbis spec as > short as possible as there are some implementations that does not care > about the problem. For the implementations that do care, they should > read the draft and follow the recommendations. I don't find that all that convincing. ICEbis talks about dual-stack stuff in several places, and makes that explicit statement about dual-stack behavior and 6724. A good part of the content of _this_ draft is spent describing things in ICE/ICEbis for context, and could probably be significantly reduced. One possibility might be to move the procedure parts into ICEBis, and refer back to this draft for motivation and an explanation of why a happy eyeballs approach is useful. (Or maybe that could just go into an appendix of ICEbis.) Now, I don't have a strong belief this needs to merge into ICEBis--I just want to make sure the working group has thought about the option. In particular, we should consider what makes things easier on the reader, not just what is easier from an IETF process perspective. > > Minor: > > - 1: The introduction jumps right to saying applications need to > deprioritize interfaces without saying what problem it's trying to > solve. An initial paragraph that says what goes wrong with current > implementations would be extremely helpful. It would also help to > define what is meant by "fairness" in this context. (I’m not sure > it's quite the same as the conventional use of the term.) > > How about: > > In multihomed and IPv4/IPv6 dual-stack environments ICE [RFC5245] > would benefit by a fair distribution of its connectivity checks > across available interfaces or IP address types. With a fair > distribution of the connectivity checks, excessive delays are > avoided > if a particular network path is broken or slow. It would arguable > be > better to put the interfaces or address types know to the > application > last in the checklist. However, the main motivation by ICE is to > make no assumptions regarding network topology, hence a fair > distribution of the connectivity checks is more appropriate. If an > application operates in a well-known environment is can safely > override the recommendation given in this document. That helps, but I still don't see s definition of what you mean by "fair distribution". > > > - 2: Assuming this stays informational, it's not really using the 2119 > keywords quite in the spirit of 2119. Personally, I don't think the > current 2119 usage (outside of text directly attributed to other > documents, which doesn't really count) adds much. I suggest removing > it. > > But if people are really attached to using 2119 language here, please > consider adjusting the boilerplate to say that, while this draft does > not include normative requirements, the keywords are used for the sake > of clarity. > > > Agree. Removed from draft. And all capital SHOULD occurrences replaced > with should. That works for me, assuming people choose to keep this as an informational. > > -3, 2nd paragraph: > > Does the working group believe that one can make reasonable inferences > from just the network type? Do you expect these to be configurable? > Statically defined in code? (Seems like there may be operational > considerations here.) > > The original intent with the text was to say; “If you think you know > better, please feel free to do as you please…”. But basing it just > on network type seems to be a bit to fragile. > > Updated text: > The application knowledge regarding the reliability of an interface > can also be based on simple metrics like previous connection > success/ > failure rates or a more static model based on interface types like > wired, wireless, cellular, virtual, tunneled in conjunction with > other operational metrics. This would require the application to > have the right permissions to obtain such operational metrics. That helps, thanks. > > > - 7.2: Can this be more specific about what implementations exist? The > boilerplate seems a bit heaviweight for something that pretty much > says “there are others" :-) > > > The section has been in and out. Main use is to inform WG and AD that > there are others? Others have confirmed during WG meetings that they > do things similar to what is described in the draft (But sometimes > they have more operational knowledge and are able to override things > in the draft). > > Safe to remove this section now? This sort of thing usually comes out at publication time, so it's probably fine for now. > > > Editorial: > > - 4 , first paragraph: How long is long? (Especially if you stick the > 2119 SHOULD). > > I think long can be dropped. IMHO intermingling of the address types > is a good thing if you want to be topology agnostic. > The paragraph still have “values” like many and small. I think > that is ok? > > New paragraph: > Candidates should be prioritized such that a sequence of candidates > belonging to the same address family will be intermingled with > candidates from an alternate IP family. For example, promoting > IPv4 > candidates in the presence of many IPv6 candidates such that an > IPv4 > address candidate is always present after a small sequence of IPv6 > candidates, i.e., reordering candidates such that both IPv6 and > IPv4 > candidates get a fair chance during the connectivity check phase. > This makes ICE connectivity checks more responsive to broken path > failures of an address family. WFM. > > - 5, last paragraph: Doesn’t this belong in the "Implementation > Status" section? > > The intent was to guide implementers to sample code. If that is moved > to Implementation Status that information will be lost when published > as an RFC. > > Previous versions had an appendix with the code examples. The WG felt > that that was a to strong encouragement to implement a specific > solution, this was something the WG did not want to do. Hence the > informational status of the draft. > > I am fine with removing it. I don't necessarily object to keeping it, but keep in mind that RFCs live forever, and code repositories might not. > > > - 7.1 and 7.2 titles: s/Starck/Stack > > Gahh.. Fixed even if removed later.. > > - 7.1, "Level of Maturity": Are there words missing around "Tests"? > > Cut and paste error. > > > > Do you want me to post a new version of the draft with the changes. We > still need to resolve the 5245, 5245bis and 6724 problem. Simple > enough once we agree. Revisions are cheap :-) I'd suggest updating with the known changes now, then dealing wtih the other stuff when we can. Thanks! Ben. From nobody Wed May 4 08:58:10 2016 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 0394612D701 for ; Wed, 4 May 2016 08:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 2-spDNls4FNq for ; Wed, 4 May 2016 08:58:08 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C4512B049 for ; Wed, 4 May 2016 08:51:22 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-d4-572a1a795125 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 44.84.12926.97A1A275; Wed, 4 May 2016 17:51:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Wed, 4 May 2016 17:51:21 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: 5245bis: New ICE option to prevent legacy peers from using aggressive nomination Thread-Index: AdGmHG6bJo539xyvSt+nU2XdpYsl7w== Date: Wed, 4 May 2016 15:51:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F93800@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F93800ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7hG6llFa4wYJ+OYtvF2odGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJXxYdNXloLjShU7pn1ibmD8LdvFyMkhIWAisWD9OxYIW0ziwr31 bCC2kMARRonJXVFdjFxA9mIg+8plpi5GDg42AQuJ7n/aIDUiAooSM1ueMYPYwgLREkvXfGGC iCdIzJy7iQ2kXERAT+LtO2+QMIuAisSPOx1g5bwCvhLnV24FsxmB1n4/tQaslVlAXOLWk/lM EOcISCzZc54ZwhaVePn4HyuErSSxYvslRoj6fIm1bcvZIGYKSpyc+YRlAqPQLCSjZiEpm4Wk DCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9iFC1OLU7KTTcy1kstykwuLs7P08tLLdnE CIyGg1t+q+5gvPzG8RCjAAejEg/vgnDNcCHWxLLiytxDjBIczEoivNqSWuFCvCmJlVWpRfnx RaU5qcWHGKU5WJTEef1fKoYLCaQnlqRmp6YWpBbBZJk4OKUaGLMs7dS53kQ+36soJt17RU/R RviVR9yP81dSzq61tIueebXngrithnCaQm+O8vuUYxdqP5u1LF+69k8kk4lCJrse7w7vlEzh Q+e8nB+UsPvLBnt+apt3QCc19FLBYuGtW0xkqrIypu379LJWwVlkpxx777crp4ykp3txPTCe zfG+6nutdkS8EktxRqKhFnNRcSIARiTgXYICAAA= Archived-At: Subject: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 15:58:10 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F93800ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, As agreed in Buenos Aires, 5245bis endpoints will not use aggressive nomina= tion, and we also agreed to define a new ICE option to be used by 5245 endp= oints in order to prevent legacy peers from using aggressive nomination (as= legacy peers would not support the ICE option, they are expected not to us= e aggressive nomination). However, defining a dummy ICE option just to prevent legacy peers from usin= g aggressive nomination would not be good protocol design, in my opinion. Also, scoping the ICE option to nomination may not be smart either. In my o= pinion the ICE option should indicate that the endpoint is compliant with 5= 245bis in general. Do people agree with that? If so, do you have suggestions for the ICE option name? :) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37F93800ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

As agreed in Buenos Aires, 5245bis endpoints will no= t use aggressive nomination, and we also agreed to define a new ICE option = to be used by 5245 endpoints in order to prevent legacy peers from using ag= gressive nomination (as legacy peers would not support the ICE option, they are expected not to use aggressive = nomination).

 

However, defining a dummy ICE option just to prevent= legacy peers from using aggressive nomination would not be good protocol d= esign, in my opinion.

 

Also, scoping the ICE option to nomination may not b= e smart either. In my opinion the ICE option should indicate that the endpo= int is compliant with 5245bis in general.

 

Do people agree with that?

 

If so, do you have suggestions for the ICE option na= me? :)

 

Regards,

 

Christer

 

 

--_000_7594FB04B1934943A5C02806D1A2204B37F93800ESESSMB209erics_-- From nobody Wed May 4 09:55:41 2016 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 BC66012D750 for ; Wed, 4 May 2016 09:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 u9oIPc2CweyJ for ; Wed, 4 May 2016 09:55:37 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::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 ADCF512D7AE for ; Wed, 4 May 2016 09:48:34 -0700 (PDT) Received: by mail-ig0-x233.google.com with SMTP id m9so53277916ige.1 for ; Wed, 04 May 2016 09:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=HPYX9KXYNAaI1Aokur/0gEd8KVMudFrskhuNn37blYM=; b=m9yZhNnwaJj6WamS1cJr9697TYm5yabAMUNeR6u0KjoTwW75A5cAs73fU0H+nzaYrE 8Ivco3u64l9Ev9zz0GxWNcEE+OuC5L5MksRwI8afZyx3TDAEbao4f8dw2hgzP/GX70GC JqF9q1lL8znr1aDVihJJbehigWvP2cAAcXrEWRZ3ept8DKad9T9/PZWOloIUxWJDP3J/ tQLdaVklz6o/BbQDBIcbEz4hlPJiSjyWrY1AxM4R9NhrP/QnXvy65qpVwmsxagCzFkq3 XOSzc87UbB4ukjOkK1NJM5Bxg5KDURFRpkTs2oYxTGMTTZXxxKOXKKCiArNZmFgEp0vE wgdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=HPYX9KXYNAaI1Aokur/0gEd8KVMudFrskhuNn37blYM=; b=PuEvB6hAUSVOhcufYj1U5vx5EatRBjm+tC0s4J/+NPVSSaKIbThyj7ESq/XamiJdZn 0yNe3YXZd2QiB6xpk9N3s7gLtj3U2Dfp5F1NLlA/JYIbFU8/ATFmoy4JmN4ABnoFL2O0 sd5dWwwB3//LRTTBi9Oq4If1LD41sY8ASEIxQqS3g12KAUHs36jrKpNS9sKrRu+jp5Vj 70ghhA3sfPc9Vtp/4U0/a/hgnqaVMreaffWjTpAjY76pQTpPnhTeey4PoVHG88wXMWsl LYqILgfb/DxIetY/zJ8gjj/3Si/Seer2EoNM0mH9RyAgiwzbqD917I7E1ewwgGtyG5e5 sGkw== X-Gm-Message-State: AOPr4FU2U7qHybP2PRHtBglmnJhLjgr5jtaoahhxVledda+K79wWA217v9PNmSxaXcVQxg== X-Received: by 10.50.28.113 with SMTP id a17mr11893254igh.44.1462380513938; Wed, 04 May 2016 09:48:33 -0700 (PDT) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com. [209.85.213.172]) by smtp.gmail.com with ESMTPSA id 19sm1778467ion.2.2016.05.04.09.48.33 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 May 2016 09:48:33 -0700 (PDT) Received: by mail-ig0-f172.google.com with SMTP id m9so53277404ige.1 for ; Wed, 04 May 2016 09:48:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.60.132 with SMTP id h4mr31987826igr.78.1462380512913; Wed, 04 May 2016 09:48:32 -0700 (PDT) Received: by 10.36.144.69 with HTTP; Wed, 4 May 2016 09:48:32 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F93800@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37F93800@ESESSMB209.ericsson.se> Date: Wed, 4 May 2016 12:48:32 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=bcaec5015c9bffd1e9053206fe12 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 16:55:40 -0000 --bcaec5015c9bffd1e9053206fe12 Content-Type: text/plain; charset=UTF-8 I agree and would suggest option name ice-bis. _____________ Roman Shpount On Wed, May 4, 2016 at 11:51 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > As agreed in Buenos Aires, 5245bis endpoints will not use aggressive > nomination, and we also agreed to define a new ICE option to be used by > 5245 endpoints in order to prevent legacy peers from using aggressive > nomination (as legacy peers would not support the ICE option, they are > expected not to use aggressive nomination). > > > > However, defining a dummy ICE option just to prevent legacy peers from > using aggressive nomination would not be good protocol design, in my > opinion. > > > > Also, scoping the ICE option to nomination may not be smart either. In my > opinion the ICE option should indicate that the endpoint is compliant with > 5245bis in general. > > > > Do people agree with that? > > > > If so, do you have suggestions for the ICE option name? :) > > > > Regards, > > > > Christer > > > > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --bcaec5015c9bffd1e9053206fe12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree and would suggest option name ice-bis.

= _____________
Roman Shpount

On Wed, May 4, 2016 at 11:51 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>

Hi,

=C2=A0

As agreed in Buenos Aires, 5245bis endpoints will no= t use aggressive nomination, and we also agreed to define a new ICE option = to be used by 5245 endpoints in order to prevent legacy peers from using ag= gressive nomination (as legacy peers would not support the ICE option, they are expected not to use aggressive = nomination).

=C2=A0

However, defining a dummy ICE option just to prevent= legacy peers from using aggressive nomination would not be good protocol d= esign, in my opinion.

=C2=A0

Also, scoping the ICE option to nomination may not b= e smart either. In my opinion the ICE option should indicate that the endpo= int is compliant with 5245bis in general.

=C2=A0

Do people agree with that?

=C2=A0

If so, do you have suggestions for the ICE option na= me? :)

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0


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


--bcaec5015c9bffd1e9053206fe12-- From nobody Wed May 4 12:49:49 2016 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 B212312D5C5 for ; Wed, 4 May 2016 12:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 vsZPOz_OEH8Y for ; Wed, 4 May 2016 12:49:44 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4581112D0C7 for ; Wed, 4 May 2016 12:49:44 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-ec-572a525597fd Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 98.75.12516.5525A275; Wed, 4 May 2016 21:49:41 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.117]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Wed, 4 May 2016 21:49:41 +0200 From: Christer Holmberg To: Roman Shpount Thread-Topic: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination Thread-Index: AdGmHG6bJo539xyvSt+nU2XdpYsl7///7zEAgABUI0Q= Date: Wed, 4 May 2016 19:49:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37F93B6F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37F93800@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37F93B6FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbHdQDc0SCvc4Ocna4tvF2otZlyYyuzA 5LFkyU8mj1tTCgKYorhsUlJzMstSi/TtErgyNs2Zw1ZwxLBixakpLA2My7S7GDk5JARMJL59 O8MGYYtJXLi3Hsjm4hASOMIoMWHvNVaQhJDAYkaJhiMRXYwcHGwCFhLd/8B6RQRUJf5+n8wE EmYWUJR4uVcNJCwskCrx/loPG0hYRCBNYv3CGAjTSuLZLyaQChYBFYnNsy6B2bwCvhIPzm6E 2jOJUeLtk0AQm1MgUOLGYog4I9Bh30+tAatnFhCXaPqykhXiYAGJJXvOM0PYohIvH/9jhajJ l7h7cTsjxHxBiZMzn7BMYBSZhaR9FpKyWUjKIOIGEl/e34aytSWWLXzNDGHrS3S/P82ELL6A kX0Vo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmAsHdzyW3cH4+rXjocYBTgYlXh4F4Rrhgux JpYVV+YeYpTgYFYS4fUJ1AoX4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuv/UjFcSCA9sSQ1OzW1 ILUIJsvEwSnVwOg9p3nVtbRFSZ9mxkUdimxruX9evqI+79HKNwZXSy1WvF62aOON2LLzFqyb n9owJ6dlMrS9U++zkvm+40Sm6dk/XaVrF9+LXpJTNEv189Wl+5pun2Z6d0/R7KNvZbffku0r L2dGXE+Lzi/PVZ759DVzTcPVo+neFm4Gf97tOFQtJThvwemLb04rsRRnJBpqMRcVJwIAxEPB CKECAAA= Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 19:49:47 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37F93B6FESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, I was thinking of "bus" too. But, it's a temporary working name. And, what = about the next time we make a bis? :) Regards, Christer Sent from my Windows Phone ________________________________ From: Roman Shpount Sent: =FD04/=FD05/=FD2016 19:48 To: Christer Holmberg Cc: ice@ietf.org Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from usi= ng aggressive nomination I agree and would suggest option name ice-bis. _____________ Roman Shpount On Wed, May 4, 2016 at 11:51 AM, Christer Holmberg > wrote: Hi, As agreed in Buenos Aires, 5245bis endpoints will not use aggressive nomina= tion, and we also agreed to define a new ICE option to be used by 5245 endp= oints in order to prevent legacy peers from using aggressive nomination (as= legacy peers would not support the ICE option, they are expected not to us= e aggressive nomination). However, defining a dummy ICE option just to prevent legacy peers from usin= g aggressive nomination would not be good protocol design, in my opinion. Also, scoping the ICE option to nomination may not be smart either. In my o= pinion the ICE option should indicate that the endpoint is compliant with 5= 245bis in general. Do people agree with that? If so, do you have suggestions for the ICE option name? :) Regards, Christer _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice --_000_7594FB04B1934943A5C02806D1A2204B37F93B6FESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

I was thinking of "bus" too. But, it's a temporary working name. = And, what about the next time we make a bis? :)

Regards,

Christer

Sent from my Windows Phone
From: Roman Shpount
Sent: =FD04= /=FD05/=FD2016 19:48
To: Christer Holmberg Cc: ice@ietf.org
Subject: Re: [= Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive = nomination

I agree and would suggest option name ice-bis.

_____________
Roman Shpount

On Wed, May 4, 2016 at 11:51 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi,

 

As agreed in Buenos Aires, 5245bis endpoints will no= t use aggressive nomination, and we also agreed to define a new ICE option = to be used by 5245 endpoints in order to prevent legacy peers from using ag= gressive nomination (as legacy peers would not support the ICE option, they are expected not to use aggressive = nomination).

 

However, defining a dummy ICE option just to prevent= legacy peers from using aggressive nomination would not be good protocol d= esign, in my opinion.

 

Also, scoping the ICE option to nomination may not b= e smart either. In my opinion the ICE option should indicate that the endpo= int is compliant with 5245bis in general.

 

Do people agree with that?

 

If so, do you have suggestions for the ICE option na= me? :)

 

Regards,

 

Christer

 

 


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


--_000_7594FB04B1934943A5C02806D1A2204B37F93B6FESESSMB209erics_-- From nobody Fri May 6 16:21:59 2016 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 6D27F12D147 for ; Fri, 6 May 2016 16:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.996 X-Spam-Level: X-Spam-Status: No, score=-2.996 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, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] 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 6Qb6p6TzqeW0 for ; Fri, 6 May 2016 16:21:56 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 9BD7B12D0C1 for ; Fri, 6 May 2016 16:21:55 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id j8so146828363lfd.2 for ; Fri, 06 May 2016 16:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=McIU14a+5sARrSoR91R1NqvVeGdl49qbyBxwXBXxGRM=; b=ZF4wvdFrd33/Jedq+MNpow3s+yzTjb3T2FHoYaeTB6wdihFi43hR/Fwp/cFdqrxjON /KiOezgzzBwsvD+zCGc23Y5f/htiuzxZFRGu/5PYRXSnGetf3bM2rtKrBp6TrgYmKS2t 3ANc28uRu5tRkYv1k9+3xQmf1yYxAOCAwFdzCIauIuxdnstTIaKisq/DHEZx5DyRXfp3 21VFIVfMUop7ZUgXTrYTM3qmL71gcNm5HSX0WBce+SfvWi/FQ65QiMomPYjfLCg3IW6A l0r4vFRSsDE5QI5i6zUzNrwoVNNwiUvo5VRaKSgVlUXSowcg6MbJQKUtqaTMbngA5K/r aNZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=McIU14a+5sARrSoR91R1NqvVeGdl49qbyBxwXBXxGRM=; b=R2bKVI6perjasy2y61NqvTJIQBwxsqll5Lb3EMyRVP2ZohnF9D9e6y4Lcvpy8d40OX miGfQ3+5d/i0TnBDETmV5ONH7pl9Gd4FSUwZj7r0g/ys7B7Pz1a5f9usn5TOcZRulm0i X9noCjr5uNPFCFASZHRI51RQqWyGzRd1asaQ1CIg9RX9FttL6H1mrEStXVTM8y3qbUe2 oaT/2/7OPxyQEO7cKyTcRsHLr9p5hsaWp+YN0wmmK21WNqjdsYNpzuYXTW2ti9YB76mB 8Ag4PtWrKnXswiAgyJrJxm6pNmSq0WDLMCB6HimEyhx4YbDHQeMVRNyU0MCxYPgqRGPw QO+w== X-Gm-Message-State: AOPr4FWd8VZASBRFHXhYMqU8QGqd2fdwuSgRmUfKcPZt3zFkSWf/f3vqIuwkIcG+N2zBI4rXxr/dSth/BZ4jqdc8 X-Received: by 10.112.150.165 with SMTP id uj5mr10691796lbb.95.1462576913667; Fri, 06 May 2016 16:21:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.208.208 with HTTP; Fri, 6 May 2016 16:21:14 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Fri, 6 May 2016 16:21:14 -0700 Message-ID: To: Byron Campen , ice@ietf.org Content-Type: multipart/alternative; boundary=047d7b3a839665a0b8053234b9ee Archived-At: Subject: Re: [Ice] [MMUSIC] ICE triggered check behavior can backfire when using aggressive nomination X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 23:21:58 -0000 --047d7b3a839665a0b8053234b9ee Content-Type: text/plain; charset=UTF-8 Moving this from the MMUSIC list to the ICE list. All of these seem like issues with aggressive nomination. And 5245bis is removing aggressive nomination. So in a way, 5245bis solves these issues. But it does have simplified rule for what to do when talking to a 5245 endpoint that does aggressive nomination, and we should probably make sure that simple rule works well with what you are suggesting. I agree that receiving a nomination should not prevent triggered checks from occurring. By the way, Chrome has the behavior you are describing where triggered checks are not affected by aggressive nomination. On Fri, May 6, 2016 at 8:45 AM, Byron Campen wrote: > I've written out the details at > https://bugzilla.mozilla.org/show_bug.cgi?id=1268961 , but the essence of > the problem is that an incoming ICE check can cause a high priority > in-progress pair to transition to waiting (due to the triggered check > rules), which leaves it vulnerable to removal from the check list when > nomination happens on a lower priority pair. Without the incoming ICE > check, the high priority pair would have remained in-progress, and would > eventually have reached nomination. > > It doesn't seem right to me that an incoming ICE check on a high > priority pair could prevent that pair from reaching nomination when > aggressive nomination is in use. It also doesn't seem right to me that > receiving an incoming ICE check would cause a pair to transition from > in-progress to waiting, given that the intent in the spec is to fast track > that pair, and not put it on the back burner. > > It seems to me that prohibiting this in-progress -> waiting transition > is the way to go, but it would also be reasonable to take priority into > account when removing pairs from the triggered check queue (or maybe even > never remove pairs from the triggered check queue). > > Best regards, > Byron Campen > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --047d7b3a839665a0b8053234b9ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Moving this from the MMUSIC list to the ICE list.
=

All of these seem like issues with aggressive nomination.= =C2=A0 And 5245bis is removing aggressive nomination.=C2=A0 So in a way, 52= 45bis solves these issues.=C2=A0 But it does have simplified rule for what = to do when talking to a 5245 endpoint that does aggressive nomination, and = we should probably make sure that simple rule works well with what you are = suggesting.=C2=A0 I agree that receiving a nomination should not prevent tr= iggered checks from occurring.

By the way, Chrome has = the behavior you are describing where triggered checks are not affected by = aggressive nomination. =C2=A0

On Fri, May 6, 2016 at 8:45 AM, Byron Campen <d= ocfaraday@gmail.com> wrote:
=C2=A0 =C2=A0 I've written out the details at https://bugzilla.mozilla.org/show_bug.cgi?id=3D1268961 , but the e= ssence of the problem is that an incoming ICE check can cause a high priori= ty in-progress pair to transition to waiting (due to the triggered check ru= les), which leaves it vulnerable to removal from the check list when nomina= tion happens on a lower priority pair. Without the incoming ICE check, the = high priority pair would have remained in-progress, and would eventually ha= ve reached nomination.

=C2=A0 =C2=A0 It doesn't seem right to me that an incoming ICE check on= a high priority pair could prevent that pair from reaching nomination when= aggressive nomination is in use. It also doesn't seem right to me that= receiving an incoming ICE check would cause a pair to transition from in-p= rogress to waiting, given that the intent in the spec is to fast track that= pair, and not put it on the back burner.

=C2=A0 =C2=A0 It seems to me that prohibiting this in-progress -> waitin= g transition is the way to go, but it would also be reasonable to take prio= rity into account when removing pairs from the triggered check queue (or ma= ybe even never remove pairs from the triggered check queue).

Best regards,
Byron Campen

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

--047d7b3a839665a0b8053234b9ee-- From nobody Fri May 20 03:15:28 2016 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 2032212B012 for ; Fri, 20 May 2016 03:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 TKa8fC-1OULy for ; Fri, 20 May 2016 03:15:25 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B4312DC7F for ; Fri, 20 May 2016 03:15:19 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-77-573ee3b61a36 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B8.48.12926.6B3EE375; Fri, 20 May 2016 12:15:18 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Fri, 20 May 2016 12:15:17 +0200 From: Christer Holmberg To: Christer Holmberg , Roman Shpount Thread-Topic: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination Thread-Index: AdGmHG6bJo539xyvSt+nU2XdpYsl7///7zEAgABUI0SAGJY7AA== Date: Fri, 20 May 2016 10:15:17 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B37F93800@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F93B6F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F93B6F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D364BE368B95christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM2K7q+62x3bhBjvOCVl8u1BrMePCVGYH Jo8lS34yedyaUhDAFMVlk5Kak1mWWqRvl8CVMW1BM3NBv1PFtzXvGRsYP1t2MXJySAiYSHy+ 94QFwhaTuHBvPVsXIxeHkMARRok/3dcZIZwljBKblz4Fcjg42AQsJLr/aYM0iAhES3z4sIAJ JMwsoCjxcq8aiCkskCpx/lIhiCkikCaxfmEMRLGTxOslN1lBbBYBVYl7F2+BbeUVsJKYfm4/ K8SiG4wS33sXsYH0cgr4SWx7XAhSwwh02fdTa5hAbGYBcYlbT+YzQVwsILFkz3lmCFtU4uXj f2DzRQX0JPa9OA92rwTQYcv75SBa4yVePlnHDrFWUOLkzCcsExjFZiGZOgtJ2SwkZRBxA4n3 5+YzQ9jaEssWvoay9SU2fjnLOAscDNYSrT94kZUsYORYxShanFqclJtuZKyXWpSZXFycn6eX l1qyiREYkQe3/FbdwXj5jeMhRgEORiUe3gX5duFCrIllxZW5hxglOJiVRHj/PwIK8aYkVlal FuXHF5XmpBYfYpTmYFES5/V/qRguJJCeWJKanZpakFoEk2Xi4JRqYHR8duWubJR666e5uxsz dmhulrvmtSngdHC0rUyeypyenYeEZiwXTvyWJZdy8IvvDUN/J8YnX2uZLu+4Er9y5vXgzFPW LxoWT3ryT+D/e0Mh6x2hB2d+Nq5OmB4Rfj/gsKuxtIT7DbEzs1UMfr12dlaIZ5p547whl/vS yvlmZ2vmZG94KRThc0yJpTgj0VCLuag4EQDDCukwxAIAAA== Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 10:15:27 -0000 --_000_D364BE368B95christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have received no further suggestions, so I guess we can call it =93simpli= fied=94. Regards, Christer From: Ice > on behalf of = Christer Holmberg > Date: Wednesday 4 May 2016 at 22:49 To: Roman Shpount > Cc: "ice@ietf.org" > Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from usi= ng aggressive nomination Hi, I was thinking of "bus" too. But, it's a temporary working name. And, what = about the next time we make a bis? :) Regards, Christer Sent from my Windows Phone ________________________________ From: Roman Shpount Sent: 04/05/2016 19:48 To: Christer Holmberg Cc: ice@ietf.org Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from usi= ng aggressive nomination I agree and would suggest option name ice-bis. _____________ Roman Shpount On Wed, May 4, 2016 at 11:51 AM, Christer Holmberg > wrote: Hi, As agreed in Buenos Aires, 5245bis endpoints will not use aggressive nomina= tion, and we also agreed to define a new ICE option to be used by 5245 endp= oints in order to prevent legacy peers from using aggressive nomination (as= legacy peers would not support the ICE option, they are expected not to us= e aggressive nomination). However, defining a dummy ICE option just to prevent legacy peers from usin= g aggressive nomination would not be good protocol design, in my opinion. Also, scoping the ICE option to nomination may not be smart either. In my o= pinion the ICE option should indicate that the endpoint is compliant with 5= 245bis in general. Do people agree with that? If so, do you have suggestions for the ICE option name? :) Regards, Christer _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice --_000_D364BE368B95christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I have received no further suggestions, so I guess we can call it =93s= implified=94.

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf of Christer Holmb= erg <christer.holmberg= @ericsson.com>
Date: Wednesday 4 May 2016 at 22:49=
To: Roman Shpount <roman@telurix.com>
Cc: "ice@ietf.org" <ice@ietf.= org>
Subject: Re: [Ice] 5245bis: New ICE= option to prevent legacy peers from using aggressive nomination

Hi,

I was thinking of "bus" too. But, it's a temporary working name. = And, what about the next time we make a bis? :)

Regards,

Christer

Sent from my Windows Phone
From: Roman Shpount
Sent: 04/05= /2016 19:48
To: Christer Holmberg Cc: ice@ietf.org
Subject: Re: [= Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive = nomination

I agree and would suggest option name ice-bis.

_____________
Roman Shpount

On Wed, May 4, 2016 at 11:51 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi,

 

As agreed in Buenos Aires, 5245bis endpoints will no= t use aggressive nomination, and we also agreed to define a new ICE option = to be used by 5245 endpoints in order to prevent legacy peers from using ag= gressive nomination (as legacy peers would not support the ICE option, they are expected not to use aggressive = nomination).

 

However, defining a dummy ICE option just to prevent= legacy peers from using aggressive nomination would not be good protocol d= esign, in my opinion.

 

Also, scoping the ICE option to nomination may not b= e smart either. In my opinion the ICE option should indicate that the endpo= int is compliant with 5245bis in general.

 

Do people agree with that?

 

If so, do you have suggestions for the ICE option na= me? :)

 

Regards,

 

Christer

 

 


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


 --_000_D364BE368B95christerholmbergericssoncom_-- From nobody Fri May 20 04:03:35 2016 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 EDC4812D821; Fri, 20 May 2016 04:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 TeClxkyaz8nL; Fri, 20 May 2016 04:03:32 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D379F12D838; Fri, 20 May 2016 04:03:31 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-ad-573eef02aad4 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 09.47.18043.20FEE375; Fri, 20 May 2016 13:03:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Fri, 20 May 2016 13:03:15 +0200 From: Christer Holmberg To: Ben Campbell , Pal Martinsen Thread-Topic: [Ice] AD Evaluation of draft-ietf-ice-dualstack-fairness-02 Thread-Index: AQHRpWEb5Ssc2siO0EqGhesod9eww5/B1REA Date: Fri, 20 May 2016 11:03:15 +0000 Message-ID: References: <86559E67-6412-4971-AB74-6680D079CAC8@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4FEEF13CCADB534A91461965CB89032F@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUyM2K7nC7Te7twg59H+Szmd55mt/h9vpHZ 4tuFWov311eyOLB4TPm9kdVjyZKfTB6zdj5hCWCO4rJJSc3JLEst0rdL4Mp4veU4Y8GV9Iqe 33+ZGxjfBHUxcnJICJhI7JnwjQXCFpO4cG89WxcjF4eQwBFGiebXnewQzhJGiWtTPgJlODjY BCwkuv9pgzSICLhJLOqaxApSwyzQwSix9vVeNpCEsICHxNGvjWwQRZ4S+zaDDAKxjSSutdxh BrFZBFQlTj2fxQpi8wpYSVyefJAZYtkyRolP786DNXAK2EtMnHuKEcRmBDrv+6k1TCA2s4C4 xK0n85kgzhaQWLLnPDOELSrx8vE/sKGiAnoS+16cZwQ5WkJAUWJ5vxxEq4HE+3PzmSFsa4m3 Ry5C2doSyxa+Zoa4R1Di5MwnLBMYJWYh2TYLSfssJO2zkLTPQtK+gJF1FaNocWpxcW66kZFe alFmcnFxfp5eXmrJJkZglB7c8ttqB+PB546HGAU4GJV4eBfk24ULsSaWFVfmHmKU4GBWEuEV ewcU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuv/UjFcSCA9sSQ1OzW1ILUIJsvEwSnVwLjKpeHR nr+/5zkyL2v7/GHFNZawtTabS7k/rzv3ea/fuUvK4WdyZfk5JZdWSLRMnen7OantWUykytqT oiEnhOZN2SLbrvzAY7fWzSNWv78ah2w7nr3q7NTO4vTp1fbtHoIZr96x6GvOyfkRNsd2ztcA hc/Na4y7Bb/FzTM33zG9g9vmzPSnrzWUWIozEg21mIuKEwEoHoMmzgIAAA== Archived-At: Cc: "draft-ietf-ice-dualstack-fairness.all@ietf.org" , "ice@ietf.org" Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-dualstack-fairness-02 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 11:03:35 -0000 Hi, I have not been very much involved the dualstack-fairness work/discussions, so forgive me if the following issues have already been discussed. As the purpose of the draft is to =B3make things work better=B2, I see no reason why we simply couldn=B9t implement the change in 5245bis. I don=B9t think we need too much extra text for the justification, and it could e.g. be put in an appendix as suggested. Now, regarding the statement that =B3some people don=B9t care/need this=B2,= how much will the technical change affect them? If you want to be compliant with 5245bis, you are anyway going to have to do some changes in your code. Regards, Christer On 03/05/16 20:25, "Ice on behalf of Ben Campbell" wrote: >Hi, > >I apologize for the delay. My schedule over the last couple of weeks has >been disrupted by some family issues. I am ramping back up now. > >So, TL;DR: I think the working group needs to have a little more >discussion about the status and purpose of this draft, and how it >relates to ICEBis. More details below. > >On 19 Apr 2016, at 6:37, Pal Martinsen (palmarti) wrote: > >> On 19 Apr 2016, at 08:36, Ben Campbell >> > wrote: >> >> Hi, >> >> This is my AD Evaluation of draft-ietf-ice-dualstack-fairness-02. I >> find the draft readable and understandable, but I have some comments >> and questions. I'd like to resolve the major comments prior to IETF >> last call. >> >> Major: >> >> The draft is now informational, but the milestone is for PS. I see the >> minutes from Prague say the wg agreed to make the change, but that >> doesn't say why, and I failed to find any discussion of that on the >> list. Can anyone remind me of the reasoning? (This interacts with my >> next comment=8A) >> >> Just for clarity I will summarise what I see as the key =B3events=B2 >> of the draft. (I might be wrong so of others see it differently please >> correct me) >> >> - Started as an DualStack Happy Eyeballs solution that would give IPv6 >> a head start. >> - Several attempts to get a happy eyeballs algorithm working failed. >> And we discovered that it would be very difficult to get right in all >> the various scenarios. Think the =B3consensus in the hallways=B2 was >> to let each application deal with it as they would know more of what >> was important to them. >>=20 >>(http://www.ietf.org/proceedings/92/minutes/minutes-92-mmusic#h.v0jtwu5re >>90f) >>=20 >>>90f>-=20 >> Since the draft only contains guidelines on how an application should >> deal with dual-stack it made sense to make it informational. >>=20 >>(http://www.ietf.org/proceedings/93/minutes/minutes-93-mmusic#h.34ilx3y4v >>kbd) > >The right choice here depends on what the working group expects the >draft to accomplish. I think informational works if we want to tell >implementors about some things they can do if they care. If, on the >other hand, we want to actually encourage implementors to implement >this, then I'm not sure informational is the right choice. Did the WG >consider BCP? > >> >> >> >> I am confused about the relationships among this draft, RFC 5245, >> 5245bis, and RFC 6724. Section 1 of this draft seems to say that it >> recommends against following the requirement in 5245 that says dual >> stack hosts SHOULD follow the precedence in 6724. Normally, that would >> require this draft to update 5245, which would require it to be >> standards track. >> >> But on the other hand, I am not entirely convinced anything here >> really changes that SHOULD, since 6724 explicitly says: >> >> "The selection rules specified in this document MUST NOT be construed >> to override an application or upper layer=B9s explicit choice of a >> legal destination or source address." >> >> Unfortunately, I think this puts things in a grey area, due to >> ambiguous wording in 5245. So I think this draft either needs to >> update 5245, or it needs to explain why the guidance here does not >> conflict with that SHOULD. >> >> This was at least discussed in IETF90, >>=20 >>http://www.ietf.org/proceedings/90/minutes/minutes-90-mmusic#h.6fijdpvean >>aa > >That discussion seemed to resolve to "we need to check to see if we are >updating 2119 language" :-) > >> >> So now my naive question is; do we care about 5245 with 5245bis soon >> finished? > >The same language is currently in 5245bis. > >> >> I think we have two possible solutions. >> >> 1. Make dual-stack fairness reference only 5245bis. Make sure text in >> both draft harmonise. They will cross reference each other and thus >> needs to be published at the same time? > >Would you expect ICEBis to normatively reference this? If so, that has >implications about the PS/Informational/BCP decisions. If so, they would >form a cluster in the RFC editor queue. Even if they were submitted at >different times, they would be formally published more or less at the >same time. > > >> >> 2. Explain why we are not braking the 5245 SHOULD and keep it as >> informational . This is done by pointing out the appropriate text you >> found in 6724. > >The current text is misleading, in the way it explicitly says that >following the SHOULD in 5245/5245bis leads to "unfair" prioritization. >As written, it does seem to relax the SHOULD. Language clarifying that >6724 allows application-specific choices would be helpful. > > >> >> And in either case: Is there an opportunity to make 5245 more clear in >> 5245bis? >> >> >> Absolutely. It must also point out that the formulas described in 5245 >> section 4.1.2 have not changes so that the compatibility discussion in >> section 5 of the dual-stack fairness draft is still valid. >> >> >> That of course leads to the bombshell question: We are already in the >> process of updating 5245. Why isn=B9t _this_ draft part of 5245bis? >> >> I think the main motivation for that was to keep the ICEbis spec as >> short as possible as there are some implementations that does not care >> about the problem. For the implementations that do care, they should >> read the draft and follow the recommendations. > >I don't find that all that convincing. ICEbis talks about dual-stack >stuff in several places, and makes that explicit statement about >dual-stack behavior and 6724. A good part of the content of _this_ draft >is spent describing things in ICE/ICEbis for context, and could probably >be significantly reduced. > >One possibility might be to move the procedure parts into ICEBis, and >refer back to this draft for motivation and an explanation of why a >happy eyeballs approach is useful. (Or maybe that could just go into an >appendix of ICEbis.) > >Now, I don't have a strong belief this needs to merge into ICEBis--I >just want to make sure the working group has thought about the option. >In particular, we should consider what makes things easier on the >reader, not just what is easier from an IETF process perspective. > >> >> Minor: >> >> - 1: The introduction jumps right to saying applications need to >> deprioritize interfaces without saying what problem it's trying to >> solve. An initial paragraph that says what goes wrong with current >> implementations would be extremely helpful. It would also help to >> define what is meant by "fairness" in this context. (I=B9m not sure >> it's quite the same as the conventional use of the term.) >> >> How about: >> >> In multihomed and IPv4/IPv6 dual-stack environments ICE [RFC5245] >> would benefit by a fair distribution of its connectivity checks >> across available interfaces or IP address types. With a fair >> distribution of the connectivity checks, excessive delays are >> avoided >> if a particular network path is broken or slow. It would arguable >> be >> better to put the interfaces or address types know to the >> application >> last in the checklist. However, the main motivation by ICE is to >> make no assumptions regarding network topology, hence a fair >> distribution of the connectivity checks is more appropriate. If an >> application operates in a well-known environment is can safely >> override the recommendation given in this document. > >That helps, but I still don't see s definition of what you mean by "fair >distribution". > >> >> >> - 2: Assuming this stays informational, it's not really using the 2119 >> keywords quite in the spirit of 2119. Personally, I don't think the >> current 2119 usage (outside of text directly attributed to other >> documents, which doesn't really count) adds much. I suggest removing >> it. >> >> But if people are really attached to using 2119 language here, please >> consider adjusting the boilerplate to say that, while this draft does >> not include normative requirements, the keywords are used for the sake >> of clarity. >> >> >> Agree. Removed from draft. And all capital SHOULD occurrences replaced >> with should. > >That works for me, assuming people choose to keep this as an >informational. > >> >> -3, 2nd paragraph: >> >> Does the working group believe that one can make reasonable inferences >> from just the network type? Do you expect these to be configurable? >> Statically defined in code? (Seems like there may be operational >> considerations here.) >> >> The original intent with the text was to say; =B3If you think you know >> better, please feel free to do as you please=8A=B2. But basing it just >> on network type seems to be a bit to fragile. >> >> Updated text: >> The application knowledge regarding the reliability of an interface >> can also be based on simple metrics like previous connection >> success/ >> failure rates or a more static model based on interface types like >> wired, wireless, cellular, virtual, tunneled in conjunction with >> other operational metrics. This would require the application to >> have the right permissions to obtain such operational metrics. > >That helps, thanks. > >> >> >> - 7.2: Can this be more specific about what implementations exist? The >> boilerplate seems a bit heaviweight for something that pretty much >> says =B3there are others" :-) >> >> >> The section has been in and out. Main use is to inform WG and AD that >> there are others? Others have confirmed during WG meetings that they >> do things similar to what is described in the draft (But sometimes >> they have more operational knowledge and are able to override things >> in the draft). >> >> Safe to remove this section now? > >This sort of thing usually comes out at publication time, so it's >probably fine for now. > >> >> >> Editorial: >> >> - 4 , first paragraph: How long is long? (Especially if you stick the >> 2119 SHOULD). >> >> I think long can be dropped. IMHO intermingling of the address types >> is a good thing if you want to be topology agnostic. >> The paragraph still have =B3values=B2 like many and small. I think >> that is ok? >> >> New paragraph: >> Candidates should be prioritized such that a sequence of candidates >> belonging to the same address family will be intermingled with >> candidates from an alternate IP family. For example, promoting >> IPv4 >> candidates in the presence of many IPv6 candidates such that an >> IPv4 >> address candidate is always present after a small sequence of IPv6 >> candidates, i.e., reordering candidates such that both IPv6 and >> IPv4 >> candidates get a fair chance during the connectivity check phase. >> This makes ICE connectivity checks more responsive to broken path >> failures of an address family. > >WFM. > >> >> - 5, last paragraph: Doesn=B9t this belong in the "Implementation >> Status" section? >> >> The intent was to guide implementers to sample code. If that is moved >> to Implementation Status that information will be lost when published >> as an RFC. >> >> Previous versions had an appendix with the code examples. The WG felt >> that that was a to strong encouragement to implement a specific >> solution, this was something the WG did not want to do. Hence the >> informational status of the draft. >> >> I am fine with removing it. > >I don't necessarily object to keeping it, but keep in mind that RFCs >live forever, and code repositories might not. > >> >> >> - 7.1 and 7.2 titles: s/Starck/Stack >> >> Gahh.. Fixed even if removed later.. >> >> - 7.1, "Level of Maturity": Are there words missing around "Tests"? >> >> Cut and paste error. >> >> >> >> Do you want me to post a new version of the draft with the changes. We >> still need to resolve the 5245, 5245bis and 6724 problem. Simple >> enough once we agree. > >Revisions are cheap :-) I'd suggest updating with the known changes now, >then dealing wtih the other stuff when we can. > >Thanks! > >Ben. > >_______________________________________________ >Ice mailing list >Ice@ietf.org >https://www.ietf.org/mailman/listinfo/ice From nobody Fri May 20 06:52:50 2016 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 7203912D982 for ; Fri, 20 May 2016 06:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 yMtTjUaf2cGN for ; Fri, 20 May 2016 06:52:45 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 E21DC12D97B for ; Fri, 20 May 2016 06:52:44 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id p64so55002703ioi.2 for ; Fri, 20 May 2016 06:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=HOTfo17OVR2RMlVUAshfea9FG+y65IK/8oG9B+v+JIU=; b=bH+yAUQ3c66R6iJemPZHZOry7hnm1H3XChMOVUkBg3Xfyy9x80QVB4mt3b18Npv2ku KvSE7CtYiUQ8JlM2et4RV+xTR+zSwP0XRoslClGd/6rZ4hpGvqROMuS66lu2JtV2Vuaj UFm83rZRQQZPGNWYGQeC9m9M4wWG5lCgLS4R6grammlcPMOl+IbYNI9rc3xple4AJSUP nOf08VI3/5LaF6uds9GOafAPMvQgGJePLt5qGZU3EfyNLtHWC0gHH5bTLACI+2aCiXHa +UJNuZ1cM2AZPzgfk/Il7L1g8sHKHyUVGeyKSmNGRHvlrMS1Nnc8eRF04wA8VWRtJdKq nkIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=HOTfo17OVR2RMlVUAshfea9FG+y65IK/8oG9B+v+JIU=; b=RnilQUa9klKhedAXJ1Qjn0pxtshRQD0zUdeNYhUwGOHT/j9pt3QfcvWAmHtzKtdf3/ tOYMjeeT7yJQpvMG/2B+mVhThlQ+4m2jRYiFZdfDy3tlJoPKanDGN+21s2VGAyOTvoVT xWyLix8b7WUXSSNCI5JO+xjIZQiwV6Qd5aTysT0Tuk32/FdlP9qNvaTReKUNvr5wMgW5 mTtpvxnz/YZz8GR9Lv03dAt67XaLLp3Q53M4ULyAjMPq0qOx3zXZKIhy+Yghh7uVykvj aqKrqLkH3+oWYg70tsN2nJfh1i3gCnWk0TycE2i0TMHjbhfGCOOJ0IUIRcBE0hDAmjwI 6zTA== X-Gm-Message-State: AOPr4FVrMECNiudQbp/5ELmxg8YA8TAMxRyz4HCS8otVW7njoMsM8On3kgHDjcX/8yOZJg== X-Received: by 10.107.35.131 with SMTP id j125mr2308969ioj.24.1463752364176; Fri, 20 May 2016 06:52:44 -0700 (PDT) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id j124sm1425678ita.8.2016.05.20.06.52.43 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 May 2016 06:52:43 -0700 (PDT) Received: by mail-io0-f174.google.com with SMTP id 190so146368618iow.1 for ; Fri, 20 May 2016 06:52:43 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.36.155.132 with SMTP id o126mr3048070itd.95.1463752362949; Fri, 20 May 2016 06:52:42 -0700 (PDT) Received: by 10.36.144.69 with HTTP; Fri, 20 May 2016 06:52:42 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B37F93800@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F93B6F@ESESSMB209.ericsson.se> Date: Fri, 20 May 2016 09:52:42 -0400 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Christer Holmberg Content-Type: multipart/alternative; boundary=94eb2c05d158a209bd0533466791 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 13:52:48 -0000 --94eb2c05d158a209bd0533466791 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How about naming it "simple"? This would be shorter and easier to read. _____________ Roman Shpount On Fri, May 20, 2016 at 6:15 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > I have received no further suggestions, so I guess we can call it > =E2=80=9Csimplified=E2=80=9D. > > Regards, > > Christer > > From: Ice on behalf of Christer Holmberg < > christer.holmberg@ericsson.com> > Date: Wednesday 4 May 2016 at 22:49 > To: Roman Shpount > Cc: "ice@ietf.org" > Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from > using aggressive nomination > > Hi, > > I was thinking of "bus" too. But, it's a temporary working name. And, wha= t > about the next time we make a bis? :) > > Regards, > > Christer > > Sent from my Windows Phone > ------------------------------ > From: Roman Shpount > Sent: 04/05/2016 19:48 > To: Christer Holmberg > Cc: ice@ietf.org > Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from > using aggressive nomination > > I agree and would suggest option name ice-bis. > > _____________ > Roman Shpount > > On Wed, May 4, 2016 at 11:51 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> Hi, >> >> >> >> As agreed in Buenos Aires, 5245bis endpoints will not use aggressive >> nomination, and we also agreed to define a new ICE option to be used by >> 5245 endpoints in order to prevent legacy peers from using aggressive >> nomination (as legacy peers would not support the ICE option, they are >> expected not to use aggressive nomination). >> >> >> >> However, defining a dummy ICE option just to prevent legacy peers from >> using aggressive nomination would not be good protocol design, in my >> opinion. >> >> >> >> Also, scoping the ICE option to nomination may not be smart either. In m= y >> opinion the ICE option should indicate that the endpoint is compliant wi= th >> 5245bis in general. >> >> >> >> Do people agree with that? >> >> >> >> If so, do you have suggestions for the ICE option name? :) >> >> >> >> Regards, >> >> >> >> Christer >> >> >> >> >> >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice >> >> > --94eb2c05d158a209bd0533466791 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How about naming it "simple"? This would be shor= ter and easier to read.

<= div>
_____________
Roman Shpount

On Fri, May 20, 2016 at 6:15 AM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>
I have received no further suggestions, so I guess we can call it =E2= =80=9Csimplified=E2=80=9D.

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf= of Christer Holmberg <christer.holmberg@ericsson.com>
Date: Wednesday 4 May 2016 at 22:49=
To: Roman Shpount <roman@telurix.com>
Cc: "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] 5245bis: New ICE= option to prevent legacy peers from using aggressive nomination

Hi,

I was thinking of "bus" too. But, it's a temporary working na= me. And, what about the next time we make a bis? :)

Regards,

Christer

Sent from my Windows Phone
From: Roman Shpount Sent: 04/05/= 2016 19:48
To: Christer Holm= berg
Cc: ice@ietf.org
Subject: Re: [I= ce] 5245bis: New ICE option to prevent legacy peers from using aggressive n= omination

I agree and would suggest option name ice-bis.

_____________
Roman Shpount

On Wed, May 4, 2016 at 11:51 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

As agreed in Buenos Aires, 5245bis endpoints will no= t use aggressive nomination, and we also agreed to define a new ICE option = to be used by 5245 endpoints in order to prevent legacy peers from using ag= gressive nomination (as legacy peers would not support the ICE option, they are expected not to use aggressive = nomination).

=C2=A0

However, defining a dummy ICE option just to prevent= legacy peers from using aggressive nomination would not be good protocol d= esign, in my opinion.

=C2=A0

Also, scoping the ICE option to nomination may not b= e smart either. In my opinion the ICE option should indicate that the endpo= int is compliant with 5245bis in general.

=C2=A0

Do people agree with that?

=C2=A0

If so, do you have suggestions for the ICE option na= me? :)

=C2=A0

Regards,=

=C2=A0

Christer

=C2=A0

=C2=A0


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

--94eb2c05d158a209bd0533466791-- From nobody Fri May 20 06:57:17 2016 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 8B0D812D15D for ; Fri, 20 May 2016 06:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 0e1bX2WGTsat for ; Fri, 20 May 2016 06:57:13 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213EC12D0E1 for ; Fri, 20 May 2016 06:57:12 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-d0-573f17b7e4a1 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EC.16.12926.7B71F375; Fri, 20 May 2016 15:57:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Fri, 20 May 2016 15:56:21 +0200 From: Christer Holmberg To: Roman Shpount Thread-Topic: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination Thread-Index: AdGmHG6bJo539xyvSt+nU2XdpYsl7///7zEAgABUI0SAGJY7AIAACc4AgAAiiww= Date: Fri, 20 May 2016 13:56:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37FDD406@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37F93800@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F93B6F@ESESSMB209.ericsson.se> , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37FDD406ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbHdVXe7uH24wdoD8hbfLtRazLgwldmB yWPJkp9MHremFAQwRXHZpKTmZJalFunbJXBlNE08zFJwOrxizYH7TA2Mvb5djBwcEgImEueO 5nQxcgKZYhIX7q1n62Lk4hASOMIo0dN2nxnCWcIo0fv8OhtIA5uAhUT3P22QBhEBVYm/3ycz gYSZBRQlXu5VAwkLC6RKvL/WA1YtIpAmsX5hDITpJzH5EwdIBQtQY8vtjWAVvAK+Eq8/ikHs OccksW7BRiaQGk6BQIm2/jNsIDYj0GXfT60BizMLiEs0fVnJCnGxgMSSPeeZIWxRiZeP/7FC 1ORLLL02GyzOKyAocXLmE5YJjCKzkLTPQlI2C0kZRNxA4sv721C2tsSyha+ZIWx9ie73p5mQ xRcwsq9iFC1OLU7KTTcy1kstykwuLs7P08tLLdnECIylg1t+q+5gvPzG8RCjAAejEg/vgny7 cCHWxLLiytxDjBIczEoivIJi9uFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEef1fKoYLCaQnlqRm p6YWpBbBZJk4OKUaGPM/Pa8IW2/y71rUq5tLS2bazlT7eNNqk5vJe75/K//2/rm06drD5eZ2 Jm/W9ThGTxLMETP/dHLu7PT3R8QdtJoTf/87WLBxTUwq+wz2k937Ju15nlDgMz/v4Zd79xR/ /cjM1K0zz3m3Y9K1i9J59ULsqWxzj3B+mPDbqnsxa5du+LMQ7xnNP9mUWIozEg21mIuKEwED OZgyoQIAAA== Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 13:57:15 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37FDD406ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable WFM. Regards, Christer Sent from my Windows Phone ________________________________ From: Roman Shpount Sent: =FD20/=FD05/=FD2016 16:52 To: Christer Holmberg Cc: ice@ietf.org Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from usi= ng aggressive nomination How about naming it "simple"? This would be shorter and easier to read. _____________ Roman Shpount On Fri, May 20, 2016 at 6:15 AM, Christer Holmberg > wrote: I have received no further suggestions, so I guess we can call it =93simpli= fied=94. Regards, Christer From: Ice > on behalf of = Christer Holmberg > Date: Wednesday 4 May 2016 at 22:49 To: Roman Shpount > Cc: "ice@ietf.org" > Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from usi= ng aggressive nomination Hi, I was thinking of "bus" too. But, it's a temporary working name. And, what = about the next time we make a bis? :) Regards, Christer Sent from my Windows Phone ________________________________ From: Roman Shpount Sent: 04/05/2016 19:48 To: Christer Holmberg Cc: ice@ietf.org Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from usi= ng aggressive nomination I agree and would suggest option name ice-bis. _____________ Roman Shpount On Wed, May 4, 2016 at 11:51 AM, Christer Holmberg > wrote: Hi, As agreed in Buenos Aires, 5245bis endpoints will not use aggressive nomina= tion, and we also agreed to define a new ICE option to be used by 5245 endp= oints in order to prevent legacy peers from using aggressive nomination (as= legacy peers would not support the ICE option, they are expected not to us= e aggressive nomination). However, defining a dummy ICE option just to prevent legacy peers from usin= g aggressive nomination would not be good protocol design, in my opinion. Also, scoping the ICE option to nomination may not be smart either. In my o= pinion the ICE option should indicate that the endpoint is compliant with 5= 245bis in general. Do people agree with that? If so, do you have suggestions for the ICE option name? :) Regards, Christer _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice --_000_7594FB04B1934943A5C02806D1A2204B37FDD406ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
WFM.

Regards,

Christer

Sent from my Windows Phone
From: Roman Shpount
Sent: =FD20= /=FD05/=FD2016 16:52
To: Christer Holmberg Cc: ice@ietf.org
Subject: Re: [= Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive = nomination

How about naming it "simple"? This would be shor= ter and easier to read.

_____________
Roman Shpount

On Fri, May 20, 2016 at 6:15 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:
I have received no further suggestions, so I guess we can call it =93s= implified=94.

Regards,

Christer

From: Ice <ice-bounces@ietf.org> on behalf= of Christer Holmberg <christer.holmberg@ericsson.com>
Date: Wednesday 4 May 2016 at 22:49=
To: Roman Shpount <roman@telurix.com>
Cc: "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] 5245bis: New ICE= option to prevent legacy peers from using aggressive nomination

Hi,

I was thinking of "bus" too. But, it's a temporary working name. = And, what about the next time we make a bis? :)

Regards,

Christer

Sent from my Windows Phone
From: Roman Shpount<= br> Sent: 04/05= /2016 19:48
To: Christer Hol= mberg
Cc: ice@ietf.org
Subject: Re: [= Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive = nomination

I agree and would suggest option name ice-bis.

_____________
Roman Shpount

On Wed, May 4, 2016 at 11:51 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi,

 

As agreed in Buenos Aires, 5245bis endpoints will no= t use aggressive nomination, and we also agreed to define a new ICE option = to be used by 5245 endpoints in order to prevent legacy peers from using ag= gressive nomination (as legacy peers would not support the ICE option, they are expected not to use aggressive = nomination).

 

However, defining a dummy ICE option just to prevent= legacy peers from using aggressive nomination would not be good protocol d= esign, in my opinion.

 

Also, scoping the ICE option to nomination may not b= e smart either. In my opinion the ICE option should indicate that the endpo= int is compliant with 5245bis in general.

 

Do people agree with that?

 

If so, do you have suggestions for the ICE option na= me? :)

 

Regards,=

 

Christer

 

 


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



--_000_7594FB04B1934943A5C02806D1A2204B37FDD406ESESSMB209erics_-- From nobody Fri May 20 09:17:07 2016 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 4FC1412D521 for ; Fri, 20 May 2016 09:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.866 X-Spam-Level: X-Spam-Status: No, score=-3.866 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] 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 Uyzkp1cvSXoR for ; Fri, 20 May 2016 09:17:03 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 99D5512DD43 for ; Fri, 20 May 2016 09:16:59 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id g133so113813688ywb.2 for ; Fri, 20 May 2016 09:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=pBZzBnrUL6lw8Gj1VLjMR0NdBdshRdaHlI2SfPDHw7c=; b=hlT+BgKelgbxyY9upJr9Bdm7LYma/ZsOvfF9TECD5yPqMZPmPJOkmdrU0scdJzXrLy zMpfRill2qim5rEpvnK93Flk18HvLlQjslIww6nvR2WDnmhDmsEJgZWAHVeNXVObIsV+ SU9aDH5K6ycF/gZKJBXgJclngkmE0JXja/x2yGpn9kPuEsghzZ5i8W812NLA0QtkKqa5 VMcc9Lo6qCHyTdMHOn8Ni/qmSA3R2z/ewfGX6lbpybXdldBKMsoVv7kFg9APNwtaJ0OJ B0VVQz1FTa1MWOeptDw66+TxEoWmIgaNok3WyA54uRu9k+sCNpcdePBmG+fUmGgPRzZ/ cCcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pBZzBnrUL6lw8Gj1VLjMR0NdBdshRdaHlI2SfPDHw7c=; b=ONaOodGwJJ9hHoKg0M/vbkZcJYFkmTGDpUTc868WBJP7zCSB3WG9fB38WbIDoY6I1L 2CP4AVILirJ6X/6eS49hXs9gGwjRAAuh6A9cgzD4yA/v6cWCx54nCGkrRcXUFVhgvI78 +rrm8cpHcXetYk3uLUgn8XYp0psTGe506/5K28xpHi0oS1MGOTuAuSPoh/GGPRA3c3Zj 1BQPRfZa7QrFM6V1EcBgC7VmFnosicSNvtZZFjUpnmt+BUETNuF2ugTgTkrWRjb+3dlp JiIKPMgCkWBV/2h8PYrph6MbE20Pxp64pGoBBzHFvcphzxEMNtKaX7ZCF5C+5r2ehsOc gJ5A== X-Gm-Message-State: AOPr4FWN2/30fhVTvB2AJpWm0fVcCL50I8vLk0vaANJCqdbumQcE4PDyBE9QUEGAzOa8RjbuGYF6lJ13SzBcPZVe X-Received: by 10.37.66.129 with SMTP id p123mr2426233yba.77.1463761018403; Fri, 20 May 2016 09:16:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.233.194 with HTTP; Fri, 20 May 2016 09:16:57 -0700 (PDT) From: Taylor Brandstetter Date: Fri, 20 May 2016 09:16:57 -0700 Message-ID: To: ice@ietf.org Content-Type: multipart/alternative; boundary=001a11c069ee8a4eb60533486ba5 Archived-At: Subject: [Ice] Issues related to ICE role switching and conflicts X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 16:17:06 -0000 --001a11c069ee8a4eb60533486ba5 Content-Type: text/plain; charset=UTF-8 While investigating a WebRTC issue related to ICE role conflicts, I noticed what seem to be some minor oddities with the rules surrounding ICE role determination. I'd like to hear what people think about these issues, and find out if I'm overlooking any motivations for the current rules. 1. Section 5.1.2, Determining Role states "An ICE restart causes a new selection of roles and tiebreakers". The only time this is necessary, as far as I can tell, is when an agent is changing its implementation level (such as "full -> lite") and one agent *needs* to take up the controlling role. So it would be ideal if this was the only situation that caused new role selection. Otherwise, in a third-party call control use case that resulted in a role conflict initially, *every* ICE restart will probably result in another role conflict, as the agents re-select their initial conflicting roles. Also, what happens if ICE is restarting for only one media stream and the role changes according to this rule? From the perspective of the non-restarting media streams, the role would be switching in the middle of ICE processing. 2. Also, why select a new tiebreaker? I don't see any real issue with this, but it seems pointless. 3. There's nothing that says "when changing implementation level, you MUST restart ICE for *all* media streams". This requirement existed in draft 13 of ICE, but then there was a bunch of restructuring and I think it may have been removed accidentally. Regardless, I believe this condition should be added back, because changing implementation level in the middle of ICE processing for a media stream doesn't make much sense. 4. Section 6.1.3.1, Failure Cases states that when receiving a "role conflict" error response, "the agent MUST switch to the (controlling|controlled) role if it has not already done so". The condition "if it has not already done so", if interpreted literally, means that the agent can only switch to a role once. I don't think this was the intention, so the condition can probably be removed. It's worth noting that this condition doesn't exist in Section 6.2.1.1, Detecting and Repairing Role Conflicts. 5. Starting to really stretch here, but in the rare situation where there's a role conflict and the tie-breakers are equal, the peers could continue flipping between roles ad infinitum. Why not just generate a new tie-breaker? I saw that this was once brought up on the MMUSIC mailing list but I couldn't find a response. If there's general agreement about these points, I'll happily write some pull requests for ICEbis. --001a11c069ee8a4eb60533486ba5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
While investigating a WebRTC issue related to ICE role con= flicts, I noticed what seem to be some minor oddities with the rules surrou= nding ICE role determination. I'd like to hear what people think about = these issues, and find out if I'm overlooking any motivations for the c= urrent rules.
  1. Section 5.1.2, Determining Role states "An I= CE restart causes a new selection of roles and tiebreakers". The only = time this is necessary, as far as I can tell, is when an agent is changing = its implementation level (such as "full -> lite") and one agen= t needs=C2=A0to take up the controlling role.=C2=A0So it would be id= eal if this was the only situation that caused new role selection. Otherwis= e, in a third-party call control use case that resulted in a role conflict = initially, every=C2=A0ICE restart will probably result in another ro= le conflict, as the agents re-select their initial conflicting roles. Also,= what happens if ICE is restarting for only one media stream and the role c= hanges according to this rule? From the perspective of the non-restarting m= edia streams, the role would be switching in the middle of ICE processing.<= /li>
  2. Also, why select a new tiebreaker? I don't see any real issue w= ith this, but it seems pointless.
  3. There's nothing that says &qu= ot;when changing implementation level, you MUST restart ICE for all = media streams". This requirement existed in draft 13 of ICE, but then = there was a bunch of restructuring and I think it may have been removed acc= identally. Regardless, I believe this condition should be added back, becau= se changing implementation level in the middle of ICE processing for a medi= a stream doesn't make much sense.
  4. Section 6.1.3.1, Failure Case= s states that when receiving a "role conflict" error response, &q= uot;the agent MUST switch to the (controlling|controlled) role if it has no= t already done so". The condition "if it has not already done so&= quot;, if interpreted literally, means that the agent can only switch to a = role once. I don't think this was the intention, so the condition can p= robably be removed. It's worth noting that this condition doesn't e= xist in Section 6.2.1.1, Detecting and Repairing Role Conflicts.
  5. St= arting to really stretch here, but in the rare situation where there's = a role conflict and the tie-breakers are equal, the peers could continue fl= ipping between roles ad infinitum. Why not just generate a new tie-breaker?= I saw that this was once brought up on the MMUSIC mailing list but I could= n't find a response.
If there's general agreement abo= ut these points, I'll happily write some pull requests for ICEbis.
--001a11c069ee8a4eb60533486ba5-- From nobody Sun May 22 06:48:31 2016 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 ECEDF12B01F for ; Sun, 22 May 2016 06:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 C0DKyXFtp8Nr for ; Sun, 22 May 2016 06:48:28 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CDE512D0C8 for ; Sun, 22 May 2016 06:48:26 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-3a-5741b8a8fad8 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8A.5B.27088.8A8B1475; Sun, 22 May 2016 15:48:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0294.000; Sun, 22 May 2016 15:47:41 +0200 From: Christer Holmberg To: Christer Holmberg , Roman Shpount Thread-Topic: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination Thread-Index: AdGmHG6bJo539xyvSt+nU2XdpYsl7///7zEAgABUI0SAGJY7AIAACc4AgAAiiwz//N3yEA== Date: Sun, 22 May 2016 13:47:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37FDF11D@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37F93800@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37F93B6F@ESESSMB209.ericsson.se> , <7594FB04B1934943A5C02806D1A2204B37FDD406@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37FDD406@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37FDF11DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7uu7KHY7hBh+62S2+Xai1mHFhKrMD k8eSJT+ZPG5NKQhgiuKySUnNySxLLdK3S+DKOHiujb3g+zzGivlb5rE0MD7oZ+xi5OSQEDCR +HRzEyuELSZx4d56ti5GLg4hgSOMEj/PP2KCcJYwSrzc9JG9i5GDg03AQqL7nzZIg4hAtMSH DwuYQMLMAooSL/eqgYSFBVIl3l/rYQMJiwikSaxfGANRHSbx5h/EEBYBVYmna91BwrwCvhLX N61ih1g0lVli0rmTrCA1nAJ+Es0vdEBqGIEu+35qDROIzSwgLnHryXwmiIsFJJbsOc8MYYtK vHz8D+oTJYnGJU9YIerzJdZ8bmGG2CUocXLmE5YJjKKzkIyahaRsFpIyiLiBxLntG9khbG2J ZQtfM0PY+hLbb89kRRZfwMi+ilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMw0g5u+W2wg/Hl c8dDjAIcjEo8vAuEHMOFWBPLiitzDzFKcDArifC+2gAU4k1JrKxKLcqPLyrNSS0+xCjNwaIk zuv/UjFcSCA9sSQ1OzW1ILUIJsvEwSnVwKit8u7PBL+Zu7eeX7TmYp174R6H/xKq6xTvzvvt H1+Qdbp1Q/q7NuO7Uzj2C2+vWJMw4VbGx4qs6Dl+mwKK9e8Zu/gHFEROS9ERXK/Av7l2TUKA /mTRnnfrv9s85tpg+1Rua+9VkaWh9yq/iMWIGYoHv7ye7R/ysuhu4QedC2Kc2xwP77l8wUCJ pTgj0VCLuag4EQCmTY2fsAIAAA== Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 13:48:30 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37FDF11DESESSMB209erics_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, Another question is whether we can define the ICE option in 5245bis, or whe= ther it should be defined somewhere else. The whole ICE option concept has = moved to draft-ice-sip-sdp, so=85 Regards, Christer From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 20 May 2016 16:56 To: Roman Shpount Cc: ice@ietf.org Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from usi= ng aggressive nomination WFM. Regards, Christer Sent from my Windows Phone ________________________________ From: Roman Shpount Sent: =FD20/=FD05/=FD2016 16:52 To: Christer Holmberg Cc: ice@ietf.org Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from usi= ng aggressive nomination How about naming it "simple"? This would be shorter and easier to read. _____________ Roman Shpount On Fri, May 20, 2016 at 6:15 AM, Christer Holmberg > wrote: I have received no further suggestions, so I guess we can call it =93simpli= fied=94. Regards, Christer From: Ice > on behalf of = Christer Holmberg > Date: Wednesday 4 May 2016 at 22:49 To: Roman Shpount > Cc: "ice@ietf.org" > Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from usi= ng aggressive nomination Hi, I was thinking of "bus" too. But, it's a temporary working name. And, what = about the next time we make a bis? :) Regards, Christer Sent from my Windows Phone ________________________________ From: Roman Shpount Sent: 04/05/2016 19:48 To: Christer Holmberg Cc: ice@ietf.org Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from usi= ng aggressive nomination I agree and would suggest option name ice-bis. _____________ Roman Shpount On Wed, May 4, 2016 at 11:51 AM, Christer Holmberg > wrote: Hi, As agreed in Buenos Aires, 5245bis endpoints will not use aggressive nomina= tion, and we also agreed to define a new ICE option to be used by 5245 endp= oints in order to prevent legacy peers from using aggressive nomination (as= legacy peers would not support the ICE option, they are expected not to us= e aggressive nomination). However, defining a dummy ICE option just to prevent legacy peers from usin= g aggressive nomination would not be good protocol design, in my opinion. Also, scoping the ICE option to nomination may not be smart either. In my o= pinion the ICE option should indicate that the endpoint is compliant with 5= 245bis in general. Do people agree with that? If so, do you have suggestions for the ICE option name? :) Regards, Christer _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice --_000_7594FB04B1934943A5C02806D1A2204B37FDF11DESESSMB209erics_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

Another qu= estion is whether we can define the ICE option in 5245bis, or whether it sh= ould be defined somewhere else. The whole ICE option concept has moved to draft-ice-sip-sdp, so=85

 = ;

Regards,

 = ;

Christer

 

From: = Ice [mailto:ice-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 20 May 2016 16:56
To: Roman Shpount <roman@telurix.com>
Cc: ice@ietf.org
Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers f= rom using aggressive nomination

 

WFM.

Regards,

Christer

Sent from my Windows Phone

From: Roman Shpount Sent: =FD20/=FD05/=FD2016 16:52
To: Chris= ter Holmberg
Cc: ice@ietf.org=
Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from using a= ggressive nomination

How about naming it "simple"? This would b= e shorter and easier to read.


_____________
Roman Shpount

 

On Fri, May 20, 2016 at 6:15 AM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

I have received no further suggestions,= so I guess we can call it =93simplified=94.

 

Regards,

 

Christer

 

From: Ice <ice-bounces@ietf.org> on behalf of Christer Holmberg = <chr= ister.holmberg@ericsson.com>
Date: Wednesday 4 May 2016 at 22:49
To: Roman Shpount <roman@telurix.com>
Cc: "ice@ietf= .org" <ice@ie= tf.org>
Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers f= rom using aggressive nomination

 

Hi,

I was thinking of "bus" too. But, it's a temporary working name. = And, what about the next time we make a bis? :)

Regards,

Christer

Sent from my Windows Phone

From: Roman Shpount
Sent: 04/05/2016 19:48
To: Christer Holmberg
Cc: i= ce@ietf.org
Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy= peers from using aggressive nomination

I agree and would suggest option name i= ce-bis.


_____________
Roman Shpount

 

On Wed, May 4, 2016 at 11:51 AM, Christ= er Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

 

As agreed in Buenos Aires, 5245bis end= points will not use aggressive nomination, and we also agreed to define a n= ew ICE option to be used by 5245 endpoints in order to prevent legacy peers from using aggressive nomination (as lega= cy peers would not support the ICE option, they are expected not to use agg= ressive nomination).

 

However, defining a dummy ICE option j= ust to prevent legacy peers from using aggressive nomination would not be g= ood protocol design, in my opinion.

 

Also, scoping the ICE option to nomina= tion may not be smart either. In my opinion the ICE option should indicate = that the endpoint is compliant with 5245bis in general.

 

Do people agree with that?<= /span>

 

If so, do you have suggestions for the= ICE option name? :)

 

Regards,

 

Christer

 

 


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

 

 

--_000_7594FB04B1934943A5C02806D1A2204B37FDF11DESESSMB209erics_-- From nobody Sun May 22 09:48:36 2016 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 D3D3812D12F for ; Sun, 22 May 2016 09:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_UKyyMl5Bdu for ; Sun, 22 May 2016 09:48:33 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::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 DC89412D10B for ; Sun, 22 May 2016 09:48:31 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id r140so19806293vkf.0 for ; Sun, 22 May 2016 09:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EHwL5pIxdieVwIsU0hp4oP+Zr6pXSEBMlkgxv5rFQnY=; b=QhofYV3dikcCVRrvH97uzFNdq0Ju+nl5ObdeUrkvTF1dV7mk14gjWDwqRqiXrLm5+N iDnps1CzGCQTM+n+r0TPLeXfbQKc5KMgzQBC/mUZqybqiTUBhGIGXmds1cw+0U52Ycbo p8S58myE+BrZA86VHAXppokWdPc6IiKcB+42cPZTNWVCUmC1xEoKSRDIbFzz5pD+Fx4Z KZZCdoj0+OAgzeE2CpnGX0wIObZ+IAbWhTshPlMWyLXtBihJfoAHGWEJlpiU6dGQBLv4 rkPEIxDujqz3eiAiqLhZRsgSzh6GkHfSDcl7GnVfb6cdbKsZ+Ot3c+uveYzPtgQ5YopJ e5bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EHwL5pIxdieVwIsU0hp4oP+Zr6pXSEBMlkgxv5rFQnY=; b=lp6SzjKbuDCWg/wuFASkJZnCPqhtUIMSINjtINRVACCuISSMN5YnrUW6N2UUpqxQc2 CIpifyz2WOBln681PBSNmrPTg4Puj57lFSoG6tUmZ1+4hpNo4tX25eKOqOxW2SnJbK30 SiR0jpA5XLOkK8naUMaatv5E6+7d4xgqfoeLxiOrDaG544MQevhkCS6aR+TgHnHi3f07 r26NqetuE0mPYGCL28Vi1jOnjwx2LtkU6hB6BgkHgW4ErOu0026zXXKRqHVHRx8Cpze0 qZtkXqy35Cx6hPru8Vh17y/zJTefrbxtTQ0SPsVnf901TjULr98g2pUsqBFFBbuXNurI abJw== X-Gm-Message-State: ALyK8tLFP2aLFAfK9xhwk8GLb8xej2rXkpmTP85gZF/rCzypnX2oOrFhXrsbPtyR19KrVKmginrfM6+TZbvwYw== X-Received: by 10.31.137.68 with SMTP id l65mr3566075vkd.103.1463935710785; Sun, 22 May 2016 09:48:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.40 with HTTP; Sun, 22 May 2016 09:48:11 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37F93800@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37F93800@ESESSMB209.ericsson.se> From: Bernard Aboba Date: Sun, 22 May 2016 09:48:11 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1144165603f6fb05337118f6 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 16:48:35 -0000 --001a1144165603f6fb05337118f6 Content-Type: text/plain; charset=UTF-8 Christer said: "As agreed in Buenos Aires, 5245bis endpoints will not use aggressive nomination, and we also agreed to define a new ICE option to be used by 5245 endpoints" [BA] Don't you mean "used by RFC 5245bis endpoints?" RFC 5245 endpoints cannot be expected to implement or understand new ICE options - they are the legacy implementations here. "in order to prevent legacy peers from using aggressive nomination (as legacy peers would not support the ICE option, they are expected not to use aggressive nomination)." [BA] Legacy peers implementing RFC 5245 won't understand the new ICE option, so their behavior will be unmodified. If a legacy implementation is inclined to do aggressive nomination, the new ICE option won't change that. What *is* possible is for an RFC 5245bis implementation to negotiate with another RFC 5245bis implementation to not use aggressive nomination. However, since the new ICE option will be ignored by a legacy peer, the RFC 5245bis implementation will need to be prepared to handle aggressive nomination by the legacy peer. On Wed, May 4, 2016 at 8:51 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > As agreed in Buenos Aires, 5245bis endpoints will not use aggressive > nomination, and we also agreed to define a new ICE option to be used by > 5245 endpoints in order to prevent legacy peers from using aggressive > nomination (as legacy peers would not support the ICE option, they are > expected not to use aggressive nomination). > > > > However, defining a dummy ICE option just to prevent legacy peers from > using aggressive nomination would not be good protocol design, in my > opinion. > > > > Also, scoping the ICE option to nomination may not be smart either. In my > opinion the ICE option should indicate that the endpoint is compliant with > 5245bis in general. > > > > Do people agree with that? > > > > If so, do you have suggestions for the ICE option name? :) > > > > Regards, > > > > Christer > > > > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --001a1144165603f6fb05337118f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Christer said:=C2=A0
"As agreed in Buenos Aires, 5245bis = endpoints will not use aggressive nomination, and we also agreed to define = a new ICE option to be used by 5245 endpoints"

= [BA] Don't you mean "used by RFC 5245bis endpoints?" =C2=A0RF= C 5245 endpoints cannot be expected to implement or understand new ICE opti= ons - they are the legacy implementations here.=C2=A0

<= /div>
"in order to prevent legacy peers from using aggressive nomination (= as legacy peers would not support the ICE option, they are expected not to = use aggressive nomination)."

[BA= ] Legacy peers implementing RFC 5245 won't understand the new ICE optio= n, so their behavior will be unmodified.=C2=A0 If a legacy implementation i= s inclined to do aggressive nomination, the new ICE option won't change= that. =C2=A0

What *is* poss= ible is for an RFC 5245bis implementation to negotiate with another RFC 524= 5bis implementation to not use aggressive nomination.=C2=A0 However, since = the new ICE option will be ignored by a legacy peer, =C2=A0the RFC 5245bis = implementation will need to be prepared to handle aggressive nomination by = the legacy peer.=C2=A0
=
On Wed, May 4, 2016 at 8:51 AM, Christer Hol= mberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

As agreed in Buenos Aires, 5245bis endpoints will no= t use aggressive nomination, and we also agreed to define a new ICE option = to be used by 5245 endpoints in order to prevent legacy peers from using ag= gressive nomination (as legacy peers would not support the ICE option, they are expected not to use aggressive = nomination).

=C2=A0

However, defining a dummy ICE option just to prevent= legacy peers from using aggressive nomination would not be good protocol d= esign, in my opinion.

=C2=A0

Also, scoping the ICE option to nomination may not b= e smart either. In my opinion the ICE option should indicate that the endpo= int is compliant with 5245bis in general.

=C2=A0

Do people agree with that?

=C2=A0

If so, do you have suggestions for the ICE option na= me? :)

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0


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


--001a1144165603f6fb05337118f6-- From nobody Sun May 22 10:30:53 2016 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 6DBEC12D11E for ; Sun, 22 May 2016 10:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 V49EGOxKAzlx for ; Sun, 22 May 2016 10:30:45 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A957712D139 for ; Sun, 22 May 2016 10:30:44 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-73-5741ecc28bca Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 03.AE.12516.2CCE1475; Sun, 22 May 2016 19:30:43 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0294.000; Sun, 22 May 2016 19:30:42 +0200 From: Christer Holmberg To: Bernard Aboba Thread-Topic: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination Thread-Index: AdGmHG6bJo539xyvSt+nU2XdpYsl7wOHId2AAAV8H7A= Date: Sun, 22 May 2016 17:30:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37FDF3E1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37F93800@ESESSMB209.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.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37FDF3E1ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7hO7hN47hBseamSw27PvPbPHtQq0D k8fOWXfZPZYs+ckUwBTFZZOSmpNZllqkb5fAlfFp7RK2gi9VFaf2HmVpYDxT3sXIySEhYCIx Z8cMZghbTOLCvfVsXYxcHEICRxglHm7eyALhLGGUuHdtDpDDwcEmYCHR/U8bpEFEQFui79s+ JpAws4CixMu9aiBhYYFUiffXethAwiICaRLrF8ZAVFtJrF7WyghiswioSsxff5wJxOYV8JVo f/KLFWLTFEaJ/39WsIL0cgoESux/YghSwwh02vdTa8DqmQXEJW49mc8EcbKAxJI956HOF5V4 +fgfK4StJLH28HYWiPp8ic6b+9khdglKnJz5hGUCo+gsJKNmISmbhaRsFthjmhLrd+lDlChK TOl+yA5ha0i0zpnLjiy+gJF9FaNocWpxcW66kbFealFmcnFxfp5eXmrJJkZgnB3c8lt3B+Pq 146HGAU4GJV4eBcIOYYLsSaWFVfmHmKU4GBWEuH1eQkU4k1JrKxKLcqPLyrNSS0+xCjNwaIk zuv/UjFcSCA9sSQ1OzW1ILUIJsvEwSnVwChW4pTsOc05f9PW8rAl/j0a3kvO2fyoeMjU/t65 JX/jbYk1f50zNpjyuKi5ilyJCFa8cePjltJICd/9crVVx2e96Umbo395lkvBtKcCJnordhyW PLjx8Vcb6WvreKTXVHtYxi5g7glS0ubi2rchcWWXZLy4hkzL3xdhbg6Nb6LD1Y5VL9+8WIml OCPRUIu5qDgRAHl08eqvAgAA Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 17:30:52 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37FDF3E1ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVybmFyZCwNCg0KPj4iQXMgYWdyZWVkIGluIEJ1ZW5vcyBBaXJlcywgNTI0NWJpcyBlbmRw b2ludHMgd2lsbCBub3QgdXNlIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiwgYW5kIHdlIGFsc28gYWdy ZWVkIHRvIGRlZmluZSBhIG5ldyBJQ0Ugb3B0aW9uIHRvIGJlIHVzZWQgYnkgNTI0NSBlbmRwb2lu dHMiDQo+DQo+W0JBXSBEb24ndCB5b3UgbWVhbiAidXNlZCBieSBSRkMgNTI0NWJpcyBlbmRwb2lu dHM/IiAgUkZDIDUyNDUgZW5kcG9pbnRzIGNhbm5vdCBiZSBleHBlY3RlZCB0byBpbXBsZW1lbnQg b3IgdW5kZXJzdGFuZCBuZXcgSUNFIG9wdGlvbnMgLSB0aGV5IGFyZSB0aGUgbGVnYWN5IGltcGxl bWVudGF0aW9ucyBoZXJlLg0KPg0KPiJpbiBvcmRlciB0byBwcmV2ZW50IGxlZ2FjeSBwZWVycyBm cm9tIHVzaW5nIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiAoYXMgbGVnYWN5IHBlZXJzIHdvdWxkIG5v dCBzdXBwb3J0IHRoZSBJQ0Ugb3B0aW9uLCB0aGV5IGFyZSBleHBlY3RlZCBub3QgdG8gdXNlIGFn Z3Jlc3NpdmUgbm9taW5hdGlvbikuIg0KPg0KPltCQV0gTGVnYWN5IHBlZXJzIGltcGxlbWVudGlu ZyBSRkMgNTI0NSB3b24ndCB1bmRlcnN0YW5kIHRoZSBuZXcgSUNFIG9wdGlvbiwgc28gdGhlaXIg YmVoYXZpb3Igd2lsbCBiZSB1bm1vZGlmaWVkLiAgSWYgYSBsZWdhY3kgaW1wbGVtZW50YXRpb24g aXMgaW5jbGluZWQgdG8gZG8gYWdncmVzc2l2ZSBub21pbmF0aW9uLCB0aGUgbmV3IElDRSA+b3B0 aW9uIHdvbid0IGNoYW5nZSB0aGF0Lg0KPg0KPldoYXQgKmlzKiBwb3NzaWJsZSBpcyBmb3IgYW4g UkZDIDUyNDViaXMgaW1wbGVtZW50YXRpb24gdG8gbmVnb3RpYXRlIHdpdGggYW5vdGhlciBSRkMg NTI0NWJpcyBpbXBsZW1lbnRhdGlvbiB0byBub3QgdXNlIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbi4g IEhvd2V2ZXIsIHNpbmNlIHRoZSBuZXcgSUNFIG9wdGlvbiB3aWxsIGJlIGlnbm9yZWQgYnkgYSA+ bGVnYWN5IHBlZXIsICB0aGUgUkZDIDUyNDViaXMgaW1wbGVtZW50YXRpb24gd2lsbCBuZWVkIHRv IGJlIHByZXBhcmVkIHRvIGhhbmRsZSBhZ2dyZXNzaXZlIG5vbWluYXRpb24gYnkgdGhlIGxlZ2Fj eSBwZWVyLg0KDQpJZiBhbiA1MjQ1IGVuZHBvaW50IGRvZXMgbm90IHVuZGVyc3RhbmQgYW4gSUNF IG9wdGlvbiAobm8gbWF0dGVyIHdoYXQgdGhlIHNlbWFudGljcyBvZiB0aGUgSUNFIG9wdGlvbiBp cyksIHRoZSBlbmRwb2ludCBNVVNUIE5PVCB1c2UgYWdncmVzc2l2ZSBub21pbmF0aW9uLiBUaGF0 IGlzIGFjY29yZGluZyB0byBSRkMgNTI0NS4gTm93LCBJIGRvbuKAmXQgcmVtZW1iZXIgdGhlIHJl YXNvbiBvZiBiaW5kaW5nIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiB3aXRoIG5vdCB1bmRlcnN0YW5k aW5nIElDRSBvcHRpb25zLCBidXQgdGhhdCBpcyB3aGF0IFJGQyA1MjQ1IHNheXMgOikNCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KSGksDQoNCkFzIGFncmVlZCBpbiBCdWVub3MgQWly ZXMsIDUyNDViaXMgZW5kcG9pbnRzIHdpbGwgbm90IHVzZSBhZ2dyZXNzaXZlIG5vbWluYXRpb24s IGFuZCB3ZSBhbHNvIGFncmVlZCB0byBkZWZpbmUgYSBuZXcgSUNFIG9wdGlvbiB0byBiZSB1c2Vk IGJ5IDUyNDUgZW5kcG9pbnRzIGluIG9yZGVyIHRvIHByZXZlbnQgbGVnYWN5IHBlZXJzIGZyb20g dXNpbmcgYWdncmVzc2l2ZSBub21pbmF0aW9uIChhcyBsZWdhY3kgcGVlcnMgd291bGQgbm90IHN1 cHBvcnQgdGhlIElDRSBvcHRpb24sIHRoZXkgYXJlIGV4cGVjdGVkIG5vdCB0byB1c2UgYWdncmVz c2l2ZSBub21pbmF0aW9uKS4NCg0KSG93ZXZlciwgZGVmaW5pbmcgYSBkdW1teSBJQ0Ugb3B0aW9u IGp1c3QgdG8gcHJldmVudCBsZWdhY3kgcGVlcnMgZnJvbSB1c2luZyBhZ2dyZXNzaXZlIG5vbWlu YXRpb24gd291bGQgbm90IGJlIGdvb2QgcHJvdG9jb2wgZGVzaWduLCBpbiBteSBvcGluaW9uLg0K DQpBbHNvLCBzY29waW5nIHRoZSBJQ0Ugb3B0aW9uIHRvIG5vbWluYXRpb24gbWF5IG5vdCBiZSBz bWFydCBlaXRoZXIuIEluIG15IG9waW5pb24gdGhlIElDRSBvcHRpb24gc2hvdWxkIGluZGljYXRl IHRoYXQgdGhlIGVuZHBvaW50IGlzIGNvbXBsaWFudCB3aXRoIDUyNDViaXMgaW4gZ2VuZXJhbC4N Cg0KRG8gcGVvcGxlIGFncmVlIHdpdGggdGhhdD8NCg0KSWYgc28sIGRvIHlvdSBoYXZlIHN1Z2dl c3Rpb25zIGZvciB0aGUgSUNFIG9wdGlvbiBuYW1lPyA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CkljZSBtYWlsaW5nIGxpc3QNCkljZUBpZXRmLm9yZzxtYWlsdG86SWNlQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pY2UNCg0K --_000_7594FB04B1934943A5C02806D1A2204B37FDF3E1ESESSMB209erics_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21w b3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkhpIEJlcm5hcmQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyZxdW90O0FzIGFn cmVlZCBpbiBCdWVub3MgQWlyZXMsIDUyNDViaXMgZW5kcG9pbnRzIHdpbGwgbm90IHVzZSBhZ2dy ZXNzaXZlIG5vbWluYXRpb24sIGFuZCB3ZSBhbHNvIGFncmVlZCB0byBkZWZpbmUgYSBuZXcgSUNF IG9wdGlvbiB0byBiZSB1c2VkIGJ5IDUyNDUgZW5kcG9pbnRzJnF1b3Q7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mZ3Q7W0JBXSBEb24ndCB5b3UgbWVhbiAmcXVvdDt1c2VkIGJ5IFJGQyA1MjQ1 YmlzIGVuZHBvaW50cz8mcXVvdDsgJm5ic3A7UkZDIDUyNDUgZW5kcG9pbnRzIGNhbm5vdCBiZSBl eHBlY3RlZCB0byBpbXBsZW1lbnQgb3IgdW5kZXJzdGFuZCBuZXcgSUNFIG9wdGlvbnMgLSB0aGV5 IGFyZSB0aGUgbGVnYWN5IGltcGxlbWVudGF0aW9ucw0KIGhlcmUuJm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7JnF1b3Q7aW4gb3JkZXIg dG8gcHJldmVudCBsZWdhY3kgcGVlcnMgZnJvbSB1c2luZyBhZ2dyZXNzaXZlIG5vbWluYXRpb24g KGFzIGxlZ2FjeSBwZWVycyB3b3VsZCBub3Qgc3VwcG9ydCB0aGUgSUNFIG9wdGlvbiwgdGhleSBh cmUgZXhwZWN0ZWQgbm90IHRvIHVzZSBhZ2dyZXNzaXZlIG5vbWluYXRpb24pLiZxdW90Ozwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0O1tCQV0gTGVnYWN5IHBlZXJzIGltcGxlbWVudGluZyBS RkMgNTI0NSB3b24ndCB1bmRlcnN0YW5kIHRoZSBuZXcgSUNFIG9wdGlvbiwgc28gdGhlaXIgYmVo YXZpb3Igd2lsbCBiZSB1bm1vZGlmaWVkLiZuYnNwOyBJZiBhIGxlZ2FjeSBpbXBsZW1lbnRhdGlv biBpcyBpbmNsaW5lZCB0byBkbyBhZ2dyZXNzaXZlDQogbm9taW5hdGlvbiwgdGhlIG5ldyBJQ0Ug Jmd0O29wdGlvbiB3b24ndCBjaGFuZ2UgdGhhdC4gJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7V2hhdCAq aXMqIHBvc3NpYmxlIGlzIGZvciBhbiBSRkMgNTI0NWJpcyBpbXBsZW1lbnRhdGlvbiB0byBuZWdv dGlhdGUgd2l0aCBhbm90aGVyIFJGQyA1MjQ1YmlzIGltcGxlbWVudGF0aW9uIHRvIG5vdCB1c2Ug YWdncmVzc2l2ZSBub21pbmF0aW9uLiZuYnNwOyBIb3dldmVyLCBzaW5jZSB0aGUgbmV3IElDRQ0K IG9wdGlvbiB3aWxsIGJlIGlnbm9yZWQgYnkgYSAmZ3Q7bGVnYWN5IHBlZXIsICZuYnNwO3RoZSBS RkMgNTI0NWJpcyBpbXBsZW1lbnRhdGlvbiB3aWxsIG5lZWQgdG8gYmUgcHJlcGFyZWQgdG8gaGFu ZGxlIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiBieSB0aGUgbGVnYWN5IHBlZXIuJm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklmIGFuIDUyNDUgZW5k cG9pbnQgZG9lcyBub3QgdW5kZXJzdGFuZCBhbiBJQ0Ugb3B0aW9uIChubyBtYXR0ZXIgd2hhdCB0 aGUgc2VtYW50aWNzIG9mIHRoZSBJQ0Ugb3B0aW9uIGlzKSwgdGhlIGVuZHBvaW50IE1VU1QgTk9U IHVzZSBhZ2dyZXNzaXZlIG5vbWluYXRpb24uIFRoYXQgaXMgYWNjb3JkaW5nDQogdG8gUkZDIDUy NDUuIE5vdywgSSBkb27igJl0IHJlbWVtYmVyIHRoZSByZWFzb24gb2YgYmluZGluZyBhZ2dyZXNz aXZlIG5vbWluYXRpb24gd2l0aCBub3QgdW5kZXJzdGFuZGluZyBJQ0Ugb3B0aW9ucywgYnV0IHRo YXQgaXMgd2hhdCBSRkMgNTI0NSBzYXlzIDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpLDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+QXMgYWdyZWVkIGluIEJ1ZW5vcyBBaXJlcywgNTI0NWJpcyBlbmRw b2ludHMgd2lsbCBub3QgdXNlIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiwgYW5kIHdlIGFsc28gYWdy ZWVkIHRvIGRlZmluZSBhIG5ldyBJQ0Ugb3B0aW9uIHRvIGJlIHVzZWQgYnkgNTI0NSBlbmRwb2lu dHMgaW4gb3JkZXIgdG8gcHJldmVudCBsZWdhY3kNCiBwZWVycyBmcm9tIHVzaW5nIGFnZ3Jlc3Np dmUgbm9taW5hdGlvbiAoYXMgbGVnYWN5IHBlZXJzIHdvdWxkIG5vdCBzdXBwb3J0IHRoZSBJQ0Ug b3B0aW9uLCB0aGV5IGFyZSBleHBlY3RlZCBub3QgdG8gdXNlIGFnZ3Jlc3NpdmUgbm9taW5hdGlv bikuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3dldmVyLCBkZWZpbmluZyBhIGR1bW15 IElDRSBvcHRpb24ganVzdCB0byBwcmV2ZW50IGxlZ2FjeSBwZWVycyBmcm9tIHVzaW5nIGFnZ3Jl c3NpdmUgbm9taW5hdGlvbiB3b3VsZCBub3QgYmUgZ29vZCBwcm90b2NvbCBkZXNpZ24sIGluIG15 IG9waW5pb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbHNvLCBzY29waW5nIHRoZSBJ Q0Ugb3B0aW9uIHRvIG5vbWluYXRpb24gbWF5IG5vdCBiZSBzbWFydCBlaXRoZXIuIEluIG15IG9w aW5pb24gdGhlIElDRSBvcHRpb24gc2hvdWxkIGluZGljYXRlIHRoYXQgdGhlIGVuZHBvaW50IGlz IGNvbXBsaWFudCB3aXRoIDUyNDViaXMgaW4gZ2VuZXJhbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkRvIHBlb3BsZSBhZ3JlZSB3aXRoIHRoYXQ/PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5JZiBzbywgZG8geW91IGhhdmUgc3VnZ2VzdGlvbnMgZm9yIHRoZSBJQ0Ugb3B0aW9uIG5h bWU/IDopPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6Izg4ODg4OCI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojODg4ODg4Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCklj ZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SWNlQGlldGYub3JnIj5JY2VAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pY2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ljZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B37FDF3E1ESESSMB209erics_-- From nobody Sun May 22 10:47:25 2016 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 AD10C12D0F5 for ; Sun, 22 May 2016 10:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id id40nhUsn917 for ; Sun, 22 May 2016 10:47:22 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::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 DFEB7128874 for ; Sun, 22 May 2016 10:47:21 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id y2so127486218vka.3 for ; Sun, 22 May 2016 10:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zgIDyhr+Rt7VNwEBQlsWVwUfM2dsLaMWKXG58NPAplQ=; b=xdFrNhFNlS2LC8bUQPfpgnpMGwG2RR2IgX4ZbJxYSlQhC1ZDJx+Kw+P0Zjt3+zd8Mp VoXkxu0ZNFJeUwXksRQPVZFioShMj+u5IioiDFzc//14+D61L9zP16G3+aqO6itx4Vwy 5AZqhbFeYx9SWYsLXurqPntvg73BgadalAantdhXcuVgmOKjtd1NwYN9jZI2XSZiVKAG 87sWDpZcZ6NlGwkj2ktuJQAWCAQAuJhFrtJHiO6pT6/t5l3FXHKKO00SO2kTDNeYoH4r oJA4uxvWIjXS1Jql5qjOuwrcOka3iOSdP+sxro9rmm/nKCMSM990lXLw0HJeMlItN8h+ CHHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zgIDyhr+Rt7VNwEBQlsWVwUfM2dsLaMWKXG58NPAplQ=; b=L93F+tCDzOx/I47+tRa5lULX1D+AHccM5/6osABoC65yloDo9r8aPqgavYNDsNtU6Q y46QV80CMoBMJFLT7ocHir1tm+nh0KknaUZ3BZwBoDHH0Bu1KUKzmqTSOwND6EAMkehz f2Wyc+/alAXKMAeS8jUMKup88qSLlebQeN9XdNwGaMuLKBu+jSqGQ1B2FbgF93ZYeAms 6yPuQv+FkSdd2738afbDm+oXJfdP4T94+ngeaqo8GUKSHyYGuPWmkYTp/fCbgJEO7itk 0hMF4IQ41TA52hUL04p2Eo1Ap+DgdwYbH+1O25+b5yZ959QV3LCPpWGzsh+SAhhiva+5 x/WQ== X-Gm-Message-State: AOPr4FXcuX+6a8hVai6auT5UCMAxoX5uuwU9y3eTSgt9vWGr04EuFdremkgjL6+Ikj+2diSKg2CHciZGaM3Kiw== X-Received: by 10.31.2.210 with SMTP id 201mr6313182vkc.58.1463939240520; Sun, 22 May 2016 10:47:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.40 with HTTP; Sun, 22 May 2016 10:47:00 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37FDF3E1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37F93800@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37FDF3E1@ESESSMB209.ericsson.se> From: Bernard Aboba Date: Sun, 22 May 2016 10:47:00 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a113dc9cc6773fe053371ea23 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 17:47:24 -0000 --001a113dc9cc6773fe053371ea23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Christer said: "If an 5245 endpoint does not understand an ICE option (no matter what the semantics of the ICE option is), the endpoint MUST NOT use aggressive nomination. That is according to RFC 5245. Now, I don=E2=80=99t remember th= e reason of binding aggressive nomination with not understanding ICE options, but that is what RFC 5245 says :)" [BA] AFAICT, most implementations of RFC 5245 that support aggressive nomination do not disable it on receiving an ICE option they do not understand, despite what RFC 5245 says. So in practice, I would not expect the new ICE option to have the desired effect. On Sun, May 22, 2016 at 10:30 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Bernard, > > > > >>"As agreed in Buenos Aires, 5245bis endpoints will not use aggressive > nomination, and we also agreed to define a new ICE option to be used by > 5245 endpoints" > > > > > >[BA] Don't you mean "used by RFC 5245bis endpoints?" RFC 5245 endpoints > cannot be expected to implement or understand new ICE options - they are > the legacy implementations here. > > > > > >"in order to prevent legacy peers from using aggressive nomination (as > legacy peers would not support the ICE option, they are expected not to u= se > aggressive nomination)." > > > > > >[BA] Legacy peers implementing RFC 5245 won't understand the new ICE > option, so their behavior will be unmodified. If a legacy implementation > is inclined to do aggressive nomination, the new ICE >option won't change > that. > > > > > >What *is* possible is for an RFC 5245bis implementation to negotiate wit= h > another RFC 5245bis implementation to not use aggressive nomination. > However, since the new ICE option will be ignored by a >legacy peer, the > RFC 5245bis implementation will need to be prepared to handle aggressive > nomination by the legacy peer. > > > > If an 5245 endpoint does not understand an ICE option (no matter what the > semantics of the ICE option is), the endpoint MUST NOT use aggressive > nomination. That is according to RFC 5245. Now, I don=E2=80=99t remember = the reason > of binding aggressive nomination with not understanding ICE options, but > that is what RFC 5245 says :) > > > > Regards, > > > > Christer > > > > > > > > > > Hi, > > > > As agreed in Buenos Aires, 5245bis endpoints will not use aggressive > nomination, and we also agreed to define a new ICE option to be used by > 5245 endpoints in order to prevent legacy peers from using aggressive > nomination (as legacy peers would not support the ICE option, they are > expected not to use aggressive nomination). > > > > However, defining a dummy ICE option just to prevent legacy peers from > using aggressive nomination would not be good protocol design, in my > opinion. > > > > Also, scoping the ICE option to nomination may not be smart either. In my > opinion the ICE option should indicate that the endpoint is compliant wit= h > 5245bis in general. > > > > Do people agree with that? > > > > If so, do you have suggestions for the ICE option name? :) > > > > Regards, > > > > Christer > > > > > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > > --001a113dc9cc6773fe053371ea23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Christer said:=C2=A0

"If an 5245 endpoint= does not understand an ICE option (no matter what the semantics of the ICE= option is), the endpoint MUST NOT use aggressive nomination. That is accor= ding to RFC 5245. Now, I don=E2=80=99t remember the reason of binding aggre= ssive nomination with not understanding ICE options, but that is what RFC 5= 245 says :)"

[BA] AFAICT, most impleme= ntations of RFC 5245 that support aggressive nomination do not disable it o= n receiving an ICE option they do not understand, despite what RFC 5245 say= s.=C2=A0 So in practice, I would not expect the new ICE option to have the = desired effect.

On Sun, May 22, 2016 at 10:30 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi Bernard,

=C2=A0

>>"As agreed in Buenos Aires, 5245bis en= dpoints will not use aggressive nomination, and we also agreed to define a = new ICE option to be used by 5245 endpoints"

>=C2=A0

>[BA] Don't you mean "used by RFC 5245b= is endpoints?" =C2=A0RFC 5245 endpoints cannot be expected to implemen= t or understand new ICE options - they are the legacy implementations here.=C2=A0

>=C2=A0

>"in order to prevent legacy peers from usi= ng aggressive nomination (as legacy peers would not support the ICE option,= they are expected not to use aggressive nomination)."

>=C2=A0

>[BA] Legacy peers implementing RFC 5245 won'= ;t understand the new ICE option, so their behavior will be unmodified.=C2= =A0 If a legacy implementation is inclined to do aggressive nomination, the new ICE >option won't change that. =C2=A0=

>=C2=A0

>What *is* possible is for an RFC 5245bis implem= entation to negotiate with another RFC 5245bis implementation to not use ag= gressive nomination.=C2=A0 However, since the new ICE option will be ignored by a >legacy peer, =C2=A0the RFC 5245bis impleme= ntation will need to be prepared to handle aggressive nomination by the leg= acy peer.=C2=A0

=C2=A0

If an 5245 endpoint does not understand an I= CE option (no matter what the semantics of the ICE option is), the endpoint= MUST NOT use aggressive nomination. That is according to RFC 5245. Now, I don=E2=80=99t remember the reason of binding aggressiv= e nomination with not understanding ICE options, but that is what RFC 5245 = says :)

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

=C2=A0

Hi,

=C2=A0

As agreed in Buenos Aires, 5245bis endpoints will no= t use aggressive nomination, and we also agreed to define a new ICE option = to be used by 5245 endpoints in order to prevent legacy peers from using aggressive nomination (as legacy peers would not support = the ICE option, they are expected not to use aggressive nomination).=

=C2=A0

However, defining a dummy ICE option just to prevent= legacy peers from using aggressive nomination would not be good protocol d= esign, in my opinion.

=C2=A0

Also, scoping the ICE option to nomination may not b= e smart either. In my opinion the ICE option should indicate that the endpo= int is compliant with 5245bis in general.

=C2=A0

Do people agree with that?

=C2=A0

If so, do you have suggestions for the ICE option na= me? :)

=C2=A0

Regards,

=C2=A0

Christer=

=C2=A0

=C2=A0


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

=C2=A0


--001a113dc9cc6773fe053371ea23-- From nobody Sun May 22 10:57:27 2016 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 58F4D12D15D for ; Sun, 22 May 2016 10:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 gVbftfrmTNiO for ; Sun, 22 May 2016 10:57:23 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA9312D155 for ; Sun, 22 May 2016 10:57:22 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-c5-5741f3009766 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 77.90.12516.003F1475; Sun, 22 May 2016 19:57:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0294.000; Sun, 22 May 2016 19:57:20 +0200 From: Christer Holmberg To: Bernard Aboba Thread-Topic: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination Thread-Index: AdGmHG6bJo539xyvSt+nU2XdpYsl7wOHId2AAAV8H7D//+SNAP//3Cug Date: Sun, 22 May 2016 17:57:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37FDF4C7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37F93800@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37FDF3E1@ESESSMB209.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.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37FDF4C7ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2J7iC7jZ8dwg9cv2C027PvPbPHtQq0D k8fOWXfZPZYs+ckUwBTFZZOSmpNZllqkb5fAldGz+wJbwZOtjBWLt99lbmD8s4Gxi5GDQ0LA RGJiR0IXIyeQKSZx4d56ti5GLg4hgSOMEg/2zoNyljBKTPtxkA2kgU3AQqL7nzZIg4iAtkTf t31MIGFmAUWJl3vVQMLCAqkS76/1gFWLCKRJrF8YA1HtJjHj7C9GEJtFQFXi4q9mNhCbV8BX Ys7zL1Cb5jNJfL9/EGwkp0CgxOo2sF5GoNO+n1rDBGIzC4hL3HoynwniZAGJJXvOM0PYohIv H/9jhbCVJNYe3s4CcVm+xN6FwhCrBCVOznzCMoFRdBaSSbMQqmYhqYIIa0qs36UPUa0oMaX7 ITuErSHROmcuO7L4Akb2VYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBUXZwy2/dHYyrXzse YhTgYFTi4V0g5BguxJpYVlyZe4hRgoNZSYSX4R1QiDclsbIqtSg/vqg0J7X4EKM0B4uSOK// S8VwIYH0xJLU7NTUgtQimCwTB6dUA6MkQ9zbrepawbNOl+x+9CupzLZ//8YjW2KsdCRj3WLv LNNeo6dt4xaz+EjvhCM7LvCznE32s52lmZS668byTT8Cer0W+Lgc85+vm8r4OtL429ptsTrN dqKP3xZ5Czwu/v7C9Mbtk113nrI4xcxcmGi5s+pUvzb/uUUH5p69oM/e/vJl29d/JSJKLMUZ iYZazEXFiQAWUiwsrgIAAA== Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 17:57:25 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37FDF4C7ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5DaHJpc3RlciBzYWlkOg0KPg0KPiJJZiBhbiA1MjQ1IGVuZHBvaW50IGRvZXMgbm90 IHVuZGVyc3RhbmQgYW4gSUNFIG9wdGlvbiAobm8gbWF0dGVyIHdoYXQgdGhlIHNlbWFudGljcyBv ZiB0aGUgSUNFIG9wdGlvbiBpcyksIHRoZSBlbmRwb2ludCBNVVNUIE5PVCB1c2UgYWdncmVzc2l2 ZSBub21pbmF0aW9uLiBUaGF0IGlzIGFjY29yZGluZyB0byBSRkMgNTI0NS4gTm93LCBJID5kb27i gJl0IHJlbWVtYmVyIHRoZSByZWFzb24gb2YgYmluZGluZyBhZ2dyZXNzaXZlIG5vbWluYXRpb24g d2l0aCBub3QgdW5kZXJzdGFuZGluZyBJQ0Ugb3B0aW9ucywgYnV0IHRoYXQgaXMgd2hhdCBSRkMg NTI0NSBzYXlzIDopIg0KPg0KPltCQV0gQUZBSUNULCBtb3N0IGltcGxlbWVudGF0aW9ucyBvZiBS RkMgNTI0NSB0aGF0IHN1cHBvcnQgYWdncmVzc2l2ZSBub21pbmF0aW9uIGRvIG5vdCBkaXNhYmxl IGl0IG9uIHJlY2VpdmluZyBhbiBJQ0Ugb3B0aW9uIHRoZXkgZG8gbm90IHVuZGVyc3RhbmQsIGRl c3BpdGUgd2hhdCBSRkMgNTI0NSBzYXlzLiAgU28gPmluIHByYWN0aWNlLCBJIHdvdWxkIG5vdCBl eHBlY3QgdGhlIG5ldyBJQ0Ugb3B0aW9uIHRvIGhhdmUgdGhlIGRlc2lyZWQgZWZmZWN0Lg0KDQpB bmQgZm9yIHRoYXQgcmVhc29uIDUyNDViaXMgZW5kcG9pbnRzIHdpbGwgY29udGludWUgdG8gc3Vw cG9ydCB0aGUgY2FzZSB3aGVyZSB0aGUgcmVtb3RlIHBlZXIgKGEgbGVnYWN5IGVuZHBvaW50KSBk b2VzIHVzZSBhZ2dyZXNzaXZlIG5vbWluYXRpb24gKGV2ZW4gaWYgdGhlIElDRSBvcHRpb24gd2Fz IGluY2x1ZGVkKSA6KQ0KDQpJIGhvcGUgdGhhdCBpcyBzdGF0ZWQgaW4gdGhlIG1lZXRpbmcgbWlu dXRlcy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCk9uIFN1biwgTWF5IDIyLCAyMDE2 IGF0IDEwOjMwIEFNLCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhp IEJlcm5hcmQsDQoNCj4+IkFzIGFncmVlZCBpbiBCdWVub3MgQWlyZXMsIDUyNDViaXMgZW5kcG9p bnRzIHdpbGwgbm90IHVzZSBhZ2dyZXNzaXZlIG5vbWluYXRpb24sIGFuZCB3ZSBhbHNvIGFncmVl ZCB0byBkZWZpbmUgYSBuZXcgSUNFIG9wdGlvbiB0byBiZSB1c2VkIGJ5IDUyNDUgZW5kcG9pbnRz Ig0KPg0KPltCQV0gRG9uJ3QgeW91IG1lYW4gInVzZWQgYnkgUkZDIDUyNDViaXMgZW5kcG9pbnRz PyIgIFJGQyA1MjQ1IGVuZHBvaW50cyBjYW5ub3QgYmUgZXhwZWN0ZWQgdG8gaW1wbGVtZW50IG9y IHVuZGVyc3RhbmQgbmV3IElDRSBvcHRpb25zIC0gdGhleSBhcmUgdGhlIGxlZ2FjeSBpbXBsZW1l bnRhdGlvbnMgaGVyZS4NCj4NCj4iaW4gb3JkZXIgdG8gcHJldmVudCBsZWdhY3kgcGVlcnMgZnJv bSB1c2luZyBhZ2dyZXNzaXZlIG5vbWluYXRpb24gKGFzIGxlZ2FjeSBwZWVycyB3b3VsZCBub3Qg c3VwcG9ydCB0aGUgSUNFIG9wdGlvbiwgdGhleSBhcmUgZXhwZWN0ZWQgbm90IHRvIHVzZSBhZ2dy ZXNzaXZlIG5vbWluYXRpb24pLiINCj4NCj5bQkFdIExlZ2FjeSBwZWVycyBpbXBsZW1lbnRpbmcg UkZDIDUyNDUgd29uJ3QgdW5kZXJzdGFuZCB0aGUgbmV3IElDRSBvcHRpb24sIHNvIHRoZWlyIGJl aGF2aW9yIHdpbGwgYmUgdW5tb2RpZmllZC4gIElmIGEgbGVnYWN5IGltcGxlbWVudGF0aW9uIGlz IGluY2xpbmVkIHRvIGRvIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiwgdGhlIG5ldyBJQ0UgPm9wdGlv biB3b24ndCBjaGFuZ2UgdGhhdC4NCj4NCj5XaGF0ICppcyogcG9zc2libGUgaXMgZm9yIGFuIFJG QyA1MjQ1YmlzIGltcGxlbWVudGF0aW9uIHRvIG5lZ290aWF0ZSB3aXRoIGFub3RoZXIgUkZDIDUy NDViaXMgaW1wbGVtZW50YXRpb24gdG8gbm90IHVzZSBhZ2dyZXNzaXZlIG5vbWluYXRpb24uICBI b3dldmVyLCBzaW5jZSB0aGUgbmV3IElDRSBvcHRpb24gd2lsbCBiZSBpZ25vcmVkIGJ5IGEgPmxl Z2FjeSBwZWVyLCAgdGhlIFJGQyA1MjQ1YmlzIGltcGxlbWVudGF0aW9uIHdpbGwgbmVlZCB0byBi ZSBwcmVwYXJlZCB0byBoYW5kbGUgYWdncmVzc2l2ZSBub21pbmF0aW9uIGJ5IHRoZSBsZWdhY3kg cGVlci4NCg0KSWYgYW4gNTI0NSBlbmRwb2ludCBkb2VzIG5vdCB1bmRlcnN0YW5kIGFuIElDRSBv cHRpb24gKG5vIG1hdHRlciB3aGF0IHRoZSBzZW1hbnRpY3Mgb2YgdGhlIElDRSBvcHRpb24gaXMp LCB0aGUgZW5kcG9pbnQgTVVTVCBOT1QgdXNlIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbi4gVGhhdCBp cyBhY2NvcmRpbmcgdG8gUkZDIDUyNDUuIE5vdywgSSBkb27igJl0IHJlbWVtYmVyIHRoZSByZWFz b24gb2YgYmluZGluZyBhZ2dyZXNzaXZlIG5vbWluYXRpb24gd2l0aCBub3QgdW5kZXJzdGFuZGlu ZyBJQ0Ugb3B0aW9ucywgYnV0IHRoYXQgaXMgd2hhdCBSRkMgNTI0NSBzYXlzIDopDQoNClJlZ2Fy ZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCkhpLA0KDQpBcyBhZ3JlZWQgaW4gQnVlbm9zIEFpcmVz LCA1MjQ1YmlzIGVuZHBvaW50cyB3aWxsIG5vdCB1c2UgYWdncmVzc2l2ZSBub21pbmF0aW9uLCBh bmQgd2UgYWxzbyBhZ3JlZWQgdG8gZGVmaW5lIGEgbmV3IElDRSBvcHRpb24gdG8gYmUgdXNlZCBi eSA1MjQ1IGVuZHBvaW50cyBpbiBvcmRlciB0byBwcmV2ZW50IGxlZ2FjeSBwZWVycyBmcm9tIHVz aW5nIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiAoYXMgbGVnYWN5IHBlZXJzIHdvdWxkIG5vdCBzdXBw b3J0IHRoZSBJQ0Ugb3B0aW9uLCB0aGV5IGFyZSBleHBlY3RlZCBub3QgdG8gdXNlIGFnZ3Jlc3Np dmUgbm9taW5hdGlvbikuDQoNCkhvd2V2ZXIsIGRlZmluaW5nIGEgZHVtbXkgSUNFIG9wdGlvbiBq dXN0IHRvIHByZXZlbnQgbGVnYWN5IHBlZXJzIGZyb20gdXNpbmcgYWdncmVzc2l2ZSBub21pbmF0 aW9uIHdvdWxkIG5vdCBiZSBnb29kIHByb3RvY29sIGRlc2lnbiwgaW4gbXkgb3Bpbmlvbi4NCg0K QWxzbywgc2NvcGluZyB0aGUgSUNFIG9wdGlvbiB0byBub21pbmF0aW9uIG1heSBub3QgYmUgc21h cnQgZWl0aGVyLiBJbiBteSBvcGluaW9uIHRoZSBJQ0Ugb3B0aW9uIHNob3VsZCBpbmRpY2F0ZSB0 aGF0IHRoZSBlbmRwb2ludCBpcyBjb21wbGlhbnQgd2l0aCA1MjQ1YmlzIGluIGdlbmVyYWwuDQoN CkRvIHBlb3BsZSBhZ3JlZSB3aXRoIHRoYXQ/DQoNCklmIHNvLCBkbyB5b3UgaGF2ZSBzdWdnZXN0 aW9ucyBmb3IgdGhlIElDRSBvcHRpb24gbmFtZT8gOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN Cg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJ Y2UgbWFpbGluZyBsaXN0DQpJY2VAaWV0Zi5vcmc8bWFpbHRvOkljZUBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWNlDQoNCg0K --_000_7594FB04B1934943A5C02806D1A2204B37FDF4C7ESESSMB209erics_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21w b3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDtDaHJpc3RlciBzYWlkOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZndDsmcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklmIGFuIDUyNDUgZW5k cG9pbnQgZG9lcyBub3QgdW5kZXJzdGFuZCBhbiBJQ0Ugb3B0aW9uIChubyBtYXR0ZXIgd2hhdCB0 aGUgc2VtYW50aWNzIG9mIHRoZSBJQ0Ugb3B0aW9uIGlzKSwgdGhlIGVuZHBvaW50IE1VU1QgTk9U IHVzZSBhZ2dyZXNzaXZlIG5vbWluYXRpb24uIFRoYXQgaXMgYWNjb3JkaW5nDQogdG8gUkZDIDUy NDUuIE5vdywgSSAmZ3Q7ZG9u4oCZdCByZW1lbWJlciB0aGUgcmVhc29uIG9mIGJpbmRpbmcgYWdn cmVzc2l2ZSBub21pbmF0aW9uIHdpdGggbm90IHVuZGVyc3RhbmRpbmcgSUNFIG9wdGlvbnMsIGJ1 dCB0aGF0IGlzIHdoYXQgUkZDIDUyNDUgc2F5cyA6KTwvc3Bhbj4mcXVvdDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtbQkFdIEFG QUlDVCwgbW9zdCBpbXBsZW1lbnRhdGlvbnMgb2YgUkZDIDUyNDUgdGhhdCBzdXBwb3J0IGFnZ3Jl c3NpdmUgbm9taW5hdGlvbiBkbyBub3QgZGlzYWJsZSBpdCBvbiByZWNlaXZpbmcgYW4gSUNFIG9w dGlvbiB0aGV5IGRvIG5vdCB1bmRlcnN0YW5kLCBkZXNwaXRlIHdoYXQgUkZDIDUyNDUgc2F5cy4m bmJzcDsgU28gJmd0O2luIHByYWN0aWNlLCBJIHdvdWxkIG5vdCBleHBlY3QgdGhlIG5ldyBJQ0Ug b3B0aW9uIHRvDQogaGF2ZSB0aGUgZGVzaXJlZCBlZmZlY3QuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbmQgZm9yIHRoYXQg cmVhc29uIDUyNDViaXMgZW5kcG9pbnRzIHdpbGwgY29udGludWUgdG8gc3VwcG9ydCB0aGUgY2Fz ZSB3aGVyZSB0aGUgcmVtb3RlIHBlZXIgKGEgbGVnYWN5IGVuZHBvaW50KSBkb2VzIHVzZSBhZ2dy ZXNzaXZlIG5vbWluYXRpb24gKGV2ZW4gaWYgdGhlIElDRSBvcHRpb24gd2FzDQogaW5jbHVkZWQp IDopPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkkgaG9wZSB0aGF0IGlzIHN0YXRlZCBpbiB0aGUgbWVldGluZyBt aW51dGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaHJpc3Rlcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIE1heSAyMiwgMjAxNiBhdCAxMDozMCBB TSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVy Z0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkhpIEJlcm5hcmQsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jmd0OyZndDsmcXVvdDtBcyBhZ3JlZWQgaW4gQnVlbm9zIEFpcmVzLCA1MjQ1YmlzIGVu ZHBvaW50cyB3aWxsIG5vdCB1c2UgYWdncmVzc2l2ZSBub21pbmF0aW9uLCBhbmQgd2UgYWxzbyBh Z3JlZWQgdG8gZGVmaW5lDQogYSBuZXcgSUNFIG9wdGlvbiB0byBiZSB1c2VkIGJ5IDUyNDUgZW5k cG9pbnRzJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mZ3Q7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0O1tCQV0gRG9uJ3Qg eW91IG1lYW4gJnF1b3Q7dXNlZCBieSBSRkMgNTI0NWJpcyBlbmRwb2ludHM/JnF1b3Q7ICZuYnNw O1JGQyA1MjQ1IGVuZHBvaW50cyBjYW5ub3QgYmUgZXhwZWN0ZWQgdG8gaW1wbGVtZW50IG9yIHVu ZGVyc3RhbmQNCiBuZXcgSUNFIG9wdGlvbnMgLSB0aGV5IGFyZSB0aGUgbGVnYWN5IGltcGxlbWVu dGF0aW9ucyBoZXJlLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsmcXVvdDtpbiBvcmRlciB0byBwcmV2ZW50IGxlZ2FjeSBwZWVy cyBmcm9tIHVzaW5nIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiAoYXMgbGVnYWN5IHBlZXJzIHdvdWxk IG5vdCBzdXBwb3J0IHRoZSBJQ0Ugb3B0aW9uLA0KIHRoZXkgYXJlIGV4cGVjdGVkIG5vdCB0byB1 c2UgYWdncmVzc2l2ZSBub21pbmF0aW9uKS4mcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDsmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7W0JBXSBMZWdhY3kgcGVlcnMgaW1wbGVtZW50aW5nIFJGQyA1MjQ1IHdvbid0IHVu ZGVyc3RhbmQgdGhlIG5ldyBJQ0Ugb3B0aW9uLCBzbyB0aGVpciBiZWhhdmlvciB3aWxsIGJlIHVu bW9kaWZpZWQuJm5ic3A7DQogSWYgYSBsZWdhY3kgaW1wbGVtZW50YXRpb24gaXMgaW5jbGluZWQg dG8gZG8gYWdncmVzc2l2ZSBub21pbmF0aW9uLCB0aGUgbmV3IElDRSAmZ3Q7b3B0aW9uIHdvbid0 IGNoYW5nZSB0aGF0LiAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7V2hhdCAqaXMqIHBvc3NpYmxl IGlzIGZvciBhbiBSRkMgNTI0NWJpcyBpbXBsZW1lbnRhdGlvbiB0byBuZWdvdGlhdGUgd2l0aCBh bm90aGVyIFJGQyA1MjQ1YmlzIGltcGxlbWVudGF0aW9uIHRvDQogbm90IHVzZSBhZ2dyZXNzaXZl IG5vbWluYXRpb24uJm5ic3A7IEhvd2V2ZXIsIHNpbmNlIHRoZSBuZXcgSUNFIG9wdGlvbiB3aWxs IGJlIGlnbm9yZWQgYnkgYSAmZ3Q7bGVnYWN5IHBlZXIsICZuYnNwO3RoZSBSRkMgNTI0NWJpcyBp bXBsZW1lbnRhdGlvbiB3aWxsIG5lZWQgdG8gYmUgcHJlcGFyZWQgdG8gaGFuZGxlIGFnZ3Jlc3Np dmUgbm9taW5hdGlvbiBieSB0aGUgbGVnYWN5IHBlZXIuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JZiBhbiA1MjQ1IGVuZHBvaW50IGRv ZXMgbm90IHVuZGVyc3RhbmQgYW4gSUNFIG9wdGlvbiAobm8gbWF0dGVyIHdoYXQgdGhlIHNlbWFu dGljcyBvZiB0aGUgSUNFIG9wdGlvbiBpcyksIHRoZSBlbmRwb2ludA0KIE1VU1QgTk9UIHVzZSBh Z2dyZXNzaXZlIG5vbWluYXRpb24uIFRoYXQgaXMgYWNjb3JkaW5nIHRvIFJGQyA1MjQ1LiBOb3cs IEkgZG9u4oCZdCByZW1lbWJlciB0aGUgcmVhc29uIG9mIGJpbmRpbmcgYWdncmVzc2l2ZSBub21p bmF0aW9uIHdpdGggbm90IHVuZGVyc3RhbmRpbmcgSUNFIG9wdGlvbnMsIGJ1dCB0aGF0IGlzIHdo YXQgUkZDIDUyNDUgc2F5cyA6KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UmVnYXJkcyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM4ODg4ODgiPkNocmlzdGVyPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiM4 ODg4ODgiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkhpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QXMgYWdyZWVkIGluIEJ1ZW5vcyBBaXJl cywgNTI0NWJpcyBlbmRwb2ludHMgd2lsbCBub3QgdXNlIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiwg YW5kIHdlIGFsc28gYWdyZWVkIHRvIGRlZmluZSBhIG5ldyBJQ0Ugb3B0aW9uIHRvIGJlIHVzZWQg YnkgNTI0NSBlbmRwb2ludHMgaW4gb3JkZXIgdG8gcHJldmVudCBsZWdhY3kNCiBwZWVycyBmcm9t IHVzaW5nIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiAoYXMgbGVnYWN5IHBlZXJzIHdvdWxkIG5vdCBz dXBwb3J0IHRoZSBJQ0Ugb3B0aW9uLCB0aGV5IGFyZSBleHBlY3RlZCBub3QgdG8gdXNlIGFnZ3Jl c3NpdmUgbm9taW5hdGlvbikuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3dldmVyLCBk ZWZpbmluZyBhIGR1bW15IElDRSBvcHRpb24ganVzdCB0byBwcmV2ZW50IGxlZ2FjeSBwZWVycyBm cm9tIHVzaW5nIGFnZ3Jlc3NpdmUgbm9taW5hdGlvbiB3b3VsZCBub3QgYmUgZ29vZCBwcm90b2Nv bCBkZXNpZ24sIGluIG15IG9waW5pb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbHNv LCBzY29waW5nIHRoZSBJQ0Ugb3B0aW9uIHRvIG5vbWluYXRpb24gbWF5IG5vdCBiZSBzbWFydCBl aXRoZXIuIEluIG15IG9waW5pb24gdGhlIElDRSBvcHRpb24gc2hvdWxkIGluZGljYXRlIHRoYXQg dGhlIGVuZHBvaW50IGlzIGNvbXBsaWFudCB3aXRoIDUyNDViaXMgaW4gZ2VuZXJhbC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkRvIHBlb3BsZSBhZ3JlZSB3aXRoIHRoYXQ/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JZiBzbywgZG8geW91IGhhdmUgc3VnZ2VzdGlvbnMgZm9yIHRo ZSBJQ0Ugb3B0aW9uIG5hbWU/IDopPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRz LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6Izg4ODg4OCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4 ODg4Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkljZSBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86SWNlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+SWNlQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaWNlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pY2U8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37FDF4C7ESESSMB209erics_-- From nobody Sun May 22 13:35:05 2016 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 7DC5412D562; Sun, 22 May 2016 13:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 KI4RQrzhMXeN; Sun, 22 May 2016 13:35:01 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577B612D1B3; Sun, 22 May 2016 13:35:00 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-bd-574217f20525 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C0.A3.12926.2F712475; Sun, 22 May 2016 22:34:58 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.175]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0294.000; Sun, 22 May 2016 22:34:57 +0200 From: =?Windows-1252?Q?Ari_Ker=E4nen?= To: Christer Holmberg , Ben Campbell , Pal Martinsen Thread-Topic: [Ice] AD Evaluation of draft-ietf-ice-dualstack-fairness-02 Thread-Index: AQHRmgXQTpUCNlXZ60Kx18kXNy9TqJ+RChGAgBZiCwCAGky7gIADxGMA Date: Sun, 22 May 2016 20:34:56 +0000 Message-ID: <12099752-1FB6-4BB6-A9E7-1CC74871234C@ericsson.com> References: <86559E67-6412-4971-AB74-6680D079CAC8@cisco.com> 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.150] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUyM2K7qO4ncadwgzczhS3md55mt/h9vpHZ 4tuFWov311eyOLB4TPm9kdVjyZKfTB6zdj5hCWCO4rJJSc3JLEst0rdL4Mr40PGOqeBBScWB 2etYGhh/xHYxcnJICJhIfHg2jRXCFpO4cG89WxcjF4eQwBFGieWLlzFBOEsYJd5cOcUMUsUm 4Chx6uFasA4RgRqJpd1tjCBFzAIdjBJrX+9lA0kIC3hIHP3ayAZR5Cmxb3MnO4TtJvF4zymg OAcHi4CqxOsH3CAmr4C9xPH5lhC7rjNK7L3dALaLU8BaYsrLeUwgNiPQdd9PrQGzmQXEJW49 mc8EcbWAxJI955khbFGJl4//QX2jJLFi+yVGiHoDiffn5jND2NYSd6Z9YIWwtSWWLXwNFucV EJQ4OfMJywRG8VlIVsxC0j4LSfssJO2zkLQvYGRdxShanFqclJtuZKyXWpSZXFycn6eXl1qy iREYjQe3/FbdwXj5jeMhRgEORiUe3gVCjuFCrIllxZW5hxglOJiVRHgZ3gGFeFMSK6tSi/Lj i0pzUosPMUpzsCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1MEb0MucfWmqmvo5vxbci/UV3 OXWFud4XTHyn/UToYdTKQ7GXrsQHLmhvipC3UnVROHbHIoblZfmh2neqWqtYtBMKS54L9jnP 6lfZdTEsc/vi4zvXyAhdkOOWYn97O32dTna7VbQR+96q4tlTBLiuxRffdrhzjPGH3z6x7jvx M73SdfhaP3w5qMRSnJFoqMVcVJwIAPqAdvnCAgAA Archived-At: Cc: "draft-ietf-ice-dualstack-fairness.all@ietf.org" , "ice@ietf.org" Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-dualstack-fairness-02 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 20:35:04 -0000 Hi, Regarding the split to different drafts, our goal with the ICEbis work was = to fix errors and make sure we have the right hooks and text for the extens= ions that we need. And we decided that everything else, such as new feature= s/extra functionality, would go to different document(s). Of course the DS = draft is a borderline case, but given how much material (e.g., the algorith= m) there is, to me (chair hat off) separate document sounds still like a be= tter idea. But yes, the current text in ICEbis about RFC6724 needs to be updated and p= oint to the dual-stack document. Having text there about the general proced= ure makes sense. Regarding BCP or Informational for the DS draft status, I don't think we co= nsidered the BCP option. Now thinking about it, BCP seems reasonable option= . Cheers, Ari > On 20 May 2016, at 14:03, Christer Holmberg wrote: >=20 >=20 > Hi, >=20 > I have not been very much involved the dualstack-fairness > work/discussions, so forgive me if the following issues have already been > discussed. >=20 > As the purpose of the draft is to =B3make things work better=B2, I see no > reason why we simply couldn=B9t implement the change in 5245bis. I don=B9= t > think we need too much extra text for the justification, and it could e.g= . > be put in an appendix as suggested. >=20 > Now, regarding the statement that =B3some people don=B9t care/need this= =B2, how > much will the technical change affect them? If you want to be compliant > with 5245bis, you are anyway going to have to do some changes in your cod= e. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > On 03/05/16 20:25, "Ice on behalf of Ben Campbell" on behalf of ben@nostrum.com> wrote: >=20 >> Hi, >>=20 >> I apologize for the delay. My schedule over the last couple of weeks has >> been disrupted by some family issues. I am ramping back up now. >>=20 >> So, TL;DR: I think the working group needs to have a little more >> discussion about the status and purpose of this draft, and how it >> relates to ICEBis. More details below. >>=20 >> On 19 Apr 2016, at 6:37, Pal Martinsen (palmarti) wrote: >>=20 >>> On 19 Apr 2016, at 08:36, Ben Campbell >>> > wrote: >>>=20 >>> Hi, >>>=20 >>> This is my AD Evaluation of draft-ietf-ice-dualstack-fairness-02. I >>> find the draft readable and understandable, but I have some comments >>> and questions. I'd like to resolve the major comments prior to IETF >>> last call. >>>=20 >>> Major: >>>=20 >>> The draft is now informational, but the milestone is for PS. I see the >>> minutes from Prague say the wg agreed to make the change, but that >>> doesn't say why, and I failed to find any discussion of that on the >>> list. Can anyone remind me of the reasoning? (This interacts with my >>> next comment=8A) >>>=20 >>> Just for clarity I will summarise what I see as the key =B3events=B2 >>> of the draft. (I might be wrong so of others see it differently please >>> correct me) >>>=20 >>> - Started as an DualStack Happy Eyeballs solution that would give IPv6 >>> a head start. >>> - Several attempts to get a happy eyeballs algorithm working failed. >>> And we discovered that it would be very difficult to get right in all >>> the various scenarios. Think the =B3consensus in the hallways=B2 was >>> to let each application deal with it as they would know more of what >>> was important to them. >>>=20 >>> (http://www.ietf.org/proceedings/92/minutes/minutes-92-mmusic#h.v0jtwu5= re >>> 90f) >>>=20 >>> >> 90f>-=20 >>> Since the draft only contains guidelines on how an application should >>> deal with dual-stack it made sense to make it informational. >>>=20 >>> (http://www.ietf.org/proceedings/93/minutes/minutes-93-mmusic#h.34ilx3y= 4v >>> kbd) >>=20 >> The right choice here depends on what the working group expects the >> draft to accomplish. I think informational works if we want to tell >> implementors about some things they can do if they care. If, on the >> other hand, we want to actually encourage implementors to implement >> this, then I'm not sure informational is the right choice. Did the WG >> consider BCP? >>=20 >>>=20 >>>=20 >>>=20 >>> I am confused about the relationships among this draft, RFC 5245, >>> 5245bis, and RFC 6724. Section 1 of this draft seems to say that it >>> recommends against following the requirement in 5245 that says dual >>> stack hosts SHOULD follow the precedence in 6724. Normally, that would >>> require this draft to update 5245, which would require it to be >>> standards track. >>>=20 >>> But on the other hand, I am not entirely convinced anything here >>> really changes that SHOULD, since 6724 explicitly says: >>>=20 >>> "The selection rules specified in this document MUST NOT be construed >>> to override an application or upper layer=B9s explicit choice of a >>> legal destination or source address." >>>=20 >>> Unfortunately, I think this puts things in a grey area, due to >>> ambiguous wording in 5245. So I think this draft either needs to >>> update 5245, or it needs to explain why the guidance here does not >>> conflict with that SHOULD. >>>=20 >>> This was at least discussed in IETF90, >>>=20 >>> http://www.ietf.org/proceedings/90/minutes/minutes-90-mmusic#h.6fijdpve= an >>> aa >>=20 >> That discussion seemed to resolve to "we need to check to see if we are >> updating 2119 language" :-) >>=20 >>>=20 >>> So now my naive question is; do we care about 5245 with 5245bis soon >>> finished? >>=20 >> The same language is currently in 5245bis. >>=20 >>>=20 >>> I think we have two possible solutions. >>>=20 >>> 1. Make dual-stack fairness reference only 5245bis. Make sure text in >>> both draft harmonise. They will cross reference each other and thus >>> needs to be published at the same time? >>=20 >> Would you expect ICEBis to normatively reference this? If so, that has >> implications about the PS/Informational/BCP decisions. If so, they would >> form a cluster in the RFC editor queue. Even if they were submitted at >> different times, they would be formally published more or less at the >> same time. >>=20 >>=20 >>>=20 >>> 2. Explain why we are not braking the 5245 SHOULD and keep it as >>> informational . This is done by pointing out the appropriate text you >>> found in 6724. >>=20 >> The current text is misleading, in the way it explicitly says that >> following the SHOULD in 5245/5245bis leads to "unfair" prioritization. >> As written, it does seem to relax the SHOULD. Language clarifying that >> 6724 allows application-specific choices would be helpful. >>=20 >>=20 >>>=20 >>> And in either case: Is there an opportunity to make 5245 more clear in >>> 5245bis? >>>=20 >>>=20 >>> Absolutely. It must also point out that the formulas described in 5245 >>> section 4.1.2 have not changes so that the compatibility discussion in >>> section 5 of the dual-stack fairness draft is still valid. >>>=20 >>>=20 >>> That of course leads to the bombshell question: We are already in the >>> process of updating 5245. Why isn=B9t _this_ draft part of 5245bis? >>>=20 >>> I think the main motivation for that was to keep the ICEbis spec as >>> short as possible as there are some implementations that does not care >>> about the problem. For the implementations that do care, they should >>> read the draft and follow the recommendations. >>=20 >> I don't find that all that convincing. ICEbis talks about dual-stack >> stuff in several places, and makes that explicit statement about >> dual-stack behavior and 6724. A good part of the content of _this_ draft >> is spent describing things in ICE/ICEbis for context, and could probably >> be significantly reduced. >>=20 >> One possibility might be to move the procedure parts into ICEBis, and >> refer back to this draft for motivation and an explanation of why a >> happy eyeballs approach is useful. (Or maybe that could just go into an >> appendix of ICEbis.) >>=20 >> Now, I don't have a strong belief this needs to merge into ICEBis--I >> just want to make sure the working group has thought about the option. >> In particular, we should consider what makes things easier on the >> reader, not just what is easier from an IETF process perspective. >>=20 >>>=20 >>> Minor: >>>=20 >>> - 1: The introduction jumps right to saying applications need to >>> deprioritize interfaces without saying what problem it's trying to >>> solve. An initial paragraph that says what goes wrong with current >>> implementations would be extremely helpful. It would also help to >>> define what is meant by "fairness" in this context. (I=B9m not sure >>> it's quite the same as the conventional use of the term.) >>>=20 >>> How about: >>>=20 >>> In multihomed and IPv4/IPv6 dual-stack environments ICE [RFC5245] >>> would benefit by a fair distribution of its connectivity checks >>> across available interfaces or IP address types. With a fair >>> distribution of the connectivity checks, excessive delays are >>> avoided >>> if a particular network path is broken or slow. It would arguable >>> be >>> better to put the interfaces or address types know to the >>> application >>> last in the checklist. However, the main motivation by ICE is to >>> make no assumptions regarding network topology, hence a fair >>> distribution of the connectivity checks is more appropriate. If an >>> application operates in a well-known environment is can safely >>> override the recommendation given in this document. >>=20 >> That helps, but I still don't see s definition of what you mean by "fair >> distribution". >>=20 >>>=20 >>>=20 >>> - 2: Assuming this stays informational, it's not really using the 2119 >>> keywords quite in the spirit of 2119. Personally, I don't think the >>> current 2119 usage (outside of text directly attributed to other >>> documents, which doesn't really count) adds much. I suggest removing >>> it. >>>=20 >>> But if people are really attached to using 2119 language here, please >>> consider adjusting the boilerplate to say that, while this draft does >>> not include normative requirements, the keywords are used for the sake >>> of clarity. >>>=20 >>>=20 >>> Agree. Removed from draft. And all capital SHOULD occurrences replaced >>> with should. >>=20 >> That works for me, assuming people choose to keep this as an >> informational. >>=20 >>>=20 >>> -3, 2nd paragraph: >>>=20 >>> Does the working group believe that one can make reasonable inferences >>> from just the network type? Do you expect these to be configurable? >>> Statically defined in code? (Seems like there may be operational >>> considerations here.) >>>=20 >>> The original intent with the text was to say; =B3If you think you know >>> better, please feel free to do as you please=8A=B2. But basing it just >>> on network type seems to be a bit to fragile. >>>=20 >>> Updated text: >>> The application knowledge regarding the reliability of an interface >>> can also be based on simple metrics like previous connection >>> success/ >>> failure rates or a more static model based on interface types like >>> wired, wireless, cellular, virtual, tunneled in conjunction with >>> other operational metrics. This would require the application to >>> have the right permissions to obtain such operational metrics. >>=20 >> That helps, thanks. >>=20 >>>=20 >>>=20 >>> - 7.2: Can this be more specific about what implementations exist? The >>> boilerplate seems a bit heaviweight for something that pretty much >>> says =B3there are others" :-) >>>=20 >>>=20 >>> The section has been in and out. Main use is to inform WG and AD that >>> there are others? Others have confirmed during WG meetings that they >>> do things similar to what is described in the draft (But sometimes >>> they have more operational knowledge and are able to override things >>> in the draft). >>>=20 >>> Safe to remove this section now? >>=20 >> This sort of thing usually comes out at publication time, so it's >> probably fine for now. >>=20 >>>=20 >>>=20 >>> Editorial: >>>=20 >>> - 4 , first paragraph: How long is long? (Especially if you stick the >>> 2119 SHOULD). >>>=20 >>> I think long can be dropped. IMHO intermingling of the address types >>> is a good thing if you want to be topology agnostic. >>> The paragraph still have =B3values=B2 like many and small. I think >>> that is ok? >>>=20 >>> New paragraph: >>> Candidates should be prioritized such that a sequence of candidates >>> belonging to the same address family will be intermingled with >>> candidates from an alternate IP family. For example, promoting >>> IPv4 >>> candidates in the presence of many IPv6 candidates such that an >>> IPv4 >>> address candidate is always present after a small sequence of IPv6 >>> candidates, i.e., reordering candidates such that both IPv6 and >>> IPv4 >>> candidates get a fair chance during the connectivity check phase. >>> This makes ICE connectivity checks more responsive to broken path >>> failures of an address family. >>=20 >> WFM. >>=20 >>>=20 >>> - 5, last paragraph: Doesn=B9t this belong in the "Implementation >>> Status" section? >>>=20 >>> The intent was to guide implementers to sample code. If that is moved >>> to Implementation Status that information will be lost when published >>> as an RFC. >>>=20 >>> Previous versions had an appendix with the code examples. The WG felt >>> that that was a to strong encouragement to implement a specific >>> solution, this was something the WG did not want to do. Hence the >>> informational status of the draft. >>>=20 >>> I am fine with removing it. >>=20 >> I don't necessarily object to keeping it, but keep in mind that RFCs >> live forever, and code repositories might not. >>=20 >>>=20 >>>=20 >>> - 7.1 and 7.2 titles: s/Starck/Stack >>>=20 >>> Gahh.. Fixed even if removed later.. >>>=20 >>> - 7.1, "Level of Maturity": Are there words missing around "Tests"? >>>=20 >>> Cut and paste error. >>>=20 >>>=20 >>>=20 >>> Do you want me to post a new version of the draft with the changes. We >>> still need to resolve the 5245, 5245bis and 6724 problem. Simple >>> enough once we agree. >>=20 >> Revisions are cheap :-) I'd suggest updating with the known changes now, >> then dealing wtih the other stuff when we can. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >> _______________________________________________ >> Ice mailing list >> Ice@ietf.org >> https://www.ietf.org/mailman/listinfo/ice From nobody Mon May 23 03:58:57 2016 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 45B5E12D52B; Mon, 23 May 2016 03:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 IJHd-GQTL9EJ; Mon, 23 May 2016 03:58:52 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54FF512D17B; Mon, 23 May 2016 03:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16249; q=dns/txt; s=iport; t=1464001132; x=1465210732; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gF5u349x+RnOdumi9B6cO55DLeO2pURiKHQH3RQd5/4=; b=BI3e62Ulmol83m3s2lmPqdHET+ThquM+TzKqDXfIIxNYtW9BAy72j7yW OuKUNYxL1apGdjUSFsuyUVE3jWxXMaiPW0B6PUV+HecAVPtDxWHmfyly5 WJXnWyRj0GafUvAHVA0AEQaFYbItvXaQFo2Yz/UmTQTOp9eLjBGQkrudQ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAgAJ4kJX/5RdJa1dgzdWfQa5egENg?= =?us-ascii?q?XUXDYVtAoEuOBQBAQEBAQEBZSeEQgEBAQMBAQEBawQHBQsCAQgYJwcnCxQRAgQ?= =?us-ascii?q?OBQkSiAwIDsN8AQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYngXaCV4Q/LIMAgi4Fi?= =?us-ascii?q?AGHFoQLhRUBhm+HMIFphE+DLHuEPYYziRgBHgEBQoIGHIFLbgGIUX8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,355,1459814400"; d="scan'208";a="276616521" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 May 2016 10:58:50 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u4NAwoI5017202 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 May 2016 10:58:50 GMT Received: from xch-rtp-019.cisco.com (64.101.220.159) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 23 May 2016 06:58:49 -0400 Received: from xch-rtp-019.cisco.com ([64.101.220.159]) by XCH-RTP-019.cisco.com ([64.101.220.159]) with mapi id 15.00.1104.009; Mon, 23 May 2016 06:58:49 -0400 From: "Pal Martinsen (palmarti)" To: =?Windows-1252?Q?Ari_Ker=E4nen?= Thread-Topic: [Ice] AD Evaluation of draft-ietf-ice-dualstack-fairness-02 Thread-Index: AQHRmgXS7VKNGBrK2EGvlNTtCBMZmp+RbqUAgBZiDACAGky7gIADxGQAgADxW4A= Date: Mon, 23 May 2016 10:58:49 +0000 Message-ID: <5FB58FA2-75F4-4A13-8D0D-B83370278344@cisco.com> References: <86559E67-6412-4971-AB74-6680D079CAC8@cisco.com> <12099752-1FB6-4BB6-A9E7-1CC74871234C@ericsson.com> In-Reply-To: <12099752-1FB6-4BB6-A9E7-1CC74871234C@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.215.187] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Ben Campbell , "ice@ietf.org" , "draft-ietf-ice-dualstack-fairness.all@ietf.org" , Christer Holmberg Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-dualstack-fairness-02 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 10:58:55 -0000 > On 22 May 2016, at 22:34, Ari Ker=E4nen wrote: >=20 > Hi, >=20 > Regarding the split to different drafts, our goal with the ICEbis work wa= s to fix errors and make sure we have the right hooks and text for the exte= nsions that we need. And we decided that everything else, such as new featu= res/extra functionality, would go to different document(s). Of course the D= S draft is a borderline case, but given how much material (e.g., the algori= thm) there is, to me (chair hat off) separate document sounds still like a = better idea. >=20 > But yes, the current text in ICEbis about RFC6724 needs to be updated and= point to the dual-stack document. Having text there about the general proc= edure makes sense. >=20 > Regarding BCP or Informational for the DS draft status, I don't think we = considered the BCP option. Now thinking about it, BCP seems reasonable opti= on. >=20 +1 BCP Seems like a better option.=20 The current proposal for progressing this draft: - Move from Informational to BCP - ICEbis will have a normative reference to ICE-Dualstack fairness. (So thi= s can potentially hold up ICEbis, but probably not) - Text can be shortened a lot if we assume readers are more familiar with I= CE and only reference the appropriate ICE sections. I prefer the current te= xt as it saves readers familiar with ICE but without fresh memories of deta= ils some time looking up the appropriate ICE section.=20 - Normative references to ICEbis instead of ICE. Work with ICEbis to remove= current ambiguity of SHOULD wording regarding 6724 (Will hold publication = of draft until ICEbis is complete).=20 Not sure if this requires a new WGLC. The chairs will decide that. .-. P=E5l-Erik >=20 > Cheers, > Ari >=20 >> On 20 May 2016, at 14:03, Christer Holmberg wrote: >>=20 >>=20 >> Hi, >>=20 >> I have not been very much involved the dualstack-fairness >> work/discussions, so forgive me if the following issues have already bee= n >> discussed. >>=20 >> As the purpose of the draft is to =B3make things work better=B2, I see n= o >> reason why we simply couldn=B9t implement the change in 5245bis. I don= =B9t >> think we need too much extra text for the justification, and it could e.= g. >> be put in an appendix as suggested. >>=20 >> Now, regarding the statement that =B3some people don=B9t care/need this= =B2, how >> much will the technical change affect them? If you want to be compliant >> with 5245bis, you are anyway going to have to do some changes in your co= de. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>=20 >> On 03/05/16 20:25, "Ice on behalf of Ben Campbell" > on behalf of ben@nostrum.com> wrote: >>=20 >>> Hi, >>>=20 >>> I apologize for the delay. My schedule over the last couple of weeks ha= s >>> been disrupted by some family issues. I am ramping back up now. >>>=20 >>> So, TL;DR: I think the working group needs to have a little more >>> discussion about the status and purpose of this draft, and how it >>> relates to ICEBis. More details below. >>>=20 >>> On 19 Apr 2016, at 6:37, Pal Martinsen (palmarti) wrote: >>>=20 >>>> On 19 Apr 2016, at 08:36, Ben Campbell >>>> > wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> This is my AD Evaluation of draft-ietf-ice-dualstack-fairness-02. I >>>> find the draft readable and understandable, but I have some comments >>>> and questions. I'd like to resolve the major comments prior to IETF >>>> last call. >>>>=20 >>>> Major: >>>>=20 >>>> The draft is now informational, but the milestone is for PS. I see the >>>> minutes from Prague say the wg agreed to make the change, but that >>>> doesn't say why, and I failed to find any discussion of that on the >>>> list. Can anyone remind me of the reasoning? (This interacts with my >>>> next comment=8A) >>>>=20 >>>> Just for clarity I will summarise what I see as the key =B3events=B2 >>>> of the draft. (I might be wrong so of others see it differently please >>>> correct me) >>>>=20 >>>> - Started as an DualStack Happy Eyeballs solution that would give IPv6 >>>> a head start. >>>> - Several attempts to get a happy eyeballs algorithm working failed. >>>> And we discovered that it would be very difficult to get right in all >>>> the various scenarios. Think the =B3consensus in the hallways=B2 was >>>> to let each application deal with it as they would know more of what >>>> was important to them. >>>>=20 >>>> (http://www.ietf.org/proceedings/92/minutes/minutes-92-mmusic#h.v0jtwu= 5re >>>> 90f) >>>>=20 >>>> >>> 90f>-=20 >>>> Since the draft only contains guidelines on how an application should >>>> deal with dual-stack it made sense to make it informational. >>>>=20 >>>> (http://www.ietf.org/proceedings/93/minutes/minutes-93-mmusic#h.34ilx3= y4v >>>> kbd) >>>=20 >>> The right choice here depends on what the working group expects the >>> draft to accomplish. I think informational works if we want to tell >>> implementors about some things they can do if they care. If, on the >>> other hand, we want to actually encourage implementors to implement >>> this, then I'm not sure informational is the right choice. Did the WG >>> consider BCP? >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> I am confused about the relationships among this draft, RFC 5245, >>>> 5245bis, and RFC 6724. Section 1 of this draft seems to say that it >>>> recommends against following the requirement in 5245 that says dual >>>> stack hosts SHOULD follow the precedence in 6724. Normally, that would >>>> require this draft to update 5245, which would require it to be >>>> standards track. >>>>=20 >>>> But on the other hand, I am not entirely convinced anything here >>>> really changes that SHOULD, since 6724 explicitly says: >>>>=20 >>>> "The selection rules specified in this document MUST NOT be construed >>>> to override an application or upper layer=B9s explicit choice of a >>>> legal destination or source address." >>>>=20 >>>> Unfortunately, I think this puts things in a grey area, due to >>>> ambiguous wording in 5245. So I think this draft either needs to >>>> update 5245, or it needs to explain why the guidance here does not >>>> conflict with that SHOULD. >>>>=20 >>>> This was at least discussed in IETF90, >>>>=20 >>>> http://www.ietf.org/proceedings/90/minutes/minutes-90-mmusic#h.6fijdpv= ean >>>> aa >>>=20 >>> That discussion seemed to resolve to "we need to check to see if we are >>> updating 2119 language" :-) >>>=20 >>>>=20 >>>> So now my naive question is; do we care about 5245 with 5245bis soon >>>> finished? >>>=20 >>> The same language is currently in 5245bis. >>>=20 >>>>=20 >>>> I think we have two possible solutions. >>>>=20 >>>> 1. Make dual-stack fairness reference only 5245bis. Make sure text in >>>> both draft harmonise. They will cross reference each other and thus >>>> needs to be published at the same time? >>>=20 >>> Would you expect ICEBis to normatively reference this? If so, that has >>> implications about the PS/Informational/BCP decisions. If so, they woul= d >>> form a cluster in the RFC editor queue. Even if they were submitted at >>> different times, they would be formally published more or less at the >>> same time. >>>=20 >>>=20 >>>>=20 >>>> 2. Explain why we are not braking the 5245 SHOULD and keep it as >>>> informational . This is done by pointing out the appropriate text you >>>> found in 6724. >>>=20 >>> The current text is misleading, in the way it explicitly says that >>> following the SHOULD in 5245/5245bis leads to "unfair" prioritization. >>> As written, it does seem to relax the SHOULD. Language clarifying that >>> 6724 allows application-specific choices would be helpful. >>>=20 >>>=20 >>>>=20 >>>> And in either case: Is there an opportunity to make 5245 more clear in >>>> 5245bis? >>>>=20 >>>>=20 >>>> Absolutely. It must also point out that the formulas described in 5245 >>>> section 4.1.2 have not changes so that the compatibility discussion in >>>> section 5 of the dual-stack fairness draft is still valid. >>>>=20 >>>>=20 >>>> That of course leads to the bombshell question: We are already in the >>>> process of updating 5245. Why isn=B9t _this_ draft part of 5245bis? >>>>=20 >>>> I think the main motivation for that was to keep the ICEbis spec as >>>> short as possible as there are some implementations that does not care >>>> about the problem. For the implementations that do care, they should >>>> read the draft and follow the recommendations. >>>=20 >>> I don't find that all that convincing. ICEbis talks about dual-stack >>> stuff in several places, and makes that explicit statement about >>> dual-stack behavior and 6724. A good part of the content of _this_ draf= t >>> is spent describing things in ICE/ICEbis for context, and could probabl= y >>> be significantly reduced. >>>=20 >>> One possibility might be to move the procedure parts into ICEBis, and >>> refer back to this draft for motivation and an explanation of why a >>> happy eyeballs approach is useful. (Or maybe that could just go into an >>> appendix of ICEbis.) >>>=20 >>> Now, I don't have a strong belief this needs to merge into ICEBis--I >>> just want to make sure the working group has thought about the option. >>> In particular, we should consider what makes things easier on the >>> reader, not just what is easier from an IETF process perspective. >>>=20 >>>>=20 >>>> Minor: >>>>=20 >>>> - 1: The introduction jumps right to saying applications need to >>>> deprioritize interfaces without saying what problem it's trying to >>>> solve. An initial paragraph that says what goes wrong with current >>>> implementations would be extremely helpful. It would also help to >>>> define what is meant by "fairness" in this context. (I=B9m not sure >>>> it's quite the same as the conventional use of the term.) >>>>=20 >>>> How about: >>>>=20 >>>> In multihomed and IPv4/IPv6 dual-stack environments ICE [RFC5245] >>>> would benefit by a fair distribution of its connectivity checks >>>> across available interfaces or IP address types. With a fair >>>> distribution of the connectivity checks, excessive delays are >>>> avoided >>>> if a particular network path is broken or slow. It would arguable >>>> be >>>> better to put the interfaces or address types know to the >>>> application >>>> last in the checklist. However, the main motivation by ICE is to >>>> make no assumptions regarding network topology, hence a fair >>>> distribution of the connectivity checks is more appropriate. If an >>>> application operates in a well-known environment is can safely >>>> override the recommendation given in this document. >>>=20 >>> That helps, but I still don't see s definition of what you mean by "fai= r >>> distribution". >>>=20 >>>>=20 >>>>=20 >>>> - 2: Assuming this stays informational, it's not really using the 2119 >>>> keywords quite in the spirit of 2119. Personally, I don't think the >>>> current 2119 usage (outside of text directly attributed to other >>>> documents, which doesn't really count) adds much. I suggest removing >>>> it. >>>>=20 >>>> But if people are really attached to using 2119 language here, please >>>> consider adjusting the boilerplate to say that, while this draft does >>>> not include normative requirements, the keywords are used for the sake >>>> of clarity. >>>>=20 >>>>=20 >>>> Agree. Removed from draft. And all capital SHOULD occurrences replaced >>>> with should. >>>=20 >>> That works for me, assuming people choose to keep this as an >>> informational. >>>=20 >>>>=20 >>>> -3, 2nd paragraph: >>>>=20 >>>> Does the working group believe that one can make reasonable inferences >>>> from just the network type? Do you expect these to be configurable? >>>> Statically defined in code? (Seems like there may be operational >>>> considerations here.) >>>>=20 >>>> The original intent with the text was to say; =B3If you think you know >>>> better, please feel free to do as you please=8A=B2. But basing it just >>>> on network type seems to be a bit to fragile. >>>>=20 >>>> Updated text: >>>> The application knowledge regarding the reliability of an interface >>>> can also be based on simple metrics like previous connection >>>> success/ >>>> failure rates or a more static model based on interface types like >>>> wired, wireless, cellular, virtual, tunneled in conjunction with >>>> other operational metrics. This would require the application to >>>> have the right permissions to obtain such operational metrics. >>>=20 >>> That helps, thanks. >>>=20 >>>>=20 >>>>=20 >>>> - 7.2: Can this be more specific about what implementations exist? The >>>> boilerplate seems a bit heaviweight for something that pretty much >>>> says =B3there are others" :-) >>>>=20 >>>>=20 >>>> The section has been in and out. Main use is to inform WG and AD that >>>> there are others? Others have confirmed during WG meetings that they >>>> do things similar to what is described in the draft (But sometimes >>>> they have more operational knowledge and are able to override things >>>> in the draft). >>>>=20 >>>> Safe to remove this section now? >>>=20 >>> This sort of thing usually comes out at publication time, so it's >>> probably fine for now. >>>=20 >>>>=20 >>>>=20 >>>> Editorial: >>>>=20 >>>> - 4 , first paragraph: How long is long? (Especially if you stick the >>>> 2119 SHOULD). >>>>=20 >>>> I think long can be dropped. IMHO intermingling of the address types >>>> is a good thing if you want to be topology agnostic. >>>> The paragraph still have =B3values=B2 like many and small. I think >>>> that is ok? >>>>=20 >>>> New paragraph: >>>> Candidates should be prioritized such that a sequence of candidates >>>> belonging to the same address family will be intermingled with >>>> candidates from an alternate IP family. For example, promoting >>>> IPv4 >>>> candidates in the presence of many IPv6 candidates such that an >>>> IPv4 >>>> address candidate is always present after a small sequence of IPv6 >>>> candidates, i.e., reordering candidates such that both IPv6 and >>>> IPv4 >>>> candidates get a fair chance during the connectivity check phase. >>>> This makes ICE connectivity checks more responsive to broken path >>>> failures of an address family. >>>=20 >>> WFM. >>>=20 >>>>=20 >>>> - 5, last paragraph: Doesn=B9t this belong in the "Implementation >>>> Status" section? >>>>=20 >>>> The intent was to guide implementers to sample code. If that is moved >>>> to Implementation Status that information will be lost when published >>>> as an RFC. >>>>=20 >>>> Previous versions had an appendix with the code examples. The WG felt >>>> that that was a to strong encouragement to implement a specific >>>> solution, this was something the WG did not want to do. Hence the >>>> informational status of the draft. >>>>=20 >>>> I am fine with removing it. >>>=20 >>> I don't necessarily object to keeping it, but keep in mind that RFCs >>> live forever, and code repositories might not. >>>=20 >>>>=20 >>>>=20 >>>> - 7.1 and 7.2 titles: s/Starck/Stack >>>>=20 >>>> Gahh.. Fixed even if removed later.. >>>>=20 >>>> - 7.1, "Level of Maturity": Are there words missing around "Tests"? >>>>=20 >>>> Cut and paste error. >>>>=20 >>>>=20 >>>>=20 >>>> Do you want me to post a new version of the draft with the changes. We >>>> still need to resolve the 5245, 5245bis and 6724 problem. Simple >>>> enough once we agree. >>>=20 >>> Revisions are cheap :-) I'd suggest updating with the known changes now= , >>> then dealing wtih the other stuff when we can. >>>=20 >>> Thanks! >>>=20 >>> Ben. >>>=20 >>> _______________________________________________ >>> Ice mailing list >>> Ice@ietf.org >>> https://www.ietf.org/mailman/listinfo/ice >=20 From nobody Mon May 23 04:14:54 2016 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 5093212D67E; Mon, 23 May 2016 04:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 MTpNZ4E2iGeD; Mon, 23 May 2016 04:14:50 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A715C12D678; Mon, 23 May 2016 04:14:49 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-6b-5742e61b9604 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BC.E5.12516.B16E2475; Mon, 23 May 2016 13:14:35 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0294.000; Mon, 23 May 2016 13:14:35 +0200 From: Christer Holmberg To: "Pal Martinsen (palmarti)" , =?utf-8?B?QXJpIEtlcsOkbmVu?= Thread-Topic: [Ice] AD Evaluation of draft-ietf-ice-dualstack-fairness-02 Thread-Index: AQHRpWEb5Ssc2siO0EqGhesod9eww5/B1REAgAORcwCAAPFegIAAN2CA Date: Mon, 23 May 2016 11:14:35 +0000 Message-ID: References: <86559E67-6412-4971-AB74-6680D079CAC8@cisco.com> <12099752-1FB6-4BB6-A9E7-1CC74871234C@ericsson.com> <5FB58FA2-75F4-4A13-8D0D-B83370278344@cisco.com> In-Reply-To: <5FB58FA2-75F4-4A13-8D0D-B83370278344@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="utf-8" Content-ID: <5CA73EE0137E1F419850EDA06D1C82A5@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFIsWRmVeSWpSXmKPExsUyM2K7sa70M6dwgz1PtS3md55mt/h9vpHZ 4tuFWov311eyOLB4TPm9kdVjyZKfTB6zdj5hCWCO4rJJSc3JLEst0rdL4MpoPvGQsaBjC2PF 32e3mBsYd6xn7GLk5JAQMJFo2LGZDcIWk7hwbz2QzcUhJHCEUWLboVtQzhJGiT8Xp7F0MXJw sAlYSHT/0wYxRQTyJPbd1QIpYRZYxSjxY8VysKHCAh4SR782gg0VEfCU2Le5kx3CdpPYPvEg M4jNIqAq8XDSPSYQm1fASuLCpyVQuw4wSbxY0M8KkuAUsJWYe/EIWBEj0HXfT60Bs5kFxCVu PZnPBHG1gMSSPeeZIWxRiZeP/4H1igroSex7cZ4R5FAJAUWJ5f1yICazgKbE+l36EFOsJRYd eQ81UVFiSvdDdohzBCVOznzCMoFRYhaSZbMQumch6Z6FpHsWku4FjKyrGEWLU4uLc9ONjPVS izKTi4vz8/TyUks2MQJj9OCW37o7GFe/djzEKMDBqMTD+0DbKVyINbGsuDL3EKMEB7OSCG/3 E6AQb0piZVVqUX58UWlOavEhRmkOFiVxXv+XiuFCAumJJanZqakFqUUwWSYOTqkGxpJ/R0Pm LN2jvvr48e9Se3U0rz6dsr/f4OQsXVvPjU/OxNQzrWdyzL1SpFg3X0RX8uAjHf+Du6um7ijJ 0hH+nPZojYBJlk2XQMw2CbFpatrnfXoCguv6np37PcNvbVXaZ6tPJ1bujHv6zbL4i/1ue/ED YWxsp0N5mn5OsixQ3GHsqvg8SYc1WYmlOCPRUIu5qDgRAMP3AwnNAgAA Archived-At: Cc: Ben Campbell , "draft-ietf-ice-dualstack-fairness.all@ietf.org" , "ice@ietf.org" Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-dualstack-fairness-02 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 11:14:53 -0000 SGksDQoNCj4+UmVnYXJkaW5nIHRoZSBzcGxpdCB0byBkaWZmZXJlbnQgZHJhZnRzLCBvdXIgZ29h bCB3aXRoIHRoZSBJQ0ViaXMgd29yaw0KPj53YXMgdG8gZml4IGVycm9ycyBhbmQgbWFrZSBzdXJl IHdlIGhhdmUgdGhlIHJpZ2h0IGhvb2tzIGFuZCB0ZXh0IGZvciB0aGUNCj4+ZXh0ZW5zaW9ucyB0 aGF0IHdlIG5lZWQuIEFuZCB3ZSBkZWNpZGVkIHRoYXQgZXZlcnl0aGluZyBlbHNlLCBzdWNoIGFz DQo+Pm5ldyBmZWF0dXJlcy9leHRyYSBmdW5jdGlvbmFsaXR5LCB3b3VsZCBnbyB0byBkaWZmZXJl bnQgZG9jdW1lbnQocykuIE9mDQo+PmNvdXJzZSB0aGUgRFMgZHJhZnQgaXMgYSBib3JkZXJsaW5l IGNhc2UsIGJ1dCBnaXZlbiBob3cgbXVjaCBtYXRlcmlhbA0KPj4oZS5nLiwgdGhlIGFsZ29yaXRo bSkgdGhlcmUgaXMsIHRvIG1lIChjaGFpciBoYXQgb2ZmKSBzZXBhcmF0ZSBkb2N1bWVudA0KPj5z b3VuZHMgc3RpbGwgbGlrZSBhIGJldHRlciBpZGVhLg0KPj4gDQo+PiBCdXQgeWVzLCB0aGUgY3Vy cmVudCB0ZXh0IGluIElDRWJpcyBhYm91dCBSRkM2NzI0IG5lZWRzIHRvIGJlIHVwZGF0ZWQNCj4+ YW5kIHBvaW50IHRvIHRoZSBkdWFsLXN0YWNrIGRvY3VtZW50LiBIYXZpbmcgdGV4dCB0aGVyZSBh Ym91dCB0aGUNCj4+Z2VuZXJhbCBwcm9jZWR1cmUgbWFrZXMgc2Vuc2UuDQo+PiANCj4+IFJlZ2Fy ZGluZyBCQ1Agb3IgSW5mb3JtYXRpb25hbCBmb3IgdGhlIERTIGRyYWZ0IHN0YXR1cywgSSBkb24n dCB0aGluaw0KPj53ZSBjb25zaWRlcmVkIHRoZSBCQ1Agb3B0aW9uLiBOb3cgdGhpbmtpbmcgYWJv dXQgaXQsIEJDUCBzZWVtcw0KPj5yZWFzb25hYmxlIG9wdGlvbi4NCj4+IA0KPg0KPisxIEJDUCBT ZWVtcyBsaWtlIGEgYmV0dGVyIG9wdGlvbi4NCj4NCj5UaGUgY3VycmVudCBwcm9wb3NhbCBmb3Ig cHJvZ3Jlc3NpbmcgdGhpcyBkcmFmdDoNCj4tIE1vdmUgZnJvbSBJbmZvcm1hdGlvbmFsIHRvIEJD UA0KPi0gSUNFYmlzIHdpbGwgaGF2ZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gSUNFLUR1YWxz dGFjayBmYWlybmVzcy4gKFNvDQo+dGhpcyBjYW4gcG90ZW50aWFsbHkgaG9sZCB1cCBJQ0ViaXMs IGJ1dCBwcm9iYWJseSBub3QpDQoNCkp1c3QgdG8gdmVyaWZ5OiBpcyBpdCBhbGxvd2VkIHRvIGhh dmUgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIGEgQkNQPw0KDQo+LSBUZXh0IGNhbiBiZSBzaG9y dGVuZWQgYSBsb3QgaWYgd2UgYXNzdW1lIHJlYWRlcnMgYXJlIG1vcmUgZmFtaWxpYXIgd2l0aA0K PklDRSBhbmQgb25seSByZWZlcmVuY2UgdGhlIGFwcHJvcHJpYXRlIElDRSBzZWN0aW9ucy4gSSBw cmVmZXIgdGhlIGN1cnJlbnQNCj50ZXh0IGFzIGl0IHNhdmVzIHJlYWRlcnMgZmFtaWxpYXIgd2l0 aCBJQ0UgYnV0IHdpdGhvdXQgZnJlc2ggbWVtb3JpZXMgb2YNCj5kZXRhaWxzIHNvbWUgdGltZSBs b29raW5nIHVwIHRoZSBhcHByb3ByaWF0ZSBJQ0Ugc2VjdGlvbi4NCg0KSWYgd2Uga2VlcCBpdCBh cyBhIHNlcGFyYXRlIGRyYWZ0LCBJIHBlcnNvbmFsbHkgaGF2ZSBubyBzdHJvbmcgb3BpbmlvbiBv bg0KaG93IG11Y2ggdGV4dCBpcyBrZXB0Lg0KDQo+IA0KPi0gTm9ybWF0aXZlIHJlZmVyZW5jZXMg dG8gSUNFYmlzIGluc3RlYWQgb2YgSUNFLg0KDQpZZXMgLSB0aGlzIGlzIHNvbWV0aGluZyB3ZSBz aG91bGQgZG8gaW4gQUxMIG5ldy9vbmdvaW5nIHdvcmsgcmVmZXJlbmNpbmcNCklDRSAodW5sZXNz IHRoZXJlIGFyZSBjYXNlcyB3aGVyZSwgZm9yIHNvbWUgcmVhc29uLCB3ZSBleHBsaWNpdGx5IG5l ZCB0bw0KcmVmZXJlbmNlIFJGQyA1MjQ2KS4NCg0KPiBXb3JrIHdpdGggSUNFYmlzIHRvIHJlbW92 ZSBjdXJyZW50IGFtYmlndWl0eSBvZiBTSE9VTEQgd29yZGluZyByZWdhcmRpbmcNCj42NzI0IChX aWxsIGhvbGQgcHVibGljYXRpb24gb2YgZHJhZnQgdW50aWwgSUNFYmlzIGlzIGNvbXBsZXRlKS4N Cg0KRmVlbCBmcmVlIHRvIHN1Z2dlc3QgdGV4dCA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K DQoNCj4gDQo+DQo+Tm90IHN1cmUgaWYgdGhpcyByZXF1aXJlcyBhIG5ldyBXR0xDLiBUaGUgY2hh aXJzIHdpbGwgZGVjaWRlIHRoYXQuDQo+DQo+Li0uDQo+UMOlbC1FcmlrDQo+DQo+PiANCj4+IENo ZWVycywNCj4+IEFyaQ0KPj4gDQo+Pj4gT24gMjAgTWF5IDIwMTYsIGF0IDE0OjAzLCBDaHJpc3Rl ciBIb2xtYmVyZw0KPj4+PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+ Pj4gDQo+Pj4gDQo+Pj4gSGksDQo+Pj4gDQo+Pj4gSSBoYXZlIG5vdCBiZWVuIHZlcnkgbXVjaCBp bnZvbHZlZCB0aGUgZHVhbHN0YWNrLWZhaXJuZXNzDQo+Pj4gd29yay9kaXNjdXNzaW9ucywgc28g Zm9yZ2l2ZSBtZSBpZiB0aGUgZm9sbG93aW5nIGlzc3VlcyBoYXZlIGFscmVhZHkNCj4+PmJlZW4N Cj4+PiBkaXNjdXNzZWQuDQo+Pj4gDQo+Pj4gQXMgdGhlIHB1cnBvc2Ugb2YgdGhlIGRyYWZ0IGlz IHRvIMKzbWFrZSB0aGluZ3Mgd29yayBiZXR0ZXLCsiwgSSBzZWUgbm8NCj4+PiByZWFzb24gd2h5 IHdlIHNpbXBseSBjb3VsZG7CuXQgaW1wbGVtZW50IHRoZSBjaGFuZ2UgaW4gNTI0NWJpcy4gSSBk b27CuXQNCj4+PiB0aGluayB3ZSBuZWVkIHRvbyBtdWNoIGV4dHJhIHRleHQgZm9yIHRoZSBqdXN0 aWZpY2F0aW9uLCBhbmQgaXQgY291bGQNCj4+PmUuZy4NCj4+PiBiZSBwdXQgaW4gYW4gYXBwZW5k aXggYXMgc3VnZ2VzdGVkLg0KPj4+IA0KPj4+IE5vdywgcmVnYXJkaW5nIHRoZSBzdGF0ZW1lbnQg dGhhdCDCs3NvbWUgcGVvcGxlIGRvbsK5dCBjYXJlL25lZWQgdGhpc8KyLA0KPj4+aG93DQo+Pj4g bXVjaCB3aWxsIHRoZSB0ZWNobmljYWwgY2hhbmdlIGFmZmVjdCB0aGVtPyBJZiB5b3Ugd2FudCB0 byBiZSBjb21wbGlhbnQNCj4+PiB3aXRoIDUyNDViaXMsIHlvdSBhcmUgYW55d2F5IGdvaW5nIHRv IGhhdmUgdG8gZG8gc29tZSBjaGFuZ2VzIGluIHlvdXINCj4+PmNvZGUuDQo+Pj4gDQo+Pj4gUmVn YXJkcywNCj4+PiANCj4+PiBDaHJpc3Rlcg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IA0K Pj4+IE9uIDAzLzA1LzE2IDIwOjI1LCAiSWNlIG9uIGJlaGFsZiBvZiBCZW4gQ2FtcGJlbGwiDQo+ Pj48aWNlLWJvdW5jZXNAaWV0Zi5vcmcNCj4+PiBvbiBiZWhhbGYgb2YgYmVuQG5vc3RydW0uY29t PiB3cm90ZToNCj4+PiANCj4+Pj4gSGksDQo+Pj4+IA0KPj4+PiBJIGFwb2xvZ2l6ZSBmb3IgdGhl IGRlbGF5LiBNeSBzY2hlZHVsZSBvdmVyIHRoZSBsYXN0IGNvdXBsZSBvZiB3ZWVrcw0KPj4+Pmhh cw0KPj4+PiBiZWVuIGRpc3J1cHRlZCBieSBzb21lIGZhbWlseSBpc3N1ZXMuIEkgYW0gcmFtcGlu ZyBiYWNrIHVwIG5vdy4NCj4+Pj4gDQo+Pj4+IFNvLCBUTDtEUjogSSB0aGluayB0aGUgd29ya2lu ZyBncm91cCBuZWVkcyB0byBoYXZlIGEgbGl0dGxlIG1vcmUNCj4+Pj4gZGlzY3Vzc2lvbiBhYm91 dCB0aGUgc3RhdHVzIGFuZCBwdXJwb3NlIG9mIHRoaXMgZHJhZnQsIGFuZCBob3cgaXQNCj4+Pj4g cmVsYXRlcyB0byBJQ0VCaXMuIE1vcmUgZGV0YWlscyBiZWxvdy4NCj4+Pj4gDQo+Pj4+IE9uIDE5 IEFwciAyMDE2LCBhdCA2OjM3LCBQYWwgTWFydGluc2VuIChwYWxtYXJ0aSkgd3JvdGU6DQo+Pj4+ IA0KPj4+Pj4gT24gMTkgQXByIDIwMTYsIGF0IDA4OjM2LCBCZW4gQ2FtcGJlbGwNCj4+Pj4+IDxi ZW5Abm9zdHJ1bS5jb208bWFpbHRvOmJlbkBub3N0cnVtLmNvbT4+IHdyb3RlOg0KPj4+Pj4gDQo+ Pj4+PiBIaSwNCj4+Pj4+IA0KPj4+Pj4gVGhpcyBpcyBteSBBRCBFdmFsdWF0aW9uIG9mIGRyYWZ0 LWlldGYtaWNlLWR1YWxzdGFjay1mYWlybmVzcy0wMi4gSQ0KPj4+Pj4gZmluZCB0aGUgZHJhZnQg cmVhZGFibGUgYW5kIHVuZGVyc3RhbmRhYmxlLCBidXQgSSBoYXZlIHNvbWUgY29tbWVudHMNCj4+ Pj4+IGFuZCBxdWVzdGlvbnMuIEknZCBsaWtlIHRvIHJlc29sdmUgdGhlIG1ham9yIGNvbW1lbnRz IHByaW9yIHRvIElFVEYNCj4+Pj4+IGxhc3QgY2FsbC4NCj4+Pj4+IA0KPj4+Pj4gTWFqb3I6DQo+ Pj4+PiANCj4+Pj4+IFRoZSBkcmFmdCBpcyBub3cgaW5mb3JtYXRpb25hbCwgYnV0IHRoZSBtaWxl c3RvbmUgaXMgZm9yIFBTLiBJIHNlZQ0KPj4+Pj50aGUNCj4+Pj4+IG1pbnV0ZXMgZnJvbSBQcmFn dWUgc2F5IHRoZSB3ZyBhZ3JlZWQgdG8gbWFrZSB0aGUgY2hhbmdlLCBidXQgdGhhdA0KPj4+Pj4g ZG9lc24ndCBzYXkgd2h5LCBhbmQgSSBmYWlsZWQgdG8gZmluZCBhbnkgZGlzY3Vzc2lvbiBvZiB0 aGF0IG9uIHRoZQ0KPj4+Pj4gbGlzdC4gQ2FuIGFueW9uZSByZW1pbmQgbWUgb2YgdGhlIHJlYXNv bmluZz8gKFRoaXMgaW50ZXJhY3RzIHdpdGggbXkNCj4+Pj4+IG5leHQgY29tbWVudMWgKQ0KPj4+ Pj4gDQo+Pj4+PiBKdXN0IGZvciBjbGFyaXR5IEkgd2lsbCBzdW1tYXJpc2Ugd2hhdCBJIHNlZSBh cyB0aGUga2V5IMKzZXZlbnRzwrINCj4+Pj4+IG9mIHRoZSBkcmFmdC4gKEkgbWlnaHQgYmUgd3Jv bmcgc28gb2Ygb3RoZXJzIHNlZSBpdCBkaWZmZXJlbnRseQ0KPj4+Pj5wbGVhc2UNCj4+Pj4+IGNv cnJlY3QgbWUpDQo+Pj4+PiANCj4+Pj4+IC0gU3RhcnRlZCBhcyBhbiBEdWFsU3RhY2sgSGFwcHkg RXllYmFsbHMgc29sdXRpb24gdGhhdCB3b3VsZCBnaXZlDQo+Pj4+PklQdjYNCj4+Pj4+IGEgaGVh ZCBzdGFydC4NCj4+Pj4+IC0gU2V2ZXJhbCBhdHRlbXB0cyB0byBnZXQgYSBoYXBweSBleWViYWxs cyBhbGdvcml0aG0gd29ya2luZyBmYWlsZWQuDQo+Pj4+PiBBbmQgd2UgZGlzY292ZXJlZCB0aGF0 IGl0IHdvdWxkIGJlIHZlcnkgZGlmZmljdWx0IHRvIGdldCByaWdodCBpbiBhbGwNCj4+Pj4+IHRo ZSB2YXJpb3VzIHNjZW5hcmlvcy4gVGhpbmsgdGhlIMKzY29uc2Vuc3VzIGluIHRoZSBoYWxsd2F5 c8KyIHdhcw0KPj4+Pj4gdG8gbGV0IGVhY2ggYXBwbGljYXRpb24gZGVhbCB3aXRoIGl0IGFzIHRo ZXkgd291bGQga25vdyBtb3JlIG9mIHdoYXQNCj4+Pj4+IHdhcyBpbXBvcnRhbnQgdG8gdGhlbS4N Cj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PihodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzky L21pbnV0ZXMvbWludXRlcy05Mi1tbXVzaWMjaC52MGp0d3UNCj4+Pj4+NXJlDQo+Pj4+PiA5MGYp DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj48aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85 Mi9taW51dGVzL21pbnV0ZXMtOTItbW11c2ljI2gudjBqdHd1DQo+Pj4+PjVyZQ0KPj4+Pj4gOTBm Pi0gDQo+Pj4+PiBTaW5jZSB0aGUgZHJhZnQgb25seSBjb250YWlucyBndWlkZWxpbmVzIG9uIGhv dyBhbiBhcHBsaWNhdGlvbiBzaG91bGQNCj4+Pj4+IGRlYWwgd2l0aCBkdWFsLXN0YWNrIGl0IG1h ZGUgc2Vuc2UgdG8gbWFrZSBpdCBpbmZvcm1hdGlvbmFsLg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+ KGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTMvbWludXRlcy9taW51dGVzLTkzLW1t dXNpYyNoLjM0aWx4Mw0KPj4+Pj55NHYNCj4+Pj4+IGtiZCkNCj4+Pj4gDQo+Pj4+IFRoZSByaWdo dCBjaG9pY2UgaGVyZSBkZXBlbmRzIG9uIHdoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgZXhwZWN0cyB0 aGUNCj4+Pj4gZHJhZnQgdG8gYWNjb21wbGlzaC4gSSB0aGluayBpbmZvcm1hdGlvbmFsIHdvcmtz IGlmIHdlIHdhbnQgdG8gdGVsbA0KPj4+PiBpbXBsZW1lbnRvcnMgYWJvdXQgc29tZSB0aGluZ3Mg dGhleSBjYW4gZG8gaWYgdGhleSBjYXJlLiBJZiwgb24gdGhlDQo+Pj4+IG90aGVyIGhhbmQsIHdl IHdhbnQgdG8gYWN0dWFsbHkgZW5jb3VyYWdlIGltcGxlbWVudG9ycyB0byBpbXBsZW1lbnQNCj4+ Pj4gdGhpcywgdGhlbiBJJ20gbm90IHN1cmUgaW5mb3JtYXRpb25hbCBpcyB0aGUgcmlnaHQgY2hv aWNlLiBEaWQgdGhlIFdHDQo+Pj4+IGNvbnNpZGVyIEJDUD8NCj4+Pj4gDQo+Pj4+PiANCj4+Pj4+ IA0KPj4+Pj4gDQo+Pj4+PiBJIGFtIGNvbmZ1c2VkIGFib3V0IHRoZSByZWxhdGlvbnNoaXBzIGFt b25nIHRoaXMgZHJhZnQsIFJGQyA1MjQ1LA0KPj4+Pj4gNTI0NWJpcywgYW5kIFJGQyA2NzI0LiBT ZWN0aW9uIDEgb2YgdGhpcyBkcmFmdCBzZWVtcyB0byBzYXkgdGhhdCBpdA0KPj4+Pj4gcmVjb21t ZW5kcyBhZ2FpbnN0IGZvbGxvd2luZyB0aGUgcmVxdWlyZW1lbnQgaW4gNTI0NSB0aGF0IHNheXMg ZHVhbA0KPj4+Pj4gc3RhY2sgaG9zdHMgU0hPVUxEIGZvbGxvdyB0aGUgcHJlY2VkZW5jZSBpbiA2 NzI0LiBOb3JtYWxseSwgdGhhdA0KPj4+Pj53b3VsZA0KPj4+Pj4gcmVxdWlyZSB0aGlzIGRyYWZ0 IHRvIHVwZGF0ZSA1MjQ1LCB3aGljaCB3b3VsZCByZXF1aXJlIGl0IHRvIGJlDQo+Pj4+PiBzdGFu ZGFyZHMgdHJhY2suDQo+Pj4+PiANCj4+Pj4+IEJ1dCBvbiB0aGUgb3RoZXIgaGFuZCwgSSBhbSBu b3QgZW50aXJlbHkgY29udmluY2VkIGFueXRoaW5nIGhlcmUNCj4+Pj4+IHJlYWxseSBjaGFuZ2Vz IHRoYXQgU0hPVUxELCBzaW5jZSA2NzI0IGV4cGxpY2l0bHkgc2F5czoNCj4+Pj4+IA0KPj4+Pj4g IlRoZSBzZWxlY3Rpb24gcnVsZXMgc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQgTVVTVCBOT1Qg YmUgY29uc3RydWVkDQo+Pj4+PiB0byBvdmVycmlkZSBhbiBhcHBsaWNhdGlvbiBvciB1cHBlciBs YXllcsK5cyBleHBsaWNpdCBjaG9pY2Ugb2YgYQ0KPj4+Pj4gbGVnYWwgZGVzdGluYXRpb24gb3Ig c291cmNlIGFkZHJlc3MuIg0KPj4+Pj4gDQo+Pj4+PiBVbmZvcnR1bmF0ZWx5LCBJIHRoaW5rIHRo aXMgcHV0cyB0aGluZ3MgaW4gYSBncmV5IGFyZWEsIGR1ZSB0bw0KPj4+Pj4gYW1iaWd1b3VzIHdv cmRpbmcgaW4gNTI0NS4gU28gSSB0aGluayB0aGlzIGRyYWZ0IGVpdGhlciBuZWVkcyB0bw0KPj4+ Pj4gdXBkYXRlIDUyNDUsIG9yIGl0IG5lZWRzIHRvIGV4cGxhaW4gd2h5IHRoZSBndWlkYW5jZSBo ZXJlIGRvZXMgbm90DQo+Pj4+PiBjb25mbGljdCB3aXRoIHRoYXQgU0hPVUxELg0KPj4+Pj4gDQo+ Pj4+PiBUaGlzIHdhcyBhdCBsZWFzdCBkaXNjdXNzZWQgaW4gSUVURjkwLA0KPj4+Pj4gDQo+Pj4+ PiANCj4+Pj4+aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85MC9taW51dGVzL21pbnV0 ZXMtOTAtbW11c2ljI2guNmZpamRwdg0KPj4+Pj5lYW4NCj4+Pj4+IGFhDQo+Pj4+IA0KPj4+PiBU aGF0IGRpc2N1c3Npb24gc2VlbWVkIHRvIHJlc29sdmUgdG8gIndlIG5lZWQgdG8gY2hlY2sgdG8g c2VlIGlmIHdlDQo+Pj4+YXJlDQo+Pj4+IHVwZGF0aW5nIDIxMTkgbGFuZ3VhZ2UiIDotKQ0KPj4+ PiANCj4+Pj4+IA0KPj4+Pj4gU28gbm93IG15IG5haXZlIHF1ZXN0aW9uIGlzOyBkbyB3ZSBjYXJl IGFib3V0IDUyNDUgd2l0aCA1MjQ1YmlzIHNvb24NCj4+Pj4+IGZpbmlzaGVkPw0KPj4+PiANCj4+ Pj4gVGhlIHNhbWUgbGFuZ3VhZ2UgaXMgY3VycmVudGx5IGluIDUyNDViaXMuDQo+Pj4+IA0KPj4+ Pj4gDQo+Pj4+PiBJIHRoaW5rIHdlIGhhdmUgdHdvIHBvc3NpYmxlIHNvbHV0aW9ucy4NCj4+Pj4+ IA0KPj4+Pj4gMS4gTWFrZSBkdWFsLXN0YWNrIGZhaXJuZXNzIHJlZmVyZW5jZSBvbmx5IDUyNDVi aXMuIE1ha2Ugc3VyZSB0ZXh0IGluDQo+Pj4+PiBib3RoIGRyYWZ0IGhhcm1vbmlzZS4gVGhleSB3 aWxsIGNyb3NzIHJlZmVyZW5jZSBlYWNoIG90aGVyIGFuZCB0aHVzDQo+Pj4+PiBuZWVkcyB0byBi ZSBwdWJsaXNoZWQgYXQgdGhlIHNhbWUgdGltZT8NCj4+Pj4gDQo+Pj4+IFdvdWxkIHlvdSBleHBl Y3QgSUNFQmlzIHRvIG5vcm1hdGl2ZWx5IHJlZmVyZW5jZSB0aGlzPyBJZiBzbywgdGhhdCBoYXMN Cj4+Pj4gaW1wbGljYXRpb25zIGFib3V0IHRoZSBQUy9JbmZvcm1hdGlvbmFsL0JDUCBkZWNpc2lv bnMuIElmIHNvLCB0aGV5DQo+Pj4+d291bGQNCj4+Pj4gZm9ybSBhIGNsdXN0ZXIgaW4gdGhlIFJG QyBlZGl0b3IgcXVldWUuIEV2ZW4gaWYgdGhleSB3ZXJlIHN1Ym1pdHRlZCBhdA0KPj4+PiBkaWZm ZXJlbnQgdGltZXMsIHRoZXkgd291bGQgYmUgZm9ybWFsbHkgcHVibGlzaGVkIG1vcmUgb3IgbGVz cyBhdCB0aGUNCj4+Pj4gc2FtZSB0aW1lLg0KPj4+PiANCj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IDIu IEV4cGxhaW4gd2h5IHdlIGFyZSBub3QgYnJha2luZyB0aGUgNTI0NSBTSE9VTEQgYW5kIGtlZXAg aXQgYXMNCj4+Pj4+IGluZm9ybWF0aW9uYWwgLiBUaGlzIGlzIGRvbmUgYnkgcG9pbnRpbmcgb3V0 IHRoZSBhcHByb3ByaWF0ZSB0ZXh0IHlvdQ0KPj4+Pj4gZm91bmQgaW4gNjcyNC4NCj4+Pj4gDQo+ Pj4+IFRoZSBjdXJyZW50IHRleHQgaXMgbWlzbGVhZGluZywgaW4gdGhlIHdheSBpdCBleHBsaWNp dGx5IHNheXMgdGhhdA0KPj4+PiBmb2xsb3dpbmcgdGhlIFNIT1VMRCBpbiA1MjQ1LzUyNDViaXMg bGVhZHMgdG8gInVuZmFpciIgcHJpb3JpdGl6YXRpb24uDQo+Pj4+IEFzIHdyaXR0ZW4sIGl0IGRv ZXMgc2VlbSB0byByZWxheCB0aGUgU0hPVUxELiBMYW5ndWFnZSBjbGFyaWZ5aW5nIHRoYXQNCj4+ Pj4gNjcyNCBhbGxvd3MgYXBwbGljYXRpb24tc3BlY2lmaWMgY2hvaWNlcyB3b3VsZCBiZSBoZWxw ZnVsLg0KPj4+PiANCj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IEFuZCBpbiBlaXRoZXIgY2FzZTogSXMg dGhlcmUgYW4gb3Bwb3J0dW5pdHkgdG8gbWFrZSA1MjQ1IG1vcmUgY2xlYXINCj4+Pj4+aW4NCj4+ Pj4+IDUyNDViaXM/DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gQWJzb2x1dGVseS4gSXQgbXVzdCBh bHNvIHBvaW50IG91dCB0aGF0IHRoZSBmb3JtdWxhcyBkZXNjcmliZWQgaW4NCj4+Pj4+NTI0NQ0K Pj4+Pj4gc2VjdGlvbiA0LjEuMiBoYXZlIG5vdCBjaGFuZ2VzIHNvIHRoYXQgdGhlIGNvbXBhdGli aWxpdHkgZGlzY3Vzc2lvbg0KPj4+Pj5pbg0KPj4+Pj4gc2VjdGlvbiA1IG9mIHRoZSBkdWFsLXN0 YWNrIGZhaXJuZXNzIGRyYWZ0IGlzIHN0aWxsIHZhbGlkLg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+ IFRoYXQgb2YgY291cnNlIGxlYWRzIHRvIHRoZSBib21ic2hlbGwgcXVlc3Rpb246IFdlIGFyZSBh bHJlYWR5IGluIHRoZQ0KPj4+Pj4gcHJvY2VzcyBvZiB1cGRhdGluZyA1MjQ1LiBXaHkgaXNuwrl0 IF90aGlzXyBkcmFmdCBwYXJ0IG9mIDUyNDViaXM/DQo+Pj4+PiANCj4+Pj4+IEkgdGhpbmsgdGhl IG1haW4gbW90aXZhdGlvbiBmb3IgdGhhdCB3YXMgdG8ga2VlcCB0aGUgSUNFYmlzIHNwZWMgYXMN Cj4+Pj4+IHNob3J0IGFzIHBvc3NpYmxlIGFzIHRoZXJlIGFyZSBzb21lIGltcGxlbWVudGF0aW9u cyB0aGF0IGRvZXMgbm90DQo+Pj4+PmNhcmUNCj4+Pj4+IGFib3V0IHRoZSBwcm9ibGVtLiBGb3Ig dGhlIGltcGxlbWVudGF0aW9ucyB0aGF0IGRvIGNhcmUsIHRoZXkgc2hvdWxkDQo+Pj4+PiByZWFk IHRoZSBkcmFmdCBhbmQgZm9sbG93IHRoZSByZWNvbW1lbmRhdGlvbnMuDQo+Pj4+IA0KPj4+PiBJ IGRvbid0IGZpbmQgdGhhdCBhbGwgdGhhdCBjb252aW5jaW5nLiBJQ0ViaXMgdGFsa3MgYWJvdXQg ZHVhbC1zdGFjaw0KPj4+PiBzdHVmZiBpbiBzZXZlcmFsIHBsYWNlcywgYW5kIG1ha2VzIHRoYXQg ZXhwbGljaXQgc3RhdGVtZW50IGFib3V0DQo+Pj4+IGR1YWwtc3RhY2sgYmVoYXZpb3IgYW5kIDY3 MjQuIEEgZ29vZCBwYXJ0IG9mIHRoZSBjb250ZW50IG9mIF90aGlzXw0KPj4+PmRyYWZ0DQo+Pj4+ IGlzIHNwZW50IGRlc2NyaWJpbmcgdGhpbmdzIGluIElDRS9JQ0ViaXMgZm9yIGNvbnRleHQsIGFu ZCBjb3VsZA0KPj4+PnByb2JhYmx5DQo+Pj4+IGJlIHNpZ25pZmljYW50bHkgcmVkdWNlZC4NCj4+ Pj4gDQo+Pj4+IE9uZSBwb3NzaWJpbGl0eSBtaWdodCBiZSB0byBtb3ZlIHRoZSBwcm9jZWR1cmUg cGFydHMgaW50byBJQ0VCaXMsIGFuZA0KPj4+PiByZWZlciBiYWNrIHRvIHRoaXMgZHJhZnQgZm9y IG1vdGl2YXRpb24gYW5kIGFuIGV4cGxhbmF0aW9uIG9mIHdoeSBhDQo+Pj4+IGhhcHB5IGV5ZWJh bGxzIGFwcHJvYWNoIGlzIHVzZWZ1bC4gKE9yIG1heWJlIHRoYXQgY291bGQganVzdCBnbyBpbnRv DQo+Pj4+YW4NCj4+Pj4gYXBwZW5kaXggb2YgSUNFYmlzLikNCj4+Pj4gDQo+Pj4+IE5vdywgSSBk b24ndCBoYXZlIGEgc3Ryb25nIGJlbGllZiB0aGlzIG5lZWRzIHRvIG1lcmdlIGludG8gSUNFQmlz LS1JDQo+Pj4+IGp1c3Qgd2FudCB0byBtYWtlIHN1cmUgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHRo b3VnaHQgYWJvdXQgdGhlIG9wdGlvbi4NCj4+Pj4gSW4gcGFydGljdWxhciwgd2Ugc2hvdWxkIGNv bnNpZGVyIHdoYXQgbWFrZXMgdGhpbmdzIGVhc2llciBvbiB0aGUNCj4+Pj4gcmVhZGVyLCBub3Qg anVzdCB3aGF0IGlzIGVhc2llciBmcm9tIGFuIElFVEYgcHJvY2VzcyBwZXJzcGVjdGl2ZS4NCj4+ Pj4gDQo+Pj4+PiANCj4+Pj4+IE1pbm9yOg0KPj4+Pj4gDQo+Pj4+PiAtIDE6IFRoZSBpbnRyb2R1 Y3Rpb24ganVtcHMgcmlnaHQgdG8gc2F5aW5nIGFwcGxpY2F0aW9ucyBuZWVkIHRvDQo+Pj4+PiBk ZXByaW9yaXRpemUgaW50ZXJmYWNlcyB3aXRob3V0IHNheWluZyB3aGF0IHByb2JsZW0gaXQncyB0 cnlpbmcgdG8NCj4+Pj4+IHNvbHZlLiBBbiBpbml0aWFsIHBhcmFncmFwaCB0aGF0IHNheXMgd2hh dCBnb2VzIHdyb25nIHdpdGggY3VycmVudA0KPj4+Pj4gaW1wbGVtZW50YXRpb25zIHdvdWxkIGJl IGV4dHJlbWVseSBoZWxwZnVsLiBJdCB3b3VsZCBhbHNvIGhlbHAgdG8NCj4+Pj4+IGRlZmluZSB3 aGF0IGlzIG1lYW50IGJ5ICJmYWlybmVzcyIgaW4gdGhpcyBjb250ZXh0LiAoScK5bSBub3Qgc3Vy ZQ0KPj4+Pj4gaXQncyBxdWl0ZSB0aGUgc2FtZSBhcyB0aGUgY29udmVudGlvbmFsIHVzZSBvZiB0 aGUgdGVybS4pDQo+Pj4+PiANCj4+Pj4+IEhvdyBhYm91dDoNCj4+Pj4+IA0KPj4+Pj4gIEluIG11 bHRpaG9tZWQgYW5kIElQdjQvSVB2NiBkdWFsLXN0YWNrIGVudmlyb25tZW50cyBJQ0UgW1JGQzUy NDVdDQo+Pj4+PiAgd291bGQgYmVuZWZpdCBieSBhIGZhaXIgZGlzdHJpYnV0aW9uIG9mIGl0cyBj b25uZWN0aXZpdHkgY2hlY2tzDQo+Pj4+PiAgYWNyb3NzIGF2YWlsYWJsZSBpbnRlcmZhY2VzIG9y IElQIGFkZHJlc3MgdHlwZXMuICBXaXRoIGEgZmFpcg0KPj4+Pj4gIGRpc3RyaWJ1dGlvbiBvZiB0 aGUgY29ubmVjdGl2aXR5IGNoZWNrcywgZXhjZXNzaXZlIGRlbGF5cyBhcmUNCj4+Pj4+IGF2b2lk ZWQNCj4+Pj4+ICBpZiBhIHBhcnRpY3VsYXIgbmV0d29yayBwYXRoIGlzIGJyb2tlbiBvciBzbG93 LiAgSXQgd291bGQgYXJndWFibGUNCj4+Pj4+IGJlDQo+Pj4+PiAgYmV0dGVyIHRvIHB1dCB0aGUg aW50ZXJmYWNlcyBvciBhZGRyZXNzIHR5cGVzIGtub3cgdG8gdGhlDQo+Pj4+PiBhcHBsaWNhdGlv bg0KPj4+Pj4gIGxhc3QgaW4gdGhlIGNoZWNrbGlzdC4gIEhvd2V2ZXIsIHRoZSBtYWluIG1vdGl2 YXRpb24gYnkgSUNFIGlzIHRvDQo+Pj4+PiAgbWFrZSBubyBhc3N1bXB0aW9ucyByZWdhcmRpbmcg bmV0d29yayB0b3BvbG9neSwgaGVuY2UgYSBmYWlyDQo+Pj4+PiAgZGlzdHJpYnV0aW9uIG9mIHRo ZSBjb25uZWN0aXZpdHkgY2hlY2tzIGlzIG1vcmUgYXBwcm9wcmlhdGUuICBJZiBhbg0KPj4+Pj4g IGFwcGxpY2F0aW9uIG9wZXJhdGVzIGluIGEgd2VsbC1rbm93biBlbnZpcm9ubWVudCBpcyBjYW4g c2FmZWx5DQo+Pj4+PiAgb3ZlcnJpZGUgdGhlIHJlY29tbWVuZGF0aW9uIGdpdmVuIGluIHRoaXMg ZG9jdW1lbnQuDQo+Pj4+IA0KPj4+PiBUaGF0IGhlbHBzLCBidXQgSSBzdGlsbCBkb24ndCBzZWUg cyBkZWZpbml0aW9uIG9mIHdoYXQgeW91IG1lYW4gYnkNCj4+Pj4iZmFpcg0KPj4+PiBkaXN0cmli dXRpb24iLg0KPj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAtIDI6IEFzc3VtaW5nIHRoaXMg c3RheXMgaW5mb3JtYXRpb25hbCwgaXQncyBub3QgcmVhbGx5IHVzaW5nIHRoZQ0KPj4+Pj4yMTE5 DQo+Pj4+PiBrZXl3b3JkcyBxdWl0ZSBpbiB0aGUgc3Bpcml0IG9mIDIxMTkuIFBlcnNvbmFsbHks IEkgZG9uJ3QgdGhpbmsgdGhlDQo+Pj4+PiBjdXJyZW50IDIxMTkgdXNhZ2UgKG91dHNpZGUgb2Yg dGV4dCBkaXJlY3RseSBhdHRyaWJ1dGVkIHRvIG90aGVyDQo+Pj4+PiBkb2N1bWVudHMsIHdoaWNo IGRvZXNuJ3QgcmVhbGx5IGNvdW50KSBhZGRzIG11Y2guIEkgc3VnZ2VzdCByZW1vdmluZw0KPj4+ Pj4gaXQuDQo+Pj4+PiANCj4+Pj4+IEJ1dCBpZiBwZW9wbGUgYXJlIHJlYWxseSBhdHRhY2hlZCB0 byB1c2luZyAyMTE5IGxhbmd1YWdlIGhlcmUsIHBsZWFzZQ0KPj4+Pj4gY29uc2lkZXIgYWRqdXN0 aW5nIHRoZSBib2lsZXJwbGF0ZSB0byBzYXkgdGhhdCwgd2hpbGUgdGhpcyBkcmFmdCBkb2VzDQo+ Pj4+PiBub3QgaW5jbHVkZSBub3JtYXRpdmUgcmVxdWlyZW1lbnRzLCB0aGUga2V5d29yZHMgYXJl IHVzZWQgZm9yIHRoZQ0KPj4+Pj5zYWtlDQo+Pj4+PiBvZiBjbGFyaXR5Lg0KPj4+Pj4gDQo+Pj4+ PiANCj4+Pj4+IEFncmVlLiBSZW1vdmVkIGZyb20gZHJhZnQuIEFuZCBhbGwgY2FwaXRhbCBTSE9V TEQgb2NjdXJyZW5jZXMNCj4+Pj4+cmVwbGFjZWQNCj4+Pj4+IHdpdGggc2hvdWxkLg0KPj4+PiAN Cj4+Pj4gVGhhdCB3b3JrcyBmb3IgbWUsIGFzc3VtaW5nIHBlb3BsZSBjaG9vc2UgdG8ga2VlcCB0 aGlzIGFzIGFuDQo+Pj4+IGluZm9ybWF0aW9uYWwuDQo+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAtMywg Mm5kIHBhcmFncmFwaDoNCj4+Pj4+IA0KPj4+Pj4gRG9lcyB0aGUgd29ya2luZyBncm91cCBiZWxp ZXZlIHRoYXQgb25lIGNhbiBtYWtlIHJlYXNvbmFibGUNCj4+Pj4+aW5mZXJlbmNlcw0KPj4+Pj4g ZnJvbSBqdXN0IHRoZSBuZXR3b3JrIHR5cGU/IERvIHlvdSBleHBlY3QgdGhlc2UgdG8gYmUgY29u ZmlndXJhYmxlPw0KPj4+Pj4gU3RhdGljYWxseSBkZWZpbmVkIGluIGNvZGU/IChTZWVtcyBsaWtl IHRoZXJlIG1heSBiZSBvcGVyYXRpb25hbA0KPj4+Pj4gY29uc2lkZXJhdGlvbnMgaGVyZS4pDQo+ Pj4+PiANCj4+Pj4+IFRoZSBvcmlnaW5hbCBpbnRlbnQgd2l0aCB0aGUgdGV4dCB3YXMgdG8gc2F5 OyDCs0lmIHlvdSB0aGluayB5b3Uga25vdw0KPj4+Pj4gYmV0dGVyLCBwbGVhc2UgZmVlbCBmcmVl IHRvIGRvIGFzIHlvdSBwbGVhc2XFoMKyLiBCdXQgYmFzaW5nIGl0IGp1c3QNCj4+Pj4+IG9uIG5l dHdvcmsgdHlwZSBzZWVtcyB0byBiZSBhIGJpdCB0byBmcmFnaWxlLg0KPj4+Pj4gDQo+Pj4+PiBV cGRhdGVkIHRleHQ6DQo+Pj4+PiBUaGUgYXBwbGljYXRpb24ga25vd2xlZGdlIHJlZ2FyZGluZyB0 aGUgcmVsaWFiaWxpdHkgb2YgYW4gaW50ZXJmYWNlDQo+Pj4+PiAgY2FuIGFsc28gYmUgYmFzZWQg b24gc2ltcGxlIG1ldHJpY3MgbGlrZSBwcmV2aW91cyBjb25uZWN0aW9uDQo+Pj4+PiBzdWNjZXNz Lw0KPj4+Pj4gIGZhaWx1cmUgcmF0ZXMgb3IgYSBtb3JlIHN0YXRpYyBtb2RlbCBiYXNlZCBvbiBp bnRlcmZhY2UgdHlwZXMgbGlrZQ0KPj4+Pj4gIHdpcmVkLCB3aXJlbGVzcywgY2VsbHVsYXIsIHZp cnR1YWwsIHR1bm5lbGVkIGluIGNvbmp1bmN0aW9uIHdpdGgNCj4+Pj4+ICBvdGhlciBvcGVyYXRp b25hbCBtZXRyaWNzLiAgVGhpcyB3b3VsZCByZXF1aXJlIHRoZSBhcHBsaWNhdGlvbiB0bw0KPj4+ Pj4gIGhhdmUgdGhlIHJpZ2h0IHBlcm1pc3Npb25zIHRvIG9idGFpbiBzdWNoIG9wZXJhdGlvbmFs IG1ldHJpY3MuDQo+Pj4+IA0KPj4+PiBUaGF0IGhlbHBzLCB0aGFua3MuDQo+Pj4+IA0KPj4+Pj4g DQo+Pj4+PiANCj4+Pj4+IC0gNy4yOiBDYW4gdGhpcyBiZSBtb3JlIHNwZWNpZmljIGFib3V0IHdo YXQgaW1wbGVtZW50YXRpb25zIGV4aXN0Pw0KPj4+Pj5UaGUNCj4+Pj4+IGJvaWxlcnBsYXRlIHNl ZW1zIGEgYml0IGhlYXZpd2VpZ2h0IGZvciBzb21ldGhpbmcgdGhhdCBwcmV0dHkgbXVjaA0KPj4+ Pj4gc2F5cyDCs3RoZXJlIGFyZSBvdGhlcnMiIDotKQ0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IFRo ZSBzZWN0aW9uIGhhcyBiZWVuIGluIGFuZCBvdXQuIE1haW4gdXNlIGlzIHRvIGluZm9ybSBXRyBh bmQgQUQgdGhhdA0KPj4+Pj4gdGhlcmUgYXJlIG90aGVycz8gT3RoZXJzIGhhdmUgY29uZmlybWVk IGR1cmluZyBXRyBtZWV0aW5ncyB0aGF0IHRoZXkNCj4+Pj4+IGRvIHRoaW5ncyBzaW1pbGFyIHRv IHdoYXQgaXMgZGVzY3JpYmVkIGluIHRoZSBkcmFmdCAoQnV0IHNvbWV0aW1lcw0KPj4+Pj4gdGhl eSBoYXZlIG1vcmUgb3BlcmF0aW9uYWwga25vd2xlZGdlIGFuZCBhcmUgYWJsZSB0byBvdmVycmlk ZSB0aGluZ3MNCj4+Pj4+IGluIHRoZSBkcmFmdCkuDQo+Pj4+PiANCj4+Pj4+IFNhZmUgdG8gcmVt b3ZlIHRoaXMgc2VjdGlvbiBub3c/DQo+Pj4+IA0KPj4+PiBUaGlzIHNvcnQgb2YgdGhpbmcgdXN1 YWxseSBjb21lcyBvdXQgYXQgcHVibGljYXRpb24gdGltZSwgc28gaXQncw0KPj4+PiBwcm9iYWJs eSBmaW5lIGZvciBub3cuDQo+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IEVkaXRvcmlhbDoN Cj4+Pj4+IA0KPj4+Pj4gLSA0ICwgZmlyc3QgcGFyYWdyYXBoOiBIb3cgbG9uZyBpcyBsb25nPyAg KEVzcGVjaWFsbHkgaWYgeW91IHN0aWNrDQo+Pj4+PnRoZQ0KPj4+Pj4gMjExOSBTSE9VTEQpLg0K Pj4+Pj4gDQo+Pj4+PiBJIHRoaW5rIGxvbmcgY2FuIGJlIGRyb3BwZWQuIElNSE8gaW50ZXJtaW5n bGluZyBvZiB0aGUgYWRkcmVzcyB0eXBlcw0KPj4+Pj4gaXMgYSBnb29kIHRoaW5nIGlmIHlvdSB3 YW50IHRvIGJlIHRvcG9sb2d5IGFnbm9zdGljLg0KPj4+Pj4gVGhlIHBhcmFncmFwaCBzdGlsbCBo YXZlIMKzdmFsdWVzwrIgIGxpa2UgbWFueSBhbmQgc21hbGwuIEkgdGhpbmsNCj4+Pj4+IHRoYXQg aXMgb2s/DQo+Pj4+PiANCj4+Pj4+IE5ldyBwYXJhZ3JhcGg6DQo+Pj4+PiAgQ2FuZGlkYXRlcyBz aG91bGQgYmUgcHJpb3JpdGl6ZWQgc3VjaCB0aGF0IGEgc2VxdWVuY2Ugb2YgY2FuZGlkYXRlcw0K Pj4+Pj4gIGJlbG9uZ2luZyB0byB0aGUgc2FtZSBhZGRyZXNzIGZhbWlseSB3aWxsIGJlIGludGVy bWluZ2xlZCB3aXRoDQo+Pj4+PiAgY2FuZGlkYXRlcyBmcm9tIGFuIGFsdGVybmF0ZSBJUCBmYW1p bHkuICBGb3IgZXhhbXBsZSwgcHJvbW90aW5nDQo+Pj4+PiBJUHY0DQo+Pj4+PiAgY2FuZGlkYXRl cyBpbiB0aGUgcHJlc2VuY2Ugb2YgbWFueSBJUHY2IGNhbmRpZGF0ZXMgc3VjaCB0aGF0IGFuDQo+ Pj4+PiBJUHY0DQo+Pj4+PiAgYWRkcmVzcyBjYW5kaWRhdGUgaXMgYWx3YXlzIHByZXNlbnQgYWZ0 ZXIgYSBzbWFsbCBzZXF1ZW5jZSBvZiBJUHY2DQo+Pj4+PiAgY2FuZGlkYXRlcywgaS5lLiwgcmVv cmRlcmluZyBjYW5kaWRhdGVzIHN1Y2ggdGhhdCBib3RoIElQdjYgYW5kDQo+Pj4+PiBJUHY0DQo+ Pj4+PiAgY2FuZGlkYXRlcyBnZXQgYSBmYWlyIGNoYW5jZSBkdXJpbmcgdGhlIGNvbm5lY3Rpdml0 eSBjaGVjayBwaGFzZS4NCj4+Pj4+ICBUaGlzIG1ha2VzIElDRSBjb25uZWN0aXZpdHkgY2hlY2tz IG1vcmUgcmVzcG9uc2l2ZSB0byBicm9rZW4gcGF0aA0KPj4+Pj4gIGZhaWx1cmVzIG9mIGFuIGFk ZHJlc3MgZmFtaWx5Lg0KPj4+PiANCj4+Pj4gV0ZNLg0KPj4+PiANCj4+Pj4+IA0KPj4+Pj4gLSA1 LCBsYXN0IHBhcmFncmFwaDogRG9lc27CuXQgdGhpcyBiZWxvbmcgaW4gdGhlICJJbXBsZW1lbnRh dGlvbg0KPj4+Pj4gU3RhdHVzIiBzZWN0aW9uPw0KPj4+Pj4gDQo+Pj4+PiBUaGUgaW50ZW50IHdh cyB0byBndWlkZSBpbXBsZW1lbnRlcnMgdG8gc2FtcGxlIGNvZGUuIElmIHRoYXQgaXMgbW92ZWQN Cj4+Pj4+IHRvIEltcGxlbWVudGF0aW9uIFN0YXR1cyB0aGF0IGluZm9ybWF0aW9uIHdpbGwgYmUg bG9zdCB3aGVuIHB1Ymxpc2hlZA0KPj4+Pj4gYXMgYW4gUkZDLg0KPj4+Pj4gDQo+Pj4+PiBQcmV2 aW91cyB2ZXJzaW9ucyBoYWQgYW4gYXBwZW5kaXggd2l0aCB0aGUgY29kZSBleGFtcGxlcy4gVGhl IFdHIGZlbHQNCj4+Pj4+IHRoYXQgdGhhdCB3YXMgYSB0byBzdHJvbmcgZW5jb3VyYWdlbWVudCB0 byBpbXBsZW1lbnQgYSBzcGVjaWZpYw0KPj4+Pj4gc29sdXRpb24sIHRoaXMgd2FzIHNvbWV0aGlu ZyB0aGUgV0cgZGlkIG5vdCB3YW50IHRvIGRvLiBIZW5jZSB0aGUNCj4+Pj4+IGluZm9ybWF0aW9u YWwgc3RhdHVzIG9mIHRoZSBkcmFmdC4NCj4+Pj4+IA0KPj4+Pj4gSSBhbSBmaW5lIHdpdGggcmVt b3ZpbmcgaXQuDQo+Pj4+IA0KPj4+PiBJIGRvbid0IG5lY2Vzc2FyaWx5IG9iamVjdCB0byBrZWVw aW5nIGl0LCBidXQga2VlcCBpbiBtaW5kIHRoYXQgUkZDcw0KPj4+PiBsaXZlIGZvcmV2ZXIsIGFu ZCBjb2RlIHJlcG9zaXRvcmllcyBtaWdodCBub3QuDQo+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+ Pj4+IC0gNy4xIGFuZCA3LjIgdGl0bGVzOiBzL1N0YXJjay9TdGFjaw0KPj4+Pj4gDQo+Pj4+PiBH YWhoLi4gRml4ZWQgZXZlbiBpZiByZW1vdmVkIGxhdGVyLi4NCj4+Pj4+IA0KPj4+Pj4gLSA3LjEs ICJMZXZlbCBvZiBNYXR1cml0eSI6IEFyZSB0aGVyZSB3b3JkcyBtaXNzaW5nIGFyb3VuZCAiVGVz dHMiPw0KPj4+Pj4gDQo+Pj4+PiBDdXQgYW5kIHBhc3RlIGVycm9yLg0KPj4+Pj4gDQo+Pj4+PiAN Cj4+Pj4+IA0KPj4+Pj4gRG8geW91IHdhbnQgbWUgdG8gcG9zdCBhIG5ldyB2ZXJzaW9uIG9mIHRo ZSBkcmFmdCB3aXRoIHRoZSBjaGFuZ2VzLg0KPj4+Pj5XZQ0KPj4+Pj4gc3RpbGwgbmVlZCB0byBy ZXNvbHZlIHRoZSA1MjQ1LCA1MjQ1YmlzIGFuZCA2NzI0IHByb2JsZW0uIFNpbXBsZQ0KPj4+Pj4g ZW5vdWdoIG9uY2Ugd2UgYWdyZWUuDQo+Pj4+IA0KPj4+PiBSZXZpc2lvbnMgYXJlIGNoZWFwIDot KSBJJ2Qgc3VnZ2VzdCB1cGRhdGluZyB3aXRoIHRoZSBrbm93biBjaGFuZ2VzDQo+Pj4+bm93LA0K Pj4+PiB0aGVuIGRlYWxpbmcgd3RpaCB0aGUgb3RoZXIgc3R1ZmYgd2hlbiB3ZSBjYW4uDQo+Pj4+ IA0KPj4+PiBUaGFua3MhDQo+Pj4+IA0KPj4+PiBCZW4uDQo+Pj4+IA0KPj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBJY2UgbWFpbGluZyBs aXN0DQo+Pj4+IEljZUBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ljZQ0KPj4gDQo+DQoNCg== From nobody Mon May 23 07:25:41 2016 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 9D60812D91A; Mon, 23 May 2016 07:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 SD4FRSz9W5dN; Mon, 23 May 2016 07:25:29 -0700 (PDT) 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 56A9912D932; Mon, 23 May 2016 07:25:27 -0700 (PDT) Received: from [10.0.1.18] (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 u4NEPHuu046134 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 23 May 2016 09:25:18 -0500 (CDT) (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.18] From: "Ben Campbell" To: "Pal Martinsen" Date: Mon, 23 May 2016 09:25:17 -0500 Message-ID: In-Reply-To: <5FB58FA2-75F4-4A13-8D0D-B83370278344@cisco.com> References: <86559E67-6412-4971-AB74-6680D079CAC8@cisco.com> <12099752-1FB6-4BB6-A9E7-1CC74871234C@ericsson.com> <5FB58FA2-75F4-4A13-8D0D-B83370278344@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: Ari =?utf-8?q?Ker=C3=A4nen?= , "draft-ietf-ice-dualstack-fairness.all@ietf.org" , Christer Holmberg , "ice@ietf.org" Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-dualstack-fairness-02 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 14:25:38 -0000 I'm okay with this approach in general. Some comments inline: Thanks! Ben. On 23 May 2016, at 5:58, Pal Martinsen (palmarti) wrote: > On 22 May 2016, at 22:34, Ari Keränen > wrote: >> >> Hi, >> >> Regarding the split to different drafts, our goal with the ICEbis >> work was to fix errors and make sure we have the right hooks and text >> for the extensions that we need. And we decided that everything else, >> such as new features/extra functionality, would go to different >> document(s). Of course the DS draft is a borderline case, but given >> how much material (e.g., the algorithm) there is, to me (chair hat >> off) separate document sounds still like a better idea. >> >> But yes, the current text in ICEbis about RFC6724 needs to be updated >> and point to the dual-stack document. Having text there about the >> general procedure makes sense. >> >> Regarding BCP or Informational for the DS draft status, I don't think >> we considered the BCP option. Now thinking about it, BCP seems >> reasonable option. >> > > > +1 BCP Seems like a better option. > > The current proposal for progressing this draft: > - Move from Informational to BCP I think that makes sense, if we keep it separate from ICEBis. As an individual, I think merging it into ICEBis would be the best long-term choice, but as AD I'm ok with progressing things as is for "historical" reasons. (read: Because we've gotten this far separately, merging them would create a fair amount of re-work.) But do not be surprised if this comes up again during IESG review. > - ICEbis will have a normative reference to ICE-Dualstack fairness. > (So this can potentially hold up ICEbis, but probably not) > - Text can be shortened a lot if we assume readers are more familiar > with ICE and only reference the appropriate ICE sections. I prefer the > current text as it saves readers familiar with ICE but without fresh > memories of details some time looking up the appropriate ICE section. The big issue here is, since ICEBis is still in play, do we expect the explanatory text to stay "current"? Otherwise, it's just a matter of making being clear that whatever explanatory material exists makes it clear that it is not authoritative. I'll leave this to the authors an chairs to decide. My personal advice would be to keep some explanatory text, but shorten it quite a bit. It's reasonable to have enough to give a reader a sense of what is going on, but it's also reasonable to expect people to understand ICE to fully understand this. > - Normative references to ICEbis instead of ICE. Work with ICEbis to > remove current ambiguity of SHOULD wording regarding 6724 (Will hold > publication of draft until ICEbis is complete). +1 > > Not sure if this requires a new WGLC. The chairs will decide that. Things like changing to BCP, changing normative references, etc need to be confirmed with the working group. It might make sense to reconfirm the split draft approach, but I will leave that to the chairs to decide. I don't think these things need a full WGLC, but if that's the easiest way forward it doesn't hurt. From nobody Mon May 23 07:26:34 2016 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 34D8712D936; Mon, 23 May 2016 07:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 cZ1SxQFt7jGM; Mon, 23 May 2016 07:26:31 -0700 (PDT) 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 582E112D926; Mon, 23 May 2016 07:26:31 -0700 (PDT) Received: from [10.0.1.18] (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 u4NEQPlo046269 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 23 May 2016 09:26:26 -0500 (CDT) (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.18] From: "Ben Campbell" To: "Christer Holmberg" Date: Mon, 23 May 2016 09:26:25 -0500 Message-ID: In-Reply-To: References: <86559E67-6412-4971-AB74-6680D079CAC8@cisco.com> <12099752-1FB6-4BB6-A9E7-1CC74871234C@ericsson.com> <5FB58FA2-75F4-4A13-8D0D-B83370278344@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: Pal Martinsen , Ari =?utf-8?q?Ker=C3=A4nen?= , "draft-ietf-ice-dualstack-fairness.all@ietf.org" , "ice@ietf.org" Subject: Re: [Ice] AD Evaluation of draft-ietf-ice-dualstack-fairness-02 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 14:26:32 -0000 On 23 May 2016, at 6:14, Christer Holmberg wrote: > Just to verify: is it allowed to have a normative reference to a BCP? Yes, a BCP has the same status as a standards track RFC for the purposes of normative references. Ben. From nobody Mon May 23 11:48:27 2016 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 BADB112D181 for ; Mon, 23 May 2016 11:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 PrJOY7N7Kdjm for ; Mon, 23 May 2016 11:48:24 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B79012D183 for ; Mon, 23 May 2016 11:48:23 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-a2-574350754256 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 66.13.27088.57053475; Mon, 23 May 2016 20:48:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0294.000; Mon, 23 May 2016 20:47:34 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: Editorial comments on draft-ietf-ice-dualstack-fairness-02 Thread-Index: AdG1I5SCQSZ3Hm7yTgG0nNh1PJ2teA== Date: Mon, 23 May 2016 18:47:33 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37FE3665@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37FE3665ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7n25pgHO4QdNrA4tvF2odGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJWx6tpCloJt2hVPF89mb2C8qNrFyMkhIWAicezNHWYIW0ziwr31 bF2MXBxCAkcYJS7PmssM4SxhlJh9cC1LFyMHB5uAhUT3P22QBhEBRYmZLc/AmoUFnCV+zT7C AhH3kDjYtIYRwtaT2PK/EyzOIqAqMXd2CzuIzSvgK3Hr/U4mEJsRaPH3U2vAbGYBcYlbT+Yz QRwkILFkz3mo40QlXj7+xwphK0msPbydBaI+X+LtwT9QMwUlTs58wjKBUWgWklGzkJTNQlIG EdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzGKFqcWJ+WmGxnppRZlJhcX5+fp5aWWbGIE RsTBLb8NdjC+fO54iFGAg1GJh/ehtlO4EGtiWXFl7iFGCQ5mJRFeb3/ncCHelMTKqtSi/Pii 0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2CyTBycUg2MnY8v5yZ1rFP+XpzItoJ/TpTE vvD03Zf+71M7ecTFyuYRz7M5pr3XTP3U/jZsTS7xmKpbNv/wcZGrUjxvJqie7tbx/Jc/v9gr 6Hyeva6GUlTQMXb33E3/+C8lrBK58FDpcKbqzvxuI/vOtYGRHJPdt7P0LhF4e5FF1v+e7e+O OetCS62+fnmnxFKckWioxVxUnAgAM3WBNIQCAAA= Archived-At: Subject: [Ice] Editorial comments on draft-ietf-ice-dualstack-fairness-02 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 18:48:26 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37FE3665ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I was reading draft-ietf-ice-dualstack-fairness-02, and I have some comment= s (mostly editorial) on sections 4 and 5. The text in section 4 says: "The best approach is to modify the formula for calculating the candidate p= riority value described in ICE [RFC5245] section 4.1.2.1" Besides that, section 4 doesn't anything about HOW the formula is modifies. The name of section 5 is "Compatibility". But, I think most of the text act= ually belongs to section 4, because it's not about compatibility - it's abo= ut how to ensure dual-stack fairness. The compatibility section should only contain the text about how entities w= ill interop even if they don't use the same algorithm, etc. Also, in my opinion the statement that the text modifies the candidate prio= rity algorithm is misleading. The algorithm from RFC 5264 is shown in the b= eginning of section 5, and it is not modified anywhere. At the end of the c= hapter, there is a formula for calculating pair priority. So, shouldn't the= text instead say that the draft extends the procedures for generating the = priority list, or something like that? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37FE3665ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I was reading draft-ietf-ice-dualstack-fairness-02, = and I have some comments (mostly editorial) on sections 4 and 5.=

 

The text in section 4 says:

 

“The best approac= h is to modify the formula for calculating the candidate priority value des= cribed in ICE [RFC5245] section 4.1.2.1”

 

Besides that, section 4 doesn’t anything about= HOW the formula is modifies.

 

The name of section 5 is “Compatibility”= . But, I think most of the text actually belongs to section 4, because it&#= 8217;s not about compatibility – it’s about how to ensure dual-= stack fairness.

 

The compatibility section should only contain the te= xt about how entities will interop even if they don’t use the same al= gorithm, etc.

 

Also, in my opinion the statement that the text modi= fies the candidate priority algorithm is misleading. The algorithm from RFC= 5264 is shown in the beginning of section 5, and it is not modified anywhe= re. At the end of the chapter, there is a formula for calculating pair priority. So, shouldn’t the text i= nstead say that the draft extends the procedures for generating the priorit= y list, or something like that?

 

Regards,

 

Christer

 

 

 

 

--_000_7594FB04B1934943A5C02806D1A2204B37FE3665ESESSMB209erics_-- From nobody Mon May 23 14:43:39 2016 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 17BC412D5A0 for ; Mon, 23 May 2016 14:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jitsi-org.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 j4hSc0Yb_Gac for ; Mon, 23 May 2016 14:43:35 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 3A75C12D595 for ; Mon, 23 May 2016 14:43:35 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id k23so92677376oih.0 for ; Mon, 23 May 2016 14:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jitsi-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=kwviXXYjS3utc1QzdRxyPL191N8bZ7mn1rqoqv4bSsw=; b=W7n2YE/AJ+Zesiro/rnktN57R7Gj+A0/yXyrG+ktIcEsfCLCvzt3hIBX98To5+zvXx xjbRJGpj3qI24QjXDS/T7XSaxjMTIK7JWlREYMhKeWePTyjhL9ywA35TviBoERio5IFh OVde+DNOBjfhBZ2eGUTrnmgB07UY43dx2yWDtuvjMBulPu8ZKtybM7mbzZHMxI7K9BkN 135PTMRIy5OcfPz6QzjYVuX/c4tvpUXjEFbcI1BaTBg1gfrxSoVTodO9O3KoaGjWuZOS NUSW4cHPC30RDWa5DTna0o5b4CZ1M/j9PdrUI8u15sARBrNSiMLqXzqYXEieQwhr179t e8mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=kwviXXYjS3utc1QzdRxyPL191N8bZ7mn1rqoqv4bSsw=; b=WYZkVrFCjfyTFueAJRaMgwQVV8cnxiYs7hdsVRFaBRx7Ygj4WplRCW5vDH1cWbgfX5 1RhUwaSecq8veWvpCjTzi21VZA5T3y8H2G3x4sUs/1HIKKegcDEBleW9PZnZ8cMT+3ep I7D3KiksqxveZpl5QuqVd2072DgWiF0NORzyMYNupaoKdotQvN/3kqNwEWhwEwHu0X4b sbQMZ7zBlBJTx2YaOg8dzKm27LUrfGJyxivHTHvbcEC4SwPSpiwZO/qxxGohH6Wp8Uqf NhoAlslP/2vyqjx9R87ws7Ney7HyYL0bNHpjX+/eSs1RtP4Sdebats9mFjmBhVqDbxIR jmQg== X-Gm-Message-State: AOPr4FU+KpAQSVRnBZM5Ju1JxZPEwo1YTfvzfoGWeIhGZxpOVNch19QemFFA4zZ2ZczqYQ== X-Received: by 10.202.104.91 with SMTP id d88mr9434199oic.75.1464039814396; Mon, 23 May 2016 14:43:34 -0700 (PDT) Received: from camionet.office.atlassian.com (72-48-156-244.static.grandenetworks.net. [72.48.156.244]) by smtp.googlemail.com with ESMTPSA id 78sm10267116otc.24.2016.05.23.14.43.31 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2016 14:43:32 -0700 (PDT) To: Justin Uberti References: From: Emil Ivov Message-ID: Date: Mon, 23 May 2016 16:43:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Check lists and trickling X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 21:43:38 -0000 Hey Justin, Many apologies for missing this one! I hadn't seen it until I explicitly went to check my mailbox for updates on this thread. So, I've gone over the text again and I can see what you mean. I think however that this is a contradiction in 5245 and that it goes against the intention of the freezing algorithm so we should probably fix it in 5245bis. Specifically, I think that section 5.7.4 and later section 7... are more accurate in the description of the freezing algorithm. 5.7.4 describes the initial situation: The agent examines the check list for the first media stream. For that media stream: * For all pairs with the same foundation, it sets the state of the pair with the lowest component ID to Waiting. (note how this only unfreezes a single pair per foundation) Then in 7.1.3.2.3 as we progress and update states we have the same foundation-based reasoning. Specifically as we validate pairs we will unfreeze certain foundations (and only foundations) of other frozen checklists: 7.1.3.2.3. subpoint 1. The agent changes the states for all other Frozen pairs for the same media stream *and same foundation* to Waiting. Then once we validate an entire foundation of a given stream we will only unfreeze the same foundation (and only that foundation) of other streams: 7.1.3.2.3. subpoint 2. If there is a pair in the valid list for every component of this media stream. The agent examines the check list for each other media stream in turn : * the state of all pairs in the check list whose foundation matches a pair in the valid list under consideration is set to Waiting This also complies with the non-normative text in 2.4: The other candidate pairs are marked "frozen". When the connectivity checks for a candidate pair succeed, the other candidate pairs with *the same foundation are unfrozen*. And then: This *avoids* (Emil: not delays) repeated checking of components that are superficially more attractive but in fact are likely to fail. So, as incredibly convoluted as this all may sound I do think that it makes more sense than the generic statement in 5.8. If we were to accept the statement in 5.8 it would create race conditions that might even get candidates that should be frozen to be checked before unfrozen ones ... it would be a mess. Do you see what I mean? Emil On 13.04.16 г. 0:04, Justin Uberti wrote: > reading 5.8, the algo indicates that for an active checklist, you check > the highest-prio pair in the waiting state, and if there is none, you > check the highest-prio frozen pair, thereby unfreezing it. This repeats > on each timer tick. > > Basically, once a checklist is active, you will soon end up checking all > of its pairs. What am I missing? > > On Tue, Apr 12, 2016 at 6:25 PM, Emil Ivov > wrote: > > > > On Tuesday, 12 April 2016, Justin Uberti > wrote: > > > > On Mon, Apr 11, 2016 at 10:06 PM, Emil Ivov wrote: > > Hey Justin, > > On Monday, 11 April 2016, Justin Uberti > wrote: > > In BA, I noted that unfreezing the candidate pairs > associated with a candidate that arrives for a media > stream other than the first one will cause all of that > stream's candidate pairs to unfreeze, due to the rules > in S 5.8 (https://tools.ietf.org/html/rfc5245#section-5.8). > > > I may be missing your point but I don't think there's > anything in 5245 (5.8 or elsewhere) that ever unfreezes all > the pairs in a checklist in one go. > > > It's not that the checklist unfreezes all at once - it's that > once you unfreeze any pair in a checklist, the algo in 5.8 will > necessarily unfreeze the entire checklist in short order. That > defeats the purpose of a frozen checklist (i.e., you'll end up > checking both streams in parallel). > > > I really don't think that's the case (and if you are saying what I > think you are saying then freezing would have been pointless even in > vanilla ice) > > Could you please point to the specific text that's bothering you? > > The whole idea about unfreezing is that it happens along a > foundation and across lists. There are many cases where you > would unfreeze some candidates in a checklist (either because it was > their turn or because their entire foundation got unfrozen) but > other pairs in the same check list would remain frozen till ICE > completes. > > Emil > > > > There's text that talks about activating a check list and > there's text that unfreezes an entire foundation actoss all > check lists but neither of them should be an issue with > Peter's suggestion > > I do agree with the rest of the mail here ... I just don't > think any of it is a problem. > > Emil > > > Someone mentioned that there was only a single check > list, which would make this a non-issue. However, I > checked and indeed each stream is supposed to have its > own check list (ignoring bundle), as described in S 5.7 > (https://tools.ietf.org/html/rfc5245#section-5.7). > > > > > > Therefore, while this concern of prematurely unfreezing > check lists isn't an issue for candidates that arrive > for a different component (since they share a check > list), I think it is an issue for candidates that arrive > for different m= lines, and as such I'm not sure this > new unfreezing behavior is the correct solution in these > cases. > > > > -- > sent from my mobile > > > > > -- > sent from my mobile > > -- https://jitsi.org From nobody Tue May 24 01:12:58 2016 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 ADE8312D137 for ; Tue, 24 May 2016 01:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 KLVrjFWGjyXX for ; Tue, 24 May 2016 01:12:54 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0343A12D0BF for ; Tue, 24 May 2016 01:12:53 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-ff-57440d0481ea Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 36.B6.27088.40D04475; Tue, 24 May 2016 10:12:52 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0294.000; Tue, 24 May 2016 10:12:51 +0200 From: Christer Holmberg To: "ice@ietf.org" Thread-Topic: ICE 'simple' Option text [was: 5245bis: New ICE option to prevent legacy peers from using aggressive nomination] Thread-Index: AQHRtZQQA2HK/oRLDEWEFIzvz0YqVA== Date: Tue, 24 May 2016 08:12:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D369E7948EEFchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbHdQ5eF1yXc4Ml0CYtvF2odGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJXxe88qloKf+hWnHmQ2MN5Q72Lk5JAQMJH4cO8KG4QtJnHh3nog m4tDSOAIo8T1U0eYIZwljBJvmycAORwcbAIWEt3/tEEaRAQUJWa2PGMGsYUFqiX2X57EClIv ItDAKDHl/1dmiCI9ibkXD4NtYBFQlZiw5xVYnFfASuLX5FZ2EJsRaPP3U2uYQGxmAXGJW0/m M0FcJCCxZM95ZghbVOLl43+sILYo0Mx9L84zQsSVJH5suMQC0Rsvsf3aKiaI+YISJ2c+YZnA KDwLydhZSMpmISmDiOtILNj9iQ3C1pZYtvA1M4x95sBjqF5riYl7J7Iiq1nAyLGKUbQ4tTgp N93ISC+1KDO5uDg/Ty8vtWQTIzCCDm75bbCD8eVzx0OMAhyMSjy8CbXO4UKsiWXFlbmHGCU4 mJVEeNtZXMKFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJxcEo1 MNq/2m/2xVSf8czpP5szJLaeTxWbc5hpwQktrctWLxuvMZl3qphxPz873eF0k7vbyuNz963m Ofji+735yzzcPlmd+9z01/L7K7b1U4xjqw7sK7u/WeLCqi1LmNh96heobF6kdH6iQWpXxALd MEVHsYOu2Z+kXvWn/jbwD32gt070ttVaj8il1b+VWIozEg21mIuKEwEhvpKhnAIAAA== Archived-At: Subject: [Ice] ICE 'simple' Option text [was: 5245bis: New ICE option to prevent legacy peers from using aggressive nomination] X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 08:12:57 -0000 --_000_D369E7948EEFchristerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below is suggested new text for the ICE option: ---- 9. ICE Option This section defines a new ICE option, 'simple'. The ICE option indicates that the ICE agent that includes it (in an ice-options attribute) is compliant to this specification. For example, the ICE agent will not use the aggressive nomination procedure defined in [RFC5245]. An ICE agent compliant to this specification MUST inform the peer about the compliance using the 'simple' ICE option. NOTE: The encoding of the 'simple' ICE option, and the message(s) used to carry it to the peer, are protocol specific. The encoding for the Session Description Protocol (SDP) [RFC4566] is defined in [I-D.ietf-mmusic-ice-sip-sdp]. ----- (IANA considerations) 18.3. ICE Options IANA is requested to register the following ICE option in the "ICE Options" sub-registry of the "Interactive Connectivity Establishment (ICE) registry", following the procedures defined in [RFC6336]. ICE Option name: simple Contact: Name: Christer Holmberg E-mail: christer.holmberg(at)ericsson(dot)com Address: Oy LM Ericsson Ab, 02420 Jorvas, FINLAND Change control: IESG Description: The ICE option indicates that the ICE agent using the ICE option is compliant and implemented according to RFC XXXX. Reference: RFC XXXX ---- Regards, Christer --_000_D369E7948EEFchristerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <21273F5CF0192C4A99948AC2914002BE@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

Below is suggested new text for the ICE option:

----

9.  ICE Option

   This section defines a new ICE option, 'simple'.  Th= e ICE option
   indicates that the ICE agent that includes it (in an ice-= options
   attribute) is compliant to this specification.  For = example, the ICE
   agent will not use the aggressive nomination procedure de= fined in
   [RFC5245].

   An ICE agent compliant to this specification MUST inform = the peer
   about the compliance using the 'simple' ICE option.

   NOTE: The encoding of the 'simple' ICE option, and the me= ssage(s)
   used to carry it to the peer, are protocol specific. &nbs= p;The encoding
   for the Session Description Protocol (SDP) [RFC4566] is d= efined in
   [I-D.ietf-mmusic-ice-sip-sdp].

-----

(IANA considerations)

18.3.  ICE Options

   IANA is requested to register the following ICE option in= the "ICE
   Options" sub-registry of the "Interactive Conne= ctivity Establishment
   (ICE) registry", following the procedures defined in= [RFC6336].

     ICE Option name:

        simple

     Contact:

        Name:    Christer Holmberg
        E-mail:  christer.holmberg(at)ericsso= n(dot)com
        Address: Oy LM Ericsson Ab, 02420 Jorvas, = FINLAND

     Change control:

        IESG

     Description:

        The ICE option indicates that the ICE agen= t using the ICE option
        is compliant and implemented according to = RFC XXXX.

     Reference:

        RFC XXXX

----

Regards,

Christer

--_000_D369E7948EEFchristerholmbergericssoncom_-- From nobody Tue May 24 11:45:44 2016 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 93D8812D99E; Tue, 24 May 2016 11:45:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160524184542.2463.24969.idtracker@ietfa.amsl.com> Date: Tue, 24 May 2016 11:45:42 -0700 Archived-At: Cc: ben@nostrum.com, ice-chairs@ietf.org, pthatcher@webrtc.org, ice@ietf.org Subject: [Ice] ice - New Meeting Session Request for IETF 96 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 18:45:42 -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): 2.5 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: payload core rtcweb avtext avtcore t2trg tls tsvarea tsvwg tram mmusic dispatch Second Priority: netvc rmcat httpbis perc Third Priority: xrblock clue lwig 6lo ace Special Requests: --------------------------------------------------------- From nobody Wed May 25 07:07:57 2016 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 7516A12D7AB for ; Wed, 25 May 2016 07:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 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] 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 q1eDo5vu3yr2 for ; Wed, 25 May 2016 07:07:53 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B0F12D1EB for ; Wed, 25 May 2016 07:05:04 -0700 (PDT) X-AuditID: c1b4fb30-f79486d0000069d0-fa-5745b10d35da Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 8F.3E.27088.D01B5475; Wed, 25 May 2016 16:05:02 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.175]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0294.000; Wed, 25 May 2016 16:05:01 +0200 From: =?iso-8859-1?Q?Ari_Ker=E4nen?= To: Christer Holmberg Thread-Topic: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination Thread-Index: AdGmHG6bJo539xyvSt+nU2XdpYsl7wOHId2AAAV8H7D//+SNAP//3CuggASc0gA= Date: Wed, 25 May 2016 14:05:00 +0000 Message-ID: <0ABC6799-566A-4CA6-BC15-888E32DF48BB@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B37F93800@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37FDF3E1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37FDF4C7@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37FDF4C7@ESESSMB209.ericsson.se> 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="iso-8859-1" Content-ID: <4F7D0EDAE7CBC4458EB22F63993178C5@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7nC7fRtdwg1v7mCw27PvPbPHtQq0D k8fOWXfZPZYs+ckUwBTFZZOSmpNZllqkb5fAlTF3yWy2gqUsFa2z3rA1MG5j7mLk5JAQMJHY 0PwFyhaTuHBvPVsXIxeHkMARRokTiyexgSSEBJYwStw/FQpiswnYS0xe85ERxBYRMJO4/rmX CcRmFvCS+D7nL5DNwSEskCpx/lIhiCkikCaxfmEMRLWfxLre72CdLAKqEtuPz2AFsXmBJj5d uZgRYu1jJokJXX/ZQXo5gRr+bdcGqWEEOu37qTVQm8Qlbj2ZzwRxsoDEkj3noc4XlXj5+B8r hK0ksej2Z6h6PYkbU6ewQdjWEofWf4CKa0ssW/iaGeIGQYmTM5+wTGAUn4VkxSwk7bOQtM9C 0j4LSfsCRtZVjKLFqcVJuelGRnqpRZnJxcX5eXp5qSWbGIGRdnDLb4MdjC+fOx5iFOBgVOLh fXDOJVyINbGsuDL3EKMEB7OSCO/iDa7hQrwpiZVVqUX58UWlOanFhxilOViUxHn9XyqGCwmk J5akZqemFqQWwWSZODilGhhLHjdL7pR52bH35/O29psib4NDpVeZpv0x5uDZq80S/yzwS+DF sLiG5ucuN5grM11cJE4d4J9em/By/v1lp6Z5Jn/a/vKirJJuzswD6wo45h9/1TAvR7PSItdD W+tqyQ+R6ppMC6aFAsabfN+7vwmQeqGdG9N54sPhqebuNrqiGxuWsAVv5lJiKc5INNRiLipO BACmrNcUsAIAAA== Archived-At: Cc: "ice@ietf.org" , Bernard Aboba Subject: Re: [Ice] 5245bis: New ICE option to prevent legacy peers from using aggressive nomination X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 14:07:55 -0000 > On 22 May 2016, at 20:57, Christer Holmberg wrote: >=20 > And for that reason 5245bis endpoints will continue to support the case w= here the remote peer (a legacy endpoint) does use aggressive nomination (ev= en if the ICE option was included) :) > =20 > I hope that is stated in the meeting minutes. The meeting minutes say that we agreed to use both discussed options to tak= e care of this case. This includes "Endpoint must still be able to receive = aggressive nomination". Cheers, Ari= From nobody Thu May 26 12:57:29 2016 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 5477212D93D for ; Thu, 26 May 2016 12:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] 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 UgrV_ve2Xlv1 for ; Thu, 26 May 2016 12:57:25 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 92E8712D7CE for ; Thu, 26 May 2016 12:57:24 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id x7so65481431qkd.3 for ; Thu, 26 May 2016 12:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FhvjWFz259x++w/H2thalJ6ZDMYVCv8HV7BkCSSVD7g=; b=LkIlMKBFSeXCNNzkuYyzK0LSNHzlyPsY4B7Ox+HzPaFxH2ZviNQ4YO658ElzH6NksF FV/owRj2U4t3Pn1dQGW7TK4YAr4UOSer0DZxKuKDmVS41WlnVHvhni5wbSyA3kNCHB1w ny1mvXpFOmPg+Rh4n9wk0VjQaiECq8iugv3nznZOGTFwVmLVgfcOtxcTEbYEbgqWE9vx RxECiQlpB0TVlOxUPsZS55JuIOCWjBRftPoteLH4D5bE0jGELpjBfqrSITADsnxbYbuv dugjMaar/Y2ctFXSMlGVbn7ReszdM6+cKwUc2a29cyXz31cUvLtG042nPGoxRbYF9ocK 21Fg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FhvjWFz259x++w/H2thalJ6ZDMYVCv8HV7BkCSSVD7g=; b=ifvDuTPlJJWGY1seTkvf2RjUsRGUmch0VUMZWawfqBO+wHmmChZVTZ0bT8r6GHlh2Q 1ZYf8oa/1zmf0zqQRlshMXiNm5wBp0mIy4K4qSJhKuYFepZz+z7wNxybM5VGe8g72EFy 1rKc2Lw44JdXSuJ8kE8Ap1aVZyAYl57zPShemIU6fp2IQnDhN6K7IicoQvi+cYlZ2OKK UOLBw2ukHlXI2X4W7mwtmufl6+auNJw0q9xWXBFmjoZMI2ke9n2+SrcmK9IhgWKVJV8W lubh7XUwf4XiVvGkJ83cUMHOleYRZwwiclAFjUlu4isBMgYnXjgKI2/dtC/W45Ueg36s f2fQ== X-Gm-Message-State: ALyK8tJdiftVYXSWrO41dVvPKApjAP80QNB12IssiwK0NFhPn0dX0hpfJ0hlMxpaiDF/uYhYUsiAwT8WaBQ4FehO X-Received: by 10.200.53.22 with SMTP id y22mr10876435qtb.3.1464292643372; Thu, 26 May 2016 12:57:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.189.195 with HTTP; Thu, 26 May 2016 12:56:43 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Thu, 26 May 2016 12:56:43 -0700 Message-ID: To: Taylor Brandstetter Content-Type: multipart/alternative; boundary=001a11436412db4ff10533c432d0 Archived-At: Cc: ice@ietf.org Subject: Re: [Ice] Issues related to ICE role switching and conflicts X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 19:57:27 -0000 --001a11436412db4ff10533c432d0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, May 20, 2016 at 9:16 AM, Taylor Brandstetter wrote: > While investigating a WebRTC issue related to ICE role conflicts, I > noticed what seem to be some minor oddities with the rules surrounding IC= E > role determination. I'd like to hear what people think about these issues= , > and find out if I'm overlooking any motivations for the current rules. > > 1. Section 5.1.2, Determining Role states "An ICE restart causes a new > selection of roles and tiebreakers". The only time this is necessary, = as > far as I can tell, is when an agent is changing its implementation lev= el > (such as "full -> lite") and one agent *needs* to take up the > controlling role. So it would be ideal if this was the only situation = that > caused new role selection. Otherwise, in a third-party call control us= e > case that resulted in a role conflict initially, *every* ICE restart > will probably result in another role conflict, as the agents re-select > their initial conflicting roles. Also, what happens if ICE is restarti= ng > for only one media stream and the role changes according to this rule?= From > the perspective of the non-restarting media streams, the role would be > switching in the middle of ICE processing. > > =E2=80=8BI think that the two rules in the spec of "must change role" and= "role must be the same for all media streams" is bad combination, and I assume a mistake in RFC5245 that no one noticed before. Changing the role of the non-restarted media streams is unnecessary and can only lead to problems. But rather than have to have per-media-stream roles (relaxing the second rule), I think it would be easier to not change the role with an ICE restart (in other words, relax the first rule). As you point out, there really isn't any reason to except if the remote side moves from full to lite, which can be handled with a specific rule rather than a general "must always change" rule. So, I agree with changing the rule from "always change the role for all media streams when any stream is restarted" to "never change the role except when the remote implementation level switches to a lite implementation".=E2=80=8B > > 1. Also, why select a new tiebreaker? I don't see any real issue with > this, but it seems pointless. > > I also don't see a point, and would be in favor of not requiring it to change, if we can't think of a good reason to require it to change. > > 1. There's nothing that says "when changing implementation level, you > MUST restart ICE for *all* media streams". This requirement existed in > draft 13 of ICE, but then there was a bunch of restructuring and I thi= nk it > may have been removed accidentally. Regardless, I believe this conditi= on > should be added back, because changing implementation level in the mid= dle > of ICE processing for a media stream doesn't make much sense. > > If the implementation level must be the same for all media streams (and i= t must be, right?), then I think you're right that we should require an ICE restart for all the media streams when the implementation level changes. Otherwise, as you say, a given media stream will have the remote implementation level change without a restart, which seems problematic. And I don't see any reason why you wouldn't restart all media streams when you change the implementation level (presumably you're talking to a different endpoint anyway). > > 1. Section 6.1.3.1, Failure Cases states that when receiving a "role > conflict" error response, "the agent MUST switch to the > (controlling|controlled) role if it has not already done so". The cond= ition > "if it has not already done so", if interpreted literally, means that = the > agent can only switch to a role once. I don't think this was the inten= tion, > so the condition can probably be removed. It's worth noting that this > condition doesn't exist in Section 6.2.1.1, Detecting and Repairing Ro= le > Conflicts. > > =E2=80=8BI agree that it should be more clear, and would be with your sug= gested text change. =E2=80=8B > > 1. Starting to really stretch here, but in the rare situation where > there's a role conflict and the tie-breakers are equal, the peers coul= d > continue flipping between roles ad infinitum. Why not just generate a = new > tie-breaker? I saw that this was once brought up on the MMUSIC mailing= list > but I couldn't find a response. > > =E2=80=8BIt seems so rare as to not matter. But if it would make you and= others feel more comfortable, I'd be fine with that logic.=E2=80=8B > If there's general agreement about these points, I'll happily write some > pull requests for ICEbis. > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --001a11436412db4ff10533c432d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, May 20, 2016 at 9:16 AM, Taylor Brandstetter <deadb= eef@google.com> wrote:
While investigating a WebRTC issue related to ICE role conflic= ts, I noticed what seem to be some minor oddities with the rules surroundin= g ICE role determination. I'd like to hear what people think about thes= e issues, and find out if I'm overlooking any motivations for the curre= nt rules.
  1. Section 5.1.2, Determining Role states "An ICE r= estart causes a new selection of roles and tiebreakers". The only time= this is necessary, as far as I can tell, is when an agent is changing its = implementation level (such as "full -> lite") and one agent needs=C2=A0to take up the controlling role.=C2=A0So it would be ideal = if this was the only situation that caused new role selection. Otherwise, i= n a third-party call control use case that resulted in a role conflict init= ially, every=C2=A0ICE restart will probably result in another role c= onflict, as the agents re-select their initial conflicting roles. Also, wha= t happens if ICE is restarting for only one media stream and the role chang= es according to this rule? From the perspective of the non-restarting media= streams, the role would be switching in the middle of ICE processing.
    2. =
=E2=80=8BI think that the two rules i= n the spec of "must change role" and "role must be the same = for all media streams" is bad combination, and I assume a mistake in R= FC5245 that no one noticed before.=C2=A0 Changing the role of the non-resta= rted media streams is unnecessary and can only lead to problems. =C2=A0 But= rather than have to have per-media-stream roles (relaxing the second rule)= , I think it would be easier to not change the role with an ICE restart (in= other words, relax the first rule).=C2=A0 As you point out, there really i= sn't any reason to except if the remote side moves from full to lite, w= hich can be handled with a specific rule rather than a general "must a= lways change" rule.

So, I agree with changing the= rule from "always change the role for all media streams when any stre= am is restarted" to "never change the role except when the remote= implementation level switches to a lite implementation".=E2=80=8B
=C2=A0
  1. Also, why select a new tiebreaker? I don't see any real issu= e with this, but it seems pointless.
I also don't see a point, and would be in favor of not requiring it= to change, if we can't think of a good reason to require it to change.=
=C2=A0
  1. There's nothing that says "when changing implementa= tion level, you MUST restart ICE for all media streams". This r= equirement existed in draft 13 of ICE, but then there was a bunch of restru= cturing and I think it may have been removed accidentally. Regardless, I be= lieve this condition should be added back, because changing implementation = level in the middle of ICE processing for a media stream doesn't make m= uch sense.
If the implementation = level must be the same for all media streams (and it must be, right?), then= I think you're right that we should require an ICE restart for all the= media streams when the implementation level changes.=C2=A0 Otherwise, as y= ou say, a given media stream will have the remote implementation level chan= ge without a restart, which seems problematic.=C2=A0 And I don't see an= y reason why you wouldn't restart all media streams when you change the= implementation level (presumably you're talking to a different endpoin= t anyway).
=C2=A0
  1. Section 6.1.3.1, Failure Cases states that when re= ceiving a "role conflict" error response, "the agent MUST sw= itch to the (controlling|controlled) role if it has not already done so&quo= t;. The condition "if it has not already done so", if interpreted= literally, means that the agent can only switch to a role once. I don'= t think this was the intention, so the condition can probably be removed. I= t's worth noting that this condition doesn't exist in Section 6.2.1= .1, Detecting and Repairing Role Conflicts.
=E2=80=8BI agree that it should be more clear, and would be with your= suggested text change. =C2=A0
=E2=80=8B
  1. Starting to really stretch here, bu= t in the rare situation where there's a role conflict and the tie-break= ers are equal, the peers could continue flipping between roles ad infinitum= . Why not just generate a new tie-breaker? I saw that this was once brought= up on the MMUSIC mailing list but I couldn't find a response.
=E2=80=8BIt seems so rare as to not matte= r.=C2=A0 But if it would make you and others feel more comfortable, I'd= be fine with that logic.=E2=80=8B

=C2=A0
If there's general ag= reement about these points, I'll happily write some pull requests for I= CEbis.

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


--001a11436412db4ff10533c432d0-- From nobody Thu May 26 15:03:19 2016 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 C6EA012D507; Thu, 26 May 2016 15:03:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160526220306.14456.75441.idtracker@ietfa.amsl.com> Date: Thu, 26 May 2016 15:03:06 -0700 Archived-At: Cc: ben@nostrum.com, ice-chairs@ietf.org, pthatcher@webrtc.org, ice@ietf.org Subject: [Ice] ice - Update to a Meeting Session Request for IETF 96 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 22:03:08 -0000 An update to a 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): 2.5 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: payload core rtcweb avtext avtcore t2trg tls tsvarea tsvwg tram mmusic dispatch Second Priority: netvc rmcat httpbis perc Third Priority: xrblock clue lwig 6lo ace sipcore Special Requests: --------------------------------------------------------- From nobody Thu May 26 15:03:21 2016 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 BACDF12D526; Thu, 26 May 2016 15:03:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160526220314.14543.70314.idtracker@ietfa.amsl.com> Date: Thu, 26 May 2016 15:03:14 -0700 Archived-At: Cc: ben@nostrum.com, ice-chairs@ietf.org, pthatcher@webrtc.org, ice@ietf.org Subject: [Ice] ice - Update to a Meeting Session Request for IETF 96 X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 22:03:17 -0000 An update to a 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): 2.5 Hours Number of Attendees: 45 Conflicts to Avoid: First Priority: payload core rtcweb avtext avtcore t2trg tls tsvarea tsvwg tram mmusic dispatch Second Priority: netvc rmcat httpbis perc Third Priority: ace 6lo lwig clue xrblock sipcore Special Requests: --------------------------------------------------------- From nobody Thu May 26 15:31:01 2016 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 8025312D58D for ; Thu, 26 May 2016 15:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] 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 tXHT3fjpE_iL for ; Thu, 26 May 2016 15:30:57 -0700 (PDT) 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 73FCA12B051 for ; Thu, 26 May 2016 15:30:57 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id h185so36401184qke.2 for ; Thu, 26 May 2016 15:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Gu8Qo3S51at75QmpQTE7C+3uRdLq+HDYyPyr4Sd+tPo=; b=Ctxz28hkZxcOL9x2eAR5IkJ/wWi2g/NSOWi7UwrHPeJflB6m6eGFftGxdyP/C4mtGF a0R6+DDTb/qQVf/v4JIYgiFoxHYZTCfteRnSCL8D0LKr6GT5hVyyLG+yCmxHFHzU2f4p 2/RtYdrYmhbOoqzzysfWswfTl3NKD5MdZQRMYvLSxwBB0BvjiuvQUrK/gEHQjnawfyHR GbipsocEZfvzd6A48dxvjmKpwtXJ1JE45+fnHW9bpDqJoe2wYNTaK78S3EWJ2tzVxw/a 5r1bFOYFH19OHL3//Ua7YbqjItaaac4zxeZwMwBH0otw0ZR2A6JsG1o43QNFDU7IRj5I mHaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Gu8Qo3S51at75QmpQTE7C+3uRdLq+HDYyPyr4Sd+tPo=; b=OaiJF4RrVr3fiajzfem/1/gp0KUr8B3RBJoF8ACSntjCB7oxycYTjkp7LxaeU7f7xY m967f5fWuBASURl641YJBsUa4omaJFpsngaLI2vpJ09o/qF81DLOa9EI7crN4JEWfMDE Sv0r3WQk+acWLkmYSWWi9YA2kw039el4rlcU7j6wCm13zKXc1o2mcp1YLIsExG/2DW9D JNrqZdUJ2xGdeDvhcVRDFjfO0yGEk3XKPlilsfxv6q9CHopQ7e0RO3TpGg3N/I4kcCoc KrBIsG3rKKxFzN2qJFDSTO2YjdUFAhKb8HZCiw6q9Gh0vYBOrf7go27zz7GTm7CIiKSl onNw== X-Gm-Message-State: ALyK8tKdF3Ur06PUhrvriHE615/fWN/pw8AWksJW/jJU9+Xbq5ZRz8+UIPQvMidn7fpe6a+wxCoqU8IrUOCe51Tk X-Received: by 10.200.52.81 with SMTP id v17mr11026651qtb.91.1464301856436; Thu, 26 May 2016 15:30:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.189.195 with HTTP; Thu, 26 May 2016 15:30:16 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Thu, 26 May 2016 15:30:16 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1141562eff98290533c65723 Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] ICE 'simple' Option text [was: 5245bis: New ICE option to prevent legacy peers from using aggressive nomination] X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 22:31:00 -0000 --001a1141562eff98290533c65723 Content-Type: text/plain; charset=UTF-8 I don't really see how "simple" == "implements 5245bis". Why not just "ice2"? It's shorter and has actually meaning: the second RFC that defines ICE. If we make a new one in the future, we can call it "ice3". Otherwise, looks good. On Tue, May 24, 2016 at 1:12 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > Below is suggested new text for the ICE option: > > ---- > > 9. ICE Option > > This section defines a new ICE option, 'simple'. The ICE option > indicates that the ICE agent that includes it (in an ice-options > attribute) is compliant to this specification. For example, the ICE > agent will not use the aggressive nomination procedure defined in > [RFC5245]. > > An ICE agent compliant to this specification MUST inform the peer > about the compliance using the 'simple' ICE option. > > NOTE: The encoding of the 'simple' ICE option, and the message(s) > used to carry it to the peer, are protocol specific. The encoding > for the Session Description Protocol (SDP) [RFC4566] is defined in > [I-D.ietf-mmusic-ice-sip-sdp]. > > ----- > > (IANA considerations) > > 18.3. ICE Options > > IANA is requested to register the following ICE option in the "ICE > Options" sub-registry of the "Interactive Connectivity Establishment > (ICE) registry", following the procedures defined in [RFC6336]. > > ICE Option name: > > simple > > Contact: > > Name: Christer Holmberg > E-mail: christer.holmberg(at)ericsson(dot)com > Address: Oy LM Ericsson Ab, 02420 Jorvas, FINLAND > > Change control: > > IESG > > Description: > > The ICE option indicates that the ICE agent using the ICE option > is compliant and implemented according to RFC XXXX. > > Reference: > > RFC XXXX > > ---- > > Regards, > > Christer > > > _______________________________________________ > Ice mailing list > Ice@ietf.org > https://www.ietf.org/mailman/listinfo/ice > > --001a1141562eff98290533c65723 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't really see how "simple" =3D=3D &q= uot;implements 5245bis". =C2=A0 Why not just "ice2"?=C2=A0 I= t's shorter and has actually meaning: the second RFC that defines ICE.= =C2=A0 If we make a new one in the future, we can call it "ice3".= =C2=A0

Otherwise, looks good. =C2=A0

On Tue, May 24, 2016 a= t 1:12 AM, Christer Holmberg <christer.holmberg@ericsson.com<= /a>> wrote:

Hi,

Below is suggested new text for the ICE option:

----

9.=C2=A0 ICE Option

=C2=A0 =C2=A0This section defines a new ICE option, 'simple'.= =C2=A0 The ICE option
=C2=A0 =C2=A0indicates that the ICE agent that includes it (in an ice-= options
=C2=A0 =C2=A0attribute) is compliant to this specification.=C2=A0 For = example, the ICE
=C2=A0 =C2=A0agent will not use the aggressive nomination procedure de= fined in
=C2=A0 =C2=A0[RFC5245].

=C2=A0 =C2=A0An ICE agent compliant to this specification MUST inform = the peer
=C2=A0 =C2=A0about the compliance using the 'simple' ICE optio= n.

=C2=A0 =C2=A0NOTE: The encoding of the 'simple' ICE option, an= d the message(s)
=C2=A0 =C2=A0used to carry it to the peer, are protocol specific.=C2= =A0 The encoding
=C2=A0 =C2=A0for the Session Description Protocol (SDP) [RFC4566] is d= efined in
=C2=A0 =C2=A0[I-D.ietf-mmusic-ice-sip-sdp].

-----

(IANA considerations)

18.3.=C2=A0 ICE Options

=C2=A0 =C2=A0IANA is requested to register the following ICE option in= the "ICE
=C2=A0 =C2=A0Options" sub-registry of the "Interactive Conne= ctivity Establishment
=C2=A0 =C2=A0(ICE) registry", following the procedures defined in= [RFC6336].

=C2=A0 =C2=A0 =C2=A0ICE Option name:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 simple

=C2=A0 =C2=A0 =C2=A0Contact:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Name: =C2=A0 =C2=A0Christer Holmberg
=C2=A0 =C2=A0 =C2=A0 =C2=A0 E-mail: =C2=A0christer.holmberg(at)ericsso= n(dot)com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Address: Oy LM Ericsson Ab, 02420 Jorvas, = FINLAND

=C2=A0 =C2=A0 =C2=A0Change control:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 IESG

=C2=A0 =C2=A0 =C2=A0Description:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The ICE option indicates that the ICE agen= t using the ICE option
=C2=A0 =C2=A0 =C2=A0 =C2=A0 is compliant and implemented according to = RFC XXXX.

=C2=A0 =C2=A0 =C2=A0Reference:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC XXXX

----

Regards,

Christer


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


--001a1141562eff98290533c65723-- From nobody Fri May 27 00:30:43 2016 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 7ABDF12B059 for ; Fri, 27 May 2016 00:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 LK7rPO5SMwbo for ; Fri, 27 May 2016 00:30:40 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C147812DBD1 for ; Fri, 27 May 2016 00:29:20 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-1c-5747f74e1b94 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C0.D9.12926.E47F7475; Fri, 27 May 2016 09:29:19 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0294.000; Fri, 27 May 2016 09:29:18 +0200 From: Christer Holmberg To: Peter Thatcher Thread-Topic: [Ice] ICE 'simple' Option text [was: 5245bis: New ICE option to prevent legacy peers from using aggressive nomination] Thread-Index: AQHRtZQQA2HK/oRLDEWEFIzvz0YqVJ/Lr6sAgADJoQA= Date: Fri, 27 May 2016 07:29:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D36DD233951Cchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyM2J7oK7/d/dwg/XrWC2+Xai1uLb8NasD k8eCTaUeS5b8ZApgiuKySUnNySxLLdK3S+DKmDepj73gilVF64/PjA2MHw26GDk5JARMJF5O +8kEYYtJXLi3nq2LkYtDSOAIo8S2wxvYIZwljBL9u2eydjFycLAJWEh0/9MGaRAR0JSYPLkZ LMwsoCjxcq8aSLmwQCujxPW2NUwgjohAG6PE+ykP2SAarCSOb57ACmKzCKhKzHx2CczmBYrv u/KUBWJZI6PEm9Uz2EESnAKBEucaOsHOYwQ67/upNWA2s4C4xK0n86HOFpBYsuc8M4QtKvHy 8T+woaICehL7XpxnBLlOQkBJYtrWNIjWeIlXvyA+5hUQlDg58wnLBEaxWUimzkJSNgtJGURc R2LB7k9sELa2xLKFr5lh7DMHHkP1Wkv8vX+WGVnNAkaOVYyixanFSbnpRsZ6qUWZycXF+Xl6 eaklmxiB0Xlwy2/VHYyX3zgeYhTgYFTi4X1Q6B4uxJpYVlyZe4hRgoNZSYS36AtQiDclsbIq tSg/vqg0J7X4EKM0B4uSOK//S8VwIYH0xJLU7NTUgtQimCwTB6dUA6OnxycpC9lXnwXNyu8v XHWqRn7ppT7bmU0eBzg3++rvkS48nCeUc1cmSuLA+4JaL6sbn9KcD/L8XGpeXvL488Zd/J83 HJPe1PY1euofzaxN36Vl1rCWFk1ZGbx1faqRcOuRd0dili1zz9lpfVnknPTptUraEaU2AktX NEdfPvR5UaqRoIrR1EIlluKMREMt5qLiRABRF/fCygIAAA== Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] ICE 'simple' Option text [was: 5245bis: New ICE option to prevent legacy peers from using aggressive nomination] X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 07:30:42 -0000 --_000_D36DD233951Cchristerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >I don't really see how "simple" =3D=3D "implements 5245bis". 5245bis is simple :) >Why not just "ice2"? It's shorter and has actually meaning: the second RF= C that defines ICE. If we make a new one in the future, we can call it "ic= e3". Works for me. Regards, Christer On Tue, May 24, 2016 at 1:12 AM, Christer Holmberg > wrote: Hi, Below is suggested new text for the ICE option: ---- 9. ICE Option This section defines a new ICE option, 'simple'. The ICE option indicates that the ICE agent that includes it (in an ice-options attribute) is compliant to this specification. For example, the ICE agent will not use the aggressive nomination procedure defined in [RFC5245]. An ICE agent compliant to this specification MUST inform the peer about the compliance using the 'simple' ICE option. NOTE: The encoding of the 'simple' ICE option, and the message(s) used to carry it to the peer, are protocol specific. The encoding for the Session Description Protocol (SDP) [RFC4566] is defined in [I-D.ietf-mmusic-ice-sip-sdp]. ----- (IANA considerations) 18.3. ICE Options IANA is requested to register the following ICE option in the "ICE Options" sub-registry of the "Interactive Connectivity Establishment (ICE) registry", following the procedures defined in [RFC6336]. ICE Option name: simple Contact: Name: Christer Holmberg E-mail: christer.holmberg(at)ericsson(dot)com Address: Oy LM Ericsson Ab, 02420 Jorvas, FINLAND Change control: IESG Description: The ICE option indicates that the ICE agent using the ICE option is compliant and implemented according to RFC XXXX. Reference: RFC XXXX ---- Regards, Christer _______________________________________________ Ice mailing list Ice@ietf.org https://www.ietf.org/mailman/listinfo/ice --_000_D36DD233951Cchristerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

>I don't really see how "simple" =3D=3D "implements 52= 45bis".

5245bis is simple :)

>Why not just "ice2"?  It's shorter and has actually m= eaning: the second RFC that defines ICE.  If we make a new one in the = future, we can call it "ice3".  

Works for me.

Regards,

Christer



On Tue, May 24, 2016 at 1:12 AM, Christer Holmbe= rg <chr= ister.holmberg@ericsson.com> wrote:

Hi,

Below is suggested new text for the ICE option:

----

9.  ICE Option

   This section defines a new ICE option, 'simple'.  Th= e ICE option
   indicates that the ICE agent that includes it (in an ice-= options
   attribute) is compliant to this specification.  For = example, the ICE
   agent will not use the aggressive nomination procedure de= fined in
   [RFC5245].

   An ICE agent compliant to this specification MUST inform = the peer
   about the compliance using the 'simple' ICE option.

   NOTE: The encoding of the 'simple' ICE option, and the me= ssage(s)
   used to carry it to the peer, are protocol specific. = ; The encoding
   for the Session Description Protocol (SDP) [RFC4566] is d= efined in
   [I-D.ietf-mmusic-ice-sip-sdp].

-----

(IANA considerations)

18.3.  ICE Options

   IANA is requested to register the following ICE option in= the "ICE
   Options" sub-registry of the "Interactive Conne= ctivity Establishment
   (ICE) registry", following the procedures defined in= [RFC6336].

     ICE Option name:

        simple

     Contact:

        Name:    Christer Holmberg
        E-mail:  christer.holmberg(at)ericsso= n(dot)com
        Address: Oy LM Ericsson Ab, 02420 Jorvas, = FINLAND

     Change control:

        IESG

     Description:

        The ICE option indicates that the ICE agen= t using the ICE option
        is compliant and implemented according to = RFC XXXX.

     Reference:

        RFC XXXX

----

Regards,

Christer


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


 --_000_D36DD233951Cchristerholmbergericssoncom_-- From nobody Fri May 27 05:57:53 2016 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 61C8E12DA74 for ; Fri, 27 May 2016 05:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 yNDnBDmEihDM for ; Fri, 27 May 2016 05:57:50 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7785712DA7A for ; Fri, 27 May 2016 05:57:49 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-09-5748444b886f Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 34.34.18043.B4448475; Fri, 27 May 2016 14:57:47 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.152]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0294.000; Fri, 27 May 2016 14:57:46 +0200 From: Christer Holmberg To: Peter Thatcher , Taylor Brandstetter Thread-Topic: [Ice] Issues related to ICE role switching and conflicts Thread-Index: AQHRsrMPW+cUSE0OREq9RLjfNQmSUJ/LioaAgAFQTgA= Date: Fri, 27 May 2016 12:57:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D36E1E9B9565christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNIsWRmVeSWpSXmKPExsUyM2K7q663i0e4wdxeSYvLKx6yWny7UGtx bflrVgdmjwWbSj2WLPnJFMAUxWWTkpqTWZZapG+XwJWxYskm9oKdcxkrPh2aztTAOG8mYxcj J4eEgInE6i3nmCBsMYkL99azdTFycQgJHGGUmH3rJzOEs4RRou3BdqAODg42AQuJ7n/aIA0i AmESE06eYQMJMwsoSrzcqwZiCgu4SnT1FEFUuEk8u/uaGcK2kjh59xIbiM0ioCrxe94TdhCb Fyg+ddYfVohN0xkl9k84xAqS4BQIlNiw+hLYnYxAt30/tQbsTmYBcYlbT+ZD3SwgsWTPeWYI W1Ti5eN/YL2iAnoS+16ch/pRUeLjq32MEL3xEp1fljBCLBaUODnzCcsERrFZSMbOQlI2C0nZ LLAvNSXW79KHKFGUmNL9kB3C1pBonTMXyraWaH34iQVZzQJGjlWMosWpxcW56UZGeqlFmcnF xfl5enmpJZsYgVF6cMtvqx2MB587HmIU4GBU4uF9UOgeLsSaWFZcmXuIUYKDWUmEl9PZI1yI NyWxsiq1KD++qDQntfgQozQHi5I4r/9LxXAhgfTEktTs1NSC1CKYLBMHp1QD4+qvM39sZv3c vXdLvL3exsyCQ5KWeQfnHNYLWvLf/eUaoYK4jV39ru5fXjbc8fqhzdT6tu6iZRFT9wsm3Vep PvMyc+a88Pwa/IKpoi3iA2tGxvr4b6skOLYX/jy6kivuuWJE3T3e4ISWwujGDxde6GSaG3sa iH5p7neRX3ZhE68wyz7uG33mSizFGYmGWsxFxYkA9e5Rj84CAAA= Archived-At: Cc: "ice@ietf.org" Subject: Re: [Ice] Issues related to ICE role switching and conflicts X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 12:57:52 -0000 --_000_D36E1E9B9565christerholmbergericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSwNCg0KV2hhdCB1c2UtY2FzZXMgYXJlIHRoZXJlIGZvciBhIGZ1bGwtPmxpdGUgc3dpdGNo PyBXaGVuIGFuIGVuZHBvaW50IHJlYWxpc2VzIHRoYXQgaXTigJlzIG5vIGxvbmdlciBiZWhpbmQg YSBOQVQsIGFuZCBkb2VzbuKAmXQgd2FudCB0byB1c2UgZnVsbCBJQ0U/DQoNCkFzIGZhciBhcyBJ IHVuZGVyc3RhbmQsIElDRS1saXRlIGlzIG1lYW50IGZvciDigJxzdGF0aWPigJ0gbmV0d29yayBi b3hlcyAoZ2F0ZXdheXMgZXRjKSB0aGF0IGFyZSBub3QgbG9jYXRlZCBiZWhpbmQgYSBOQVQuDQoN ClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQpGcm9tOiBJY2UgPGljZS1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzppY2UtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiAicHRoYXRjaGVy QGdvb2dsZS5jb208bWFpbHRvOnB0aGF0Y2hlckBnb29nbGUuY29tPiIgPHB0aGF0Y2hlckBnb29n bGUuY29tPG1haWx0bzpwdGhhdGNoZXJAZ29vZ2xlLmNvbT4+DQpEYXRlOiBUaHVyc2RheSAyNiBN YXkgMjAxNiBhdCAyMjo1Ng0KVG86IFRheWxvciBCcmFuZHN0ZXR0ZXIgPGRlYWRiZWVmQGdvb2ds ZS5jb208bWFpbHRvOmRlYWRiZWVmQGdvb2dsZS5jb20+Pg0KQ2M6ICJpY2VAaWV0Zi5vcmc8bWFp bHRvOmljZUBpZXRmLm9yZz4iIDxpY2VAaWV0Zi5vcmc8bWFpbHRvOmljZUBpZXRmLm9yZz4+DQpT dWJqZWN0OiBSZTogW0ljZV0gSXNzdWVzIHJlbGF0ZWQgdG8gSUNFIHJvbGUgc3dpdGNoaW5nIGFu ZCBjb25mbGljdHMNCg0KDQoNCk9uIEZyaSwgTWF5IDIwLCAyMDE2IGF0IDk6MTYgQU0sIFRheWxv ciBCcmFuZHN0ZXR0ZXIgPGRlYWRiZWVmQGdvb2dsZS5jb208bWFpbHRvOmRlYWRiZWVmQGdvb2ds ZS5jb20+PiB3cm90ZToNCldoaWxlIGludmVzdGlnYXRpbmcgYSBXZWJSVEMgaXNzdWUgcmVsYXRl ZCB0byBJQ0Ugcm9sZSBjb25mbGljdHMsIEkgbm90aWNlZCB3aGF0IHNlZW0gdG8gYmUgc29tZSBt aW5vciBvZGRpdGllcyB3aXRoIHRoZSBydWxlcyBzdXJyb3VuZGluZyBJQ0Ugcm9sZSBkZXRlcm1p bmF0aW9uLiBJJ2QgbGlrZSB0byBoZWFyIHdoYXQgcGVvcGxlIHRoaW5rIGFib3V0IHRoZXNlIGlz c3VlcywgYW5kIGZpbmQgb3V0IGlmIEknbSBvdmVybG9va2luZyBhbnkgbW90aXZhdGlvbnMgZm9y IHRoZSBjdXJyZW50IHJ1bGVzLg0KDQogIDEuICBTZWN0aW9uIDUuMS4yLCBEZXRlcm1pbmluZyBS b2xlIHN0YXRlcyAiQW4gSUNFIHJlc3RhcnQgY2F1c2VzIGEgbmV3IHNlbGVjdGlvbiBvZiByb2xl cyBhbmQgdGllYnJlYWtlcnMiLiBUaGUgb25seSB0aW1lIHRoaXMgaXMgbmVjZXNzYXJ5LCBhcyBm YXIgYXMgSSBjYW4gdGVsbCwgaXMgd2hlbiBhbiBhZ2VudCBpcyBjaGFuZ2luZyBpdHMgaW1wbGVt ZW50YXRpb24gbGV2ZWwgKHN1Y2ggYXMgImZ1bGwgLT4gbGl0ZSIpIGFuZCBvbmUgYWdlbnQgbmVl ZHMgdG8gdGFrZSB1cCB0aGUgY29udHJvbGxpbmcgcm9sZS4gU28gaXQgd291bGQgYmUgaWRlYWwg aWYgdGhpcyB3YXMgdGhlIG9ubHkgc2l0dWF0aW9uIHRoYXQgY2F1c2VkIG5ldyByb2xlIHNlbGVj dGlvbi4gT3RoZXJ3aXNlLCBpbiBhIHRoaXJkLXBhcnR5IGNhbGwgY29udHJvbCB1c2UgY2FzZSB0 aGF0IHJlc3VsdGVkIGluIGEgcm9sZSBjb25mbGljdCBpbml0aWFsbHksIGV2ZXJ5IElDRSByZXN0 YXJ0IHdpbGwgcHJvYmFibHkgcmVzdWx0IGluIGFub3RoZXIgcm9sZSBjb25mbGljdCwgYXMgdGhl IGFnZW50cyByZS1zZWxlY3QgdGhlaXIgaW5pdGlhbCBjb25mbGljdGluZyByb2xlcy4gQWxzbywg d2hhdCBoYXBwZW5zIGlmIElDRSBpcyByZXN0YXJ0aW5nIGZvciBvbmx5IG9uZSBtZWRpYSBzdHJl YW0gYW5kIHRoZSByb2xlIGNoYW5nZXMgYWNjb3JkaW5nIHRvIHRoaXMgcnVsZT8gRnJvbSB0aGUg cGVyc3BlY3RpdmUgb2YgdGhlIG5vbi1yZXN0YXJ0aW5nIG1lZGlhIHN0cmVhbXMsIHRoZSByb2xl IHdvdWxkIGJlIHN3aXRjaGluZyBpbiB0aGUgbWlkZGxlIG9mIElDRSBwcm9jZXNzaW5nLg0KDQri gItJIHRoaW5rIHRoYXQgdGhlIHR3byBydWxlcyBpbiB0aGUgc3BlYyBvZiAibXVzdCBjaGFuZ2Ug cm9sZSIgYW5kICJyb2xlIG11c3QgYmUgdGhlIHNhbWUgZm9yIGFsbCBtZWRpYSBzdHJlYW1zIiBp cyBiYWQgY29tYmluYXRpb24sIGFuZCBJIGFzc3VtZSBhIG1pc3Rha2UgaW4gUkZDNTI0NSB0aGF0 IG5vIG9uZSBub3RpY2VkIGJlZm9yZS4gIENoYW5naW5nIHRoZSByb2xlIG9mIHRoZSBub24tcmVz dGFydGVkIG1lZGlhIHN0cmVhbXMgaXMgdW5uZWNlc3NhcnkgYW5kIGNhbiBvbmx5IGxlYWQgdG8g cHJvYmxlbXMuICAgQnV0IHJhdGhlciB0aGFuIGhhdmUgdG8gaGF2ZSBwZXItbWVkaWEtc3RyZWFt IHJvbGVzIChyZWxheGluZyB0aGUgc2Vjb25kIHJ1bGUpLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGVh c2llciB0byBub3QgY2hhbmdlIHRoZSByb2xlIHdpdGggYW4gSUNFIHJlc3RhcnQgKGluIG90aGVy IHdvcmRzLCByZWxheCB0aGUgZmlyc3QgcnVsZSkuICBBcyB5b3UgcG9pbnQgb3V0LCB0aGVyZSBy ZWFsbHkgaXNuJ3QgYW55IHJlYXNvbiB0byBleGNlcHQgaWYgdGhlIHJlbW90ZSBzaWRlIG1vdmVz IGZyb20gZnVsbCB0byBsaXRlLCB3aGljaCBjYW4gYmUgaGFuZGxlZCB3aXRoIGEgc3BlY2lmaWMg cnVsZSByYXRoZXIgdGhhbiBhIGdlbmVyYWwgIm11c3QgYWx3YXlzIGNoYW5nZSIgcnVsZS4NCg0K U28sIEkgYWdyZWUgd2l0aCBjaGFuZ2luZyB0aGUgcnVsZSBmcm9tICJhbHdheXMgY2hhbmdlIHRo ZSByb2xlIGZvciBhbGwgbWVkaWEgc3RyZWFtcyB3aGVuIGFueSBzdHJlYW0gaXMgcmVzdGFydGVk IiB0byAibmV2ZXIgY2hhbmdlIHRoZSByb2xlIGV4Y2VwdCB3aGVuIHRoZSByZW1vdGUgaW1wbGVt ZW50YXRpb24gbGV2ZWwgc3dpdGNoZXMgdG8gYSBsaXRlIGltcGxlbWVudGF0aW9uIi7igIsNCg0K DQogIDEuICBBbHNvLCB3aHkgc2VsZWN0IGEgbmV3IHRpZWJyZWFrZXI/IEkgZG9uJ3Qgc2VlIGFu eSByZWFsIGlzc3VlIHdpdGggdGhpcywgYnV0IGl0IHNlZW1zIHBvaW50bGVzcy4NCg0KSSBhbHNv IGRvbid0IHNlZSBhIHBvaW50LCBhbmQgd291bGQgYmUgaW4gZmF2b3Igb2Ygbm90IHJlcXVpcmlu ZyBpdCB0byBjaGFuZ2UsIGlmIHdlIGNhbid0IHRoaW5rIG9mIGEgZ29vZCByZWFzb24gdG8gcmVx dWlyZSBpdCB0byBjaGFuZ2UuDQoNCg0KICAxLiAgVGhlcmUncyBub3RoaW5nIHRoYXQgc2F5cyAi d2hlbiBjaGFuZ2luZyBpbXBsZW1lbnRhdGlvbiBsZXZlbCwgeW91IE1VU1QgcmVzdGFydCBJQ0Ug Zm9yIGFsbCBtZWRpYSBzdHJlYW1zIi4gVGhpcyByZXF1aXJlbWVudCBleGlzdGVkIGluIGRyYWZ0 IDEzIG9mIElDRSwgYnV0IHRoZW4gdGhlcmUgd2FzIGEgYnVuY2ggb2YgcmVzdHJ1Y3R1cmluZyBh bmQgSSB0aGluayBpdCBtYXkgaGF2ZSBiZWVuIHJlbW92ZWQgYWNjaWRlbnRhbGx5LiBSZWdhcmRs ZXNzLCBJIGJlbGlldmUgdGhpcyBjb25kaXRpb24gc2hvdWxkIGJlIGFkZGVkIGJhY2ssIGJlY2F1 c2UgY2hhbmdpbmcgaW1wbGVtZW50YXRpb24gbGV2ZWwgaW4gdGhlIG1pZGRsZSBvZiBJQ0UgcHJv Y2Vzc2luZyBmb3IgYSBtZWRpYSBzdHJlYW0gZG9lc24ndCBtYWtlIG11Y2ggc2Vuc2UuDQoNCklm IHRoZSBpbXBsZW1lbnRhdGlvbiBsZXZlbCBtdXN0IGJlIHRoZSBzYW1lIGZvciBhbGwgbWVkaWEg c3RyZWFtcyAoYW5kIGl0IG11c3QgYmUsIHJpZ2h0PyksIHRoZW4gSSB0aGluayB5b3UncmUgcmln aHQgdGhhdCB3ZSBzaG91bGQgcmVxdWlyZSBhbiBJQ0UgcmVzdGFydCBmb3IgYWxsIHRoZSBtZWRp YSBzdHJlYW1zIHdoZW4gdGhlIGltcGxlbWVudGF0aW9uIGxldmVsIGNoYW5nZXMuICBPdGhlcndp c2UsIGFzIHlvdSBzYXksIGEgZ2l2ZW4gbWVkaWEgc3RyZWFtIHdpbGwgaGF2ZSB0aGUgcmVtb3Rl IGltcGxlbWVudGF0aW9uIGxldmVsIGNoYW5nZSB3aXRob3V0IGEgcmVzdGFydCwgd2hpY2ggc2Vl bXMgcHJvYmxlbWF0aWMuICBBbmQgSSBkb24ndCBzZWUgYW55IHJlYXNvbiB3aHkgeW91IHdvdWxk bid0IHJlc3RhcnQgYWxsIG1lZGlhIHN0cmVhbXMgd2hlbiB5b3UgY2hhbmdlIHRoZSBpbXBsZW1l bnRhdGlvbiBsZXZlbCAocHJlc3VtYWJseSB5b3UncmUgdGFsa2luZyB0byBhIGRpZmZlcmVudCBl bmRwb2ludCBhbnl3YXkpLg0KDQoNCiAgMS4gIFNlY3Rpb24gNi4xLjMuMSwgRmFpbHVyZSBDYXNl cyBzdGF0ZXMgdGhhdCB3aGVuIHJlY2VpdmluZyBhICJyb2xlIGNvbmZsaWN0IiBlcnJvciByZXNw b25zZSwgInRoZSBhZ2VudCBNVVNUIHN3aXRjaCB0byB0aGUgKGNvbnRyb2xsaW5nfGNvbnRyb2xs ZWQpIHJvbGUgaWYgaXQgaGFzIG5vdCBhbHJlYWR5IGRvbmUgc28iLiBUaGUgY29uZGl0aW9uICJp ZiBpdCBoYXMgbm90IGFscmVhZHkgZG9uZSBzbyIsIGlmIGludGVycHJldGVkIGxpdGVyYWxseSwg bWVhbnMgdGhhdCB0aGUgYWdlbnQgY2FuIG9ubHkgc3dpdGNoIHRvIGEgcm9sZSBvbmNlLiBJIGRv bid0IHRoaW5rIHRoaXMgd2FzIHRoZSBpbnRlbnRpb24sIHNvIHRoZSBjb25kaXRpb24gY2FuIHBy b2JhYmx5IGJlIHJlbW92ZWQuIEl0J3Mgd29ydGggbm90aW5nIHRoYXQgdGhpcyBjb25kaXRpb24g ZG9lc24ndCBleGlzdCBpbiBTZWN0aW9uIDYuMi4xLjEsIERldGVjdGluZyBhbmQgUmVwYWlyaW5n IFJvbGUgQ29uZmxpY3RzLg0KDQrigItJIGFncmVlIHRoYXQgaXQgc2hvdWxkIGJlIG1vcmUgY2xl YXIsIGFuZCB3b3VsZCBiZSB3aXRoIHlvdXIgc3VnZ2VzdGVkIHRleHQgY2hhbmdlLg0K4oCLDQoN CiAgMS4gIFN0YXJ0aW5nIHRvIHJlYWxseSBzdHJldGNoIGhlcmUsIGJ1dCBpbiB0aGUgcmFyZSBz aXR1YXRpb24gd2hlcmUgdGhlcmUncyBhIHJvbGUgY29uZmxpY3QgYW5kIHRoZSB0aWUtYnJlYWtl cnMgYXJlIGVxdWFsLCB0aGUgcGVlcnMgY291bGQgY29udGludWUgZmxpcHBpbmcgYmV0d2VlbiBy b2xlcyBhZCBpbmZpbml0dW0uIFdoeSBub3QganVzdCBnZW5lcmF0ZSBhIG5ldyB0aWUtYnJlYWtl cj8gSSBzYXcgdGhhdCB0aGlzIHdhcyBvbmNlIGJyb3VnaHQgdXAgb24gdGhlIE1NVVNJQyBtYWls aW5nIGxpc3QgYnV0IEkgY291bGRuJ3QgZmluZCBhIHJlc3BvbnNlLg0KDQrigItJdCBzZWVtcyBz byByYXJlIGFzIHRvIG5vdCBtYXR0ZXIuICBCdXQgaWYgaXQgd291bGQgbWFrZSB5b3UgYW5kIG90 aGVycyBmZWVsIG1vcmUgY29tZm9ydGFibGUsIEknZCBiZSBmaW5lIHdpdGggdGhhdCBsb2dpYy7i gIsNCg0KDQpJZiB0aGVyZSdzIGdlbmVyYWwgYWdyZWVtZW50IGFib3V0IHRoZXNlIHBvaW50cywg SSdsbCBoYXBwaWx5IHdyaXRlIHNvbWUgcHVsbCByZXF1ZXN0cyBmb3IgSUNFYmlzLg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSWNlIG1haWxpbmcg bGlzdA0KSWNlQGlldGYub3JnPG1haWx0bzpJY2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZQ0KDQoNCg== --_000_D36E1E9B9565christerholmbergericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+SGksPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5XaGF0IHVzZS1jYXNl cyBhcmUgdGhlcmUgZm9yIGEgZnVsbC0mZ3Q7bGl0ZSBzd2l0Y2g/IFdoZW4gYW4gZW5kcG9pbnQg cmVhbGlzZXMgdGhhdCBpdOKAmXMgbm8gbG9uZ2VyIGJlaGluZCBhIE5BVCwgYW5kIGRvZXNu4oCZ dCB3YW50IHRvIHVzZSBmdWxsIElDRT88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFz IGZhciBhcyBJIHVuZGVyc3RhbmQsIElDRS1saXRlIGlzIG1lYW50IGZvciDigJxzdGF0aWPigJ0g bmV0d29yayBib3hlcyAoZ2F0ZXdheXMgZXRjKSB0aGF0IGFyZSBub3QgbG9jYXRlZCBiZWhpbmQg YSBOQVQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzLDwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+Q2hyaXN0ZXI8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JP RFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6 MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVt IG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFE RElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAx cHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5JY2UgJmx0OzxhIGhy ZWY9Im1haWx0bzppY2UtYm91bmNlc0BpZXRmLm9yZyI+aWNlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ Jmd0OyBvbiBiZWhhbGYgb2YgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnB0aGF0Y2hlckBnb29nbGUu Y29tIj5wdGhhdGNoZXJAZ29vZ2xlLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpw dGhhdGNoZXJAZ29vZ2xlLmNvbSI+cHRoYXRjaGVyQGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+VGh1cnNkYXkgMjYgTWF5 IDIwMTYgYXQgMjI6NTY8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwv c3Bhbj5UYXlsb3IgQnJhbmRzdGV0dGVyICZsdDs8YSBocmVmPSJtYWlsdG86ZGVhZGJlZWZAZ29v Z2xlLmNvbSI+ZGVhZGJlZWZAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZv bnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmljZUBpZXRm Lm9yZyI+aWNlQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmljZUBpZXRm Lm9yZyI+aWNlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbSWNlXSBJc3N1ZXMgcmVsYXRlZCB0byBJQ0Ugcm9s ZSBzd2l0Y2hpbmcgYW5kIGNvbmZsaWN0czxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0 IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPjxicj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj5PbiBGcmksIE1heSAyMCwgMjAxNiBhdCA5OjE2IEFNLCBUYXlsb3IgQnJhbmRzdGV0dGVy IDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86ZGVhZGJlZWZAZ29vZ2xlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmRlYWRiZWVmQGdvb2dsZS5jb208L2E+Jmd0Ozwvc3Bhbj4gd3Jv dGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAg MCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8 ZGl2IGRpcj0ibHRyIj5XaGlsZSBpbnZlc3RpZ2F0aW5nIGEgV2ViUlRDIGlzc3VlIHJlbGF0ZWQg dG8gSUNFIHJvbGUgY29uZmxpY3RzLCBJIG5vdGljZWQgd2hhdCBzZWVtIHRvIGJlIHNvbWUgbWlu b3Igb2RkaXRpZXMgd2l0aCB0aGUgcnVsZXMgc3Vycm91bmRpbmcgSUNFIHJvbGUgZGV0ZXJtaW5h dGlvbi4gSSdkIGxpa2UgdG8gaGVhciB3aGF0IHBlb3BsZSB0aGluayBhYm91dCB0aGVzZSBpc3N1 ZXMsIGFuZCBmaW5kIG91dCBpZiBJJ20gb3Zlcmxvb2tpbmcNCiBhbnkgbW90aXZhdGlvbnMgZm9y IHRoZSBjdXJyZW50IHJ1bGVzLg0KPGRpdj4NCjxvbD4NCjxsaT5TZWN0aW9uIDUuMS4yLCBEZXRl cm1pbmluZyBSb2xlIHN0YXRlcyAmcXVvdDtBbiBJQ0UgcmVzdGFydCBjYXVzZXMgYSBuZXcgc2Vs ZWN0aW9uIG9mIHJvbGVzIGFuZCB0aWVicmVha2VycyZxdW90Oy4gVGhlIG9ubHkgdGltZSB0aGlz IGlzIG5lY2Vzc2FyeSwgYXMgZmFyIGFzIEkgY2FuIHRlbGwsIGlzIHdoZW4gYW4gYWdlbnQgaXMg Y2hhbmdpbmcgaXRzIGltcGxlbWVudGF0aW9uIGxldmVsIChzdWNoIGFzICZxdW90O2Z1bGwgLSZn dDsgbGl0ZSZxdW90OykgYW5kIG9uZSBhZ2VudA0KPGk+bmVlZHM8L2k+Jm5ic3A7dG8gdGFrZSB1 cCB0aGUgY29udHJvbGxpbmcgcm9sZS4mbmJzcDtTbyBpdCB3b3VsZCBiZSBpZGVhbCBpZiB0aGlz IHdhcyB0aGUgb25seSBzaXR1YXRpb24gdGhhdCBjYXVzZWQgbmV3IHJvbGUgc2VsZWN0aW9uLiBP dGhlcndpc2UsIGluIGEgdGhpcmQtcGFydHkgY2FsbCBjb250cm9sIHVzZSBjYXNlIHRoYXQgcmVz dWx0ZWQgaW4gYSByb2xlIGNvbmZsaWN0IGluaXRpYWxseSwNCjxpPmV2ZXJ5PC9pPiZuYnNwO0lD RSByZXN0YXJ0IHdpbGwgcHJvYmFibHkgcmVzdWx0IGluIGFub3RoZXIgcm9sZSBjb25mbGljdCwg YXMgdGhlIGFnZW50cyByZS1zZWxlY3QgdGhlaXIgaW5pdGlhbCBjb25mbGljdGluZyByb2xlcy4g QWxzbywgd2hhdCBoYXBwZW5zIGlmIElDRSBpcyByZXN0YXJ0aW5nIGZvciBvbmx5IG9uZSBtZWRp YSBzdHJlYW0gYW5kIHRoZSByb2xlIGNoYW5nZXMgYWNjb3JkaW5nIHRvIHRoaXMgcnVsZT8gRnJv bSB0aGUgcGVyc3BlY3RpdmUNCiBvZiB0aGUgbm9uLXJlc3RhcnRpbmcgbWVkaWEgc3RyZWFtcywg dGhlIHJvbGUgd291bGQgYmUgc3dpdGNoaW5nIGluIHRoZSBtaWRkbGUgb2YgSUNFIHByb2Nlc3Np bmcuPC9saT48L29sPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWYiPuKAi0kgdGhpbmsgdGhhdCB0aGUgdHdvIHJ1bGVzIGluIHRoZSBzcGVjIG9m ICZxdW90O211c3QgY2hhbmdlIHJvbGUmcXVvdDsgYW5kICZxdW90O3JvbGUgbXVzdCBiZSB0aGUg c2FtZSBmb3IgYWxsIG1lZGlhIHN0cmVhbXMmcXVvdDsgaXMgYmFkIGNvbWJpbmF0aW9uLCBhbmQg SSBhc3N1bWUgYSBtaXN0YWtlIGluIFJGQzUyNDUgdGhhdCBubyBvbmUgbm90aWNlZA0KIGJlZm9y ZS4mbmJzcDsgQ2hhbmdpbmcgdGhlIHJvbGUgb2YgdGhlIG5vbi1yZXN0YXJ0ZWQgbWVkaWEgc3Ry ZWFtcyBpcyB1bm5lY2Vzc2FyeSBhbmQgY2FuIG9ubHkgbGVhZCB0byBwcm9ibGVtcy4gJm5ic3A7 IEJ1dCByYXRoZXIgdGhhbiBoYXZlIHRvIGhhdmUgcGVyLW1lZGlhLXN0cmVhbSByb2xlcyAocmVs YXhpbmcgdGhlIHNlY29uZCBydWxlKSwgSSB0aGluayBpdCB3b3VsZCBiZSBlYXNpZXIgdG8gbm90 IGNoYW5nZSB0aGUgcm9sZSB3aXRoIGFuIElDRSByZXN0YXJ0DQogKGluIG90aGVyIHdvcmRzLCBy ZWxheCB0aGUgZmlyc3QgcnVsZSkuJm5ic3A7IEFzIHlvdSBwb2ludCBvdXQsIHRoZXJlIHJlYWxs eSBpc24ndCBhbnkgcmVhc29uIHRvIGV4Y2VwdCBpZiB0aGUgcmVtb3RlIHNpZGUgbW92ZXMgZnJv bSBmdWxsIHRvIGxpdGUsIHdoaWNoIGNhbiBiZSBoYW5kbGVkIHdpdGggYSBzcGVjaWZpYyBydWxl IHJhdGhlciB0aGFuIGEgZ2VuZXJhbCAmcXVvdDttdXN0IGFsd2F5cyBjaGFuZ2UmcXVvdDsgcnVs ZS48L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTph cmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFp bF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYi PlNvLCBJIGFncmVlIHdpdGggY2hhbmdpbmcgdGhlIHJ1bGUgZnJvbSAmcXVvdDthbHdheXMgY2hh bmdlIHRoZSByb2xlIGZvciBhbGwgbWVkaWEgc3RyZWFtcyB3aGVuIGFueSBzdHJlYW0gaXMgcmVz dGFydGVkJnF1b3Q7IHRvICZxdW90O25ldmVyIGNoYW5nZSB0aGUgcm9sZSBleGNlcHQgd2hlbiB0 aGUgcmVtb3RlIGltcGxlbWVudGF0aW9uIGxldmVsDQogc3dpdGNoZXMgdG8gYSBsaXRlIGltcGxl bWVudGF0aW9uJnF1b3Q7LuKAizwvZGl2Pg0KPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9y ZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRy Ij4NCjxkaXY+DQo8b2w+DQo8bGk+QWxzbywgd2h5IHNlbGVjdCBhIG5ldyB0aWVicmVha2VyPyBJ IGRvbid0IHNlZSBhbnkgcmVhbCBpc3N1ZSB3aXRoIHRoaXMsIGJ1dCBpdCBzZWVtcyBwb2ludGxl c3MuPC9saT48L29sPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNh LHNhbnMtc2VyaWYiPkkgYWxzbyBkb24ndCBzZWUgYSBwb2ludCwgYW5kIHdvdWxkIGJlIGluIGZh dm9yIG9mIG5vdCByZXF1aXJpbmcgaXQgdG8gY2hhbmdlLCBpZiB3ZSBjYW4ndCB0aGluayBvZiBh IGdvb2QgcmVhc29uIHRvIHJlcXVpcmUgaXQgdG8gY2hhbmdlLjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFy Z2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFl eCI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+DQo8b2w+DQo8bGk+VGhlcmUncyBub3RoaW5nIHRo YXQgc2F5cyAmcXVvdDt3aGVuIGNoYW5naW5nIGltcGxlbWVudGF0aW9uIGxldmVsLCB5b3UgTVVT VCByZXN0YXJ0IElDRSBmb3INCjxpPmFsbDwvaT4gbWVkaWEgc3RyZWFtcyZxdW90Oy4gVGhpcyBy ZXF1aXJlbWVudCBleGlzdGVkIGluIGRyYWZ0IDEzIG9mIElDRSwgYnV0IHRoZW4gdGhlcmUgd2Fz IGEgYnVuY2ggb2YgcmVzdHJ1Y3R1cmluZyBhbmQgSSB0aGluayBpdCBtYXkgaGF2ZSBiZWVuIHJl bW92ZWQgYWNjaWRlbnRhbGx5LiBSZWdhcmRsZXNzLCBJIGJlbGlldmUgdGhpcyBjb25kaXRpb24g c2hvdWxkIGJlIGFkZGVkIGJhY2ssIGJlY2F1c2UgY2hhbmdpbmcgaW1wbGVtZW50YXRpb24NCiBs ZXZlbCBpbiB0aGUgbWlkZGxlIG9mIElDRSBwcm9jZXNzaW5nIGZvciBhIG1lZGlhIHN0cmVhbSBk b2Vzbid0IG1ha2UgbXVjaCBzZW5zZS48L2xpPjwvb2w+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZh bWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+SWYgdGhlIGltcGxlbWVudGF0aW9uIGxl dmVsIG11c3QgYmUgdGhlIHNhbWUgZm9yIGFsbCBtZWRpYSBzdHJlYW1zIChhbmQgaXQgbXVzdCBi ZSwgcmlnaHQ/KSwgdGhlbiBJIHRoaW5rIHlvdSdyZSByaWdodCB0aGF0IHdlIHNob3VsZCByZXF1 aXJlIGFuIElDRSByZXN0YXJ0IGZvciBhbGwgdGhlIG1lZGlhIHN0cmVhbXMNCiB3aGVuIHRoZSBp bXBsZW1lbnRhdGlvbiBsZXZlbCBjaGFuZ2VzLiZuYnNwOyBPdGhlcndpc2UsIGFzIHlvdSBzYXks IGEgZ2l2ZW4gbWVkaWEgc3RyZWFtIHdpbGwgaGF2ZSB0aGUgcmVtb3RlIGltcGxlbWVudGF0aW9u IGxldmVsIGNoYW5nZSB3aXRob3V0IGEgcmVzdGFydCwgd2hpY2ggc2VlbXMgcHJvYmxlbWF0aWMu Jm5ic3A7IEFuZCBJIGRvbid0IHNlZSBhbnkgcmVhc29uIHdoeSB5b3Ugd291bGRuJ3QgcmVzdGFy dCBhbGwgbWVkaWEgc3RyZWFtcyB3aGVuIHlvdQ0KIGNoYW5nZSB0aGUgaW1wbGVtZW50YXRpb24g bGV2ZWwgKHByZXN1bWFibHkgeW91J3JlIHRhbGtpbmcgdG8gYSBkaWZmZXJlbnQgZW5kcG9pbnQg YW55d2F5KS48L2Rpdj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFw eCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0K PG9sPg0KPGxpPlNlY3Rpb24gNi4xLjMuMSwgRmFpbHVyZSBDYXNlcyBzdGF0ZXMgdGhhdCB3aGVu IHJlY2VpdmluZyBhICZxdW90O3JvbGUgY29uZmxpY3QmcXVvdDsgZXJyb3IgcmVzcG9uc2UsICZx dW90O3RoZSBhZ2VudCBNVVNUIHN3aXRjaCB0byB0aGUgKGNvbnRyb2xsaW5nfGNvbnRyb2xsZWQp IHJvbGUgaWYgaXQgaGFzIG5vdCBhbHJlYWR5IGRvbmUgc28mcXVvdDsuIFRoZSBjb25kaXRpb24g JnF1b3Q7aWYgaXQgaGFzIG5vdCBhbHJlYWR5IGRvbmUgc28mcXVvdDssIGlmIGludGVycHJldGVk IGxpdGVyYWxseSwNCiBtZWFucyB0aGF0IHRoZSBhZ2VudCBjYW4gb25seSBzd2l0Y2ggdG8gYSBy b2xlIG9uY2UuIEkgZG9uJ3QgdGhpbmsgdGhpcyB3YXMgdGhlIGludGVudGlvbiwgc28gdGhlIGNv bmRpdGlvbiBjYW4gcHJvYmFibHkgYmUgcmVtb3ZlZC4gSXQncyB3b3J0aCBub3RpbmcgdGhhdCB0 aGlzIGNvbmRpdGlvbiBkb2Vzbid0IGV4aXN0IGluIFNlY3Rpb24gNi4yLjEuMSwgRGV0ZWN0aW5n IGFuZCBSZXBhaXJpbmcgUm9sZSBDb25mbGljdHMuPC9saT48L29sPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZh bWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZiI+4oCLSSBhZ3JlZSB0aGF0IGl0IHNob3Vs ZCBiZSBtb3JlIGNsZWFyLCBhbmQgd291bGQgYmUgd2l0aCB5b3VyIHN1Z2dlc3RlZCB0ZXh0IGNo YW5nZS4gJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9u dC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWYiPuKAizwvZGl2Pg0KPGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxl ZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxk aXY+DQo8b2w+DQo8bGk+U3RhcnRpbmcgdG8gcmVhbGx5IHN0cmV0Y2ggaGVyZSwgYnV0IGluIHRo ZSByYXJlIHNpdHVhdGlvbiB3aGVyZSB0aGVyZSdzIGEgcm9sZSBjb25mbGljdCBhbmQgdGhlIHRp ZS1icmVha2VycyBhcmUgZXF1YWwsIHRoZSBwZWVycyBjb3VsZCBjb250aW51ZSBmbGlwcGluZyBi ZXR3ZWVuIHJvbGVzIGFkIGluZmluaXR1bS4gV2h5IG5vdCBqdXN0IGdlbmVyYXRlIGEgbmV3IHRp ZS1icmVha2VyPyBJIHNhdyB0aGF0IHRoaXMgd2FzIG9uY2UgYnJvdWdodA0KIHVwIG9uIHRoZSBN TVVTSUMgbWFpbGluZyBsaXN0IGJ1dCBJIGNvdWxkbid0IGZpbmQgYSByZXNwb25zZS48L2xpPjwv b2w+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXYgY2xhc3M9Imdt YWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJp ZiI+4oCLSXQgc2VlbXMgc28gcmFyZSBhcyB0byBub3QgbWF0dGVyLiZuYnNwOyBCdXQgaWYgaXQg d291bGQgbWFrZSB5b3UgYW5kIG90aGVycyBmZWVsIG1vcmUgY29tZm9ydGFibGUsIEknZCBiZSBm aW5lIHdpdGggdGhhdCBsb2dpYy7igIs8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8 L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAg MCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRp diBkaXI9Imx0ciI+DQo8ZGl2Pg0KPGRpdj5JZiB0aGVyZSdzIGdlbmVyYWwgYWdyZWVtZW50IGFi b3V0IHRoZXNlIHBvaW50cywgSSdsbCBoYXBwaWx5IHdyaXRlIHNvbWUgcHVsbCByZXF1ZXN0cyBm b3IgSUNFYmlzLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KSWNlIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpJY2VAaWV0Zi5vcmciPkljZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ljZSIgcmVsPSJub3Jl ZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pY2U8L2E+PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D36E1E9B9565christerholmbergericssoncom_-- From nobody Fri May 27 08:19:33 2016 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 4E11712D0E5 for ; Fri, 27 May 2016 08:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-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 wvKJcSX6xnM6 for ; Fri, 27 May 2016 08:19:29 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::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 60CC712B018 for ; Fri, 27 May 2016 08:09:49 -0700 (PDT) Received: by mail-qg0-x22f.google.com with SMTP id 90so52040224qgz.1 for ; Fri, 27 May 2016 08:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZMiNxR3I8jXU+B7zowKkXK+zCq4+XebO3VBrcK0kWVA=; b=CKQYZ+4aILbhiYBj9yOZwplfKrmiGQ0tTwQUjWulQi9r8KOv/yg04NbP74pi366jb3 iUXQNnRfVk2O51tmtkCfUH2sY+1Y75Rcks8hzptGQpG9W5+fP3hX5IV9scFe9GbEas1y OJoL1o5eJiGmr/KtrOGFkvga5efmiHX+oIZ9D5j7DGpi0yACLdPILfscRVyX+L4TZnTR b02rmZ+x8sB1b9ccj9OPj6pcJQVG2dc1cIpgwwlduTDbWIY3wprmQrwxYxJj7fYFLNyD EAClZvcrjLMoyc4iJ+yc1lfAuk4vXdlBNNW4ZSqz5n34eCXuBsIL9oHujOZy8p09agmz u3YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZMiNxR3I8jXU+B7zowKkXK+zCq4+XebO3VBrcK0kWVA=; b=LnjuvRCr6kQLd+0Mc+s6MRueJxbbex3s5nDmjCdgIXcKTwpg5BbTsCnIPqThoZmnuv f8Gx6fV00lqCX0FGw1D0DUd8xziEPdvqSByOloICmP3WrYJW9mSNT1wguN/DJdfqjF3m f/fUwQRc920tNCxiiHbaElKhK+bRuOHqcatt3qHGUR20TbYwoiHPjDgevM0wFaVlBM/N 5Q0kRB/EOCzNjfaxAHya51+w2jCHr57N5U9+7l5oa5LVLsTF8PRSx+uDpNtKwPvRRx20 nXr0ZV43IXtD6MqvDseU/FVWZqxEa+l7iHkckwtq48fZ5kGpInynsTG4M+kJyTzMo0IF dgyw== X-Gm-Message-State: ALyK8tI9ssALkP3FIQ5+Su4D4o0uF7XtR6B8vnl2MlFr/r/8VpkQ9M9TaoIyIpE/6MPDcDC4XLmlXewfCIWzVW3c X-Received: by 10.140.195.69 with SMTP id q66mr14151481qha.79.1464361788349; Fri, 27 May 2016 08:09:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.189.195 with HTTP; Fri, 27 May 2016 08:09:08 -0700 (PDT) In-Reply-To: References: From: Peter Thatcher Date: Fri, 27 May 2016 08:09:08 -0700 Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001a1143355637fe0e0533d44cba Archived-At: Cc: "ice@ietf.org" , Taylor Brandstetter Subject: Re: [Ice] Issues related to ICE role switching and conflicts X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 15:19:31 -0000 --001a1143355637fe0e0533d44cba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sequential forking, I believe. On Fri, May 27, 2016 at 5:57 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > What use-cases are there for a full->lite switch? When an endpoint > realises that it=E2=80=99s no longer behind a NAT, and doesn=E2=80=99t wa= nt to use full ICE? > > As far as I understand, ICE-lite is meant for =E2=80=9Cstatic=E2=80=9D ne= twork boxes > (gateways etc) that are not located behind a NAT. > > Regards, > > Christer > > > > From: Ice on behalf of "pthatcher@google.com" < > pthatcher@google.com> > Date: Thursday 26 May 2016 at 22:56 > To: Taylor Brandstetter > Cc: "ice@ietf.org" > Subject: Re: [Ice] Issues related to ICE role switching and conflicts > > > > On Fri, May 20, 2016 at 9:16 AM, Taylor Brandstetter > wrote: > >> While investigating a WebRTC issue related to ICE role conflicts, I >> noticed what seem to be some minor oddities with the rules surrounding I= CE >> role determination. I'd like to hear what people think about these issue= s, >> and find out if I'm overlooking any motivations for the current rules. >> >> 1. Section 5.1.2, Determining Role states "An ICE restart causes a >> new selection of roles and tiebreakers". The only time this is necess= ary, >> as far as I can tell, is when an agent is changing its implementation= level >> (such as "full -> lite") and one agent *needs* to take up the >> controlling role. So it would be ideal if this was the only situation= that >> caused new role selection. Otherwise, in a third-party call control u= se >> case that resulted in a role conflict initially, *every* ICE restart >> will probably result in another role conflict, as the agents re-selec= t >> their initial conflicting roles. Also, what happens if ICE is restart= ing >> for only one media stream and the role changes according to this rule= ? From >> the perspective of the non-restarting media streams, the role would b= e >> switching in the middle of ICE processing. >> >> =E2=80=8BI think that the two rules in the spec of "must change role" an= d "role > must be the same for all media streams" is bad combination, and I assume = a > mistake in RFC5245 that no one noticed before. Changing the role of the > non-restarted media streams is unnecessary and can only lead to problems. > But rather than have to have per-media-stream roles (relaxing the second > rule), I think it would be easier to not change the role with an ICE > restart (in other words, relax the first rule). As you point out, there > really isn't any reason to except if the remote side moves from full to > lite, which can be handled with a specific rule rather than a general "mu= st > always change" rule. > > So, I agree with changing the rule from "always change the role for all > media streams when any stream is restarted" to "never change the role > except when the remote implementation level switches to a lite > implementation".=E2=80=8B > > >> >> 1. Also, why select a new tiebreaker? I don't see any real issue with >> this, but it seems pointless. >> >> I also don't see a point, and would be in favor of not requiring it to > change, if we can't think of a good reason to require it to change. > > >> >> 1. There's nothing that says "when changing implementation level, you >> MUST restart ICE for *all* media streams". This requirement existed >> in draft 13 of ICE, but then there was a bunch of restructuring and I= think >> it may have been removed accidentally. Regardless, I believe this con= dition >> should be added back, because changing implementation level in the mi= ddle >> of ICE processing for a media stream doesn't make much sense. >> >> If the implementation level must be the same for all media streams (and > it must be, right?), then I think you're right that we should require an > ICE restart for all the media streams when the implementation level > changes. Otherwise, as you say, a given media stream will have the remot= e > implementation level change without a restart, which seems problematic. > And I don't see any reason why you wouldn't restart all media streams whe= n > you change the implementation level (presumably you're talking to a > different endpoint anyway). > > >> >> 1. Section 6.1.3.1, Failure Cases states that when receiving a "role >> conflict" error response, "the agent MUST switch to the >> (controlling|controlled) role if it has not already done so". The con= dition >> "if it has not already done so", if interpreted literally, means that= the >> agent can only switch to a role once. I don't think this was the inte= ntion, >> so the condition can probably be removed. It's worth noting that this >> condition doesn't exist in Section 6.2.1.1, Detecting and Repairing R= ole >> Conflicts. >> >> =E2=80=8BI agree that it should be more clear, and would be with your su= ggested > text change. > =E2=80=8B > >> >> 1. Starting to really stretch here, but in the rare situation where >> there's a role conflict and the tie-breakers are equal, the peers cou= ld >> continue flipping between roles ad infinitum. Why not just generate a= new >> tie-breaker? I saw that this was once brought up on the MMUSIC mailin= g list >> but I couldn't find a response. >> >> =E2=80=8BIt seems so rare as to not matter. But if it would make you an= d others > feel more comfortable, I'd be fine with that logic.=E2=80=8B > > > >> If there's general agreement about these points, I'll happily write some >> pull requests for ICEbis. >> >> _______________________________________________ >> 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 > > --001a1143355637fe0e0533d44cba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sequential forking, I believe.

On Fri, May 27, 2016 at 5:57 A= M, Christer Holmberg <christer.holmberg@ericsson.com><= /span> wrote:

Hi,

What use-cases are there for a full->lite switch? When an endpoint = realises that it=E2=80=99s no longer behind a NAT, and doesn=E2=80=99t want= to use full ICE?

As far as I understand, ICE-lite is meant for =E2=80=9Cstatic=E2=80=9D= network boxes (gateways etc) that are not located behind a NAT.

Regards,

Christer



From: Ice <ice-bounces@ietf.org> on behalf= of "pthatch= er@google.com" <pthatcher@google.com>
Date: Thursday 26 May 2016 at 22:56=
To: Taylor Brandstetter <deadbeef@google.com&g= t;
Cc: "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Issues related t= o ICE role switching and conflicts



On Fri, May 20, 2016 at 9:16 AM, Taylor Brandste= tter <deadbeef@googl= e.com> wrote:
While investigating a WebRTC issue related to ICE role con= flicts, I noticed what seem to be some minor oddities with the rules surrou= nding ICE role determination. I'd like to hear what people think about = these issues, and find out if I'm overlooking any motivations for the current rules.
  1. Section 5.1.2, Determining Role states "An ICE restart causes a ne= w selection of roles and tiebreakers". The only time this is necessary= , as far as I can tell, is when an agent is changing its implementation lev= el (such as "full -> lite") and one agent needs=C2=A0to take up the controlling role.=C2=A0So it would be idea= l if this was the only situation that caused new role selection. Otherwise,= in a third-party call control use case that resulted in a role conflict in= itially, every=C2=A0ICE restart will probably result in another role conflict= , as the agents re-select their initial conflicting roles. Also, what happe= ns if ICE is restarting for only one media stream and the role changes acco= rding to this rule? From the perspective of the non-restarting media streams, the role would be switching in the mi= ddle of ICE processing.
=E2=80=8BI think that the two rules in the spec of "must change rol= e" and "role must be the same for all media streams" is bad = combination, and I assume a mistake in RFC5245 that no one noticed before.=C2=A0 Changing the role of the non-restarted media streams is unne= cessary and can only lead to problems. =C2=A0 But rather than have to have = per-media-stream roles (relaxing the second rule), I think it would be easi= er to not change the role with an ICE restart (in other words, relax the first rule).=C2=A0 As you point out, there real= ly isn't any reason to except if the remote side moves from full to lit= e, which can be handled with a specific rule rather than a general "mu= st always change" rule.

So, I agree with changing the rule from "always change the role for= all media streams when any stream is restarted" to "never change= the role except when the remote implementation level switches to a lite implementation".=E2=80=8B
=C2=A0
  1. Also, why select a new tiebreaker? I don't see any real issue with = this, but it seems pointless.
I also don't see a point, and would be in favor of not requiring it = to change, if we can't think of a good reason to require it to change.<= /div>
=C2=A0
  1. There's nothing that says "when changing implementation level,= you MUST restart ICE for all media streams". This requirement existed in draft 13 of ICE= , but then there was a bunch of restructuring and I think it may have been = removed accidentally. Regardless, I believe this condition should be added = back, because changing implementation level in the middle of ICE processing for a media stream doesn't make = much sense.
If the implementation level must be the same for all media streams (and = it must be, right?), then I think you're right that we should require a= n ICE restart for all the media streams when the implementation level changes.=C2=A0 Otherwise, as you say, a give= n media stream will have the remote implementation level change without a r= estart, which seems problematic.=C2=A0 And I don't see any reason why y= ou wouldn't restart all media streams when you change the implementation level (presumably you're talking to a differ= ent endpoint anyway).
=C2=A0
  1. Section 6.1.3.1, Failure Cases states that when receiving a "role = conflict" error response, "the agent MUST switch to the (controll= ing|controlled) role if it has not already done so". The condition &qu= ot;if it has not already done so", if interpreted literally, means that the agent can only switch to a role once. I don't think thi= s was the intention, so the condition can probably be removed. It's wor= th noting that this condition doesn't exist in Section 6.2.1.1, Detecti= ng and Repairing Role Conflicts.
=E2=80=8BI agree that it should be more clear, and would be with your su= ggested text change. =C2=A0
=E2=80=8B
  1. Starting to really stretch here, but in the rare situation where there&= #39;s a role conflict and the tie-breakers are equal, the peers could conti= nue flipping between roles ad infinitum. Why not just generate a new tie-br= eaker? I saw that this was once brought up on the MMUSIC mailing list but I couldn't find a response.
=E2=80=8BIt seems so rare as to not matter.=C2=A0 But if it would make y= ou and others feel more comfortable, I'd be fine with that logic.=E2=80= =8B

=C2=A0
If there's general agreement about these points, I'll happily = write some pull requests for ICEbis.

_______________________________________________
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


--001a1143355637fe0e0533d44cba-- From nobody Fri May 27 12:24:43 2016 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 218CF12D721 for ; Fri, 27 May 2016 12:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] 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 SRUc5CJPevQS for ; Fri, 27 May 2016 12:24:39 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 A337E12D61F for ; Fri, 27 May 2016 12:24:39 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id x189so114862591ywe.3 for ; Fri, 27 May 2016 12:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xPzOBDgGze2+bizYuK+yA5W9fd+pZ7usWhG92HS8Nsw=; b=os7LhO83eqSnWYyrPxUQYRlAZpFibg4LQUmNOr87mLOlxRM/Nl48o0JBds7+74cywh QqhAOQkA/H2Tc/oiaC5XoBkbZftD6jetR7UxJYN0fvTKNFIpuJ/fCQnbdPN1Tm2Jjoa5 Pbxayv6J4KJ1sTLxnRrWuwQsGIkfKC6+/zxuUjkDk3Q6G/Vngv3/tS4HIVS+awuSI2bX z3dvdy5OLYvfxu8kgSShkd8GqC3D8PQ8IT/zS+6vqfeKt7s5Qql1b8YEfWktai0TT986 nmuCBI+mFWX9ghVCVPT0zVmoGhrhbI3lexchXO5P7UWwlzEVe+N9sFAzqEIl2KPj/JH0 mlIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xPzOBDgGze2+bizYuK+yA5W9fd+pZ7usWhG92HS8Nsw=; b=lA3cNmY/562vSpzaQ5V8GW6gUmx9MYsqaH8hf2uEQG2erFqdQaQHBa1kpGo8t8xaFQ yZqe6X3htXZBS/eG84ClsQBXEGKlvAT8okJoyC8UPcVtt4e/yQx804wgMpGSzp6ox38H qHmm9fhh5fq0oNC7gUyhyJw1xNDBU+WQE3e+FPKbbgEFfntMQ181S5wEcer3qkkTHMsl H9tQ5Volp/uLR0h/tQQvedFwuUN/e7U5EWiZdkUk1ireAwK1tdBe20HxfSWlr7nPcI+0 T4DugcmeWdvm7wLOIOnoKjoCfAiywWSwjTP9Ve07og5S9VNh5ePky+1KsYvN50gzyUvu q72A== X-Gm-Message-State: ALyK8tIdTmPo4xjLnCQQrWxEQ3mfoN+rvNTgkjkKICqYUsoWrcekwJVqCz/KDqUEWwcPiOS1l+DbMCvoHkWYa0Cj X-Received: by 10.13.204.21 with SMTP id o21mr9581073ywd.106.1464377078668; Fri, 27 May 2016 12:24:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.233.194 with HTTP; Fri, 27 May 2016 12:24:38 -0700 (PDT) In-Reply-To: References: From: Taylor Brandstetter Date: Fri, 27 May 2016 12:24:38 -0700 Message-ID: To: Peter Thatcher Content-Type: multipart/alternative; boundary=001a11482e6e97d3320533d7dbf6 Archived-At: Cc: "ice@ietf.org" , Christer Holmberg Subject: Re: [Ice] Issues related to ICE role switching and conflicts X-BeenThere: ice@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interactive Connectivity Establishment \(ICE\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2016 19:24:42 -0000 --001a11482e6e97d3320533d7dbf6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, sequential forking is the main use case. Specifically, it seems that the ability to switch ICE roles was intended for the third-party call control use cases described here: https://tools.ietf.org/html/rfc3725 On Fri, May 27, 2016 at 8:09 AM, Peter Thatcher wrote: > Sequential forking, I believe. > > On Fri, May 27, 2016 at 5:57 AM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> >> Hi, >> >> What use-cases are there for a full->lite switch? When an endpoint >> realises that it=E2=80=99s no longer behind a NAT, and doesn=E2=80=99t w= ant to use full ICE? >> >> As far as I understand, ICE-lite is meant for =E2=80=9Cstatic=E2=80=9D n= etwork boxes >> (gateways etc) that are not located behind a NAT. >> >> Regards, >> >> Christer >> >> >> >> From: Ice on behalf of "pthatcher@google.com" < >> pthatcher@google.com> >> Date: Thursday 26 May 2016 at 22:56 >> To: Taylor Brandstetter >> Cc: "ice@ietf.org" >> Subject: Re: [Ice] Issues related to ICE role switching and conflicts >> >> >> >> On Fri, May 20, 2016 at 9:16 AM, Taylor Brandstetter > > wrote: >> >>> While investigating a WebRTC issue related to ICE role conflicts, I >>> noticed what seem to be some minor oddities with the rules surrounding = ICE >>> role determination. I'd like to hear what people think about these issu= es, >>> and find out if I'm overlooking any motivations for the current rules. >>> >>> 1. Section 5.1.2, Determining Role states "An ICE restart causes a >>> new selection of roles and tiebreakers". The only time this is neces= sary, >>> as far as I can tell, is when an agent is changing its implementatio= n level >>> (such as "full -> lite") and one agent *needs* to take up the >>> controlling role. So it would be ideal if this was the only situatio= n that >>> caused new role selection. Otherwise, in a third-party call control = use >>> case that resulted in a role conflict initially, *every* ICE restart >>> will probably result in another role conflict, as the agents re-sele= ct >>> their initial conflicting roles. Also, what happens if ICE is restar= ting >>> for only one media stream and the role changes according to this rul= e? From >>> the perspective of the non-restarting media streams, the role would = be >>> switching in the middle of ICE processing. >>> >>> =E2=80=8BI think that the two rules in the spec of "must change role" a= nd "role >> must be the same for all media streams" is bad combination, and I assume= a >> mistake in RFC5245 that no one noticed before. Changing the role of the >> non-restarted media streams is unnecessary and can only lead to problems= . >> But rather than have to have per-media-stream roles (relaxing the second >> rule), I think it would be easier to not change the role with an ICE >> restart (in other words, relax the first rule). As you point out, there >> really isn't any reason to except if the remote side moves from full to >> lite, which can be handled with a specific rule rather than a general "m= ust >> always change" rule. >> >> So, I agree with changing the rule from "always change the role for all >> media streams when any stream is restarted" to "never change the role >> except when the remote implementation level switches to a lite >> implementation".=E2=80=8B >> >> >>> >>> 1. Also, why select a new tiebreaker? I don't see any real issue >>> with this, but it seems pointless. >>> >>> I also don't see a point, and would be in favor of not requiring it to >> change, if we can't think of a good reason to require it to change. >> >> >>> >>> 1. There's nothing that says "when changing implementation level, >>> you MUST restart ICE for *all* media streams". This requirement >>> existed in draft 13 of ICE, but then there was a bunch of restructur= ing and >>> I think it may have been removed accidentally. Regardless, I believe= this >>> condition should be added back, because changing implementation leve= l in >>> the middle of ICE processing for a media stream doesn't make much se= nse. >>> >>> If the implementation level must be the same for all media streams (and >> it must be, right?), then I think you're right that we should require an >> ICE restart for all the media streams when the implementation level >> changes. Otherwise, as you say, a given media stream will have the remo= te >> implementation level change without a restart, which seems problematic. >> And I don't see any reason why you wouldn't restart all media streams wh= en >> you change the implementation level (presumably you're talking to a >> different endpoint anyway). >> >> >>> >>> 1. Section 6.1.3.1, Failure Cases states that when receiving a "role >>> conflict" error response, "the agent MUST switch to the >>> (controlling|controlled) role if it has not already done so". The co= ndition >>> "if it has not already done so", if interpreted literally, means tha= t the >>> agent can only switch to a role once. I don't think this was the int= ention, >>> so the condition can probably be removed. It's worth noting that thi= s >>> condition doesn't exist in Section 6.2.1.1, Detecting and Repairing = Role >>> Conflicts. >>> >>> =E2=80=8BI agree that it should be more clear, and would be with your s= uggested >> text change. >> =E2=80=8B >> >>> >>> 1. Starting to really stretch here, but in the rare situation where >>> there's a role conflict and the tie-breakers are equal, the peers co= uld >>> continue flipping between roles ad infinitum. Why not just generate = a new >>> tie-breaker? I saw that this was once brought up on the MMUSIC maili= ng list >>> but I couldn't find a response. >>> >>> =E2=80=8BIt seems so rare as to not matter. But if it would make you a= nd others >> feel more comfortable, I'd be fine with that logic.=E2=80=8B >> >> >> >>> If there's general agreement about these points, I'll happily write som= e >>> pull requests for ICEbis. >>> >>> _______________________________________________ >>> 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 >> >> > --001a11482e6e97d3320533d7dbf6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, sequential forking is the main use case. Specifically= , it seems that the ability to switch ICE roles was intended for the third-= party call control use cases described here: https://tools.ietf.org/html/rfc3725

On Fri, May 27, 2016 at 8:0= 9 AM, Peter Thatcher <pthatcher@google.com> wrote:
Sequential forking, I belie= ve.

On Fri, May 27, 2016 at 5:57 AM, Chri= ster Holmberg <christer.holmberg@ericsson.com> = wrote:

Hi,

What use-cases are there for a full->lite switch? When an endpoint = realises that it=E2=80=99s no longer behind a NAT, and doesn=E2=80=99t want= to use full ICE?

As far as I understand, ICE-lite is meant for =E2=80=9Cstatic=E2=80=9D= network boxes (gateways etc) that are not located behind a NAT.

Regards,

Christer



From: Ice <ice-bounces@ietf.org> on behalf= of "pthatch= er@google.com" <pthatcher@google.com>
Date: Thursday 26 May 2016 at 22:56=
To: Taylor Brandstetter <deadbeef@google.com&g= t;
Cc: "ice@ietf.org" <ice@ietf.org>
Subject: Re: [Ice] Issues related t= o ICE role switching and conflicts



On Fri, May 20, 2016 at 9:16 AM, Taylor Brandste= tter <deadbeef@googl= e.com> wrote:
While investigating a WebRTC issue related to ICE role con= flicts, I noticed what seem to be some minor oddities with the rules surrou= nding ICE role determination. I'd like to hear what people think about = these issues, and find out if I'm overlooking any motivations for the current rules.
  1. Section 5.1.2, Determining Role states "An ICE restart causes a ne= w selection of roles and tiebreakers". The only time this is necessary= , as far as I can tell, is when an agent is changing its implementation lev= el (such as "full -> lite") and one agent needs=C2=A0to take up the controlling role.=C2=A0So it would be idea= l if this was the only situation that caused new role selection. Otherwise,= in a third-party call control use case that resulted in a role conflict in= itially, every=C2=A0ICE restart will probably result in another role conflict= , as the agents re-select their initial conflicting roles. Also, what happe= ns if ICE is restarting for only one media stream and the role changes acco= rding to this rule? From the perspective of the non-restarting media streams, the role would be switching in the mi= ddle of ICE processing.
=E2=80=8BI think that the two rules in the spec of "must change rol= e" and "role must be the same for all media streams" is bad = combination, and I assume a mistake in RFC5245 that no one noticed before.=C2=A0 Changing the role of the non-restarted media streams is unne= cessary and can only lead to problems. =C2=A0 But rather than have to have = per-media-stream roles (relaxing the second rule), I think it would be easi= er to not change the role with an ICE restart (in other words, relax the first rule).=C2=A0 As you point out, there real= ly isn't any reason to except if the remote side moves from full to lit= e, which can be handled with a specific rule rather than a general "mu= st always change" rule.

So, I agree with changing the rule from "always change the role for= all media streams when any stream is restarted" to "never change= the role except when the remote implementation level switches to a lite implementation".=E2=80=8B
=C2=A0
  1. Also, why select a new tiebreaker? I don't see any real issue with = this, but it seems pointless.
I also don't see a point, and would be in favor of not requiring it = to change, if we can't think of a good reason to require it to change.<= /div>
=C2=A0
  1. There's nothing that says "when changing implementation level,= you MUST restart ICE for all media streams". This requirement existed in draft 13 of ICE= , but then there was a bunch of restructuring and I think it may have been = removed accidentally. Regardless, I believe this condition should be added = back, because changing implementation level in the middle of ICE processing for a media stream doesn't make = much sense.
If the implementation level must be the same for all media streams (and = it must be, right?), then I think you're right that we should require a= n ICE restart for all the media streams when the implementation level changes.=C2=A0 Otherwise, as you say, a give= n media stream will have the remote implementation level change without a r= estart, which seems problematic.=C2=A0 And I don't see any reason why y= ou wouldn't restart all media streams when you change the implementation level (presumably you're talking to a differ= ent endpoint anyway).
=C2=A0
  1. Section 6.1.3.1, Failure Cases states that when receiving a "role = conflict" error response, "the agent MUST switch to the (controll= ing|controlled) role if it has not already done so". The condition &qu= ot;if it has not already done so", if interpreted literally, means that the agent can only switch to a role once. I don't think thi= s was the intention, so the condition can probably be removed. It's wor= th noting that this condition doesn't exist in Section 6.2.1.1, Detecti= ng and Repairing Role Conflicts.
=E2=80=8BI agree that it should be more clear, and would be with your su= ggested text change. =C2=A0
=E2=80=8B
  1. Starting to really stretch here, but in the rare situation where there&= #39;s a role conflict and the tie-breakers are equal, the peers could conti= nue flipping between roles ad infinitum. Why not just generate a new tie-br= eaker? I saw that this was once brought up on the MMUSIC mailing list but I couldn't find a response.
=E2=80=8BIt seems so rare as to not matter.=C2=A0 But if it would make y= ou and others feel more comfortable, I'd be fine with that logic.=E2=80= =8B

=C2=A0
If there's general agreement about these points, I'll happily = write some pull requests for ICEbis.

_______________________________________________
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



--001a11482e6e97d3320533d7dbf6--