From nobody Fri Aug  1 01:50:20 2014
Return-Path: <xvilajosana@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B9F1A030D; Fri,  1 Aug 2014 01:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 rAfW_WCWya9J; Fri,  1 Aug 2014 01:50:16 -0700 (PDT)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087061A010D; Fri,  1 Aug 2014 01:50:15 -0700 (PDT)
Received: by mail-ig0-f176.google.com with SMTP id hn18so1161385igb.3 for <multiple recipients>; Fri, 01 Aug 2014 01:50:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hsGlE5ethnUo51DLtSkziO+xogSTV0FnomfyTMbLajE=; b=jTcPiZYbUAqvecNGsWM/XrjkulibrsBz8W0Yit1stWEvEMrJzmt3v7rTrhVGZ4990f g9hyttpjmr9tH0F1oJ93AccnGhZFqm1OH49OovanVvrwWQcmPqkH/LYRVg7OraoMOT0b bWQK6HJUF46bRjfErrpe85Bn/LP7XLDiZIgUJYSR3ke+KQ+IdRD5JXVgbC1lL9QbMM3h 2EDsPhBfohw7OPSnrwYy8MNfSOhuU/pUkgFhGSESq+d9wcABhtEPQrcNYd/uE8Xd7w9c zh37vNEM8a/dWfwXvIMYtbTAlMOILr+/szurtzdvL+pu6tGfLadPlSADJFtckvC3Ulxu F4ew==
MIME-Version: 1.0
X-Received: by 10.42.109.79 with SMTP id k15mr5287828icp.42.1406883015394; Fri, 01 Aug 2014 01:50:15 -0700 (PDT)
Sender: xvilajosana@gmail.com
Received: by 10.64.129.198 with HTTP; Fri, 1 Aug 2014 01:50:15 -0700 (PDT)
In-Reply-To: <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu>
Date: Fri, 1 Aug 2014 10:50:15 +0200
X-Google-Sender-Auth: _k70OTDGsaT1OR1GClrs1hWOAWo
Message-ID: <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com>
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
To: Philip Levis <pal@cs.stanford.edu>
Content-Type: multipart/alternative; boundary=20cf303dd3b05f8a8f04ff8d7a46
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/W_p3W-4_6YpNHnUgv-JmFRZ1Z-M
Cc: Brian Haberman <brian@innovationslab.net>, "ipv6@ietf.org" <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, roll <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, Bob Hinden <bob.hinden@gmail.com>, Ole Troan <otroan@cisco.com>, "Pascal Thubert \(pthubert\)" <pthubert@cisco.com>, Adrian Farrel <adrian@olddog.co.uk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 08:50:18 -0000

--20cf303dd3b05f8a8f04ff8d7a46
Content-Type: text/plain; charset=UTF-8

Dear Phil, all,

I do not completely agree :)

Let's look at what IPHC does at the LBR when a flow label is elided and has
to be inflated to be forwarded to the IPv6 network, this standardized
behaviour is somehow interfering the end to end notion of the flow label as
the content is being populated at the border of the LLN. For me this is not
different than changing the scope of the flow label inside the LLN to
transport RPL information and resetting  it at the LBR once data moves
outside of the network considering that inside the LLN the flow label has
no meaning.

Looking into an article we wrote some time back, "A Realistic Energy
Consumption Model for TSCH Networks". published in IEEE Sensors

we know that the charge used by a mote (something similar to telosb) to
send 127bytes is around 69uC and to receive them is 72uC (considering the
optimal case where receiver has a guard time of 1ms and the network is
synchronized).  By using the flow label instead of the RPL extension header
we save 5bytes which give us a gain 2,71uC per data packet per hop when
sent and something similar when received (i.e ~5uC in total), this is a 8%
saving (accounting TX and RX side) considering that motes are always using
127bytes packets.

If we go to a more realistic case where motes send ~50bytes packets, the
charge needed to send/receive them is something around 27.5uC and being
able to save 5 bytes represents a 10% saving for the sender and 10% for the
receiver (~20% saving if we look it overall per hop).
If we use batteries that power the mote for 5 years, a 20% saving gives us
~1 more year which I think is pretty significant.

regards,
Xavi



2014-08-01 0:11 GMT+02:00 Philip Levis <pal@cs.stanford.edu>:

>
> On Jul 29, 2014, at 6:36 PM, Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
>
> > On 30/07/2014 12:02, Philip Levis wrote:
> > ...
> >> "This specification suggests that energy-saving is another
> >> compelling reason for a violation to the aforementioned
> >> rule."
> >>
> >> makes the assumption that the energy saving is significant.
> >> Breaking the end-to-end nature of the flow label for some
> >> tiny saving seems like a mistake.
> >
> > I can't evaluate whether the energy saving is significant.
> > However, I don't have any deep faith in the e2e-ness of the
> > flow label. The reality (as RFC 6437 tries to recognise)
> > is that it's a mutable field, and is therefore untrustworthy
> > for e2e use. It has value for load balancing if all packets
> > of a given flow have the same label, whether the label is
> > set by the source or by a border device. For that reason,
> > I think the usage proposed in this draft is OK.
> >
> > However, I do agree that at least a hand-waving estimate of
> > the % energy saving would be useful.
> >
> >    Brian Carpenter
>
> *shrug* My thoughts are pretty simple. I'm sure you know all this (as one
> of the authors!) but I'll revisit for everyone else's sake. 6437 states
>
> "A forwarding node MUST either leave a non-zero flow label value unchanged
> or change it only for compelling operational security reasons as described
> in Section 6.1."
>
> So, this is a MUST. Either the RPL flow label draft contradicts 6437 (and
> should say so explicitly), or there should be an explicit update to 6437.
> In fact, the current draft is misleading and incorrect. It says
>
> "but the RFC also indicates a violation to the rule can be accepted for
> compelling reasons, and that security is a case justifying such a
> violation.  This specification suggests that energy-saving is another
> compelling    reason for a violation to the aforementioned rule."
>
> This is *not* what 6437 says. It says for compelling operational security
> reasons, not compelling reasons, of which one case is security.
>
> Having been researching, implementing, and deploying low-power protocols
> for over a decade, I've become exceedingly skeptical when someone proposes
> a protocol with energy as a motivation without quantifying it. For example,
> there are tons of protocols in the research literature which talk about
> using transmission power control to save energy (trading off range for
> power). But almost all of these papers ignore the fact that (unlike
> mobile/cellular systems, which the authors have been publishing in for
> years) RF is a tiny sliver of power in low-power networks. So reducing your
> transmission (RF) power by 99% only reduces your radio power by 50%.
> Generally a losing proposition. This is the same reason why power saving in
> WiFi involves synchronization on AP beacons and not adjusting transmit
> power. If someone doesn't quantify the potential benefit based on real
> hardware and protocols, then it could be based on mistaken assumptions.
>
> I mean, it doesn't take much here. Start with a working low-power RPL
> network. Send packets with sizes following a reasonable distribution based
> on an actual application. In one experiment send just those packets. In
> another add the 8 bytes. In a third add 8 + the IP-in-IP encapsulation.
> Measure the energy cost.
>
> And, generally speaking, if you can't demonstrate the problem very easily,
> then perhaps it isn't a real problem at all.
>
> All that being said, I think using the flow label in this way is a good
> idea, and definitely valuable. But as it is now, doing so violates 6437,
> and so the assumptions implementers make when reading 6437. I think the bar
> for doing so should be high, higher than vague suggestions and hand waving
> which might not be correct.
>
> Phil
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

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

<div dir=3D"ltr"><div>Dear Phil, all,</div><div><br></div><div>I do not com=
pletely agree :)</div><div><br></div><div>Let&#39;s look at what IPHC does =
at the LBR when a flow label is elided and has to be inflated to be forward=
ed to the IPv6 network, this standardized behaviour is somehow interfering =
the end to end notion of the flow label as the content is being populated a=
t the border of the LLN. For me this is not different than changing the sco=
pe of the flow label inside the LLN to transport RPL information and resett=
ing =C2=A0it at the LBR once data moves outside of the network considering =
that inside the LLN the flow label has no meaning.=C2=A0</div>
<div><br></div><div>Looking into an article we wrote some time back, &quot;=
A Realistic Energy Consumption Model for TSCH Networks&quot;. published in =
IEEE Sensors=C2=A0</div><div><br></div><div>we know that the charge used by=
 a mote (something similar to telosb) to send 127bytes is around 69uC and t=
o receive them is 72uC (considering the optimal case where receiver has a g=
uard time of 1ms and the network is synchronized). =C2=A0By using the flow =
label instead of the RPL extension header we save 5bytes which give us a ga=
in 2,71uC per data packet per hop when sent and something similar when rece=
ived (i.e ~5uC in total), this is a 8% saving (accounting TX and RX side) c=
onsidering that motes are always using 127bytes packets.</div>
<div><br></div><div>If we go to a more realistic case where motes send ~50b=
ytes packets, the charge needed to send/receive them is something around 27=
.5uC and being able to save 5 bytes represents a 10% saving for the sender =
and 10% for the receiver (~20% saving if we look it overall per hop).=C2=A0=
</div>
<div>If we use batteries that power the mote for 5 years, a 20% saving give=
s us ~1 more year which I think is pretty significant.</div><div><br></div>=
<div>regards,=C2=A0</div><div>Xavi</div><div><br></div></div><div class=3D"=
gmail_extra">
<br><br><div class=3D"gmail_quote">2014-08-01 0:11 GMT+02:00 Philip Levis <=
span dir=3D"ltr">&lt;<a href=3D"mailto:pal@cs.stanford.edu" target=3D"_blan=
k">pal@cs.stanford.edu</a>&gt;</span>:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D""><br>
On Jul 29, 2014, at 6:36 PM, Brian E Carpenter &lt;<a href=3D"mailto:brian.=
e.carpenter@gmail.com">brian.e.carpenter@gmail.com</a>&gt; wrote:<br>
<br>
&gt; On 30/07/2014 12:02, Philip Levis wrote:<br>
&gt; ...<br>
&gt;&gt; &quot;This specification suggests that energy-saving is another<br=
>
&gt;&gt; compelling reason for a violation to the aforementioned<br>
&gt;&gt; rule.&quot;<br>
&gt;&gt;<br>
&gt;&gt; makes the assumption that the energy saving is significant.<br>
&gt;&gt; Breaking the end-to-end nature of the flow label for some<br>
&gt;&gt; tiny saving seems like a mistake.<br>
&gt;<br>
&gt; I can&#39;t evaluate whether the energy saving is significant.<br>
&gt; However, I don&#39;t have any deep faith in the e2e-ness of the<br>
&gt; flow label. The reality (as RFC 6437 tries to recognise)<br>
&gt; is that it&#39;s a mutable field, and is therefore untrustworthy<br>
&gt; for e2e use. It has value for load balancing if all packets<br>
&gt; of a given flow have the same label, whether the label is<br>
&gt; set by the source or by a border device. For that reason,<br>
&gt; I think the usage proposed in this draft is OK.<br>
&gt;<br>
&gt; However, I do agree that at least a hand-waving estimate of<br>
&gt; the % energy saving would be useful.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0Brian Carpenter<br>
<br>
</div>*shrug* My thoughts are pretty simple. I&#39;m sure you know all this=
 (as one of the authors!) but I&#39;ll revisit for everyone else&#39;s sake=
. 6437 states<br>
<br>
&quot;A forwarding node MUST either leave a non-zero flow label value uncha=
nged or change it only for compelling operational security reasons as descr=
ibed in Section 6.1.&quot;<br>
<br>
So, this is a MUST. Either the RPL flow label draft contradicts 6437 (and s=
hould say so explicitly), or there should be an explicit update to 6437. In=
 fact, the current draft is misleading and incorrect. It says<br>
<br>
&quot;but the RFC also indicates a violation to the rule can be accepted fo=
r compelling reasons, and that security is a case justifying such a violati=
on. =C2=A0This specification suggests that energy-saving is another compell=
ing =C2=A0 =C2=A0reason for a violation to the aforementioned rule.&quot;<b=
r>

<br>
This is *not* what 6437 says. It says for compelling operational security r=
easons, not compelling reasons, of which one case is security.<br>
<br>
Having been researching, implementing, and deploying low-power protocols fo=
r over a decade, I&#39;ve become exceedingly skeptical when someone propose=
s a protocol with energy as a motivation without quantifying it. For exampl=
e, there are tons of protocols in the research literature which talk about =
using transmission power control to save energy (trading off range for powe=
r). But almost all of these papers ignore the fact that (unlike mobile/cell=
ular systems, which the authors have been publishing in for years) RF is a =
tiny sliver of power in low-power networks. So reducing your transmission (=
RF) power by 99% only reduces your radio power by 50%. Generally a losing p=
roposition. This is the same reason why power saving in WiFi involves synch=
ronization on AP beacons and not adjusting transmit power. If someone doesn=
&#39;t quantify the potential benefit based on real hardware and protocols,=
 then it could be based on mistaken assumptions.<br>

<br>
I mean, it doesn&#39;t take much here. Start with a working low-power RPL n=
etwork. Send packets with sizes following a reasonable distribution based o=
n an actual application. In one experiment send just those packets. In anot=
her add the 8 bytes. In a third add 8 + the IP-in-IP encapsulation. Measure=
 the energy cost.<br>

<br>
And, generally speaking, if you can&#39;t demonstrate the problem very easi=
ly, then perhaps it isn&#39;t a real problem at all.<br>
<br>
All that being said, I think using the flow label in this way is a good ide=
a, and definitely valuable. But as it is now, doing so violates 6437, and s=
o the assumptions implementers make when reading 6437. I think the bar for =
doing so should be high, higher than vague suggestions and hand waving whic=
h might not be correct.<br>

<br>
Phil<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--------------------------------------------------------------------<br>
IETF IPv6 working group mailing list<br>
<a href=3D"mailto:ipv6@ietf.org">ipv6@ietf.org</a><br>
Administrative Requests: <a href=3D"https://www.ietf.org/mailman/listinfo/i=
pv6" target=3D"_blank">https://www.ietf.org/mailman/listinfo/ipv6</a><br>
--------------------------------------------------------------------<br>
</div></div></blockquote></div><br></div>

--20cf303dd3b05f8a8f04ff8d7a46--


From nobody Fri Aug  1 03:22:39 2014
Return-Path: <xvilajosana@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0974C1A0659 for <ipv6@ietfa.amsl.com>; Fri,  1 Aug 2014 03:22:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 gQB9FtoRFVeh for <ipv6@ietfa.amsl.com>; Fri,  1 Aug 2014 03:22:34 -0700 (PDT)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77FCA1A0654 for <ipv6@ietf.org>; Fri,  1 Aug 2014 03:22:34 -0700 (PDT)
Received: by mail-ig0-f174.google.com with SMTP id c1so1270072igq.1 for <ipv6@ietf.org>; Fri, 01 Aug 2014 03:22:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=W8Xi9IjhYk/qceZcsRw7sQPklvEPBr6r1HJYEuwzH3w=; b=NfENXAD0MDUexJOhwDW1jwol+EWvVBlCp9tNO7hMN1ZjDaawzLEqGqSz8jDvC/Oh/h MyJcIV023tZDdC3kdPoqSH1xLO0phYXmyReKYHw+mqluQkS4HXYqFR+AlrpQtZjllehm jz7Dnrn0hygXBASrXMrWDXgS9s3IO3R2H/gi3bZYwSvKeW/ZnV6i9W7yeLRVw+uD3iX/ AII0o7o5IwuZl+HGMQUYaryFs9G0YlDAD2DlpmnZBqWhpk12TmlXnRtY9hRLC/SxcGt5 Af3Mb93QgT1TlCDJiIcdjrzrwlESzgWGoQVPRt8V9uKnJw+gBusMfggPpVJVXeEvA0BS lxrA==
MIME-Version: 1.0
X-Received: by 10.50.111.132 with SMTP id ii4mr5382254igb.8.1406888553910; Fri, 01 Aug 2014 03:22:33 -0700 (PDT)
Sender: xvilajosana@gmail.com
Received: by 10.64.129.198 with HTTP; Fri, 1 Aug 2014 03:22:33 -0700 (PDT)
In-Reply-To: <53DB675C.9000502@tm.uka.de>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <53DB675C.9000502@tm.uka.de>
Date: Fri, 1 Aug 2014 12:22:33 +0200
X-Google-Sender-Auth: el9dUg6O4PI-bWlyjwx6dXf99g8
Message-ID: <CAMsDxWTGG1MMaYPTcQqsBb78GuzsPun_k7r6Qi29fELp=z-mKA@mail.gmail.com>
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
To: Christian Haas <haas@tm.uka.de>
Content-Type: multipart/alternative; boundary=047d7b4141107e975004ff8ec41d
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Vv34ZDqzUS_tecIyJApY2qbxyaA
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 10:22:36 -0000

--047d7b4141107e975004ff8ec41d
Content-Type: text/plain; charset=UTF-8

Hi Christian,

Inline

Hi,

i am not sure i can follow your calculation. According to your paper
listening and receiving have the same costs for the RF231, transmitting
is a bit cheaper.

Yes, tx is slightly cheaper than rx. Rx uses a guard time of ~1ms so radio
is turned on a little bit before to cope with clock drifts. (note that
nodes are synchronized)

So for the sender it would be better to send more data (cheaper than
simply listening (=radio ON, do nothing)), for the receiving node it
makes no difference whether receiving more or less data.

I do not agree with that, the number of bytes sent and received determine
the amount of time the radio is on, therefore, the less time the radio is
on the less energy consumption, this applies to both sides. The key point
in that networks is to have the radio turned off most of the time. Note
that in 15.4e networks radio is duty-cycled and only is used when needed
taking advantage of node synchronization.

Why do you conclude you are saving 8% energy ?! Also your duty-cycling
model of the radio is not quite clear to me.

4% at each side. The sender saves 4% of the energy by sending 5bytes less
meaning that the radio is on some  uS less as there are less bytes to be
tx. In the other side the receiver also has the radio on for less time as
there are less bytes on the air. I do not see what is not clear on that.

Regards,
 Christian

thanks for your comment!
X


2014-08-01 12:09 GMT+02:00 Christian Haas <haas@tm.uka.de>:

> On 08/01/2014 10:50 AM, Xavier Vilajosana wrote:
> > Dear Phil, all,
> >
> > we know that the charge used by a mote (something similar to telosb) to
> > send 127bytes is around 69uC and to receive them is 72uC (considering the
> > optimal case where receiver has a guard time of 1ms and the network is
> > synchronized).  By using the flow label instead of the RPL extension
> header
> > we save 5bytes which give us a gain 2,71uC per data packet per hop when
> > sent and something similar when received (i.e ~5uC in total), this is a
> 8%
> > saving (accounting TX and RX side) considering that motes are always
> using
> > 127bytes packets.
>
> Hi,
>
> i am not sure i can follow your calculation. According to your paper
> listening and receiving have the same costs for the RF231, transmitting
> is a bit cheaper.
>
> So for the sender it would be better to send more data (cheaper than
> simply listening (=radio ON, do nothing)), for the receiving node it
> makes no difference whether receiving more or less data.
>
> Why do you conclude you are saving 8% energy ?! Also your duty-cycling
> model of the radio is not quite clear to me.
>
> Regards,
>  Christian
>
>
>
>

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

<div dir=3D"ltr">Hi Christian,<div><br></div><div>Inline=C2=A0</div><div><b=
r></div><div><font color=3D"#0000ff"><span style=3D"font-family:arial,sans-=
serif;font-size:12.800000190734863px">Hi,</span><br style=3D"font-family:ar=
ial,sans-serif;font-size:12.800000190734863px">
<br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"><=
span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">=
i am not sure i can follow your calculation. According to your paper</span>=
<br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">
<span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=
>listening and receiving have the same costs for the RF231, transmitting</s=
pan><br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863p=
x">
<span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=
>is a bit cheaper.=C2=A0</span></font></div><div><font color=3D"#0000ff"><s=
pan style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"><=
br></span></font></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:12.8000001907348=
63px"><font color=3D"#000000">Yes, tx is slightly cheaper than rx. Rx uses =
a guard time of ~1ms so radio is turned on a little bit before to cope with=
 clock drifts. (note that nodes are synchronized)</font></span></div>
<div><br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863=
px"><span style=3D"color:rgb(0,0,255);font-family:arial,sans-serif;font-siz=
e:12.800000190734863px">So for the sender it would be better to send more d=
ata (cheaper than</span><br style=3D"font-family:arial,sans-serif;font-size=
:12.800000190734863px">
<span style=3D"color:rgb(0,0,255);font-family:arial,sans-serif;font-size:12=
.800000190734863px">simply listening (=3Dradio ON, do nothing)), for the re=
ceiving node it</span><br style=3D"font-family:arial,sans-serif;font-size:1=
2.800000190734863px">
<span style=3D"color:rgb(0,0,255);font-family:arial,sans-serif;font-size:12=
.800000190734863px">makes no difference whether receiving more or less data=
.</span><br style=3D"font-family:arial,sans-serif;font-size:12.800000190734=
863px">
<br><font color=3D"#000000">I do not agree with that, the number of bytes s=
ent and received determine the amount of time the radio is on, therefore, t=
he less time the radio is on the less energy consumption, this applies to b=
oth sides. The key point in that networks is to have the radio turned off m=
ost of the time. Note that in 15.4e networks radio is duty-cycled and only =
is used when needed taking advantage of node synchronization.</font></div>
<div><font color=3D"#0000ff"><br style=3D"font-family:arial,sans-serif;font=
-size:12.800000190734863px"><span style=3D"font-family:arial,sans-serif;fon=
t-size:12.800000190734863px">Why do you conclude you are saving 8% energy ?=
! Also your duty-cycling</span><br style=3D"font-family:arial,sans-serif;fo=
nt-size:12.800000190734863px">
<span style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"=
>model of the radio is not quite clear to me.</span></font></div><div><font=
 color=3D"#0000ff"><br></font></div><div><font color=3D"#000000">4% at each=
 side. The sender saves 4% of the energy by sending 5bytes less meaning tha=
t the radio is on some =C2=A0uS less as there are less bytes to be tx. In t=
he other side the receiver also has the radio on for less time as there are=
 less bytes on the air. I do not see what is not clear on that.</font><br s=
tyle=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">
<br style=3D"font-family:arial,sans-serif;font-size:12.800000190734863px"><=
span style=3D"color:rgb(0,0,255);font-family:arial,sans-serif;font-size:12.=
800000190734863px">Regards,</span><br style=3D"font-family:arial,sans-serif=
;font-size:12.800000190734863px">
<span style=3D"color:rgb(0,0,255);font-family:arial,sans-serif;font-size:12=
.800000190734863px">=C2=A0Christian</span><br></div><div><span style=3D"col=
or:rgb(0,0,255);font-family:arial,sans-serif;font-size:12.800000190734863px=
"><br>
</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:12.=
800000190734863px"><font color=3D"#000000">thanks for your comment!</font><=
/span></div><div><span style=3D"color:rgb(0,0,255);font-family:arial,sans-s=
erif;font-size:12.800000190734863px">X</span></div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014-08=
-01 12:09 GMT+02:00 Christian Haas <span dir=3D"ltr">&lt;<a href=3D"mailto:=
haas@tm.uka.de" target=3D"_blank">haas@tm.uka.de</a>&gt;</span>:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
On 08/01/2014 10:50 AM, Xavier Vilajosana wrote:<br>
&gt; Dear Phil, all,<br>
<div class=3D"">&gt;<br>
&gt; we know that the charge used by a mote (something similar to telosb) t=
o<br>
&gt; send 127bytes is around 69uC and to receive them is 72uC (considering =
the<br>
&gt; optimal case where receiver has a guard time of 1ms and the network is=
<br>
&gt; synchronized). =C2=A0By using the flow label instead of the RPL extens=
ion header<br>
&gt; we save 5bytes which give us a gain 2,71uC per data packet per hop whe=
n<br>
&gt; sent and something similar when received (i.e ~5uC in total), this is =
a 8%<br>
&gt; saving (accounting TX and RX side) considering that motes are always u=
sing<br>
&gt; 127bytes packets.<br>
<br>
</div>Hi,<br>
<br>
i am not sure i can follow your calculation. According to your paper<br>
listening and receiving have the same costs for the RF231, transmitting<br>
is a bit cheaper.<br>
<br>
So for the sender it would be better to send more data (cheaper than<br>
simply listening (=3Dradio ON, do nothing)), for the receiving node it<br>
makes no difference whether receiving more or less data.<br>
<br>
Why do you conclude you are saving 8% energy ?! Also your duty-cycling<br>
model of the radio is not quite clear to me.<br>
<br>
Regards,<br>
=C2=A0Christian<br>
<br>
<br>
<br>
</blockquote></div><br></div>

--047d7b4141107e975004ff8ec41d--


From nobody Fri Aug  1 04:24:07 2014
Return-Path: <cabo@tzi.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E871A0A99; Fri,  1 Aug 2014 04:24:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 8JlMv16c09kM; Fri,  1 Aug 2014 04:24:04 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13D3A1ABB18; Fri,  1 Aug 2014 04:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s71BNliK010532; Fri, 1 Aug 2014 13:23:47 +0200 (CEST)
Received: from [192.168.217.106] (p5489377C.dip0.t-ipconnect.de [84.137.55.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D3147F2E; Fri,  1 Aug 2014 13:23:46 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com>
Date: Fri, 1 Aug 2014 13:23:44 +0200
X-Mao-Original-Outgoing-Id: 428585024.77831-f8a90d73a64f26af62a888953db75812
Content-Transfer-Encoding: quoted-printable
Message-Id: <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com>
To: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/y1ZtJVUrvuC7rqoDpMCcnJR2-Rg
Cc: roll <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 11:24:06 -0000

On 01 Aug 2014, at 10:50, Xavier Vilajosana =
<xvilajosana@eecs.berkeley.edu> wrote:

>=20
> Let's look at what IPHC does at the LBR when a flow label is elided =
and has to be inflated to be forwarded to the IPv6 network, this =
standardized behaviour is somehow interfering the end to end notion of =
the flow label as the content is being populated at the border of the =
LLN.=20

No.  With IPHC, the flow label has always been there, it just was =
transmitted in a very compressed form.

I think the visceral reaction that most of us have in using the flow =
label as a mesh routing header is that this blurs the layer boundaries.  =
So much for O, R, F, and rank.  Putting the VLAN (=93instance ID=94) =
into the packet is a significantly larger change, because it essentially =
extends the IP service interface by a VLAN ID.  We normally try to hide =
IDs of this kind below IP.

Now, I=92m not saying any of this new architecture is wrong.  I just =
think what we need to do is discuss this as the architectural change =
that it is, not as a simple optimization.  (The need for some kind of =
optimization of IP-in-IP mesh routing for small-packet IoT applications =
is pretty obvious to me.)

The other story is that we are retracting RFC 6437 and turning the flow =
label into the =93field you may trample on in your lower layers if you =
have a good reason=94.  Cynically, one could say this is proper payback =
for designing this field without a compelling purpose and no protocol =
evolution story attached to it.  So the evolution just eats it.  =
Teachable moment.

Gr=FC=DFe, Carsten


From nobody Fri Aug  1 04:54:23 2014
Return-Path: <haas@tm.uka.de>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76EB91A0649 for <ipv6@ietfa.amsl.com>; Fri,  1 Aug 2014 03:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 T1_Q4QE3MVxD for <ipv6@ietfa.amsl.com>; Fri,  1 Aug 2014 03:09:36 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556821A0648 for <ipv6@ietf.org>; Fri,  1 Aug 2014 03:09:36 -0700 (PDT)
Received: from i72xdenise.tm.uni-karlsruhe.de ([141.3.71.36]) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 587  iface 141.3.10.81 id 1XD9mI-0002Vm-Pn; Fri, 01 Aug 2014 12:09:34 +0200
Message-ID: <53DB675C.9000502@tm.uka.de>
Date: Fri, 01 Aug 2014 12:09:32 +0200
From: Christian Haas <haas@tm.uka.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com>
In-Reply-To: <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de  esmtpsa 1406887774.
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Ed70JP1w7Dku-tQ36Dy5uNsd_9g
X-Mailman-Approved-At: Fri, 01 Aug 2014 04:54:21 -0700
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 10:09:38 -0000

On 08/01/2014 10:50 AM, Xavier Vilajosana wrote:
> Dear Phil, all,
> 
> we know that the charge used by a mote (something similar to telosb) to
> send 127bytes is around 69uC and to receive them is 72uC (considering the
> optimal case where receiver has a guard time of 1ms and the network is
> synchronized).  By using the flow label instead of the RPL extension header
> we save 5bytes which give us a gain 2,71uC per data packet per hop when
> sent and something similar when received (i.e ~5uC in total), this is a 8%
> saving (accounting TX and RX side) considering that motes are always using
> 127bytes packets.

Hi,

i am not sure i can follow your calculation. According to your paper
listening and receiving have the same costs for the RF231, transmitting
is a bit cheaper.

So for the sender it would be better to send more data (cheaper than
simply listening (=radio ON, do nothing)), for the receiving node it
makes no difference whether receiving more or less data.

Why do you conclude you are saving 8% energy ?! Also your duty-cycling
model of the radio is not quite clear to me.

Regards,
 Christian




From nobody Fri Aug  1 05:44:30 2014
Return-Path: <xvilajosana@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4121A0AE9 for <ipv6@ietfa.amsl.com>; Fri,  1 Aug 2014 05:44:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 VVdbHDaAf7QS for <ipv6@ietfa.amsl.com>; Fri,  1 Aug 2014 05:44:28 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4A61A0AE8 for <ipv6@ietf.org>; Fri,  1 Aug 2014 05:44:28 -0700 (PDT)
Received: by mail-ie0-f172.google.com with SMTP id lx4so5810234iec.3 for <ipv6@ietf.org>; Fri, 01 Aug 2014 05:44:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=LasjJXRJd9x2zKwqX4e343oK2KQBbs+NBMXku9UU4WM=; b=0TkFR2hPkYvaOYGPJVtBtoQRj21t9vNVn7bxC1KrA0xCJ2QDiHl5YHJaQWhTN3I8H4 l360Ncua0JOO/+FJVyqEdh96UdAag0CQlcm2ZPwQGURsbjZac4swnuYEasfQnxOlzth2 y7TlpdGwtkL4rwN+vV42HWesw1oF8Y+OtWN9fovNEYfhj5QcVBya5i37pBw3s9yFcEab tUZDPKeWBZiCge8fceNIkAYySdz8tb6GOFrNjCxyZ2CKqNRQLbgi7cyrcZU5Cnf46rIL deOZWVwKp4NC7fijuBaXNYswAgv8yrfHWIU+rfBlCzIooHe3hLDkGhjVW7Qa1kR82QkU D9Qw==
MIME-Version: 1.0
X-Received: by 10.50.67.51 with SMTP id k19mr7222925igt.39.1406897067945; Fri, 01 Aug 2014 05:44:27 -0700 (PDT)
Sender: xvilajosana@gmail.com
Received: by 10.64.129.198 with HTTP; Fri, 1 Aug 2014 05:44:27 -0700 (PDT)
In-Reply-To: <53DB88B7.80205@tm.uka.de>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <53DB675C.9000502@tm.uka.de> <CAMsDxWTGG1MMaYPTcQqsBb78GuzsPun_k7r6Qi29fELp=z-mKA@mail.gmail.com> <53DB88B7.80205@tm.uka.de>
Date: Fri, 1 Aug 2014 14:44:27 +0200
X-Google-Sender-Auth: FTMTtcHFcWs-frhNUAnC4ejAjYU
Message-ID: <CAMsDxWROddNcfcWATpr4wmM+iMGhn4xMGO77f6hGvmRB9+Ow6g@mail.gmail.com>
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
To: Christian Haas <haas@tm.uka.de>
Content-Type: multipart/alternative; boundary=047d7bd756e6f8789d04ff90bfc9
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/kvlSryzmOCYQwcyhefeu44c-4kc
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 12:44:29 -0000

--047d7bd756e6f8789d04ff90bfc9
Content-Type: text/plain; charset=UTF-8

Hi Christian,

I think that duty cycling the radio is a very common approach in most of
the MAC layers for LLNs. 15.4e CSL for example would also benefit from
that. Of course if you have always on nodes, then the saving is minor, but
I wonder how many real networks are deployed in "real scenarios" that make
use of non-duty cycled mac layers. Anyway in that case, saving a few % is
always something interesting IMHO.

regards,
Xavi


2014-08-01 14:31 GMT+02:00 Christian Haas <haas@tm.uka.de>:

> Hi,
>
> On 08/01/2014 12:22 PM, Xavier Vilajosana wrote:
> > I do not agree with that, the number of bytes sent and received determine
> > the amount of time the radio is on, therefore, the less time the radio is
> > on the less energy consumption, this applies to both sides. The key point
> > in that networks is to have the radio turned off most of the time. Note
> > that in 15.4e networks radio is duty-cycled and only is used when needed
> > taking advantage of node synchronization.
>
> My (maybe uninformed view) was that the timeslots have a fixed
> (configurable) size and the radio is active within the time slot (=not
> OFF).
>
> So again i think your energy savings really depend on the used
> duty-cycling mechanism, e.g. what happens for someone not using
> 15.4e/TiSCH ?
>
> Christian
>

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

<div dir=3D"ltr">Hi Christian,<div><br></div><div>I think that duty cycling=
 the radio is a very common approach in most of the MAC layers for LLNs. 15=
.4e CSL for example would also benefit from that. Of course if you have alw=
ays on nodes, then the saving is minor, but I wonder how many real networks=
 are deployed in &quot;real scenarios&quot; that make use of non-duty cycle=
d mac layers. Anyway in that case, saving a few % is always something inter=
esting IMHO.</div>
<div><br></div><div>regards,</div><div>Xavi</div></div><div class=3D"gmail_=
extra"><br><br><div class=3D"gmail_quote">2014-08-01 14:31 GMT+02:00 Christ=
ian Haas <span dir=3D"ltr">&lt;<a href=3D"mailto:haas@tm.uka.de" target=3D"=
_blank">haas@tm.uka.de</a>&gt;</span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi,<br>
<div class=3D""><br>
On 08/01/2014 12:22 PM, Xavier Vilajosana wrote:<br>
&gt; I do not agree with that, the number of bytes sent and received determ=
ine<br>
&gt; the amount of time the radio is on, therefore, the less time the radio=
 is<br>
&gt; on the less energy consumption, this applies to both sides. The key po=
int<br>
&gt; in that networks is to have the radio turned off most of the time. Not=
e<br>
&gt; that in 15.4e networks radio is duty-cycled and only is used when need=
ed<br>
&gt; taking advantage of node synchronization.<br>
<br>
</div>My (maybe uninformed view) was that the timeslots have a fixed<br>
(configurable) size and the radio is active within the time slot (=3Dnot<br=
>
OFF).<br>
<br>
So again i think your energy savings really depend on the used<br>
duty-cycling mechanism, e.g. what happens for someone not using<br>
15.4e/TiSCH ?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Christian<br>
</font></span></blockquote></div><br></div>

--047d7bd756e6f8789d04ff90bfc9--


From nobody Fri Aug  1 05:44:54 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243141A0B00; Fri,  1 Aug 2014 05:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 kyycVQksyiF0; Fri,  1 Aug 2014 05:44:49 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9046C1A0B04; Fri,  1 Aug 2014 05:44:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6467; q=dns/txt; s=iport; t=1406897086; x=1408106686; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=c/WKTYA/5UNVR/gnH9rZnEDWWLXiE++Vy3iLXfbKTpw=; b=PTFlutIxvO6jK7cT5hc8aq9wUsqp9+Ij+AqOeSaAjkNO5BBzV+tFHm2e 4bBHSPP6KUV75M1Yl95w//lfLb/VH7UV0C4KvDGTduaN0CTF87Cs9Wj8P AQ9VNPIDA+3RwfzAGnkhGMdVWcXLO0ZVocAdwktLon7AGk4SJyQd83O2N w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjEFADeL21OtJV2T/2dsb2JhbABPDA6Cf4EpBNNTAYEIFneEAwEBAQQdShIMBAIBCA4DBAEBAQodByERFAkIAgQBDQUIiCYDEcJrDYcPF40fgUYBGB0xBwaDKYEcBYpMjyKQOoYlgwdCbAGBRA
X-IronPort-AV: E=Sophos;i="5.01,780,1400025600"; d="scan'208";a="344417706"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-6.cisco.com with ESMTP; 01 Aug 2014 12:44:42 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s71CigDg001383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 12:44:42 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 07:44:42 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Philip Levis <pal@cs.stanford.edu>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: RE: WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPq3MQL9UY5QNEnE6ScMk7SCjlQJu4D/iAgAAaYwCAAutIgIAAk91g
Date: Fri, 1 Aug 2014 12:44:41 +0000
Deferred-Delivery: Fri, 1 Aug 2014 12:44:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D04850@xmb-rcd-x01.cisco.com>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu>
In-Reply-To: <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.197.62]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/3AUQ1ZO4LCyrB5k4d4tPA_2sNEw
Cc: Brian Haberman <brian@innovationslab.net>, "ipv6@ietf.org" <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, roll <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, Bob Hinden <bob.hinden@gmail.com>, "Ole Troan \(otroan\)" <otroan@cisco.com>, Pat Kinney <pat.kinney@KINNEYCONSULTINGLLC.COM>, Adrian Farrel <adrian@olddog.co.uk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 12:44:52 -0000

Hello Phil:

The end-to-end principle will not break in pieces if we reuse the flow labe=
l field within the LLN.=20

FYI, it will break nothing since there is no assumption in the Internet tha=
t the flow label will be carried unchanged. Consistently, there is no nativ=
e way to secure the flow label to make sure it was not tempered with (IOW i=
t is not protected by ULP checksums, IPSec AH or ESP transport mode).=20

The last call at 6MAN is where I expect problems with the use of the flow l=
abel field in this draft to be pointed at. I'm happy to report that there w=
as no trace of bigotry there, all the contrary. 6MAN will confirm whether t=
his draft conforms the spirit of the existing RFCs and so far I gathered, f=
rom all but you, that it does.

About SDOs: To be very clear, ISA100.11a made a clear condition to acceptan=
ce of 6LoWPAN that we compress the UDP checksum - 2 bytes. And we made that=
 happen.
As the standard is now considering what new work may be taken in, RPL will =
not be considered if we waste those 5 bytes, simple as that. Sorry that you=
 missed the ROLL meeting, but Pat Kinney was very clear on that both as vic=
e chair of 802.15,  and as chair of ISA100.11a where he "fought over every =
byte". " Both hats say that this is what we need this".

We'll also note that each additional octet in a frame is an increased chanc=
e of loss and retry. This is an argument that I hear frequently at IEEE and=
 the people there as well as at ISA100 are very sensitive to frame size in =
general.

The distribution of the frame size and the cost of security depend on the a=
pplication and the app layer. With high levels of security, if the distribu=
tion includes NLPDU around 80-90 octets then the extra bytes will cause fra=
gmentation, which will add all sorts of new problems to the picture.

The benefits are quite clear, both on actual numbers (thanks Xavi!) and on =
the political arena where such a waste of bytes is just not defendable.

Please reconsider where you are placing your efforts and what you are tryin=
g to achieve...

Pascal


> -----Original Message-----
> From: Philip Levis [mailto:pal@cs.stanford.edu]
> Sent: vendredi 1 ao=FBt 2014 00:11
> To: Brian E Carpenter
> Cc: Ines Robles; Brian Haberman; ipv6@ietf.org; Michael Richardson; roll;
> Bob Hinden; Ole Troan (otroan); Pascal Thubert (pthubert); Adrian Farrel
> Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
>=20
>=20
> On Jul 29, 2014, at 6:36 PM, Brian E Carpenter
> <brian.e.carpenter@gmail.com> wrote:
>=20
> > On 30/07/2014 12:02, Philip Levis wrote:
> > ...
> >> "This specification suggests that energy-saving is another compelling
> >> reason for a violation to the aforementioned rule."
> >>
> >> makes the assumption that the energy saving is significant.
> >> Breaking the end-to-end nature of the flow label for some tiny saving
> >> seems like a mistake.
> >
> > I can't evaluate whether the energy saving is significant.
> > However, I don't have any deep faith in the e2e-ness of the flow
> > label. The reality (as RFC 6437 tries to recognise) is that it's a
> > mutable field, and is therefore untrustworthy for e2e use. It has
> > value for load balancing if all packets of a given flow have the same
> > label, whether the label is set by the source or by a border device.
> > For that reason, I think the usage proposed in this draft is OK.
> >
> > However, I do agree that at least a hand-waving estimate of the %
> > energy saving would be useful.
> >
> >    Brian Carpenter
>=20
> *shrug* My thoughts are pretty simple. I'm sure you know all this (as one=
 of
> the authors!) but I'll revisit for everyone else's sake. 6437 states
>=20
> "A forwarding node MUST either leave a non-zero flow label value
> unchanged or change it only for compelling operational security reasons a=
s
> described in Section 6.1."
>=20
> So, this is a MUST. Either the RPL flow label draft contradicts 6437 (and
> should say so explicitly), or there should be an explicit update to 6437.=
 In
> fact, the current draft is misleading and incorrect. It says
>=20
> "but the RFC also indicates a violation to the rule can be accepted for
> compelling reasons, and that security is a case justifying such a violati=
on.
> This specification suggests that energy-saving is another compelling    r=
eason
> for a violation to the aforementioned rule."
>=20
> This is *not* what 6437 says. It says for compelling operational security
> reasons, not compelling reasons, of which one case is security.
>=20
> Having been researching, implementing, and deploying low-power protocols
> for over a decade, I've become exceedingly skeptical when someone
> proposes a protocol with energy as a motivation without quantifying it. F=
or
> example, there are tons of protocols in the research literature which tal=
k
> about using transmission power control to save energy (trading off range =
for
> power). But almost all of these papers ignore the fact that (unlike
> mobile/cellular systems, which the authors have been publishing in for
> years) RF is a tiny sliver of power in low-power networks. So reducing yo=
ur
> transmission (RF) power by 99% only reduces your radio power by 50%.
> Generally a losing proposition. This is the same reason why power saving =
in
> WiFi involves synchronization on AP beacons and not adjusting transmit
> power. If someone doesn't quantify the potential benefit based on real
> hardware and protocols, then it could be based on mistaken assumptions.
>=20
> I mean, it doesn't take much here. Start with a working low-power RPL
> network. Send packets with sizes following a reasonable distribution base=
d
> on an actual application. In one experiment send just those packets. In
> another add the 8 bytes. In a third add 8 + the IP-in-IP encapsulation.
> Measure the energy cost.
>=20
> And, generally speaking, if you can't demonstrate the problem very easily=
,
> then perhaps it isn't a real problem at all.
>=20
> All that being said, I think using the flow label in this way is a good i=
dea, and
> definitely valuable. But as it is now, doing so violates 6437, and so the
> assumptions implementers make when reading 6437. I think the bar for
> doing so should be high, higher than vague suggestions and hand waving
> which might not be correct.
>=20
> Phil


From nobody Fri Aug  1 05:46:47 2014
Return-Path: <haas@tm.uka.de>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E590B1A0324 for <ipv6@ietfa.amsl.com>; Fri,  1 Aug 2014 05:31:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 G0hzrfnSMXDH for <ipv6@ietfa.amsl.com>; Fri,  1 Aug 2014 05:31:55 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E085C1A03AE for <ipv6@ietf.org>; Fri,  1 Aug 2014 05:31:54 -0700 (PDT)
Received: from i72xdenise.tm.uni-karlsruhe.de ([141.3.71.36]) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 587  iface 141.3.10.81 id 1XDC01-0003I1-DY; Fri, 01 Aug 2014 14:31:53 +0200
Message-ID: <53DB88B7.80205@tm.uka.de>
Date: Fri, 01 Aug 2014 14:31:51 +0200
From: Christian Haas <haas@tm.uka.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: xvilajosana@eecs.berkeley.edu
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <53DB675C.9000502@tm.uka.de> <CAMsDxWTGG1MMaYPTcQqsBb78GuzsPun_k7r6Qi29fELp=z-mKA@mail.gmail.com>
In-Reply-To: <CAMsDxWTGG1MMaYPTcQqsBb78GuzsPun_k7r6Qi29fELp=z-mKA@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de  esmtpsa 1406896313.
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/c-Y2yfFGpXMc7rRAAffT8ungc9Q
X-Mailman-Approved-At: Fri, 01 Aug 2014 05:46:47 -0700
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 12:31:57 -0000

Hi,

On 08/01/2014 12:22 PM, Xavier Vilajosana wrote:
> I do not agree with that, the number of bytes sent and received determine
> the amount of time the radio is on, therefore, the less time the radio is
> on the less energy consumption, this applies to both sides. The key point
> in that networks is to have the radio turned off most of the time. Note
> that in 15.4e networks radio is duty-cycled and only is used when needed
> taking advantage of node synchronization.

My (maybe uninformed view) was that the timeslots have a fixed
(configurable) size and the radio is active within the time slot (=not
OFF).

So again i think your energy savings really depend on the used
duty-cycling mechanism, e.g. what happens for someone not using
15.4e/TiSCH ?

Christian


From nobody Fri Aug  1 05:56:50 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19921A854B; Fri,  1 Aug 2014 05:56:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 qVTfW_Gq8kUU; Fri,  1 Aug 2014 05:56:42 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CEB81A0B14; Fri,  1 Aug 2014 05:56:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3352; q=dns/txt; s=iport; t=1406897802; x=1408107402; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tVR2wH25GCFpDfqHL4WDRHLF1o52CijN/QbyRyKzFY0=; b=RzeHxqv549lxjCMRTokONjKPSTKl0WPxOAWC01AVTQ7ItpecEaSnC3Wt x5pToU1Jnth+sYJUOcGh70rz5NX0VTnONQb5tl9gi1OTDRKH5M4Vx90Q4 cvzkd2nZtJy/BQSrw54Qk6nmoHcxbIAG5sf2tiCef6OMHA3WCGfHfQWK/ g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiEFAHyN21OtJA2D/2dsb2JhbABbDoJ/UlcEy38Kh0wBgQgWd4QDAQEBAwEBAQFrCwwEAgEIDgMBAwEBAQodBycLFAMGCAIEAQ0FCIgyCA3JeBMEjn4dMQcGgymBHAWGBoRIpgaDB0JsgUU
X-IronPort-AV: E=Sophos;i="5.01,780,1400025600"; d="scan'208";a="344416242"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP; 01 Aug 2014 12:56:41 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s71CufmE019179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 12:56:41 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 07:55:51 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Carsten Bormann <cabo@tzi.org>, Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
Subject: RE: WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPrXsN1MAnFsPEm0SwuR6qTQA6spu7svGw
Date: Fri, 1 Aug 2014 12:56:40 +0000
Deferred-Delivery: Fri, 1 Aug 2014 12:56:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D049E9@xmb-rcd-x01.cisco.com>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org>
In-Reply-To: <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.197.62]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/ahpFXHuCqjjMyRLyxXNW2MOjfhU
Cc: roll <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 12:56:48 -0000

> > Let's look at what IPHC does at the LBR when a flow label is elided and=
 has
> to be inflated to be forwarded to the IPv6 network, this standardized
> behaviour is somehow interfering the end to end notion of the flow label =
as
> the content is being populated at the border of the LLN.
>=20
> No.  With IPHC, the flow label has always been there, it just was transmi=
tted
> in a very compressed form.

My take is that you are both providing angles on a same thing. It does not =
make sense for a LLN node to waste compute power and bandwidth to get a ran=
dom through that is of use only in the core of the internet, should the pac=
ket ever get there. So the flow label is effectively zero - or something lo=
cally significant in specific standards, which is not design to serve the p=
urpose of load balancing in the core. So in either case, we need the root t=
o 'inflate' the zero flow label, or replace it by something that fits the c=
ore of the Internet. That behavior was not specified so far and it should b=
e. This document is covering this particular gap.

Cheers,

Pascal


> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Carsten Bormann
> Sent: vendredi 1 ao=FBt 2014 13:24
> To: Xavier Vilajosana
> Cc: roll; ipv6@ietf.org
> Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
>=20
> On 01 Aug 2014, at 10:50, Xavier Vilajosana <xvilajosana@eecs.berkeley.ed=
u>
> wrote:
>=20
> >
> > Let's look at what IPHC does at the LBR when a flow label is elided and=
 has
> to be inflated to be forwarded to the IPv6 network, this standardized
> behaviour is somehow interfering the end to end notion of the flow label =
as
> the content is being populated at the border of the LLN.
>=20
> No.  With IPHC, the flow label has always been there, it just was transmi=
tted
> in a very compressed form.
>=20
> I think the visceral reaction that most of us have in using the flow labe=
l as a
> mesh routing header is that this blurs the layer boundaries.  So much for=
 O,
> R, F, and rank.  Putting the VLAN ("instance ID") into the packet is a
> significantly larger change, because it essentially extends the IP servic=
e
> interface by a VLAN ID.  We normally try to hide IDs of this kind below I=
P.
>=20
> Now, I'm not saying any of this new architecture is wrong.  I just think =
what
> we need to do is discuss this as the architectural change that it is, not=
 as a
> simple optimization.  (The need for some kind of optimization of IP-in-IP
> mesh routing for small-packet IoT applications is pretty obvious to me.)
>=20
> The other story is that we are retracting RFC 6437 and turning the flow l=
abel
> into the "field you may trample on in your lower layers if you have a goo=
d
> reason".  Cynically, one could say this is proper payback for designing t=
his
> field without a compelling purpose and no protocol evolution story attach=
ed
> to it.  So the evolution just eats it.  Teachable moment.
>=20
> Gr=FC=DFe, Carsten
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Fri Aug  1 06:25:12 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E4F1A0B13; Fri,  1 Aug 2014 06:25:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 QlWDk0sQR-t1; Fri,  1 Aug 2014 06:25:08 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237361A0B06; Fri,  1 Aug 2014 06:25:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1573; q=dns/txt; s=iport; t=1406899508; x=1408109108; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QhAjaCNubhiAAMcAlhI5fiNV4z2CCx9hEgOCeJUHzfs=; b=VEn9Ebw5lNX2IXqLQNR7yKrIVEPqG/dRyhpsTbYsRsgTkt2WZfSc6QEe E86LmeO48C/K3Z9OBZ6iL89ISeCoXdvKA7lMGkBQPohCuYiL08PZkffWA C+dVmay4WxEgUUNdC5Xl6gSJGrBJERa6hK/u1JIeuGnBR0RiBSSkpl18G w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAA+U21OtJV2b/2dsb2JhbABbgw2BLdNVAYEIFneEBAEBAwE6PwULAgEIDgQQFBAyFw4CBA4NiDIIyXwXjxsxB4MvgRwBBLBUg0mCMQ
X-IronPort-AV: E=Sophos;i="5.01,780,1400025600"; d="scan'208";a="341312469"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 01 Aug 2014 13:25:07 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s71DP7a6016088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 13:25:07 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 08:25:06 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Carsten Bormann <cabo@tzi.org>
Subject: RE: WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPrXsN1MAnFsPEm0SwuR6qTQA6spu7tLlA
Date: Fri, 1 Aug 2014 13:25:06 +0000
Deferred-Delivery: Fri, 1 Aug 2014 13:25:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D04B02@xmb-rcd-x01.cisco.com>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org>
In-Reply-To: <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.197.62]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/7-0usCcppwaykiynS3JlULGiJ8U
Cc: roll <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 13:25:10 -0000

> I think the visceral reaction that most of us have in using the flow labe=
l as a
> mesh routing header is that this blurs the layer boundaries.  So much for=
 O,
> R, F, and rank.  Putting the VLAN ("instance ID") into the packet is a
> significantly larger change, because it essentially extends the IP servic=
e
> interface by a VLAN ID.  We normally try to hide IDs of this kind below I=
P.
>=20
> Now, I'm not saying any of this new architecture is wrong.  I just think =
what
> we need to do is discuss this as the architectural change that it is, not=
 as a
> simple optimization.  (The need for some kind of optimization of IP-in-IP
> mesh routing for small-packet IoT applications is pretty obvious to me.)
>=20
>=20
I agree, Carsten.

An angle is that we allow for localized usage of the flow label as opposed =
to end-to-end.

Another is that we allow for different semantics within a local domain, as =
long as the packet that leaves the local domain fits the requirements in RF=
C 6437.

As you point out, it is worth noting that we include information about flow=
 isolation and rules by which a flow will be routed, which is akin to Multi=
-Topology Routing though MTR is based on TOS bits.

It would be good to design an architecture that encompasses such capabiliti=
es.

We'll note that ISA100.11a is shipping with a flow label that contains an i=
ndex to a state (so-called a contract) that is installed on the nodes on th=
e way and by and large extends the notion of PHB on a per flow basis.

Cheers,

Pascal


From nobody Fri Aug  1 09:50:40 2014
Return-Path: <pal@cs.stanford.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8782A1A00E2; Fri,  1 Aug 2014 09:50:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.201
X-Spam-Level: 
X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 ppxLHhoWdeuz; Fri,  1 Aug 2014 09:50:28 -0700 (PDT)
Received: from smtp2.cs.Stanford.EDU (smtp2.cs.Stanford.EDU [171.64.64.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C881A00B5; Fri,  1 Aug 2014 09:50:28 -0700 (PDT)
Received: from gates-ap-275.stanford.edu ([171.64.70.25]:53072 helo=[10.171.216.192]) by smtp2.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XDG2E-000594-7j; Fri, 01 Aug 2014 09:50:26 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD842D04850@xmb-rcd-x01.cisco.com>
Date: Fri, 1 Aug 2014 09:21:46 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <09EC423F-FC09-495D-9B48-0DABFA4C19F6@cs.stanford.edu>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D04850@xmb-rcd-x01.cisco.com>
To: Pascal Thubert (pthubert) <pthubert@cisco.com>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 5c460fe7d3aaafaf78d72307c0bc7e10
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/7dimSrWRJT7An4QMY-eWDK3p-cM
Cc: Brian Haberman <brian@innovationslab.net>, "ipv6@ietf.org" <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, roll <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, Bob Hinden <bob.hinden@gmail.com>, "Ole Troan \(otroan\)" <otroan@cisco.com>, Pat Kinney <pat.kinney@KINNEYCONSULTINGLLC.COM>, Adrian Farrel <adrian@olddog.co.uk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 16:50:36 -0000

On Aug 1, 2014, at 5:44 AM, Pascal Thubert (pthubert) =
<pthubert@cisco.com> wrote:

>=20
> FYI, it will break nothing since there is no assumption in the =
Internet that the flow label will be carried unchanged. Consistently, =
there is no native way to secure the flow label to make sure it was not =
tempered with (IOW it is not protected by ULP checksums, IPSec AH or ESP =
transport mode).=20
>=20
> The last call at 6MAN is where I expect problems with the use of the =
flow label field in this draft to be pointed at. I'm happy to report =
that there was no trace of bigotry there, all the contrary. 6MAN will =
confirm whether this draft conforms the spirit of the existing RFCs and =
so far I gathered, from all but you, that it does

Pascal, I don't think this is a question of spirit or anything. I mean, =
I'll repeat, 6437 states

"A forwarding node MUST either leave a non-zero flow label value =
unchanged or change it only for compelling operational security reasons =
as described in Section 6.1."

If the point is that experience and use and the spirit of the flow label =
has changed from this MUST, then we should explicitly state so. I'm not =
arguing that the above prescription is right; but it's what's written. =
What worries me is the idea of directly contradicting the text of a =
prior RFC (the one explicitly on flow labels, no less), without =
correspondingly obsoleting that RFC. This isn't a SHOULD. It's a MUST!

I've always thought that using the flow label in this way within an LLN =
is a good idea. The problem is that you can't do so without violating a =
MUST in the RFC that specifies how flow labels are used. It sounds like =
the letter of that document doesn't match the spirit of it -- so let's =
fix the letter, so it says what was intended! Why is there such =
recalcitrance to do so? Or provide any quantitative basis for the claims =
of battery power? You've been proposing this for nearly 4 years now...

I personally see two reasonable ways forward:

1) (As Carsten mentioned) Update 6437 to embrace these new and valuable =
uses of the flow label.

2) Provide evidence that using the flow label in this way would provide =
significant enough gains that violating a MUST in the RFC specifying the =
flow label is worth it.

It seems like you're advocating a third:

3) Violate a MUST in the RFC specifying how the flow label is used =
without any evidence that the actual energy savings are significant.

As for what I'm trying to achieve, that's pretty simple. I think it's a =
terrible mistake for a standards body as important as the IETF to rely =
on the spirit of the standard rather than the letter of the standard, =
especially when they contradict. If you are one of the hundreds of =
thousands of network engineers and software developers who work in the =
Internet, you can't know that a bunch of people in a meeting decided =
that the spirit of a specification differs from its text. All you have =
to go on is the text. When the founder of the next YouTube or Instagram =
or Google or Nicira takes my class and I ask them to write their code to =
follow an RFC (which I currently do), what should I tell them MUST =
means?

Phil=


From nobody Fri Aug  1 09:57:12 2014
Return-Path: <pal@cs.stanford.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29AA1B2844 for <ipv6@ietfa.amsl.com>; Fri,  1 Aug 2014 09:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 i5dc6nYNAK4b for <ipv6@ietfa.amsl.com>; Fri,  1 Aug 2014 09:57:06 -0700 (PDT)
Received: from smtp2.cs.Stanford.EDU (smtp2.cs.Stanford.EDU [171.64.64.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A8ED1B2839 for <ipv6@ietf.org>; Fri,  1 Aug 2014 09:57:06 -0700 (PDT)
Received: from gates-ap-275.stanford.edu ([171.64.70.25]:53109 helo=[10.171.216.192]) by smtp2.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XDG8e-0005Z0-G4; Fri, 01 Aug 2014 09:57:05 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <CAMsDxWROddNcfcWATpr4wmM+iMGhn4xMGO77f6hGvmRB9+Ow6g@mail.gmail.com>
Date: Fri, 1 Aug 2014 09:57:05 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <B80833DA-CF92-4F84-91FA-A45A74B4D03D@cs.stanford.edu>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <53DB675C.9000502@tm.uka.de> <CAMsDxWTGG1MMaYPTcQqsBb78GuzsPun_k7r6Qi29fELp=z-mKA@mail.gmail.com> <53DB88B7.80205@tm.uka.de> <CAMsDxWROddNcfcWATpr4wmM+iMGhn4xMGO77f6hGvmRB9+Ow6g@mail.gmail.com>
To: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 47150f6aa31409442f7db1cf5c00e98a
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/iG8ML2APd0-13fwcr5hHbuSK9DU
Cc: Christian Haas <haas@tm.uka.de>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 16:57:10 -0000

Xavier,

The paper is very helpful, thanks! Can you comment on what is a typical =
idle slot configuration in a TiSCH network? Can you provide some insight =
on what fraction of energy is spent in data communication versus control =
and idle listening?

Phil

On Aug 1, 2014, at 5:44 AM, Xavier Vilajosana =
<xvilajosana@eecs.berkeley.edu> wrote:

> Hi Christian,
>=20
> I think that duty cycling the radio is a very common approach in most =
of the MAC layers for LLNs. 15.4e CSL for example would also benefit =
from that. Of course if you have always on nodes, then the saving is =
minor, but I wonder how many real networks are deployed in "real =
scenarios" that make use of non-duty cycled mac layers. Anyway in that =
case, saving a few % is always something interesting IMHO.
>=20
> regards,
> Xavi
>=20
>=20
> 2014-08-01 14:31 GMT+02:00 Christian Haas <haas@tm.uka.de>:
> Hi,
>=20
> On 08/01/2014 12:22 PM, Xavier Vilajosana wrote:
> > I do not agree with that, the number of bytes sent and received =
determine
> > the amount of time the radio is on, therefore, the less time the =
radio is
> > on the less energy consumption, this applies to both sides. The key =
point
> > in that networks is to have the radio turned off most of the time. =
Note
> > that in 15.4e networks radio is duty-cycled and only is used when =
needed
> > taking advantage of node synchronization.
>=20
> My (maybe uninformed view) was that the timeslots have a fixed
> (configurable) size and the radio is active within the time slot (=3Dnot=

> OFF).
>=20
> So again i think your energy savings really depend on the used
> duty-cycling mechanism, e.g. what happens for someone not using
> 15.4e/TiSCH ?
>=20
> Christian
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Fri Aug  1 10:47:41 2014
Return-Path: <pal@cs.stanford.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC171A02DB for <ipv6@ietfa.amsl.com>; Fri,  1 Aug 2014 10:47:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 BaVwlo-ILzXL for <ipv6@ietfa.amsl.com>; Fri,  1 Aug 2014 10:47:33 -0700 (PDT)
Received: from smtp2.cs.Stanford.EDU (smtp2.cs.Stanford.EDU [171.64.64.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CCF1A028A for <ipv6@ietf.org>; Fri,  1 Aug 2014 10:47:24 -0700 (PDT)
Received: from gates-ap-275.stanford.edu ([171.64.70.25]:53287 helo=[10.171.216.192]) by smtp2.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XDGvL-0004pB-S5; Fri, 01 Aug 2014 10:47:24 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <CAMsDxWTGG1MMaYPTcQqsBb78GuzsPun_k7r6Qi29fELp=z-mKA@mail.gmail.com>
Date: Fri, 1 Aug 2014 09:20:24 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <544B6184-72FE-42B2-AAA4-DF44D0E1BD5A@cs.stanford.edu>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <53DB675C.9000502@tm.uka.de> <CAMsDxWTGG1MMaYPTcQqsBb78GuzsPun_k7r6Qi29fELp=z-mKA@mail.gmail.com>
To: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: ae35470b07fbe4e2dbb6b33d1de23969
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Bmi9WXtEJn5ELfNbBKWALX0y-I8
Cc: Christian Haas <haas@tm.uka.de>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 17:47:38 -0000

On Aug 1, 2014, at 3:22 AM, Xavier Vilajosana =
<xvilajosana@eecs.berkeley.edu> wrote:

> Hi Christian,
>=20
> Inline=20
>=20
> Hi,
>=20
> i am not sure i can follow your calculation. According to your paper
> listening and receiving have the same costs for the RF231, =
transmitting
> is a bit cheaper.=20
>=20
> Yes, tx is slightly cheaper than rx. Rx uses a guard time of ~1ms so =
radio is turned on a little bit before to cope with clock drifts. (note =
that nodes are synchronized)
>=20

Xavier is right -- this is commonly the case. In low-power wireless, the =
receive path often requires much more complex (digital) logic and the =
power costs of the amplifiers are similar. This is different than higher =
power networks, where the amplifier circuits dominate. E.g., take a look =
at a 4G eNodeB transmitting at 6W and it'll be drawing more than 100W, =
most of which goes into the final power amplifier (with a big heat sink =
on it).

> Why do you conclude you are saving 8% energy ?! Also your duty-cycling
> model of the radio is not quite clear to me.
>=20
> 4% at each side. The sender saves 4% of the energy by sending 5bytes =
less meaning that the radio is on some  uS less as there are less bytes =
to be tx. In the other side the receiver also has the radio on for less =
time as there are less bytes on the air. I do not see what is not clear =
on that.

This calculation seems a bit weird. If you're calculating both sides, =
then the numerator *and* the denominator have both costs in them. It's =
either  (1.04 * tx) + (1.04 * rx) / (tx + rx). So, 4%. How do you get =
8%?

Also, this seems to *only* consider receive/transmit time. I assume that =
the radios are on for other periods of time (the overhead of the =
protocol)? How does this factor in?

Phil=


From nobody Fri Aug  1 12:58:42 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E911B28B3; Fri,  1 Aug 2014 12:58:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 dzWyXlpn-ouQ; Fri,  1 Aug 2014 12:58:39 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E901A0467; Fri,  1 Aug 2014 12:58:39 -0700 (PDT)
Received: by mail-pa0-f46.google.com with SMTP id lj1so6345450pab.33 for <multiple recipients>; Fri, 01 Aug 2014 12:58:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=65VqK3L8Io+gxTbGcPhMlmRHYmei9ukzebgwZ3yvwoI=; b=jquQukMkQbEMWA1wYLcREps6MPMwYgN8hMeyFkFYiK4jRKOoj6DCIPPomEo/6iva6J oQHip2j2ZjBIJ6l55QcRraJr8c5PDRFf4XIMscdXZO8nP5uKb2fOovNim3PTlwbN6bTA BijuqBgD15sbzePy8LYqAHKfSZJl5NFz9eT2rvNzHVxhbNi6zLfI3unbvyiUi9fEXVKN dmXMY3GzLJ7tUpBgNg2OQitfT1CK24nY52WLCanN1MCoXwqkEjcMFCEbMrIH0bUtz08Q hh4XkWoMCt49W/XFSwOQDIEmXcIFNuRBZREhWhaoxSPTSzTHYhR4n7ngsgzUe3nTEVff xrag==
X-Received: by 10.68.245.9 with SMTP id xk9mr8745410pbc.123.1406923118839; Fri, 01 Aug 2014 12:58:38 -0700 (PDT)
Received: from [192.168.178.23] (48.195.69.111.dynamic.snap.net.nz. [111.69.195.48]) by mx.google.com with ESMTPSA id xq3sm33503484pab.0.2014.08.01.12.58.36 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Aug 2014 12:58:38 -0700 (PDT)
Message-ID: <53DBF16F.2090202@gmail.com>
Date: Sat, 02 Aug 2014 07:58:39 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Carsten Bormann <cabo@tzi.org>
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org>
In-Reply-To: <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/t3PXTEDcW-vDI3Sal3vizAjLm6c
Cc: roll <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 19:58:41 -0000

On 01/08/2014 23:23, Carsten Bormann wrote:
=2E..
> The other story is that we are retracting RFC 6437 and turning the flow=
 label into the =E2=80=9Cfield you may trample on in your lower layers if=
 you have a good reason=E2=80=9D.  Cynically, one could say this is prope=
r payback for designing this field without a compelling purpose and no pr=
otocol evolution story attached to it.  So the evolution just eats it.  T=
eachable moment.

RFC 6437 co-author hat on (but only speaking for myself, of course):

My opinion is that the draft doesn't retract RFC 6437. As I already said,=

6437 attempts to recognise the reality that middleboxes can mess with the=

flow label, and to set conditions for that messing such that remote syste=
ms
can still use it for load balancing. Since it's unprotected by checksum o=
r
crypto, there is a strict limit to how much it can be trusted anyway. As
the RFC says:

   There is no way to verify whether a flow label has been modified en
   route or whether it belongs to a uniform distribution.  Therefore, no
   Internet-wide mechanism can depend mathematically on unmodified and
   uniformly distributed flow labels; they have a "best effort" quality.
   Implementers should be aware that the flow label is an unprotected
   field that could have been accidentally or intentionally changed en
   route (see Section 6).

It is true that the RFC also says

   A forwarding node
   MUST either leave a non-zero flow label value unchanged or change it
   only for compelling operational security reasons...

There is a case for arguing that flow-label-for-rpl should carry the
legend "Updates: 6437 (if approved)" because it adds another exception
to this sentence. There is also a case for arguing that flow-label-for-rp=
l
is a stateful mechanism, out of scope for RFC 6437 according to
Section 4 of that RFC.

Either way, I don't see a problem.

Regards

   Brian




From nobody Fri Aug  1 13:27:46 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3BB1B28B3; Fri,  1 Aug 2014 13:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.502
X-Spam-Level: 
X-Spam-Status: No, score=-16.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 b7JjwIfE-vrn; Fri,  1 Aug 2014 13:27:42 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2290B1A0137; Fri,  1 Aug 2014 13:27:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3995; q=dns/txt; s=iport; t=1406924862; x=1408134462; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lk8u0FO2bB5hKVS6eu4FnolzVYn48Q5NItL1v2QSvcI=; b=XEhdVBsZ60U0bJR+R/MT8F8Fxai4Zg6301vORpnqr7oCjIhmTxYq58Vh u3DhW0dfxAhzZ57OblN6Yj3JEgJz6c6b4bRx06HbExs0DpSyITGoGeaaV 5usBtbLsjwjsrhiTEw8LfrXA9ija1JckK4zG2SoBL8b9DYKw66VE3IQXv s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhwFALT321OtJV2U/2dsb2JhbABPDA6Cf4Ep02EBgQsWd4QDAQEBAwEdSgUNBQsCAQgOCi4yJQIEDgWIOgjIZxeOZAEBGBszB4MvgRwFhH0ChU+RLJRagwdCbA
X-IronPort-AV: E=Sophos;i="5.01,782,1400025600"; d="scan'208";a="344523903"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP; 01 Aug 2014 20:27:41 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s71KRfgG028932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 20:27:41 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 15:27:41 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Philip Levis <pal@cs.stanford.edu>
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPrai33Dn9icet106HlaTIaH7gh5u8MoZe
Date: Fri, 1 Aug 2014 20:27:40 +0000
Message-ID: <C17BE08C-E179-472D-A349-B6CB8ADDCDF5@cisco.com>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D04850@xmb-rcd-x01.cisco.com>, <09EC423F-FC09-495D-9B48-0DABFA4C19F6@cs.stanford.edu>
In-Reply-To: <09EC423F-FC09-495D-9B48-0DABFA4C19F6@cs.stanford.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/nUWyWsnDSVH4zvziC7lONiypl80
Cc: Brian Haberman <brian@innovationslab.net>, "ipv6@ietf.org" <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, roll <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, Bob Hinden <bob.hinden@gmail.com>, "Ole Troan \(otroan\)" <otroan@cisco.com>, Pat Kinney <pat.kinney@KINNEYCONSULTINGLLC.COM>, Adrian Farrel <adrian@olddog.co.uk>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Aug 2014 20:27:44 -0000

Phil,

Though I attended the discussions and have a clear reading of this work I'l=
l certainly defer to Brian on whether there is a violation or not.=20

OTOH you need to understand that there is no need for a bis to update a MUS=
T in an RFC. We recognize the imperfection in our work and are always ready=
 to revise and amend after due consideration.

This process takes is another RFC and best judgement from the original grou=
p that the new text is indeed valuable and not breaking the original object=
ives.

We are going through that process.

Pascal

> Le 1 ao=FBt 2014 =E0 18:50, "Philip Levis" <pal@cs.stanford.edu> a =E9cri=
t :
>=20
>> On Aug 1, 2014, at 5:44 AM, Pascal Thubert (pthubert) <pthubert@cisco.co=
m> wrote:
>>=20
>>=20
>> FYI, it will break nothing since there is no assumption in the Internet =
that the flow label will be carried unchanged. Consistently, there is no na=
tive way to secure the flow label to make sure it was not tempered with (IO=
W it is not protected by ULP checksums, IPSec AH or ESP transport mode).=20
>>=20
>> The last call at 6MAN is where I expect problems with the use of the flo=
w label field in this draft to be pointed at. I'm happy to report that ther=
e was no trace of bigotry there, all the contrary. 6MAN will confirm whethe=
r this draft conforms the spirit of the existing RFCs and so far I gathered=
, from all but you, that it does
>=20
> Pascal, I don't think this is a question of spirit or anything. I mean, I=
'll repeat, 6437 states
>=20
> "A forwarding node MUST either leave a non-zero flow label value unchange=
d or change it only for compelling operational security reasons as describe=
d in Section 6.1."
>=20
> If the point is that experience and use and the spirit of the flow label =
has changed from this MUST, then we should explicitly state so. I'm not arg=
uing that the above prescription is right; but it's what's written. What wo=
rries me is the idea of directly contradicting the text of a prior RFC (the=
 one explicitly on flow labels, no less), without correspondingly obsoletin=
g that RFC. This isn't a SHOULD. It's a MUST!
>=20
> I've always thought that using the flow label in this way within an LLN i=
s a good idea. The problem is that you can't do so without violating a MUST=
 in the RFC that specifies how flow labels are used. It sounds like the let=
ter of that document doesn't match the spirit of it -- so let's fix the let=
ter, so it says what was intended! Why is there such recalcitrance to do so=
? Or provide any quantitative basis for the claims of battery power? You've=
 been proposing this for nearly 4 years now...
>=20
> I personally see two reasonable ways forward:
>=20
> 1) (As Carsten mentioned) Update 6437 to embrace these new and valuable u=
ses of the flow label.
>=20
> 2) Provide evidence that using the flow label in this way would provide s=
ignificant enough gains that violating a MUST in the RFC specifying the flo=
w label is worth it.
>=20
> It seems like you're advocating a third:
>=20
> 3) Violate a MUST in the RFC specifying how the flow label is used withou=
t any evidence that the actual energy savings are significant.
>=20
> As for what I'm trying to achieve, that's pretty simple. I think it's a t=
errible mistake for a standards body as important as the IETF to rely on th=
e spirit of the standard rather than the letter of the standard, especially=
 when they contradict. If you are one of the hundreds of thousands of netwo=
rk engineers and software developers who work in the Internet, you can't kn=
ow that a bunch of people in a meeting decided that the spirit of a specifi=
cation differs from its text. All you have to go on is the text. When the f=
ounder of the next YouTube or Instagram or Google or Nicira takes my class =
and I ask them to write their code to follow an RFC (which I currently do),=
 what should I tell them MUST means?
>=20
> Phil


From nobody Fri Aug  1 23:02:39 2014
Return-Path: <pal@cs.stanford.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179C91B2901; Fri,  1 Aug 2014 23:02:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 Kyjw9tq6FDD0; Fri,  1 Aug 2014 23:02:22 -0700 (PDT)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 979831B28FC; Fri,  1 Aug 2014 23:02:19 -0700 (PDT)
Received: from [76.14.66.110] (port=58043 helo=[192.168.0.103]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XDSOY-0003Nm-NU; Fri, 01 Aug 2014 23:02:19 -0700
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <C17BE08C-E179-472D-A349-B6CB8ADDCDF5@cisco.com>
Date: Fri, 1 Aug 2014 23:02:17 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <2A7F73B7-FCDC-44C6-99A5-FBA0EBFBC27D@cs.stanford.edu>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D04850@xmb-rcd-x01.cisco.com>, <09EC423F-FC09-495D-9B48-0DABFA4C19F6@cs.stanford.edu> <C17BE08C-E179-472D-A349-B6CB8ADDCDF5@cisco.com>
To: Pascal Thubert (pthubert) <pthubert@cisco.com>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 2e2010fe0da008b9f5e122b86dc99621
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Dn5v8qaJyB8nNxDO0yB0HpxX5xQ
Cc: roll Lossy networks <roll@ietf.org>, ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Aug 2014 06:02:26 -0000

On Aug 1, 2014, at 1:27 PM, Pascal Thubert (pthubert) =
<pthubert@cisco.com> wrote:

> Phil,
>=20
> Though I attended the discussions and have a clear reading of this =
work I'll certainly defer to Brian on whether there is a violation or =
not.=20
>=20
> OTOH you need to understand that there is no need for a bis to update =
a MUST in an RFC. We recognize the imperfection in our work and are =
always ready to revise and amend after due consideration.
>=20
> This process takes is another RFC and best judgement from the original =
group that the new text is indeed valuable and not breaking the original =
objectives.
>=20
> We are going through that process.


If the proposal is to have an Updates: 6437 (such that someone looking =
up 6437 will see a forward reference and know there's an update), I'm =
all in favor! That seems entirely reasonable. In that way, as I've =
always said, I think using the flow label is an excellent solution. I =
just also think doing so is significant in the context of 6437 and so =
should correctly acknowledge so. Someone reading 6437 should be able to =
easily learn there's another exception. It seems like an Updates: would =
do that well.=20

That being said, I don't think the energy claims in the current document =
will hold up to much experimental scrutiny or actual network =
measurements. Xavier's back-of-the-envelope calculations don't include =
preambles, slot padding, or idle listening. TSCH is nice in that it has =
much lower idle listening costs than ad-hoc algorithms, but they are far =
from zero. Reducing overhead is valuable due to the corresponding =
increase in MSS and reduced memory pressure: the energy argument is a =
red herring.

Phil


From nobody Sat Aug  2 12:09:11 2014
Return-Path: <mcr@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D97F1B28B2; Sat,  2 Aug 2014 12:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Level: 
X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
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 2HS6w4SB__gq; Sat,  2 Aug 2014 12:09:01 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DA751B28CE; Sat,  2 Aug 2014 12:08:58 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A6B3D20012; Sat,  2 Aug 2014 15:11:12 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 5FCEA638D9; Sat,  2 Aug 2014 15:08:55 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 46F1D638D7; Sat,  2 Aug 2014 15:08:55 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "ipv6\@ietf.org" <ipv6@ietf.org>, roll <roll@ietf.org>
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
In-Reply-To: <C17BE08C-E179-472D-A349-B6CB8ADDCDF5@cisco.com>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D04850@xmb-rcd-x01.cisco.com>, <09EC423F-FC09-495D-9B48-0DABFA4C19F6@cs.stanford.edu> <C17BE08C-E179-472D-A349-B6CB8ADDCDF5@cisco.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Sat, 02 Aug 2014 15:08:55 -0400
Message-ID: <3211.1407006535@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/B92l9WrUuq6RmsHPLtW76PgGSdo
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Aug 2014 19:09:09 -0000

--=-=-=


Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
    > OTOH you need to understand that there is no need for a bis to update a
    > MUST in an RFC. We recognize the imperfection in our work and are
    > always ready to revise and amend after due consideration.

Perhaps this document UPDATES 6437 then?

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBU903QoCLcPvd0N1lAQJAzwgAuxOtt18r18lpLJhN5hF6VUbQ3nlCWu7I
hssUIKYU/RCBzAAoAwd2/jIZXydsgknyRMmvucJKJC8XN6hRBgTfRXOg+70qF8y0
3H8/c0QMLSSmGEoh1C/bAw3uaTemX4POOdras3jXyTJpsNgCROAlA7VOiu9KRdNQ
/UgY38nKKze/YDgadtFzD5Ch4a20OfNY0HnlM14Keaz26AywClxOXW77xJGnvtb3
rY+B06c0TILvmzvf3tHezy6tSCN7pp6nmfaIiU/uINTXjvFqTnD83F1ImHyf0Mq7
1sWxg2M8cTRfRlRJYsdEXmr6VfMzmmAN+jbuTS1CUsDM8fm8rgfYXw==
=ojCE
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Sat Aug  2 12:23:20 2014
Return-Path: <mcr@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1861B295C; Sat,  2 Aug 2014 12:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Level: 
X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
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 tMgDFGlzeZyy; Sat,  2 Aug 2014 12:23:15 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D44A31B295A; Sat,  2 Aug 2014 12:23:14 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D86A520012; Sat,  2 Aug 2014 15:25:29 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 6B5CD638D9; Sat,  2 Aug 2014 15:23:13 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 521E7638D7; Sat,  2 Aug 2014 15:23:13 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "ipv6\@ietf.org" <ipv6@ietf.org>, roll@ietf.org
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
In-Reply-To: <B80833DA-CF92-4F84-91FA-A45A74B4D03D@cs.stanford.edu>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <53DB675C.9000502@tm.uka.de> <CAMsDxWTGG1MMaYPTcQqsBb78GuzsPun_k7r6Qi29fELp=z-mKA@mail.gmail.com> <53DB88B7.80205@tm.uka.de> <CAMsDxWROddNcfcWATpr4wmM+iMGhn4xMGO77f6hGvmRB9+Ow6g@mail.gmail.com> <B80833DA-CF92-4F84-91FA-A45A74B4D03D@cs.stanford.edu>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Sat, 02 Aug 2014 15:23:13 -0400
Message-ID: <6439.1407007393@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/OiPJ_vfEHgEcNkNw7VFMy_pbwfo
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Aug 2014 19:23:16 -0000

--=-=-=


Philip Levis <pal@cs.stanford.edu> wrote:
    > The paper is very helpful, thanks! Can you comment on what is a typical
    > idle slot configuration in a TiSCH network? Can you provide some
    > insight on what fraction of energy is spent in data communication
    > versus control and idle listening?

Here is a recent post with some real numbers:
  https://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY
it concerns diet-ESP, but the numbers are correct.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBU906nYCLcPvd0N1lAQIfjgf/e5tNGcSKP2vG6y3yCVtQ/3N6VRfQ92/j
6la/iEomMdjJH7ncdMcvx3b++YrfaIQCb3Wh7JURecOghW9zy4nzvzltfDAb59CQ
nFFM+wcM7YqtpmbVHbjrgDmBlJQVvcqUHuZcXy+xbwWKYcr5yaepS+smQBFKtjzE
sliyGkFjH51iFkduGli+/jr9Hmh4DGSXwVd9MwpKQbYOq3QGQJ42p9/je75tRZyT
N5I+6QHpi/tIWgx+6MmFQ7bYYzUPxKCyLRS0K6cxfxu1CQoNdMysUysEqR9Dt6WB
b4YEO0Fnf3r/5u2J/Z9ZuCD61uE1JA/GgWiWaa30/RwaEzxNqqt2gw==
=F9ZH
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Sat Aug  2 13:48:59 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D231B2997; Sat,  2 Aug 2014 13:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 tE6lGiINojd1; Sat,  2 Aug 2014 13:48:52 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5921B2996; Sat,  2 Aug 2014 13:48:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1019; q=dns/txt; s=iport; t=1407012532; x=1408222132; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TQKh1eu/EmtaeFSuCylW2b+tPv5W3oh+yBYq/wS723w=; b=lcxbc6/3j369RbCCHXYoIh7lJnumi//u9r2vTFng0Geebif6eCVurQ/y g7sqHCcHoEculFxQbHXPcXsrmHwhtJTJbmejZ72pa0e5+Q/lziKvNS9Ni 4dcKJEWrMKdpE4QYmDpWcueXf9PYwGUBofhKpjzT82U/CwAXGQG5jVEm8 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FAKVN3VOtJA2F/2dsb2JhbABagmojUlfMDwqHTAGBBRZ3hAMBAQEDAQEBAWsLBQsCAQgYLicLJQIEDgWIOggBDMZWEwSPGTMHgy+BHAWKVZExlF+DTWw
X-IronPort-AV: E=Sophos;i="5.01,787,1400025600"; d="scan'208";a="66067890"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP; 02 Aug 2014 20:48:50 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s72KmoM2029355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Aug 2014 20:48:50 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Sat, 2 Aug 2014 15:48:49 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPrai33Dn9icet106HlaTIaH7gh5u8MoZegAHQY4D//8gYNw==
Date: Sat, 2 Aug 2014 20:48:49 +0000
Message-ID: <C6FECB27-1A70-4AF7-B4BE-2218B0344C3F@cisco.com>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D04850@xmb-rcd-x01.cisco.com>, <09EC423F-FC09-495D-9B48-0DABFA4C19F6@cs.stanford.edu> <C17BE08C-E179-472D-A349-B6CB8ADDCDF5@cisco.com>, <3211.1407006535@sandelman.ca>
In-Reply-To: <3211.1407006535@sandelman.ca>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/DU70RLv3fidzniXA2IeVfkodQ30
Cc: roll <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Aug 2014 20:48:57 -0000

That sounds right, Michael, though slightly on the overkill side.  And this=
 is consistent with what Brian suggested. This can be added during the rfc =
editor process I expect?

Pascal

> Le 2 ao=FBt 2014 =E0 21:09, "Michael Richardson" <mcr+ietf@sandelman.ca> =
a =E9crit :
>=20
>=20
> Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>> OTOH you need to understand that there is no need for a bis to update a
>> MUST in an RFC. We recognize the imperfection in our work and are
>> always ready to revise and amend after due consideration.
>=20
> Perhaps this document UPDATES 6437 then?
>=20
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -=3D IPv6 IoT consulting =3D-
>=20
>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Sat Aug  2 13:56:43 2014
Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5201B29A7; Sat,  2 Aug 2014 13:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham
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 9GNeIqg_xcUc; Sat,  2 Aug 2014 13:56:40 -0700 (PDT)
Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30A421B29A2; Sat,  2 Aug 2014 13:56:40 -0700 (PDT)
Received: by mail-qa0-f46.google.com with SMTP id v10so5352479qac.5 for <multiple recipients>; Sat, 02 Aug 2014 13:56:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6dmX27P7oPeXR3Xuakm7AqBZBpkaDo0yg55z08VUPOc=; b=xOvohFOZQb+4iB7MOnoItGsHZuc/WrBlYtqGi0PFF/ZVGUPw72RjtOr4XvN2gU3seJ glJVBw00+RMiMt3Drrj6BcIgpreMdU38En8zMKkTfXbjZ4Wia5A5UJaFQKK6ngzRDLcC BVgHhOV8dLVCEfYa6KaA75r5ma994SQf0Aponkr8V8/mT5kTI8xPa/bCx2nCko+ymazc LB5DwIsOswB/OGavHT18aSRmSu1mLxXsnh0SR2tDQXbey+wvOxdduGsjdTAaioo/LvMI 1apsqC7Zbk9By8m4VikBGZW1AnnSlFY/EmEUEZL/eXFt+hvwTIgYu+ikYFxFB3vEL7oC jaZA==
X-Received: by 10.140.94.70 with SMTP id f64mr21051974qge.64.1407012998981; Sat, 02 Aug 2014 13:56:38 -0700 (PDT)
Received: from ?IPv6:2601:6:6780:636:f96f:9ecd:5aaa:13b2? ([2601:6:6780:636:f96f:9ecd:5aaa:13b2]) by mx.google.com with ESMTPSA id o89sm13796116qgo.1.2014.08.02.13.56.37 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Aug 2014 13:56:37 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-B614815F-7F8B-43E7-995E-AC221C0662B2
Mime-Version: 1.0 (1.0)
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Ralph Droms <rdroms.ietf@gmail.com>
X-Mailer: iPad Mail (11D257)
In-Reply-To: <C6FECB27-1A70-4AF7-B4BE-2218B0344C3F@cisco.com>
Date: Sat, 2 Aug 2014 16:56:36 -0400
Content-Transfer-Encoding: 7bit
Message-Id: <2F2D5FEA-51E0-4F04-8A54-2493ECB73757@gmail.com>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D04850@xmb-rcd-x01.cisco.com> <09EC423F-FC09-495D-9B48-0DABFA4C19F6@cs.stanford.edu> <C17BE08C-E179-472D-A349-B6CB8ADDCDF5@cisco.com> <3211.1407006535@sandelman.ca> <C6FECB27-1A70-4AF7-B4BE-2218B0344C3F@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/5PuQ9yhUYgvcsQ6yuJFoiEdd5Ts
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Aug 2014 20:56:42 -0000

--Apple-Mail-B614815F-7F8B-43E7-995E-AC221C0662B2
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable



> On Aug 2, 2014, at 4:48 PM, "Pascal Thubert (pthubert)" <pthubert@cisco.co=
m> wrote:
>=20
> That sounds right, Michael,

I agree that "updates 6437" is a right thing to do.

> though slightly on the overkill side.

I disagree that it is overkill.  In my opinion, draft-thubert-6man-flow-labe=
l-for-RPL pretty clearly contradicts RFC 6437, so "updates 6437" is an appro=
priate action.

>  And this is consistent with what Brian suggested. This can be added durin=
g the rfc editor process I expect?

It should be added as soon as possible, certainly before it goes to the IESG=
.  In my opinion, the change might warrant a new or extended WGLC; that acti=
on is up to the chairs, of course.

- Ralph

>=20
> Pascal
>=20
>> Le 2 ao=C3=BBt 2014 =C3=A0 21:09, "Michael Richardson" <mcr+ietf@sandelma=
n.ca> a =C3=A9crit :
>>=20
>>=20
>> Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>>> OTOH you need to understand that there is no need for a bis to update a
>>> MUST in an RFC. We recognize the imperfection in our work and are
>>> always ready to revise and amend after due consideration.
>>=20
>> Perhaps this document UPDATES 6437 then?
>>=20
>> --
>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>> -=3D IPv6 IoT consulting =3D-
>>=20
>>=20
>>=20
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

--Apple-Mail-B614815F-7F8B-43E7-995E-AC221C0662B2
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div><br></div><div><br>On Aug 2, 2014, at 4=
:48 PM, "Pascal Thubert (pthubert)" &lt;<a href=3D"mailto:pthubert@cisco.com=
">pthubert@cisco.com</a>&gt; wrote:<br><br></div><blockquote type=3D"cite"><=
div><span>That sounds right, Michael, </span></div></blockquote><div><br></d=
iv>I agree that "updates 6437" is a right thing to do.<div><br><blockquote t=
ype=3D"cite"><div><span>though slightly on the overkill side. </span></div><=
/blockquote><div><br></div>I disagree that it is overkill. &nbsp;In my opini=
on,&nbsp;<span style=3D"font-size: 12pt; font-family: Helvetica;">draft-thub=
ert-6man-flow-label-for-RPL pretty clearly contradicts RFC 6437, so&nbsp;</s=
pan>"updates 6437" is an appropriate action.</div><div><br><blockquote type=3D=
"cite"><div><span>&nbsp;And this is consistent with what Brian suggested. Th=
is can be added during the rfc editor process I expect?</span><br></div></bl=
ockquote><div><br></div>It should be added as soon as possible, certainly be=
fore it goes to the IESG. &nbsp;In my opinion, the change might warrant a ne=
w or extended WGLC; that action is up to the chairs, of course.</div><div><b=
r></div><div>- Ralph</div><div><br><blockquote type=3D"cite"><div><span></sp=
an><br><span>Pascal</span><br><span></span><br><blockquote type=3D"cite"><sp=
an>Le 2 ao=C3=BBt 2014 =C3=A0 21:09, "Michael Richardson" &lt;<a href=3D"mai=
lto:mcr+ietf@sandelman.ca">mcr+ietf@sandelman.ca</a>&gt; a =C3=A9crit :</spa=
n><br></blockquote><blockquote type=3D"cite"><span></span><br></blockquote><=
blockquote type=3D"cite"><span></span><br></blockquote><blockquote type=3D"c=
ite"><span>Pascal Thubert (pthubert) &lt;<a href=3D"mailto:pthubert@cisco.co=
m">pthubert@cisco.com</a>&gt; wrote:</span><br></blockquote><blockquote type=
=3D"cite"><blockquote type=3D"cite"><span>OTOH you need to understand that t=
here is no need for a bis to update a</span><br></blockquote></blockquote><b=
lockquote type=3D"cite"><blockquote type=3D"cite"><span>MUST in an RFC. We r=
ecognize the imperfection in our work and are</span><br></blockquote></block=
quote><blockquote type=3D"cite"><blockquote type=3D"cite"><span>always ready=
 to revise and amend after due consideration.</span><br></blockquote></block=
quote><blockquote type=3D"cite"><span></span><br></blockquote><blockquote ty=
pe=3D"cite"><span>Perhaps this document UPDATES 6437 then?</span><br></block=
quote><blockquote type=3D"cite"><span></span><br></blockquote><blockquote ty=
pe=3D"cite"><span>--</span><br></blockquote><blockquote type=3D"cite"><span>=
Michael Richardson &lt;<a href=3D"mailto:mcr+IETF@sandelman.ca">mcr+IETF@san=
delman.ca</a>&gt;, Sandelman Software Works</span><br></blockquote><blockquo=
te type=3D"cite"><span>-=3D IPv6 IoT consulting =3D-</span><br></blockquote>=
<blockquote type=3D"cite"><span></span><br></blockquote><blockquote type=3D"=
cite"><span></span><br></blockquote><blockquote type=3D"cite"><span></span><=
br></blockquote><blockquote type=3D"cite"><span>----------------------------=
----------------------------------------</span><br></blockquote><blockquote t=
ype=3D"cite"><span>IETF IPv6 working group mailing list</span><br></blockquo=
te><blockquote type=3D"cite"><span><a href=3D"mailto:ipv6@ietf.org">ipv6@iet=
f.org</a></span><br></blockquote><blockquote type=3D"cite"><span>Administrat=
ive Requests: <a href=3D"https://www.ietf.org/mailman/listinfo/ipv6">https:/=
/www.ietf.org/mailman/listinfo/ipv6</a></span><br></blockquote><blockquote t=
ype=3D"cite"><span>---------------------------------------------------------=
-----------</span><br></blockquote><span></span><br><span>__________________=
_____________________________</span><br><span>Roll mailing list</span><br><s=
pan><a href=3D"mailto:Roll@ietf.org">Roll@ietf.org</a></span><br><span><a hr=
ef=3D"https://www.ietf.org/mailman/listinfo/roll">https://www.ietf.org/mailm=
an/listinfo/roll</a></span><br></div></blockquote></div></body></html>=

--Apple-Mail-B614815F-7F8B-43E7-995E-AC221C0662B2--


From nobody Sat Aug  2 14:41:16 2014
Return-Path: <pal@cs.stanford.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF6C1B29CB; Sat,  2 Aug 2014 14:41:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.302
X-Spam-Level: 
X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=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 99jRnVlc69u2; Sat,  2 Aug 2014 14:41:14 -0700 (PDT)
Received: from smtp2.cs.Stanford.EDU (smtp2.cs.Stanford.EDU [171.64.64.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F0A1B29DB; Sat,  2 Aug 2014 14:41:14 -0700 (PDT)
Received: from [76.14.66.110] (port=61141 helo=[192.168.0.103]) by smtp2.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XDh3A-0007pH-7T; Sat, 02 Aug 2014 14:41:14 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <6439.1407007393@sandelman.ca>
Date: Sat, 2 Aug 2014 14:41:12 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <06C4F090-4731-4917-84F1-7C5798574F42@cs.stanford.edu>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <53DB675C.9000502@tm.uka.de> <CAMsDxWTGG1MMaYPTcQqsBb78GuzsPun_k7r6Qi29fELp=z-mKA@mail.gmail.com> <53DB88B7.80205@tm.uka.de> <CAMsDxWROddNcfcWATpr4wmM+iMGhn4xMGO77f6hGvmRB9+Ow6g@mail.gmail.com> <B80833DA-CF92-4F84-91FA-A45A74B4D03D@cs.stanford.edu> <6439.1407007393@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 127ff6e1eac6b45a32dc112250ed777d
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/cEhS3sZfuMLbgSIBFy96VzBnwNk
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Aug 2014 21:41:15 -0000

On Aug 2, 2014, at 12:23 PM, Michael Richardson <mcr+ietf@sandelman.ca> =
wrote:

>=20
> Philip Levis <pal@cs.stanford.edu> wrote:
>> The paper is very helpful, thanks! Can you comment on what is a =
typical
>> idle slot configuration in a TiSCH network? Can you provide some
>> insight on what fraction of energy is spent in data communication
>> versus control and idle listening?
>=20
> Here is a recent post with some real numbers:
>  =
https://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY
> it concerns diet-ESP, but the numbers are correct.

Michael,

I'm confused on what this email message is supposed to be providing: the =
energy cost of sending a bit? That's pretty simple to calculate. The =
tradeoff between CPU and network is also very well known, going back to =
Pottie's "Every bit transmitted brings a sensor node one moment closer =
to death." If you look at the behavior of most micro controller based =
devices, the MCU is insignificant -- and 95% of its energy is spent =
handling interrupts (per-byte, over an SPI bus) for the radio. Yes, =
unless you're doing something quite silly, the CPU cost of compression =
is almost always absolutely worth the benefit in terms of reduced =
transmission energy.

My question related to the fraction of radio energy in TSCH that is =
consumed by data transmission/reception versus everything else (idle =
listening, guard periods, control frames, etc.

To give you a data point -- early low-power link layers continually =
transmitted a packet (or wakeup frame) until receiving an =
acknowledgement from the intended receiver. Receivers periodically wake =
up, listen if there's energy on the channel, and if so, stay awake for 2 =
packet times (in case they woke up just after the preamble of a packet). =
If there's no coordination between receiver and sender, this means a =
sender must send on average for 1/2 of a wakeup interval to deliver a =
packet. E.g., 0.5s. Clearly in such a protocol a few extra bytes doesn't =
matter in terms of energy. Of course, TSCH is much, much better than =
this, I only mention this protocol as a simple explanatory example -- =
but what's the actual number?

Phil





From nobody Sat Aug  2 20:37:14 2014
Return-Path: <twatteyne@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C94D1A00ED; Sat,  2 Aug 2014 20:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.622
X-Spam-Level: **
X-Spam-Status: No, score=2.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FB_CIALIS_LEO3=3.899, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 pP8hnxkJxyPs; Sat,  2 Aug 2014 20:37:05 -0700 (PDT)
Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA80D1A00EA; Sat,  2 Aug 2014 20:37:04 -0700 (PDT)
Received: by mail-pd0-f173.google.com with SMTP id w10so7695384pde.4 for <multiple recipients>; Sat, 02 Aug 2014 20:37:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=cswJ6EWhfSEatvVaLn4TLLDysFyCRVAS/unDHT5MEYk=; b=E/mBRPsg/frVzFmhSFOXlb0QE3hsfCRpy+keeGAwOZ7k1TJOrcBI+C6Z4CmW2BTQOF DOVwLuFHJEhmlTnB3QG3lqHNrKtC7NmL69EqwvLjmUmW3PIneTQsGKOiiwrNMBl4OOHG 29kbNfnt7WOCWnOhAuom0Qo3tl3nOh+GVgLzT22i+DI+34spFJC2uJB0PCGZKPkZqwEP upUDRF32jV6jYxNDJLuaSS97ufwAk7jbwolZlYOzaZUM5lJybCzuzlXD8LwrRog1kTh5 ABvxDispjuC/HlsSyQOzH/JbT5t1rfEJmubRN0wRUStzQduUsSrrzGzFejf6PX3+03bJ w9Xw==
X-Received: by 10.68.68.207 with SMTP id y15mr16122177pbt.25.1407037024445; Sat, 02 Aug 2014 20:37:04 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.66.144.1 with HTTP; Sat, 2 Aug 2014 20:36:44 -0700 (PDT)
In-Reply-To: <06C4F090-4731-4917-84F1-7C5798574F42@cs.stanford.edu>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <53DB675C.9000502@tm.uka.de> <CAMsDxWTGG1MMaYPTcQqsBb78GuzsPun_k7r6Qi29fELp=z-mKA@mail.gmail.com> <53DB88B7.80205@tm.uka.de> <CAMsDxWROddNcfcWATpr4wmM+iMGhn4xMGO77f6hGvmRB9+Ow6g@mail.gmail.com> <B80833DA-CF92-4F84-91FA-A45A74B4D03D@cs.stanford.edu> <6439.1407007393@sandelman.ca> <06C4F090-4731-4917-84F1-7C5798574F42@cs.stanford.edu>
From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Sat, 2 Aug 2014 20:36:44 -0700
X-Google-Sender-Auth: odZ7zxR-YZSv4h907uuVZUeYPCo
Message-ID: <CADJ9OA_=FnuaaR_On_AJoqSVHfvUtcsxcM7WyLMR41AwQA5B-A@mail.gmail.com>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
To: Philip Levis <pal@cs.stanford.edu>
Content-Type: multipart/alternative; boundary=001a11381772072a7504ffb156ea
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/5nNH9PvLqv9x-al-5q6FCh5vCJM
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Aug 2014 03:37:07 -0000

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

Phil,

There are two parts in answering your question. Let me describe both, I
will then justify why the answer is "it depends".

*a single slot*

Let's consider for starters only a single TSCH slot: mote A sends a packet
to mote B, which replies with an ACK. This timeslot is depicted below
(borrowed from [1])


      /------------------- Time Slot duration --------------------/
      |                                        /tsShortGT/        |
      |            |                              | | |           |
      |------------+-----------------+--------------+------+------|
   TX |            |    TX-Packet    |              |RX Ack|      |
      |------------+-----------------+--------------+------+------|
      |/tsTxOffset/|                 |              |      |      |
      |            |                 |              |      |      |
      |------------+-----------------+--------------+------+------|
   RX |         |  |  | RX-Packet    |              |TX Ack|      |
      |---------+--+--+--------------+--------------+------+------|
      |         |  |  |              |              |      |      |
      |        /tsLongGT/            |/TsTxAckDelay/|      |      |
     Start                                                       End
      of                                                          of
     Slot                                                        Slot


Let's assume that the IEEE802.15.4 frame is 127B long, i.e. full length.
Let's assume, finally, that you are using the default 10ms timeslot
template from the IEEE802.15.4e-2012 standard [2] (Table 52e), no CCA. This
is the radio-on time on both A and B:

   - mote A
      - transmitting the data packet: 4256us
      - listening for ACK during the guard time (i.e. idle listening): 200us
      - receiving the ACK (~15B long): 480us
   - mote B:
      - listening for data during the guard time (i.e. idle listening):
      1000us
      - receiving data: 4256us
      - transmitting the ACK: 480us

>From an energy point of view, you also need to account for the time is
takes to switch the radio on/off and for the possible energy consumed
between the data and ack, in case the radio is kept in a state allowing it
to TX/RX fast. Good embedded engineers will reduce this overhead through
firmware and hardware wizardry.

Considering only time, the radio on-time budget can hence be cut into:

   - total: 10672us
   - transmission of data: 8512us (~80%)
   - desynchronization overhead (i.e. idle listening during guard time):
   1200us (~10%)
   - ACK overhead: 960us (~10%)

>From these numbers, you see that the actual data transmission accounts for
~80% of the radio-on time budget.

Of course, this timeslot template is the default one. If you are very good
at keeping synchronized, you might be able to shorten the guard times and
reduce the desynchronization overhead.

*full network*

Now the fun part.

In a TSCH network, the communication schedule indicates to every mote what
to do: transmit, listen or sleep. You can tune the TSCH communication
schedule any way you want. In fact, the 6TiSCH WG was created to define
mechanisms for centralized and distributed managements of this schedule.

Your goal should be to match the amount of bandwidth in your schedule (i.e.
the cells used for transmission and reception) to what is needed by the
network. If every cell you schedule is used, the single slot results from
above carry over to a full network. If, however, you schedule has too many
cells, some might be unused. In that case, the transmitter will keep its
radio off (i.e. consume no energy), while the receiver will have to listen
for a full guard time, or 2ms when using the default timeslot template.

So there you go: it depends. In the best possible case, the portion of
radio on-time spent of exchanging actual useful data can be very high
(80%+), but it's easy to mess things up, resulting in a large number of
over-provisioned cells.

For a (hopefully clear) overview of IEEE802.15.4e TSCH, take a look at
http://tools.ietf.org/html/draft-ietf-6tisch-tsch-01.

Thomas

[1] http://tools.ietf.org/html/draft-ietf-6tisch-minimal-02
[2] http://standards.ieee.org/getieee802/download/802.15.4e-2012.pdf


On Sat, Aug 2, 2014 at 2:41 PM, Philip Levis <pal@cs.stanford.edu> wrote:

> On Aug 2, 2014, at 12:23 PM, Michael Richardson <mcr+ietf@sandelman.ca>
> wrote:
>
> >
> > Philip Levis <pal@cs.stanford.edu> wrote:
> >> The paper is very helpful, thanks! Can you comment on what is a typical
> >> idle slot configuration in a TiSCH network? Can you provide some
> >> insight on what fraction of energy is spent in data communication
> >> versus control and idle listening?
> >
> > Here is a recent post with some real numbers:
> >  https://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY
> > it concerns diet-ESP, but the numbers are correct.
>
> Michael,
>
> I'm confused on what this email message is supposed to be providing: the
> energy cost of sending a bit? That's pretty simple to calculate. The
> tradeoff between CPU and network is also very well known, going back to
> Pottie's "Every bit transmitted brings a sensor node one moment closer to
> death." If you look at the behavior of most micro controller based devices,
> the MCU is insignificant -- and 95% of its energy is spent handling
> interrupts (per-byte, over an SPI bus) for the radio. Yes, unless you're
> doing something quite silly, the CPU cost of compression is almost always
> absolutely worth the benefit in terms of reduced transmission energy.
>
> My question related to the fraction of radio energy in TSCH that is
> consumed by data transmission/reception versus everything else (idle
> listening, guard periods, control frames, etc.
>
> To give you a data point -- early low-power link layers continually
> transmitted a packet (or wakeup frame) until receiving an acknowledgement
> from the intended receiver. Receivers periodically wake up, listen if
> there's energy on the channel, and if so, stay awake for 2 packet times (in
> case they woke up just after the preamble of a packet). If there's no
> coordination between receiver and sender, this means a sender must send on
> average for 1/2 of a wakeup interval to deliver a packet. E.g., 0.5s.
> Clearly in such a protocol a few extra bytes doesn't matter in terms of
> energy. Of course, TSCH is much, much better than this, I only mention this
> protocol as a simple explanatory example -- but what's the actual number?
>
> Phil
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

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

<div dir=3D"ltr">Phil,<div><br></div><div>There are two parts in answering =
your question. Let me describe both, I will then justify why the answer is =
&quot;it depends&quot;.</div><div><br></div><div><b><u>a single slot</u></b=
></div>

<div><br></div><div>Let&#39;s consider for starters only a single TSCH slot=
: mote A sends a packet to mote B, which replies with an ACK. This timeslot=
 is depicted below (borrowed from [1])</div><div><br></div><div><pre class=
=3D"" style=3D"font-size:1em;margin-top:0px;margin-bottom:0px;color:rgb(0,0=
,0)">

      /------------------- Time Slot duration --------------------/
      |                                        /tsShortGT/        |
      |            |                              | | |           |
      |------------+-----------------+--------------+------+------|
   TX |            |    TX-Packet    |              |RX Ack|      |
      |------------+-----------------+--------------+------+------|
      |/tsTxOffset/|                 |              |      |      |
      |            |                 |              |      |      |
      |------------+-----------------+--------------+------+------|
   RX |         |  |  | RX-Packet    |              |TX Ack|      |
      |---------+--+--+--------------+--------------+------+------|
      |         |  |  |              |              |      |      |
      |        /tsLongGT/            |/TsTxAckDelay/|      |      |
     Start                                                       End
      of                                                          of
     Slot                                                        Slot</pre>=
</div><div><br></div><div>Let&#39;s assume that the IEEE802.15.4 frame is 1=
27B long, i.e. full length. Let&#39;s assume, finally, that you are using t=
he default 10ms timeslot template from the IEEE802.15.4e-2012 standard [2] =
(Table 52e), no CCA. This is the radio-on time on both A and B:</div>

<div><ul><li>mote A</li><ul><li>transmitting the data packet: 4256us<br></l=
i><li>listening for ACK during the guard time (i.e. idle listening): 200us<=
/li><li>receiving the ACK (~15B long): 480us</li></ul><li>mote B:</li>
<ul>
<li>listening for data during the guard time (i.e. idle listening): 1000us<=
/li><li>receiving data:=C2=A04256us</li><li>transmitting the ACK: 480us</li=
></ul></ul></div><div>From an energy point of view, you also need to accoun=
t for the time is takes to switch the radio on/off and for the possible ene=
rgy consumed between the data and ack, in case the radio is kept in a state=
 allowing it to TX/RX fast. Good embedded engineers will reduce this overhe=
ad through firmware and hardware wizardry.</div>

<div><br></div><div>Considering only time, the radio on-time budget can hen=
ce be cut into:</div><div><ul><li>total: 10672us</li><li>transmission of da=
ta: 8512us (~80%)</li><li>desynchronization overhead (i.e. idle listening d=
uring guard time): 1200us (~10%)</li>

<li>ACK overhead: 960us=C2=A0(~10%)</li></ul><div>From these numbers, you s=
ee that the actual data transmission accounts for ~80% of the radio-on time=
 budget.</div><div><br></div><div>Of course, this timeslot template is the =
default one. If you are very good at keeping synchronized, you might be abl=
e to shorten the guard times and reduce the desynchronization overhead.</di=
v>

</div><div><br></div><div><b><u>full network</u></b></div><div><br></div><d=
iv>Now the fun part.</div><div><br></div><div>In a TSCH network, the commun=
ication schedule indicates to every mote what to do: transmit, listen or sl=
eep. You can tune the TSCH communication schedule any way you want. In fact=
, the 6TiSCH WG was created to define mechanisms for centralized and distri=
buted managements of this schedule.</div>

<div><br></div><div>Your goal should be to match the amount of bandwidth in=
 your schedule (i.e. the cells used for transmission and reception) to what=
 is needed by the network. If every cell you schedule is used, the single s=
lot results from above carry over to a full network. If, however, you sched=
ule has too many cells, some might be unused. In that case, the transmitter=
 will keep its radio off (i.e. consume no energy), while the receiver will =
have to listen for a full guard time, or 2ms when using the default timeslo=
t template.</div>

<div><br></div><div>So there you go: it depends. In the best possible case,=
 the portion of radio on-time spent of exchanging actual useful data can be=
 very high (80%+), but it&#39;s easy to mess things up, resulting in a larg=
e number of over-provisioned cells.</div>

<div><br></div><div>For a (hopefully clear) overview of IEEE802.15.4e TSCH,=
 take a look at=C2=A0<a href=3D"http://tools.ietf.org/html/draft-ietf-6tisc=
h-tsch-01">http://tools.ietf.org/html/draft-ietf-6tisch-tsch-01</a>.</div><=
div>

<br></div><div>Thomas</div><div><br></div><div>[1]=C2=A0<a href=3D"http://t=
ools.ietf.org/html/draft-ietf-6tisch-minimal-02">http://tools.ietf.org/html=
/draft-ietf-6tisch-minimal-02</a></div><div>[2]=C2=A0<a href=3D"http://stan=
dards.ieee.org/getieee802/download/802.15.4e-2012.pdf">http://standards.iee=
e.org/getieee802/download/802.15.4e-2012.pdf</a></div>

</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat,=
 Aug 2, 2014 at 2:41 PM, Philip Levis <span dir=3D"ltr">&lt;<a href=3D"mail=
to:pal@cs.stanford.edu" target=3D"_blank">pal@cs.stanford.edu</a>&gt;</span=
> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On Aug 2, 2014, at 12:23 PM,=
 Michael Richardson &lt;<a href=3D"mailto:mcr%2Bietf@sandelman.ca">mcr+ietf=
@sandelman.ca</a>&gt; wrote:<br>


<br>
&gt;<br>
&gt; Philip Levis &lt;<a href=3D"mailto:pal@cs.stanford.edu">pal@cs.stanfor=
d.edu</a>&gt; wrote:<br>
&gt;&gt; The paper is very helpful, thanks! Can you comment on what is a ty=
pical<br>
&gt;&gt; idle slot configuration in a TiSCH network? Can you provide some<b=
r>
&gt;&gt; insight on what fraction of energy is spent in data communication<=
br>
&gt;&gt; versus control and idle listening?<br>
&gt;<br>
&gt; Here is a recent post with some real numbers:<br>
&gt; =C2=A0<a href=3D"https://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-=
84AjZGB_RMyhqOPucY" target=3D"_blank">https://mailarchive.ietf.org/arch/msg=
/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY</a><br>
&gt; it concerns diet-ESP, but the numbers are correct.<br>
<br>
</div>Michael,<br>
<br>
I&#39;m confused on what this email message is supposed to be providing: th=
e energy cost of sending a bit? That&#39;s pretty simple to calculate. The =
tradeoff between CPU and network is also very well known, going back to Pot=
tie&#39;s &quot;Every bit transmitted brings a sensor node one moment close=
r to death.&quot; If you look at the behavior of most micro controller base=
d devices, the MCU is insignificant -- and 95% of its energy is spent handl=
ing interrupts (per-byte, over an SPI bus) for the radio. Yes, unless you&#=
39;re doing something quite silly, the CPU cost of compression is almost al=
ways absolutely worth the benefit in terms of reduced transmission energy.<=
br>


<br>
My question related to the fraction of radio energy in TSCH that is consume=
d by data transmission/reception versus everything else (idle listening, gu=
ard periods, control frames, etc.<br>
<br>
To give you a data point -- early low-power link layers continually transmi=
tted a packet (or wakeup frame) until receiving an acknowledgement from the=
 intended receiver. Receivers periodically wake up, listen if there&#39;s e=
nergy on the channel, and if so, stay awake for 2 packet times (in case the=
y woke up just after the preamble of a packet). If there&#39;s no coordinat=
ion between receiver and sender, this means a sender must send on average f=
or 1/2 of a wakeup interval to deliver a packet. E.g., 0.5s. Clearly in suc=
h a protocol a few extra bytes doesn&#39;t matter in terms of energy. Of co=
urse, TSCH is much, much better than this, I only mention this protocol as =
a simple explanatory example -- but what&#39;s the actual number?<br>


<br>
Phil<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
<br>
--------------------------------------------------------------------<br>
IETF IPv6 working group mailing list<br>
<a href=3D"mailto:ipv6@ietf.org">ipv6@ietf.org</a><br>
Administrative Requests: <a href=3D"https://www.ietf.org/mailman/listinfo/i=
pv6" target=3D"_blank">https://www.ietf.org/mailman/listinfo/ipv6</a><br>
--------------------------------------------------------------------<br>
</div></div></blockquote></div><br></div>

--001a11381772072a7504ffb156ea--


From nobody Sat Aug  2 21:38:53 2014
Return-Path: <slblake@petri-meat.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5041A0149 for <ipv6@ietfa.amsl.com>; Sat,  2 Aug 2014 21:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham
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 bnBxq1vfGyWc for <ipv6@ietfa.amsl.com>; Sat,  2 Aug 2014 21:38:46 -0700 (PDT)
Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 171D01A014A for <ipv6@ietf.org>; Sat,  2 Aug 2014 21:38:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=petri-meat.com; s=default;  h=Content-Transfer-Encoding:Mime-Version:Content-Type:References:In-Reply-To:Date:To:From:Subject:Message-ID; bh=Rp/JUcdPwUxRRTHQ9cq7rm5qFAzetjOBnH+symJf9AA=;  b=TQSLR+VMyITakgpfU30Y4NP/4qO0E+C4ii58Xp02MdEIdQfV7lxjsVOr1e8dxewjTYiwX5uXBroyOXdA0+EnV0O6ua41dN95Z+2gskYIckPoVl4rjDIOLjbexqUYu6nO;
Received: from cpe-098-027-048-172.nc.res.rr.com ([98.27.48.172]:44954 helo=[192.168.144.57]) by elom.tchmachines.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from <slblake@petri-meat.com>) id 1XDnZD-0005CJ-Gk for ipv6@ietf.org; Sun, 03 Aug 2014 00:38:43 -0400
Message-ID: <1407040724.26409.35.camel@tachyon.blake>
Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-why64-01.txt>
From: Steven Blake <slblake@petri-meat.com>
To: 6man WG <ipv6@ietf.org>
Date: Sun, 03 Aug 2014 00:38:44 -0400
In-Reply-To: <BB9B7724-CE31-47E9-9A23-F51B4FF6E028@employees.org>
References: <125059BB-7FBD-4701-A179-54C412617FB4@gmail.com> <BB9B7724-CE31-47E9-9A23-F51B4FF6E028@employees.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - elom.tchmachines.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - petri-meat.com
X-Get-Message-Sender-Via: elom.tchmachines.com: authenticated_id: slblake+petri-meat.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/xpLyTLybtG37G1TUpm6JGWw-SlM
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Aug 2014 04:38:50 -0000

I have reviewed draft-ietf-6man-why64-01.txt, and, modulo a few nits, I
think it is ready for publication.
 
The document endeavors to list the advantages of a fixed-size IID (Sec.
2), and to identify many of the issue which would arise if
variable-sized IIDs were allowed (Sec. 4).  I think it accomplishes
both.  Further, it is thorough in identifying many of the places in the
IPv6 specifications where a fixed-sized 64-bit IID is baked in (Secs. 1,
2, & 4).

In addition to the above, I believe the document does a good job of
defending 64 bits as a reasonable IID size (Secs. 3 & 5).

Comments:

Sec. 3.1: To elaborate, using a conservative HD-ratio = 0.94 (RFC4692),
there are ~5 trillion /48 prefixes available for allocation under
2000::/3.  ~1 trillion /48s are available with a relaxed HD-ratio =
0.89.  "There is no objective risk" indeed.

In cases where providers may not allocate sufficient space to number all
of a site's subnets with /64 prefixes, enabling the site to operate with
> /64 subnet prefixes (e.g., smaller IIDs) will not solve the problem in
the long run; such providers are likely to start allocating even less
address space to sites.  This would be an instance of a
social/commercial problem, not a technical one.

Sec. 3.2: If a campus site or enterprise gets a /48 allocation (or
shorter), then that provides quite a bit of space for hierarchical
allocation.  Compare to IPv4, where an organization with a /8 allocation
(e.g, Apple, AT&T, DOD, GE, HP, IBM, etc.) and with /24 subnets has the
same 16 bits for internal hierarchical allocation.

Sec. 4.2: CGA: "has defined a detailed algorithm how to generate"
                                                ^for

          ILNP: ILNP has Node Identifiers (RFC6741), not interface
identifiers.  The Node Identifiers are encoded in the IID field.


Regards,

// Steve


From nobody Sun Aug  3 10:25:00 2014
Return-Path: <xvilajosana@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A7C1A0AF5 for <ipv6@ietfa.amsl.com>; Sun,  3 Aug 2014 10:24:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 O32FudvSX7V9 for <ipv6@ietfa.amsl.com>; Sun,  3 Aug 2014 10:24:56 -0700 (PDT)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807081A0AEA for <ipv6@ietf.org>; Sun,  3 Aug 2014 10:24:56 -0700 (PDT)
Received: by mail-ig0-f174.google.com with SMTP id c1so4106432igq.13 for <ipv6@ietf.org>; Sun, 03 Aug 2014 10:24:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Bb47HUnlO+xZ/FfeoXluTHjqKjmAizzLbM5u3rk+gec=; b=r8LeBJmwIMm89pBZ6SMkmq18rMhsU37SqFCjqMZErHOA3xv2OvE4Jyj9crdgr+0JT/ Yi7zeCEMF1rlE3u8FwGHVlhbI7eDzz6muyJpDmOUk1cbNe/Qt1Gwmi2RlyOk1iQE7IBN P5ZVs7f5Z6m5B/VaHoQ4oSvirII1Bj+3Cg5L5Ym2WoRHokEQaLmdnQEiLKmPv+OROIcc qruA6zM06+7k/wOlL3/t7qHJ0Zl9sIp3F8hP3BjHJoR5ZbggawwIhilcS0gJwDb3dmH7 7I2QZ3+Zbb8zBYtvAk7NCrXOu0g4dpFgyjU1CZCZG7rbX70yFwe1icS8pMlptXbJizCa +zwg==
MIME-Version: 1.0
X-Received: by 10.50.111.167 with SMTP id ij7mr28647284igb.49.1407086695618; Sun, 03 Aug 2014 10:24:55 -0700 (PDT)
Sender: xvilajosana@gmail.com
Received: by 10.64.129.198 with HTTP; Sun, 3 Aug 2014 10:24:55 -0700 (PDT)
In-Reply-To: <544B6184-72FE-42B2-AAA4-DF44D0E1BD5A@cs.stanford.edu>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <53DB675C.9000502@tm.uka.de> <CAMsDxWTGG1MMaYPTcQqsBb78GuzsPun_k7r6Qi29fELp=z-mKA@mail.gmail.com> <544B6184-72FE-42B2-AAA4-DF44D0E1BD5A@cs.stanford.edu>
Date: Sun, 3 Aug 2014 19:24:55 +0200
X-Google-Sender-Auth: W10XmeOcNwhDZGkKv4PT_K8zvZk
Message-ID: <CAMsDxWQOSgy42DpSoiL3EVNjukpad6WPBXFNHRfsJVvYwaPJJg@mail.gmail.com>
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
To: Philip Levis <pal@cs.stanford.edu>
Content-Type: multipart/alternative; boundary=047d7b414478a920f904ffbce62f
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/U1TyohQ1rlpybKOeEqom-UcF_3w
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Aug 2014 17:24:59 -0000

--047d7b414478a920f904ffbce62f
Content-Type: text/plain; charset=UTF-8

Dear Phil,

let me answer this point (note that I do not want to enter in a very
detailed discussion):

This calculation seems a bit weird. If you're calculating both sides, then
the numerator *and* the denominator have both costs in them. It's either
 (1.04 * tx) + (1.04 * rx) / (tx + rx). So, 4%. How do you get 8%?

I've been not clear, sorry, you are right if the node is a leaf node or a
dagroot (it sends and the other receive, there are 2 batteries and each
battery saves 4%, so 4% in overall). However if a node is a relay, it
receives and sends to forward the packet, so the 5 bytes are saved 2 times,
one when receiving and one when sending to the next hop (all of that with
the same battery, so double saving at each side, no?).

Also, this seems to *only* consider receive/transmit time. I assume that
the radios are on for other periods of time (the overhead of the protocol)?
How does this factor in?

In TSCH the radios are only on for the duration of the packets to be
sent/receive + the duration of ACKs in case the packets are required to be
acknowledged. Packets can be beacon packets or data packets. Beacons are
control packets that can be sent infrequently depending on the network
configuration.

In 15.4e CSL, there is a short preamble sampling that enables nodes to
"agree" when the transmission will happen so they can turn off the radio
until that time, so the overhead preamble sampling is also small.

IMHO, we do not need to loose the focus of this discussion in the details,
there is an advantage of saving 5 bytes at each data packet. The question
is how do we get its value and how do we integrate that to the current
standards.

regards,
Xavi



2014-08-01 18:20 GMT+02:00 Philip Levis <pal@cs.stanford.edu>:

> On Aug 1, 2014, at 3:22 AM, Xavier Vilajosana <
> xvilajosana@eecs.berkeley.edu> wrote:
>
> > Hi Christian,
> >
> > Inline
> >
> > Hi,
> >
> > i am not sure i can follow your calculation. According to your paper
> > listening and receiving have the same costs for the RF231, transmitting
> > is a bit cheaper.
> >
> > Yes, tx is slightly cheaper than rx. Rx uses a guard time of ~1ms so
> radio is turned on a little bit before to cope with clock drifts. (note
> that nodes are synchronized)
> >
>
> Xavier is right -- this is commonly the case. In low-power wireless, the
> receive path often requires much more complex (digital) logic and the power
> costs of the amplifiers are similar. This is different than higher power
> networks, where the amplifier circuits dominate. E.g., take a look at a 4G
> eNodeB transmitting at 6W and it'll be drawing more than 100W, most of
> which goes into the final power amplifier (with a big heat sink on it).
>
> > Why do you conclude you are saving 8% energy ?! Also your duty-cycling
> > model of the radio is not quite clear to me.
> >
> > 4% at each side. The sender saves 4% of the energy by sending 5bytes
> less meaning that the radio is on some  uS less as there are less bytes to
> be tx. In the other side the receiver also has the radio on for less time
> as there are less bytes on the air. I do not see what is not clear on that.
>
> This calculation seems a bit weird. If you're calculating both sides, then
> the numerator *and* the denominator have both costs in them. It's either
>  (1.04 * tx) + (1.04 * rx) / (tx + rx). So, 4%. How do you get 8%?
>
> Also, this seems to *only* consider receive/transmit time. I assume that
> the radios are on for other periods of time (the overhead of the protocol)?
> How does this factor in?
>
> Phil

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

<div dir=3D"ltr">Dear Phil,<div><br></div><div>let me answer this point (no=
te that I do not want to enter in a very detailed discussion):</div><div><b=
r></div><div><span style=3D"color:rgb(0,0,255);font-family:arial,sans-serif=
;font-size:13px">This calculation seems a bit weird. If you&#39;re calculat=
ing both sides, then the numerator *and* the denominator have both costs in=
 them. It&#39;s either =C2=A0(1.04 * tx) + (1.04 * rx) / (tx + rx). So, 4%.=
 How do you get 8%?</span><br style=3D"font-family:arial,sans-serif;font-si=
ze:13px">
<br>I&#39;ve been not clear, sorry, y<font color=3D"#000000">ou are right i=
f the node is a leaf node or a dagroot (it sends and the other receive, the=
re are 2 batteries and each battery saves 4%, so 4% in overall). However if=
 a node is a relay, it receives and sends to forward the packet, so the 5 b=
ytes are saved 2 times, one when receiving and one when sending to the next=
 hop (all of that with the same battery, so double saving at each side, no?=
).=C2=A0</font></div>
<div><br></div><div><span style=3D"color:rgb(0,0,255);font-family:arial,san=
s-serif;font-size:13px">Also, this seems to *only* consider receive/transmi=
t time. I assume that the radios are on for other periods of time (the over=
head of the protocol)? How does this factor in?</span><br>
</div><div><font color=3D"#0000ff"><span style=3D"font-family:arial,sans-se=
rif;font-size:13px"><br></span></font></div><div><span style=3D"color:rgb(0=
,0,0);font-family:arial,sans-serif;font-size:13px">In TSCH the radios are o=
nly on for the duration of the packets to be sent/receive + the duration of=
 ACKs in case the packets are required to be acknowledged. Packets can be b=
eacon packets or data packets. Beacons are control packets that can be sent=
 infrequently depending on the network configuration.</span><br>
</div><div><span style=3D"color:rgb(0,0,0);font-family:arial,sans-serif;fon=
t-size:13px"><br></span></div><div><span style=3D"color:rgb(0,0,0);font-fam=
ily:arial,sans-serif;font-size:13px">In 15.4e CSL, there is a short preambl=
e sampling that enables nodes to &quot;agree&quot; when the transmission wi=
ll happen so they can turn off the radio until that time, so the overhead p=
reamble sampling is also small.</span></div>
<div><br></div><div>IMHO, we do not need to loose the focus of this discuss=
ion in the details, there is an advantage of saving 5 bytes at each data pa=
cket. The question is how do we get its value and how do we integrate that =
to the current standards.</div>
<div><br></div><div>regards,</div><div>Xavi</div><div><br></div></div><div =
class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014-08-01 18:20 G=
MT+02:00 Philip Levis <span dir=3D"ltr">&lt;<a href=3D"mailto:pal@cs.stanfo=
rd.edu" target=3D"_blank">pal@cs.stanford.edu</a>&gt;</span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On Aug 1, 2014, at 3:22 AM, =
Xavier Vilajosana &lt;<a href=3D"mailto:xvilajosana@eecs.berkeley.edu">xvil=
ajosana@eecs.berkeley.edu</a>&gt; wrote:<br>

<br>
&gt; Hi Christian,<br>
&gt;<br>
&gt; Inline<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; i am not sure i can follow your calculation. According to your paper<b=
r>
&gt; listening and receiving have the same costs for the RF231, transmittin=
g<br>
&gt; is a bit cheaper.<br>
&gt;<br>
&gt; Yes, tx is slightly cheaper than rx. Rx uses a guard time of ~1ms so r=
adio is turned on a little bit before to cope with clock drifts. (note that=
 nodes are synchronized)<br>
&gt;<br>
<br>
</div>Xavier is right -- this is commonly the case. In low-power wireless, =
the receive path often requires much more complex (digital) logic and the p=
ower costs of the amplifiers are similar. This is different than higher pow=
er networks, where the amplifier circuits dominate. E.g., take a look at a =
4G eNodeB transmitting at 6W and it&#39;ll be drawing more than 100W, most =
of which goes into the final power amplifier (with a big heat sink on it).<=
br>

<div class=3D""><br>
&gt; Why do you conclude you are saving 8% energy ?! Also your duty-cycling=
<br>
&gt; model of the radio is not quite clear to me.<br>
&gt;<br>
&gt; 4% at each side. The sender saves 4% of the energy by sending 5bytes l=
ess meaning that the radio is on some =C2=A0uS less as there are less bytes=
 to be tx. In the other side the receiver also has the radio on for less ti=
me as there are less bytes on the air. I do not see what is not clear on th=
at.<br>

<br>
</div>This calculation seems a bit weird. If you&#39;re calculating both si=
des, then the numerator *and* the denominator have both costs in them. It&#=
39;s either =C2=A0(1.04 * tx) + (1.04 * rx) / (tx + rx). So, 4%. How do you=
 get 8%?<br>

<br>
Also, this seems to *only* consider receive/transmit time. I assume that th=
e radios are on for other periods of time (the overhead of the protocol)? H=
ow does this factor in?<br>
<br>
Phil</blockquote></div><br></div>

--047d7b414478a920f904ffbce62f--


From nobody Sun Aug  3 10:28:42 2014
Return-Path: <pal@cs.stanford.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAA91A0AF7; Sun,  3 Aug 2014 10:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.302
X-Spam-Level: 
X-Spam-Status: No, score=-0.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=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 HnbD7IcV_Kj5; Sun,  3 Aug 2014 10:28:38 -0700 (PDT)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B6531A0AF6; Sun,  3 Aug 2014 10:28:38 -0700 (PDT)
Received: from [76.14.66.110] (port=62544 helo=[192.168.0.103]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XDzaG-00057V-MZ; Sun, 03 Aug 2014 10:28:38 -0700
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <CADJ9OA_=FnuaaR_On_AJoqSVHfvUtcsxcM7WyLMR41AwQA5B-A@mail.gmail.com>
Date: Sun, 3 Aug 2014 10:28:39 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A525A33-FC53-4574-86F9-0FC4E8E5EC43@cs.stanford.edu>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <53DB675C.9000502@tm.uka.de> <CAMsDxWTGG1MMaYPTcQqsBb78GuzsPun_k7r6Qi29fELp=z-mKA@mail.gmail.com> <53DB88B7.80205@tm.uka.de> <CAMsDxWROddNcfcWATpr4wmM+iMGhn4xMGO77f6hGvmRB9+Ow6g@mail.gmail.com> <B80833DA-CF92-4F84-91FA-A45A74B4D03D@cs.stanford.edu> <6439.1407007393@sandelman.ca> <06C4F090-4731-4917-84F1-7C5798574F42@cs.stanford.edu> <CADJ9OA_=FnuaaR_On_AJoqSVHfvUtcsxcM7WyLMR41AwQA5B-A@mail.gmail.com>
To: Thomas Watteyne <watteyne@eecs.berkeley.edu>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: e2fb03075b2557fb7882065b4eb34aa8
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/-RqmrL5l8GcRsWjgLzP4amjPKc8
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Aug 2014 17:28:40 -0000

Thomas,

This is great, thank you! Precise, technical statements. What I conclude =
from your text (correct me if I'm wrong):

1) If 802.15.4e uses maximum sized frames (127 bytes), the data =
communication time (reception or transmission) within a transmit slot is =
80% of the total radio-on time. I appreciate that you separate the costs =
of the two sides (e.g., idle listening guard period on receive).

2) Following Xavier's analysis, using 127-byte frames means the RPL =
option increases data communication time by 4%. This means, from 1), =
that it will increase energy consumption by ~3.5%. Or, supposing his 8% =
number is correct (I still don't understand how he reached it), the =
energy consumption is increased by ~6.5%.

3) For smaller frames (e.g., the 50 bytes Xavier suggested), the idle =
listening on the receiver takes a larger fraction of the radio-on time, =
so his 10% number is too high.

4) None of these calculations consider the control overhead or, as you =
point out, inefficiencies in slot assignment. E.g., if you have a =
low-bandwidth, low-delay network, then you will allocate slots (for low =
latency) that you do not use (low bandwidth). For networks that are =
perfectly tuned, as you suggest, you can approach the transmission slot =
gains in 1) and 2). But they do not consider the costs and time of =
beacons or management time slots. Or radio wakeup overhead (dead time): =
my understanding is that on modern chips this is about 300us? I think =
your ACK timing considers RX/TX turnaround time. So in that way, 1) and =
2) represent the absolute *best* savings this might give you.=20

So my conclusion from this data is that, in the absolute best case -- =
assuming the radio is all of the system energy, you have a perfectly =
tuned TSCH schedule, etc., etc., using the flow label will save <10%, =
and often on the order of 5%. For simpler, less efficient and tuned MAC =
layers, the savings will be less.

5% or 10% isn't huge, but it is significant and valuable. I've just been =
a bit confused as to why this proposal has been trotted around for 4 =
years and yet no-one had yet even done this simple calculation, so WG =
members could make an informed engineering decision. IMO, a 5-10% =
savings in already highly tuned networks is above the bar and worth it. =
In most networks, the savings will be much less, but the benefits of =
reduced memory pressure and larger application payloads without =
fragmentation are more than sufficient motivation and justification of =
the value of the approach.

Phil



On Aug 2, 2014, at 8:36 PM, Thomas Watteyne <watteyne@eecs.berkeley.edu> =
wrote:

> Phil,
>=20
> There are two parts in answering your question. Let me describe both, =
I will then justify why the answer is "it depends".
>=20
> a single slot
>=20
> Let's consider for starters only a single TSCH slot: mote A sends a =
packet to mote B, which replies with an ACK. This timeslot is depicted =
below (borrowed from [1])
>=20
>=20
>       /------------------- Time Slot duration --------------------/
>       |                                        /tsShortGT/        |
>       |            |                              | | |           |
>       |------------+-----------------+--------------+------+------|
>    TX |            |    TX-Packet    |              |RX Ack|      |
>       |------------+-----------------+--------------+------+------|
>       |/tsTxOffset/|                 |              |      |      |
>       |            |                 |              |      |      |
>       |------------+-----------------+--------------+------+------|
>    RX |         |  |  | RX-Packet    |              |TX Ack|      |
>       |---------+--+--+--------------+--------------+------+------|
>       |         |  |  |              |              |      |      |
>       |        /tsLongGT/            |/TsTxAckDelay/|      |      |
>      Start                                                       End
>       of                                                          of
>      Slot                                                        Slot
>=20
>=20
> Let's assume that the IEEE802.15.4 frame is 127B long, i.e. full =
length. Let's assume, finally, that you are using the default 10ms =
timeslot template from the IEEE802.15.4e-2012 standard [2] (Table 52e), =
no CCA. This is the radio-on time on both A and B:
> 	=95 mote A
> 		=95 transmitting the data packet: 4256us
> 		=95 listening for ACK during the guard time (i.e. idle =
listening): 200us
> 		=95 receiving the ACK (~15B long): 480us
> 	=95 mote B:
> 		=95 listening for data during the guard time (i.e. idle =
listening): 1000us
> 		=95 receiving data: 4256us
> 		=95 transmitting the ACK: 480us
> =46rom an energy point of view, you also need to account for the time =
is takes to switch the radio on/off and for the possible energy consumed =
between the data and ack, in case the radio is kept in a state allowing =
it to TX/RX fast. Good embedded engineers will reduce this overhead =
through firmware and hardware wizardry.
>=20
> Considering only time, the radio on-time budget can hence be cut into:
> 	=95 total: 10672us
> 	=95 transmission of data: 8512us (~80%)
> 	=95 desynchronization overhead (i.e. idle listening during guard =
time): 1200us (~10%)
> 	=95 ACK overhead: 960us (~10%)
> =46rom these numbers, you see that the actual data transmission =
accounts for ~80% of the radio-on time budget.
>=20
> Of course, this timeslot template is the default one. If you are very =
good at keeping synchronized, you might be able to shorten the guard =
times and reduce the desynchronization overhead.
>=20
> full network
>=20
> Now the fun part.
>=20
> In a TSCH network, the communication schedule indicates to every mote =
what to do: transmit, listen or sleep. You can tune the TSCH =
communication schedule any way you want. In fact, the 6TiSCH WG was =
created to define mechanisms for centralized and distributed managements =
of this schedule.
>=20
> Your goal should be to match the amount of bandwidth in your schedule =
(i.e. the cells used for transmission and reception) to what is needed =
by the network. If every cell you schedule is used, the single slot =
results from above carry over to a full network. If, however, you =
schedule has too many cells, some might be unused. In that case, the =
transmitter will keep its radio off (i.e. consume no energy), while the =
receiver will have to listen for a full guard time, or 2ms when using =
the default timeslot template.
>=20
> So there you go: it depends. In the best possible case, the portion of =
radio on-time spent of exchanging actual useful data can be very high =
(80%+), but it's easy to mess things up, resulting in a large number of =
over-provisioned cells.
>=20
> For a (hopefully clear) overview of IEEE802.15.4e TSCH, take a look at =
http://tools.ietf.org/html/draft-ietf-6tisch-tsch-01.
>=20
> Thomas
>=20
> [1] http://tools.ietf.org/html/draft-ietf-6tisch-minimal-02
> [2] http://standards.ieee.org/getieee802/download/802.15.4e-2012.pdf
>=20
>=20
> On Sat, Aug 2, 2014 at 2:41 PM, Philip Levis <pal@cs.stanford.edu> =
wrote:
> On Aug 2, 2014, at 12:23 PM, Michael Richardson =
<mcr+ietf@sandelman.ca> wrote:
>=20
> >
> > Philip Levis <pal@cs.stanford.edu> wrote:
> >> The paper is very helpful, thanks! Can you comment on what is a =
typical
> >> idle slot configuration in a TiSCH network? Can you provide some
> >> insight on what fraction of energy is spent in data communication
> >> versus control and idle listening?
> >
> > Here is a recent post with some real numbers:
> >  =
https://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY
> > it concerns diet-ESP, but the numbers are correct.
>=20
> Michael,
>=20
> I'm confused on what this email message is supposed to be providing: =
the energy cost of sending a bit? That's pretty simple to calculate. The =
tradeoff between CPU and network is also very well known, going back to =
Pottie's "Every bit transmitted brings a sensor node one moment closer =
to death." If you look at the behavior of most micro controller based =
devices, the MCU is insignificant -- and 95% of its energy is spent =
handling interrupts (per-byte, over an SPI bus) for the radio. Yes, =
unless you're doing something quite silly, the CPU cost of compression =
is almost always absolutely worth the benefit in terms of reduced =
transmission energy.
>=20
> My question related to the fraction of radio energy in TSCH that is =
consumed by data transmission/reception versus everything else (idle =
listening, guard periods, control frames, etc.
>=20
> To give you a data point -- early low-power link layers continually =
transmitted a packet (or wakeup frame) until receiving an =
acknowledgement from the intended receiver. Receivers periodically wake =
up, listen if there's energy on the channel, and if so, stay awake for 2 =
packet times (in case they woke up just after the preamble of a packet). =
If there's no coordination between receiver and sender, this means a =
sender must send on average for 1/2 of a wakeup interval to deliver a =
packet. E.g., 0.5s. Clearly in such a protocol a few extra bytes doesn't =
matter in terms of energy. Of course, TSCH is much, much better than =
this, I only mention this protocol as a simple explanatory example -- =
but what's the actual number?
>=20
> Phil
>=20
>=20
>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>=20


From nobody Sun Aug  3 16:57:21 2014
Return-Path: <pal@cs.stanford.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 334BD1A0188 for <ipv6@ietfa.amsl.com>; Sun,  3 Aug 2014 16:57:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 YV3PI-wSfUbD for <ipv6@ietfa.amsl.com>; Sun,  3 Aug 2014 16:57:18 -0700 (PDT)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5FC1A0021 for <ipv6@ietf.org>; Sun,  3 Aug 2014 16:57:18 -0700 (PDT)
Received: from [76.14.66.110] (port=63935 helo=[192.168.0.103]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XE5eP-0000xc-Qe; Sun, 03 Aug 2014 16:57:18 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <CAMsDxWQOSgy42DpSoiL3EVNjukpad6WPBXFNHRfsJVvYwaPJJg@mail.gmail.com>
Date: Sun, 3 Aug 2014 16:57:21 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <5D368BAF-A7F1-432B-8A81-CBB49947CC92@cs.stanford.edu>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <53DB675C.9000502@tm.uka.de> <CAMsDxWTGG1MMaYPTcQqsBb78GuzsPun_k7r6Qi29fELp=z-mKA@mail.gmail.com> <544B6184-72FE-42B2-AAA4-DF44D0E1BD5A@cs.stanford.edu> <CAMsDxWQOSgy42DpSoiL3EVNjukpad6WPBXFNHRfsJVvYwaPJJg@mail.gmail.com>
To: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 2c238adc2661b13b123d68c6db09dced
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/-afG29P8J0oPJiFwoPe_bxcSCcY
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Aug 2014 23:57:20 -0000

On Aug 3, 2014, at 10:24 AM, Xavier Vilajosana =
<xvilajosana@eecs.berkeley.edu> wrote:

> IMHO, we do not need to loose the focus of this discussion in the =
details, there is an advantage of saving 5 bytes at each data packet. =
The question is how do we get its value and how do we integrate that to =
the current standards.

I agree that there's value -- but in that logic there's also value in =
saving a single bit and so we should modify the flow label to save =
sending a single bit. Engineering is about tradeoffs. I don't understand =
the resistance to providing even a ballpark estimate (that doesn't just =
assume best case everything, like no overhead or control traffic or idle =
listening or...) for what the tradeoffs are. That leads to uninformed =
decisions based on rhetoric and claims rather than a good discussion =
that leads to the right engineering decision.

Would you argue that RPL should re-use the flow label to save energy if =
doing so would reduce energy consumption by 0.01%? Recall that power =
consumption (e.g., processor sleep consumption) on these devices =
increases with resources, such that just adding many of tiny =
optimizations that make implementations larger, more complex, and =
buggier might not actually reduce energy consumption.

Phil=


From nobody Mon Aug  4 02:51:05 2014
Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91D21B298A; Mon,  4 Aug 2014 02:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.235
X-Spam-Level: 
X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
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 pkfDDUwHcbEt; Mon,  4 Aug 2014 02:51:02 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5B501B298C; Mon,  4 Aug 2014 02:51:00 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmEGAKJW31OtJssW/2dsb2JhbABbhDaCeNB2BAIBgS53hAMBAQQBI1YFCwsYAgImAgIhNgYTiC4DCQitZI9sDYcAF4Esi3OBViQzB4J5NoEcAQSZf5A+hiiDTzsvAYEE
X-IronPort-AV: E=Sophos;i="5.01,797,1400025600"; d="scan'208";a="132591672"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 04 Aug 2014 09:50:59 +0000
Received: from dhcp-10-61-106-70.cisco.com (dhcp-10-61-106-70.cisco.com [10.61.106.70]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s749ovhq019970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2014 09:50:58 GMT
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1971.5\))
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Ole Troan <otroan@employees.org>
In-Reply-To: <53DBF16F.2090202@gmail.com>
Date: Mon, 4 Aug 2014 11:50:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <E25D93A9-92E7-4DD0-BD95-06764C2155D5@employees.org>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53DBF16F.2090202@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1971.5)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/EyDq6EXcdITGrBmmnD96S9cfa0U
Cc: 6man WG <ipv6@ietf.org>, roll <roll@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 09:51:04 -0000

> On 01 Aug 2014, at 21:58 , Brian E Carpenter =
<brian.e.carpenter@gmail.com> wrote:
>=20
> On 01/08/2014 23:23, Carsten Bormann wrote:
> ...
>> The other story is that we are retracting RFC 6437 and turning the =
flow label into the =E2=80=9Cfield you may trample on in your lower =
layers if you have a good reason=E2=80=9D.  Cynically, one could say =
this is proper payback for designing this field without a compelling =
purpose and no protocol evolution story attached to it.  So the =
evolution just eats it.  Teachable moment.
>=20
> RFC 6437 co-author hat on (but only speaking for myself, of course):
>=20
> My opinion is that the draft doesn't retract RFC 6437. As I already =
said,
> 6437 attempts to recognise the reality that middleboxes can mess with =
the
> flow label, and to set conditions for that messing such that remote =
systems
> can still use it for load balancing. Since it's unprotected by =
checksum or
> crypto, there is a strict limit to how much it can be trusted anyway. =
As
> the RFC says:
>=20
>   There is no way to verify whether a flow label has been modified en
>   route or whether it belongs to a uniform distribution.  Therefore, =
no
>   Internet-wide mechanism can depend mathematically on unmodified and
>   uniformly distributed flow labels; they have a "best effort" =
quality.
>   Implementers should be aware that the flow label is an unprotected
>   field that could have been accidentally or intentionally changed en
>   route (see Section 6).
>=20
> It is true that the RFC also says
>=20
>   A forwarding node
>   MUST either leave a non-zero flow label value unchanged or change it
>   only for compelling operational security reasons...
>=20
> There is a case for arguing that flow-label-for-rpl should carry the
> legend "Updates: 6437 (if approved)" because it adds another exception
> to this sentence. There is also a case for arguing that =
flow-label-for-rpl
> is a stateful mechanism, out of scope for RFC 6437 according to
> Section 4 of that RFC.
>=20
> Either way, I don't see a problem.

I see the principles in these two documents as mutually exclusive:
RFC6437: middleboxes can mess with the flow label
-flow-label-for-rpl: networks uses flow label field as an immutable =
protocol field

you can't both use the flow label as an immutable protocol field and =
have middleboxes rewriting it.

cheers,
Ole


From nobody Mon Aug  4 03:20:26 2014
Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9831B2947 for <ipv6@ietfa.amsl.com>; Mon,  4 Aug 2014 03:20:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.235
X-Spam-Level: 
X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
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 zheIJ1T9arNu for <ipv6@ietfa.amsl.com>; Mon,  4 Aug 2014 03:20:21 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C14F71B29BA for <ipv6@ietf.org>; Mon,  4 Aug 2014 03:20:20 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqEEAH5d31OtJssW/2dsb2JhbABbg1/NB4dKAYEud4QEAQQBOj8QC0ZXBohNCA3EWhMEjxkzB4MvgRwBBLBlg087
X-IronPort-AV: E=Sophos;i="5.01,797,1400025600"; d="scan'208";a="127882435"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 04 Aug 2014 10:20:19 +0000
Received: from dhcp-10-61-106-70.cisco.com (dhcp-10-61-106-70.cisco.com [10.61.106.70]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s74AKHgJ005187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2014 10:20:18 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1971.5\))
Subject: Re: draft-ietf-6man-resilient-rs update
From: Ole Troan <otroan@employees.org>
In-Reply-To: <351e522158e14ed7a8e533f4137bf401@SN2PR03MB077.namprd03.prod.outlook.com>
Date: Mon, 4 Aug 2014 12:20:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B7B1EBCD-6BAC-4938-B32F-167DFAC76593@employees.org>
References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> <BA7546DE-AD9B-46BA-90DD-6E89836E2A2F@employees.org> <3dfb3ea73b5d450c923198ce06704f5a@SN2PR03MB077.namprd03.prod.outlook.com> <57CD62D4-0D87-4F23-A6AA-0AA9E4EFCD26@employees.org> <7613b4b345e2473fb48ef90e7dc5844f@SN2PR03MB077.namprd03.prod.outlook.com> <F795F34D-AC5F-4DB5-9B99-B7D2EA462839@employees.org> <8c9ccd4087ca4358862e773776bf67b5@SN2PR03MB077.namprd03.prod.outlook.com> <CB21E017-EB8A-449A-9EE9-0346C214DE24@employees.org> <d63acea236f64a22bd51b30cefad37b8@SN2PR03MB077.namprd03.prod.outlook.com> <004AD154-0D65-4F7F-A198-61382562550A@employees.org> <351e522158e14ed7a8e533f4137bf401@SN2PR03MB077.namprd03.prod.outlook.com>
To: Dmitry Anipko <Dmitry.Anipko@microsoft.com>
X-Mailer: Apple Mail (2.1971.5)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/DCUMwFpCIEqvZd8wxTaZ5zsfDY4
Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" <draft-ietf-6man-resilient-rs@tools.ietf.org>, 6man WG <ipv6@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 10:20:23 -0000

Dmitry,

>>> I do agree with that. the specific concern with the MAY, is that =
we'll end up with inconsistent behaviour on the link. I'd much rather =
that we specified behaviour in detail.
>=20
> Ok, can you elaborate to what level of details you'd expect the =
behavior to be specified? Is statement on rate limiting would be =
sufficient, or you think the description of the algo along the lines of =
DHCPv6 retransmissions is needed (or the latter could be referenced)?

Erik Nordmark has raised a number of questions that needs to be answered =
if we were to specify this:
I think you'll find them here:
=
https://mailarchive.ietf.org/arch/search/?q=3Ddraft-ietf-6man-resilient-rs=
+and+nordmark

if we were to go down the route of solving 2 and 3, we'd need to see =
text.

cheers,
Ole=


From nobody Mon Aug  4 06:48:08 2014
Return-Path: <maildanrl@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EEA1B2AFE for <ipv6@ietfa.amsl.com>; Mon,  4 Aug 2014 06:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level: 
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 gfj2LKWDFnnV for <ipv6@ietfa.amsl.com>; Mon,  4 Aug 2014 06:45:07 -0700 (PDT)
Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C4B1B2AF9 for <ipv6@ietf.org>; Mon,  4 Aug 2014 06:45:07 -0700 (PDT)
Received: by mail-ob0-f177.google.com with SMTP id wp18so4355154obc.22 for <ipv6@ietf.org>; Mon, 04 Aug 2014 06:45:05 -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:content-type:content-transfer-encoding; bh=OulWxAPvnepsToeW6I2WT2DB4UqmiTwPPglMsj65zcI=; b=blclx2aFuE2qF9z2Q7OB2H/H1negLR1xWJslpJNvF3eNJuCMHvjQlxFusZrzb7wn2x 0QLe4FPSg4Yqc4THctOuEDsJ9OZbd9eAtrOUrBmCoyYGTuU+adFn32iMQtvnVGdm4zWU pyFaW9FAptKIfBVGQH7ebJbLfm5d8s+thfP6dRswMl/YsE0YkJhNBXVJuFL53PW7a8+M pxQUVFjEqFg5oOD8YVy4MofGpiW5c4oKnJiegR8v/h8C9DolT0S0FhGWbaTqQIohDiR6 yOueqJ1Z+CGicVHimh7lq5CE5bu2+tDH4h70blWpK0qNvbzSo79JJ5s530/Ul54pTIRF BCPw==
X-Received: by 10.60.115.234 with SMTP id jr10mr4509456oeb.85.1407159905288; Mon, 04 Aug 2014 06:45:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.15.142 with HTTP; Mon, 4 Aug 2014 06:44:45 -0700 (PDT)
In-Reply-To: <53CE3624.3040007@gmail.com>
References: <53CE3624.3040007@gmail.com>
From: =?UTF-8?Q?Dan_L=C3=BCdtke?= <maildanrl@gmail.com>
Date: Mon, 4 Aug 2014 15:44:45 +0200
Message-ID: <CAAfuxnLJq2pvpUThQ7tzhAEfyuFE-aNuVXE1H1=gtbAfnygzxA@mail.gmail.com>
Subject: Re: updated draft-petrescu-autoconf-ra-based-routing-05.txt - RAs for routing between moving networks
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/2zvOVww4-CUkfM8abqL_Cb4-B0Q
X-Mailman-Approved-At: Mon, 04 Aug 2014 06:48:06 -0700
Cc: Ipv <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 13:45:09 -0000

Hi Alexandru,

> Each Mobile Router multicasts special RAs on the egress interface, contai=
ning the Mobile Network Prefix that is assigned to its moving network.

Could there be a situation where "normal" and "special" RAs are being
sent by the same router? If so, how will they differ despite the M-Bit
set? Will this lead to routers sending two types of RAs? Is there a
special reason why we do not mark the individual Route Information
Option with a M-Bit but the whole RA?

I tried to do a sketch how to implement this draft into the "ratools"
daemon, at came accross the mentioned questions.

Cheers

Dan

On Tue, Jul 22, 2014 at 12:00 PM, Alexandru Petrescu
<alexandru.petrescu@gmail.com> wrote:
> Hello,
>
> We have updated the draft
> "RAs for routing between moving networks"
> http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-05
>
> This draft describes an extension to be carried by RAs containing IP
> prefixes to be exchanged between mobile routers ('exchanged' - as opposed=
 to
> 'announcing' prefixes active on links).
>
> The implementation of this extension allows 1-hop neighboring vehicles to
> establish IP paths between any pair of onboard IP-addressable devices; on=
e
> potential application is a live videostream sent by an IP camera in a lar=
ge
> vehicle to an IP display in the following vehicle, to help during
> view-obstructing situations.
>
> This -05 update is minor - just added a reference to another draft which =
may
> present similarities.
>
> Alex
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------



--=20
Dan L=C3=BCdtke
http://www.danrl.de


From nobody Mon Aug  4 07:02:35 2014
Return-Path: <mcr@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BA81B2B10; Mon,  4 Aug 2014 07:02:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Level: 
X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
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 l4lO3PNrG7zK; Mon,  4 Aug 2014 07:02:32 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262FB1B2B0F; Mon,  4 Aug 2014 07:02:32 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 71D0320029; Mon,  4 Aug 2014 10:04:50 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id F279363AC9; Mon,  4 Aug 2014 10:02:27 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DC1D8638D6; Mon,  4 Aug 2014 10:02:27 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Philip Levis <pal@cs.stanford.edu>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
In-Reply-To: <9A525A33-FC53-4574-86F9-0FC4E8E5EC43@cs.stanford.edu>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <53DB675C.9000502@tm.uka.de> <CAMsDxWTGG1MMaYPTcQqsBb78GuzsPun_k7r6Qi29fELp=z-mKA@mail.gmail.com> <53DB88B7.80205@tm.uka.de> <CAMsDxWROddNcfcWATpr4wmM+iMGhn4xMGO77f6hGvmRB9+Ow6g@mail.gmail.com> <B80833DA-CF92-4F84-91FA-A45A74B4D03D@cs.stanford.edu> <6439.1407007393@sandelman.ca> <06C4F090-4731-4917-84F1-7C5798574F42@cs.stanford.edu> <CADJ9OA_=FnuaaR_On_AJoqSVHfvUtcsxcM7WyLMR41AwQA5B-A@mail.gmail.com> <9A525A33-FC53-4574-86F9-0FC4E8E5EC43@cs.stanford.edu>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 04 Aug 2014 10:02:27 -0400
Message-ID: <23675.1407160947@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/UUMWLjRgW1y2TBKNu49mJb8GBHY
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 14:02:34 -0000

--=-=-=


Philip Levis <pal@cs.stanford.edu> wrote:
    > 5% or 10% isn't huge, but it is significant and valuable. I've just
    > been a bit confused as to why this proposal has been trotted around for
    > 4 years and yet no-one had yet even done this simple calculation, so WG
    > members could make an informed engineering decision. IMO, a 5-10%

my opinion:

1) the exact calculation was hard to really do until 6tisch made it clearer
   what the duty cycle was going to be.

2) it took awhile to come back to figuring out how to deal with the flow
   label issue.

3) it is now clear exactly how close many of our packets are to the 127 byte
   limit, and how much the HbH header hurts if it is the reason we go into
   two fraglets.

4) we had other things to worry about!

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBU9+ScYCLcPvd0N1lAQKSrQgAj0jM9dgzgL8ZP78Ey5/OcRv9kKCkqVjp
InGMXvpZCpBuUY0yZyxiIIGYUDh02v41QbATGgyCUmVIM6aUfQ3lhlpbu4CSUR7l
C5l/Z6ZlT97u6DMHQvzhgtSlY7frGk1Nlf4H+4I2jRvAYVOz/LB5WsEhm+imYYKL
dY6WXvUVxguG9G8cvgmeJS0rRlx9zs4chWNqI5lC4MMn4XXfRwTp90Wl+2eQZYjG
3kNzzgz5gRA60umoZq8JWSSc9R+XohPEOt2vB+U9oxp5DR/v3WkcjsWP2uAmoZiY
Qd55MnA4qBZtXKcUmhVzT1ULPWxRNRFM77XsKOF1QnTvNNDc2TGBkw==
=6iHG
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Mon Aug  4 07:15:25 2014
Return-Path: <mcr@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA6D1B2B16; Mon,  4 Aug 2014 07:15:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.892
X-Spam-Level: 
X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
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 EHmOtWcFVU5V; Mon,  4 Aug 2014 07:15:17 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA5D1B2B11; Mon,  4 Aug 2014 07:15:17 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6309620029; Mon,  4 Aug 2014 10:17:38 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id E5E0F63AC9; Mon,  4 Aug 2014 10:15:15 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D3FF6638D6; Mon,  4 Aug 2014 10:15:15 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ole Troan <otroan@employees.org>
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
In-Reply-To: <E25D93A9-92E7-4DD0-BD95-06764C2155D5@employees.org>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53DBF16F.2090202@gmail.com> <E25D93A9-92E7-4DD0-BD95-06764C2155D5@employees.org>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 04 Aug 2014 10:15:15 -0400
Message-ID: <26363.1407161715@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/oKqY9q0WvKVcxPom84dJQ9_GIDg
Cc: roll <roll@ietf.org>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 14:15:20 -0000

--=-=-=


On 01 Aug 2014, at 21:58 , Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    >> It is true that the RFC also says
    >>
    >> A forwarding node MUST either leave a non-zero flow label value
    >> unchanged or change it only for compelling operational security
    >> reasons...
    >>
    >> There is a case for arguing that flow-label-for-rpl should carry the
    >> legend "Updates: 6437 (if approved)" because it adds another exception
    >> to this sentence. There is also a case for arguing that
    >> flow-label-for-rpl is a stateful mechanism, out of scope for RFC 6437
    >> according to Section 4 of that RFC.
    >>
    >> Either way, I don't see a problem.

Ole Troan <otroan@employees.org> wrote:
    > I see the principles in these two documents as mutually exclusive:
    > RFC6437: middleboxes can mess with the flow label -flow-label-for-rpl:
    > networks uses flow label field as an immutable protocol field

    > you can't both use the flow label as an immutable protocol field and
    > have middleboxes rewriting it.

This is my take.
Case 1:  packet is within the LLN.  No issue; the sender sets the flow label,
     and we know (by design) that there aren't any (non-RPL) middle boxes
     that need to rewrite it.

Case 2: the packet has to leave the LLN, travel across the Internet, and
     enter another LLN.
     Here the arguments about the LLN being a kind of virtual host from
     the document are relevant.  The flow label, when it crosses the
     Internet, would be immutable.  Prior to this document, the flow label
     would have been compressed out, been zero, and the DODAG root ought to
     have set it in some consistent fashion anyway.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBU9+VcYCLcPvd0N1lAQKI8wgAlset3iLkNvBTxf7b910wO9yiu1ZaXXyF
mKtFTL5OeAT/oyO2hDu3ph+NgvJo5+x9HruzyCsEG/lqqJgTs2GipU3XeP9m9Opt
ZhzukyIVhRXxVFToFrIx34v/WNJQxojtOcc9UEdiWnx9tMqrTZU9GZ8n7LGEUbhp
9lrQQ5JqZBifDwu6I+u7mSlh47G5+jDiMe26HhdSfyB0fKvtM/I91Iv0DwpV8pkz
mxPZIHSWyixyIMfkTWVKmdpr0Hi7jpTpaPd0cK4qlwZDCO5+UDW05U2UBCUj7XAS
IKoML9yAni1Tg4fXEExefidhFEP/OR4h4eTL+pP85HaFdIyb/c0tbQ==
=PD8O
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Mon Aug  4 08:42:08 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028711B2B85; Mon,  4 Aug 2014 08:42:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 i2uzP1eyA2Ne; Mon,  4 Aug 2014 08:42:04 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE9471B2B87; Mon,  4 Aug 2014 08:42:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2791; q=dns/txt; s=iport; t=1407166925; x=1408376525; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xw3B3o2JPOVlwtt1J2/28xsD7wSNskWemkGFgIbJPoA=; b=Q+xk0i1hPwJMQZzZMdTIebNY51L7W4uI19HfoNNFmwhc+L67v3yCzcui xjCV3bvnHxbl/C37RXIBqQKDwii+vcfMpynp/Sm470vWity1aM/pr11i9 ReoandSFkk5X7Fx76XJwDgYXSSfZxtS2zLLGD82qO4S60q5DFaI/hoWIR M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Aj4FAJup31OtJV2a/2dsb2JhbABagw2BKQTTewGBEBZ3hAMBAQEEeQwEAgEIEQQBAQEKHQchERQJCAIEAQ0FCIgmAxG+Jw2HABeNH4F8MQcGgymBHAWKVY8qkD6GKINNbAGBRQ
X-IronPort-AV: E=Sophos;i="5.01,799,1400025600"; d="scan'208";a="344977142"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 04 Aug 2014 15:41:57 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s74FfuAB031725 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 15:41:56 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 10:41:56 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Ole Troan <otroan@employees.org>
Subject: RE: WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPrcL83Dn9icet106HlaTIaH7gh5vAi3mAgABJ2ID//8HXoA==
Date: Mon, 4 Aug 2014 15:41:55 +0000
Deferred-Delivery: Mon, 4 Aug 2014 15:41:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D17F25@xmb-rcd-x01.cisco.com>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53DBF16F.2090202@gmail.com> <E25D93A9-92E7-4DD0-BD95-06764C2155D5@employees.org> <26363.1407161715@sandelman.ca>
In-Reply-To: <26363.1407161715@sandelman.ca>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.74.174]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/hoK5z0Yqkk2hQcZm8KjxTlAErnU
Cc: roll <roll@ietf.org>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 15:42:06 -0000

Exactly;

It can be argued that the LLN is a single something that is a more complex =
form of the classical host-router link from the L3 perspective.
RFC6437 understands that the host can leave the flow label to all zeroes an=
d allows the first router to set it in a recommended fashion.=20
The draft pushes that role to the RPL root that is effectively the gateway =
from the LLN onto the Internet.
Upon the WLLC discussion I have added " Updates: 6437 (if approved) " and p=
osted an update with no other change in the text.

Cheers,

Pascal


> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Michael Richardson
> Sent: lundi 4 ao=FBt 2014 16:15
> To: Ole Troan
> Cc: roll; 6man WG
> Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
>=20
>=20
> On 01 Aug 2014, at 21:58 , Brian E Carpenter <brian.e.carpenter@gmail.com=
>
> wrote:
>     >> It is true that the RFC also says
>     >>
>     >> A forwarding node MUST either leave a non-zero flow label value
>     >> unchanged or change it only for compelling operational security
>     >> reasons...
>     >>
>     >> There is a case for arguing that flow-label-for-rpl should carry t=
he
>     >> legend "Updates: 6437 (if approved)" because it adds another
> exception
>     >> to this sentence. There is also a case for arguing that
>     >> flow-label-for-rpl is a stateful mechanism, out of scope for RFC 6=
437
>     >> according to Section 4 of that RFC.
>     >>
>     >> Either way, I don't see a problem.
>=20
> Ole Troan <otroan@employees.org> wrote:
>     > I see the principles in these two documents as mutually exclusive:
>     > RFC6437: middleboxes can mess with the flow label -flow-label-for-r=
pl:
>     > networks uses flow label field as an immutable protocol field
>=20
>     > you can't both use the flow label as an immutable protocol field an=
d
>     > have middleboxes rewriting it.
>=20
> This is my take.
> Case 1:  packet is within the LLN.  No issue; the sender sets the flow la=
bel,
>      and we know (by design) that there aren't any (non-RPL) middle boxes
>      that need to rewrite it.
>=20
> Case 2: the packet has to leave the LLN, travel across the Internet, and
>      enter another LLN.
>      Here the arguments about the LLN being a kind of virtual host from
>      the document are relevant.  The flow label, when it crosses the
>      Internet, would be immutable.  Prior to this document, the flow labe=
l
>      would have been compressed out, been zero, and the DODAG root ought
> to
>      have set it in some consistent fashion anyway.
>=20
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -=3D IPv6 IoT consulting =3D-
>=20
>=20


From nobody Mon Aug  4 11:01:23 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA81E1A008B; Mon,  4 Aug 2014 11:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 YWFPeGHQGJtp; Mon,  4 Aug 2014 11:01:14 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58B61A00B2; Mon,  4 Aug 2014 11:01:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2834; q=dns/txt; s=iport; t=1407175274; x=1408384874; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=SguRyPk9qyZJA4pK5gAZKGObnA9g9cKVnhnwi5fPhJ4=; b=hObilLyKDC4OjRWS6c/YGl3husDQk7cSU765r0bm/pxB3l9q3KmTCCmU kBOw2ziY5Gi8NfygORybxMpUldWUgcepghybAujHdgdV/xEU0auX4YYOy UwSP/n1T3yt/yVhIHx0DiuMHvW+e9209M0VXu5q+l/FKOtqn6cRT9za97 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkQFAEfJ31OtJV2Z/2dsb2JhbABagw1SVwSCdMk6CodKARl4FneEAwEBAQQBAQEgEToLEgEIDgMEAQEDAgYdAwIEJQsUAQgJAQQOBQiIOg2uG5cJEwSBLI1SHTGDADaBHAWGCapcg01sgUY
X-IronPort-AV: E=Sophos;i="5.01,799,1400025600"; d="scan'208";a="66416238"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 04 Aug 2014 18:01:13 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s74I1CCT014433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 18:01:12 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 13:01:12 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Ralph Droms <rdroms.ietf@gmail.com>, "Routing Over Low power and Lossy networks" <roll@ietf.org>
Subject: RE: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoA==
Date: Mon, 4 Aug 2014 18:01:11 +0000
Deferred-Delivery: Mon, 4 Aug 2014 18:01:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.74.174]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/PYHsiZKYABomodZ5zIj-zf12SmE
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 18:01:17 -0000

VGhlIGNoYW5nZSBpcyBub3cgZG9uZSwgUmFscGguDQoNClRoZSBvbmx5IGRpZmZlcmVuY2UgYmV0
d2VlbiBkcmFmdC10aHViZXJ0LTZtYW4tZmxvdy1sYWJlbC1mb3ItcnBsLTAzIGFuZCBkcmFmdC10
aHViZXJ0LTZtYW4tZmxvdy1sYWJlbC1mb3ItcnBsLTA0IGlzIA0KDQpVcGRhdGVzOiA2NDM3IChp
ZiBhcHByb3ZlZCkNCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg0KRnJvbTogaXB2NiBbbWFpbHRvOmlw
djYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJhbHBoIERyb21zDQpTZW50OiBzYW1l
ZGkgMiBhb8O7dCAyMDE0IDIyOjU3DQpUbzogUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9z
c3kgbmV0d29ya3MNCkNjOiBNaWNoYWVsIFJpY2hhcmRzb247IGlwdjZAaWV0Zi5vcmcNClN1Ympl
Y3Q6IFJlOiBbUm9sbF0gV0dMQyBmb3IgZHJhZnQtdGh1YmVydC02bWFuLWZsb3ctbGFiZWwtZm9y
LXJwbC0wMw0KDQoNCg0KT24gQXVnIDIsIDIwMTQsIGF0IDQ6NDggUE0sICJQYXNjYWwgVGh1YmVy
dCAocHRodWJlcnQpIiA8cHRodWJlcnRAY2lzY28uY29tPiB3cm90ZToNClRoYXQgc291bmRzIHJp
Z2h0LCBNaWNoYWVsLCANCg0KSSBhZ3JlZSB0aGF0ICJ1cGRhdGVzIDY0MzciIGlzIGEgcmlnaHQg
dGhpbmcgdG8gZG8uDQoNCnRob3VnaCBzbGlnaHRseSBvbiB0aGUgb3ZlcmtpbGwgc2lkZS4gDQoN
CkkgZGlzYWdyZWUgdGhhdCBpdCBpcyBvdmVya2lsbC4gwqBJbiBteSBvcGluaW9uLMKgZHJhZnQt
dGh1YmVydC02bWFuLWZsb3ctbGFiZWwtZm9yLVJQTCBwcmV0dHkgY2xlYXJseSBjb250cmFkaWN0
cyBSRkMgNjQzNywgc2/CoCJ1cGRhdGVzIDY0MzciIGlzIGFuIGFwcHJvcHJpYXRlIGFjdGlvbi4N
Cg0KwqBBbmQgdGhpcyBpcyBjb25zaXN0ZW50IHdpdGggd2hhdCBCcmlhbiBzdWdnZXN0ZWQuIFRo
aXMgY2FuIGJlIGFkZGVkIGR1cmluZyB0aGUgcmZjIGVkaXRvciBwcm9jZXNzIEkgZXhwZWN0Pw0K
DQpJdCBzaG91bGQgYmUgYWRkZWQgYXMgc29vbiBhcyBwb3NzaWJsZSwgY2VydGFpbmx5IGJlZm9y
ZSBpdCBnb2VzIHRvIHRoZSBJRVNHLiDCoEluIG15IG9waW5pb24sIHRoZSBjaGFuZ2UgbWlnaHQg
d2FycmFudCBhIG5ldyBvciBleHRlbmRlZCBXR0xDOyB0aGF0IGFjdGlvbiBpcyB1cCB0byB0aGUg
Y2hhaXJzLCBvZiBjb3Vyc2UuDQoNCi0gUmFscGgNCg0KDQpQYXNjYWwNCg0KTGUgMiBhb8O7dCAy
MDE0IMOgIDIxOjA5LCAiTWljaGFlbCBSaWNoYXJkc29uIiA8bWNyK2lldGZAc2FuZGVsbWFuLmNh
PiBhIMOpY3JpdCA6DQoNCg0KUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lz
Y28uY29tPiB3cm90ZToNCk9UT0ggeW91IG5lZWQgdG8gdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGlz
IG5vIG5lZWQgZm9yIGEgYmlzIHRvIHVwZGF0ZSBhDQpNVVNUIGluIGFuIFJGQy4gV2UgcmVjb2du
aXplIHRoZSBpbXBlcmZlY3Rpb24gaW4gb3VyIHdvcmsgYW5kIGFyZQ0KYWx3YXlzIHJlYWR5IHRv
IHJldmlzZSBhbmQgYW1lbmQgYWZ0ZXIgZHVlIGNvbnNpZGVyYXRpb24uDQoNClBlcmhhcHMgdGhp
cyBkb2N1bWVudCBVUERBVEVTIDY0MzcgdGhlbj8NCg0KLS0NCk1pY2hhZWwgUmljaGFyZHNvbiA8
bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzDQotPSBJUHY2
IElvVCBjb25zdWx0aW5nID0tDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSUVURiBJUHY2IHdvcmtpbmcg
Z3JvdXAgbWFpbGluZyBsaXN0DQppcHY2QGlldGYub3JnDQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0
czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQotLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KUm9s
bCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vcm9sbA0K


From nobody Mon Aug  4 11:10:57 2014
Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F4B1A00D7; Mon,  4 Aug 2014 11:10:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 lpBM8bC73jLx; Mon,  4 Aug 2014 11:10:50 -0700 (PDT)
Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C85F51A00E6; Mon,  4 Aug 2014 11:10:43 -0700 (PDT)
Received: by mail-qg0-f42.google.com with SMTP id j5so9434151qga.1 for <multiple recipients>; Mon, 04 Aug 2014 11:10:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3Q5zBVkMJA3QW5n+26VXwUczY9lgy1b3mn+s2DlhXQk=; b=sAWn4Wq+L6o7vtbE0tRDVR2oka/4pEdr0kkN3Cg5Xa1F00xTnvhuB1tCLA3D9pv7SY JD/lK3n2qM9irU+cvsn5OLjHwAEgIF1oNCdAWCoE8YhasaveFep8jastxhIEejEQd43D nk8yiGIc3H09fNAwJjswaYdNHVRvJ37yWoron6M+bYWVZ16Q53qnwHDsa0FASORWtsmc qgkAzzoQcD4aWvx+UdM3zOnpZXb2NgNe7PWTCqqEHxlPhHHGKxO+WC2snA9zMkt0eOPp huf6HqYPxCKBdIpz1hOgUPYukQFAz8M1x7Xly++U5VmMPVv3v0TcREIGkLmXM5NlvgKm DKzw==
X-Received: by 10.224.11.9 with SMTP id r9mr23103790qar.43.1407175843072; Mon, 04 Aug 2014 11:10:43 -0700 (PDT)
Received: from [10.82.101.21] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id s7sm8832174qgd.20.2014.08.04.11.10.41 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 11:10:42 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com>
Date: Mon, 4 Aug 2014 14:10:40 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/uBa8YvKiPBWq6Vf8fYl6IJuELJg
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 18:10:53 -0000

On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert) =
<pthubert@cisco.com> wrote:

> The change is now done, Ralph.
>=20
> The only difference between draft-thubert-6man-flow-label-for-rpl-03 =
and draft-thubert-6man-flow-label-for-rpl-04 is=20
>=20
> Updates: 6437 (if approved)

I suggest adding a section to your doc that explains exactly what is =
being updated in RFC 6437.

- Ralph

>=20
> Cheers,
>=20
> Pascal
>=20
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ralph Droms
> Sent: samedi 2 ao=FBt 2014 22:57
> To: Routing Over Low power and Lossy networks
> Cc: Michael Richardson; ipv6@ietf.org
> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
>=20
>=20
>=20
> On Aug 2, 2014, at 4:48 PM, "Pascal Thubert (pthubert)" =
<pthubert@cisco.com> wrote:
> That sounds right, Michael,=20
>=20
> I agree that "updates 6437" is a right thing to do.
>=20
> though slightly on the overkill side.=20
>=20
> I disagree that it is overkill.  In my opinion, =
draft-thubert-6man-flow-label-for-RPL pretty clearly contradicts RFC =
6437, so "updates 6437" is an appropriate action.
>=20
>  And this is consistent with what Brian suggested. This can be added =
during the rfc editor process I expect?
>=20
> It should be added as soon as possible, certainly before it goes to =
the IESG.  In my opinion, the change might warrant a new or extended =
WGLC; that action is up to the chairs, of course.
>=20
> - Ralph
>=20
>=20
> Pascal
>=20
> Le 2 ao=FBt 2014 =E0 21:09, "Michael Richardson" =
<mcr+ietf@sandelman.ca> a =E9crit :
>=20
>=20
> Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> OTOH you need to understand that there is no need for a bis to update =
a
> MUST in an RFC. We recognize the imperfection in our work and are
> always ready to revise and amend after due consideration.
>=20
> Perhaps this document UPDATES 6437 then?
>=20
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -=3D IPv6 IoT consulting =3D-
>=20
>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From nobody Mon Aug  4 11:23:13 2014
Return-Path: <pal@cs.stanford.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154121A00D7; Mon,  4 Aug 2014 11:23:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 fkpsltyXDc-z; Mon,  4 Aug 2014 11:23:09 -0700 (PDT)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0351A005C; Mon,  4 Aug 2014 11:23:09 -0700 (PDT)
Received: from 108-192-17-194.lightspeed.sntcca.sbcglobal.net ([108.192.17.194]:49954 helo=phoenix.att.net) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XEMuW-0001Mu-Mf; Mon, 04 Aug 2014 11:23:08 -0700
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com>
Date: Mon, 4 Aug 2014 11:23:07 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com>
To: Ralph Droms <rdroms.ietf@gmail.com>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: a11a15d02c0ec4233875b3872b0caebb
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/iuRLB2-qF2DZe-2oOUOvM4U6EaU
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "Pascal Thubert \(pthubert\)" <pthubert@cisco.com>, "ipv6@ietf.org" <ipv6@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 18:23:11 -0000

On Aug 4, 2014, at 11:10 AM, Ralph Droms <rdroms.ietf@gmail.com> wrote:

>=20
> On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert) =
<pthubert@cisco.com> wrote:
>=20
>> The change is now done, Ralph.
>>=20
>> The only difference between draft-thubert-6man-flow-label-for-rpl-03 =
and draft-thubert-6man-flow-label-for-rpl-04 is=20
>>=20
>> Updates: 6437 (if approved)
>=20
> I suggest adding a section to your doc that explains exactly what is =
being updated in RFC 6437.
>=20
> - Ralph


I agree. I think some of the text in 1.3 can be re-used for this =
purpose.

Phil=


From nobody Mon Aug  4 11:24:53 2014
Return-Path: <pal@cs.stanford.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4216E1A005C; Mon,  4 Aug 2014 11:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 bYjxXJv1vA51; Mon,  4 Aug 2014 11:24:48 -0700 (PDT)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB211A00E5; Mon,  4 Aug 2014 11:24:35 -0700 (PDT)
Received: from 108-192-17-194.lightspeed.sntcca.sbcglobal.net ([108.192.17.194]:49959 helo=phoenix.att.net) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XEMvy-0001V9-Lr; Mon, 04 Aug 2014 11:24:35 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <23675.1407160947@sandelman.ca>
Date: Mon, 4 Aug 2014 11:24:39 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <7FA35615-C9A0-4591-B60B-874B95E87D1E@cs.stanford.edu>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <53DB675C.9000502@tm.uka.de> <CAMsDxWTGG1MMaYPTcQqsBb78GuzsPun_k7r6Qi29fELp=z-mKA@mail.gmail.com> <53DB88B7.80205@tm.uka.de> <CAMsDxWROddNcfcWATpr4wmM+iMGhn4xMGO77f6hGvmRB9+Ow6g@mail.gmail.com> <B80833DA-CF92-4F84-91FA-A45A74B4D03D@cs.stanford.edu> <6439.1407007393@sandelman.ca> <06C4F090-4731-4917-84F1-7C5798574F42@cs.stanford.edu> <CADJ9OA_=FnuaaR_On_AJoqSVHfvUtcsxcM7WyLMR41AwQA5B-A@mail.gmail.com> <9A525A33-FC53-4574-86F9-0FC4E8E5EC43@cs.stanford.edu> <23675.1407160947@sandelman.ca>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 2c21b60125577a2cbf52524016395bed
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/yY7YZHCRVhe5uh21ly04EjWACl0
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 18:24:50 -0000

On Aug 4, 2014, at 7:02 AM, Michael Richardson <mcr+ietf@sandelman.ca> =
wrote:

>=20
> Philip Levis <pal@cs.stanford.edu> wrote:
>> 5% or 10% isn't huge, but it is significant and valuable. I've just
>> been a bit confused as to why this proposal has been trotted around =
for
>> 4 years and yet no-one had yet even done this simple calculation, so =
WG
>> members could make an informed engineering decision. IMO, a 5-10%
>=20
> my opinion:
>=20
> 1) the exact calculation was hard to really do until 6tisch made it =
clearer
>   what the duty cycle was going to be.
>=20
> 2) it took awhile to come back to figuring out how to deal with the =
flow
>   label issue.
>=20
> 3) it is now clear exactly how close many of our packets are to the =
127 byte
>   limit, and how much the HbH header hurts if it is the reason we go =
into
>   two fraglets.
>=20
> 4) we had other things to worry about!

Michael,

1) doesn't depend on 6tisch, it's based on 15.4e timing, and could have =
been calculated for any other low power link layer. Years ago.

2) The proposal isn't substantively different -- in terms of bytes =
sent/saved -- from the first version of the proposal suggested in 2010.

3) The analysis so far hasn't even touched this issue.

4) The entire introduction/motivation for the proposal is saving energy! =
But no-one thought it important enough to actually estimate how much =
energy it would save (in a best case, typical case) before a last call?

Here's my worry -- the tradeoffs of low-power networks are very =
different than the kinds of networks the IETF typically deals with. =
It'll lead to protocol decisions a bit different than always-on =
networks. But that doesn't mean it should be used as a blanket =
justification or motivation. Otherwise it's just smoke and mirrors =
(energy is critical! battery is critical! we therefore need less =
CPU-intensive compression schemes! here's a new one. we need less =
CPU-intensive cryptographic schemes! here's a new one.). If energy is so =
important, and this would be such a big savings, then why the =
recalcitrance to estimate it?  It doesn't help my confidence in the =
engineering when some of the back-of-the-envelope analyses (Xavier's) =
have basic arithmetic errors that seem incognizant of how to measure =
energy.=20

Phil


From nobody Mon Aug  4 11:52:55 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F111A0107; Mon,  4 Aug 2014 11:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 cgxAY2FzZbv5; Mon,  4 Aug 2014 11:52:47 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE74D1A00F2; Mon,  4 Aug 2014 11:52:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3099; q=dns/txt; s=iport; t=1407178366; x=1408387966; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Uz8edhBF+3tpo4HTxDhKvQFo8Z/z1KuwSSxDOr+TLGM=; b=ZybPunGFvYsIOLz08LZAvAsMdppw+lM/Z8Obx8Y2UgTxpA6+DLNm1HCI zu9zCwtzN9B/cxGU6oY2YC/m3rXO6vDhD3KzfYNkpu/fzo5tfcytjR/3O DgGTOPX7Zg6qKa6/1hzwVKlBOB34Q9k3e0I5jGhQVtUV62lQ6ndGN1px0 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkIFAH/V31OtJA2E/2dsb2JhbABbgw1SVwTMMAqHSgGBERZ3hAMBAQEEAQEBawsMBAIBCA4DBAEBAQodByEGCxQJCAEBBA4FCIgmAxENvgQNhmMTBI0fgV8dMQcGgymBHAWKVY8qkD6GKINNbIFG
X-IronPort-AV: E=Sophos;i="5.01,799,1400025600"; d="scan'208";a="66440083"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP; 04 Aug 2014 18:52:45 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s74IqjqQ000673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 18:52:45 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 13:52:45 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Ralph Droms <rdroms.ietf@gmail.com>
Subject: RE: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoAAK2YQAAAkecMA=
Date: Mon, 4 Aug 2014 18:52:44 +0000
Deferred-Delivery: Mon, 4 Aug 2014 18:52:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D1A13E@xmb-rcd-x01.cisco.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com>
In-Reply-To: <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.74.174]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/8zQHmdrNEQ58iam4hY6WSJSA86o
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 18:52:52 -0000

Hi Ralph:

This is exactly section 3.=20

The section provides a scope of applicability (the RPL domain) and the chan=
ges from RFC 6437 that become acceptable within that scope.

Cheers,

Pascal

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms.ietf@gmail.com]
> Sent: lundi 4 ao=FBt 2014 20:11
> To: Pascal Thubert (pthubert)
> Cc: Routing Over Low power and Lossy networks; Michael Richardson;
> ipv6@ietf.org
> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
>=20
>=20
> On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert)
> <pthubert@cisco.com> wrote:
>=20
> > The change is now done, Ralph.
> >
> > The only difference between draft-thubert-6man-flow-label-for-rpl-03
> > and draft-thubert-6man-flow-label-for-rpl-04 is
> >
> > Updates: 6437 (if approved)
>=20
> I suggest adding a section to your doc that explains exactly what is bein=
g
> updated in RFC 6437.
>=20
> - Ralph
>=20
> >
> > Cheers,
> >
> > Pascal
> >
> > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ralph Droms
> > Sent: samedi 2 ao=FBt 2014 22:57
> > To: Routing Over Low power and Lossy networks
> > Cc: Michael Richardson; ipv6@ietf.org
> > Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
> >
> >
> >
> > On Aug 2, 2014, at 4:48 PM, "Pascal Thubert (pthubert)"
> <pthubert@cisco.com> wrote:
> > That sounds right, Michael,
> >
> > I agree that "updates 6437" is a right thing to do.
> >
> > though slightly on the overkill side.
> >
> > I disagree that it is overkill.  In my opinion, draft-thubert-6man-flow=
-label-
> for-RPL pretty clearly contradicts RFC 6437, so "updates 6437" is an
> appropriate action.
> >
> >  And this is consistent with what Brian suggested. This can be added du=
ring
> the rfc editor process I expect?
> >
> > It should be added as soon as possible, certainly before it goes to the=
 IESG.
> In my opinion, the change might warrant a new or extended WGLC; that
> action is up to the chairs, of course.
> >
> > - Ralph
> >
> >
> > Pascal
> >
> > Le 2 ao=FBt 2014 =E0 21:09, "Michael Richardson" <mcr+ietf@sandelman.ca=
> a
> =E9crit :
> >
> >
> > Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> > OTOH you need to understand that there is no need for a bis to update
> > a MUST in an RFC. We recognize the imperfection in our work and are
> > always ready to revise and amend after due consideration.
> >
> > Perhaps this document UPDATES 6437 then?
> >
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software
> Works
> > -=3D IPv6 IoT consulting =3D-
> >
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> > _______________________________________________
> > Roll mailing list
> > Roll@ietf.org
> > https://www.ietf.org/mailman/listinfo/roll


From nobody Mon Aug  4 12:44:20 2014
Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5FF1A0305; Mon,  4 Aug 2014 12:44:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 XdxeDzmfmnbA; Mon,  4 Aug 2014 12:44:14 -0700 (PDT)
Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651581A0301; Mon,  4 Aug 2014 12:44:14 -0700 (PDT)
Received: by mail-qa0-f48.google.com with SMTP id m5so7281111qaj.21 for <multiple recipients>; Mon, 04 Aug 2014 12:44:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5Ltqlyh35MTWx9l+txl8Yu3tfNwVBN+BV3dzh9maHCg=; b=bmWTi+UGjnODlRNMhXtkYOYqayx3PK3zs5Pcpvy7lF09rHct8jTxt8Aw/hl+3Aa3jj HHCFAgXiQvuy67AEKWzFupReHjfYwCWGmlUMNcr9wo3ooYW9YnV5UxyIJHsiF1LQNmtv +ywjeM+lvjsRSLlu1rxRGNUUvhaen1/ICfealo1Xj3MXVuwa53NTH0CiWnVQpYmrnPiQ GEMavom8EJnzogXOc/K//o6cqanQBX035y5K0Ksrxt6LO7E8W9S6Idux06xYb07MgtvH uqYr9eoGFF+IjIMjdJ/v0ty232i3qiIr/mEj5nPGDbKHIET/xZHdxLSasBX7BGsTBCOh VH4Q==
X-Received: by 10.140.17.81 with SMTP id 75mr37557788qgc.36.1407181453580; Mon, 04 Aug 2014 12:44:13 -0700 (PDT)
Received: from [10.82.101.21] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id f92sm20246655qgd.44.2014.08.04.12.44.11 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 12:44:12 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD842D1A13E@xmb-rcd-x01.cisco.com>
Date: Mon, 4 Aug 2014 15:44:10 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <00DFB20D-0A21-4AB7-B56B-F0E0F6DC01B3@gmail.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <E045AECD98228444A58C61C200AE1BD842D1A13E@xmb-rcd-x01.cisco.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/gDxaSEYZqJkZEiLUNpMFtQye-tI
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 19:44:17 -0000

On Aug 4, 2014, at 2:52 PM 8/4/14, Pascal Thubert (pthubert) =
<pthubert@cisco.com> wrote:

> Hi Ralph:
>=20
> This is exactly section 3.=20
>=20
> The section provides a scope of applicability (the RPL domain) and the =
changes from RFC 6437 that become acceptable within that scope.

I disagree.  Section 3 explains how =
draft-thubert-6man-flow-label-for-rpl can be interpreted as following =
RFC 6437 rather than describing the specific ways in which it updates =
RFC 6437.

For example, as Philip wrote:

> "but the RFC also indicates a violation to the rule can be accepted =
for compelling reasons, and that security is a case justifying such a =
violation.  This specification suggests that energy-saving is another =
compelling    reason for a violation to the aforementioned rule."
>=20
> This is *not* what 6437 says. It says for compelling operational =
security reasons, not compelling reasons, of which one case is security.

- Ralph


>=20
> Cheers,
>=20
> Pascal
>=20
>> -----Original Message-----
>> From: Ralph Droms [mailto:rdroms.ietf@gmail.com]
>> Sent: lundi 4 ao=FBt 2014 20:11
>> To: Pascal Thubert (pthubert)
>> Cc: Routing Over Low power and Lossy networks; Michael Richardson;
>> ipv6@ietf.org
>> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
>>=20
>>=20
>> On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert)
>> <pthubert@cisco.com> wrote:
>>=20
>>> The change is now done, Ralph.
>>>=20
>>> The only difference between draft-thubert-6man-flow-label-for-rpl-03
>>> and draft-thubert-6man-flow-label-for-rpl-04 is
>>>=20
>>> Updates: 6437 (if approved)
>>=20
>> I suggest adding a section to your doc that explains exactly what is =
being
>> updated in RFC 6437.
>>=20
>> - Ralph
>>=20
>>>=20
>>> Cheers,
>>>=20
>>> Pascal
>>>=20
>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ralph Droms
>>> Sent: samedi 2 ao=FBt 2014 22:57
>>> To: Routing Over Low power and Lossy networks
>>> Cc: Michael Richardson; ipv6@ietf.org
>>> Subject: Re: [Roll] WGLC for =
draft-thubert-6man-flow-label-for-rpl-03
>>>=20
>>>=20
>>>=20
>>> On Aug 2, 2014, at 4:48 PM, "Pascal Thubert (pthubert)"
>> <pthubert@cisco.com> wrote:
>>> That sounds right, Michael,
>>>=20
>>> I agree that "updates 6437" is a right thing to do.
>>>=20
>>> though slightly on the overkill side.
>>>=20
>>> I disagree that it is overkill.  In my opinion, =
draft-thubert-6man-flow-label-
>> for-RPL pretty clearly contradicts RFC 6437, so "updates 6437" is an
>> appropriate action.
>>>=20
>>> And this is consistent with what Brian suggested. This can be added =
during
>> the rfc editor process I expect?
>>>=20
>>> It should be added as soon as possible, certainly before it goes to =
the IESG.
>> In my opinion, the change might warrant a new or extended WGLC; that
>> action is up to the chairs, of course.
>>>=20
>>> - Ralph
>>>=20
>>>=20
>>> Pascal
>>>=20
>>> Le 2 ao=FBt 2014 =E0 21:09, "Michael Richardson" =
<mcr+ietf@sandelman.ca> a
>> =E9crit :
>>>=20
>>>=20
>>> Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>>> OTOH you need to understand that there is no need for a bis to =
update
>>> a MUST in an RFC. We recognize the imperfection in our work and are
>>> always ready to revise and amend after due consideration.
>>>=20
>>> Perhaps this document UPDATES 6437 then?
>>>=20
>>> --
>>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software
>> Works
>>> -=3D IPv6 IoT consulting =3D-
>>>=20
>>>=20
>>>=20
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>=20
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>=20


From nobody Mon Aug  4 13:44:52 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4790F1A032A; Mon,  4 Aug 2014 13:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 RHdXrnJcAgx1; Mon,  4 Aug 2014 13:44:47 -0700 (PDT)
Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31FA01A0326; Mon,  4 Aug 2014 13:44:47 -0700 (PDT)
Received: by mail-pa0-f42.google.com with SMTP id lf10so10604096pab.15 for <multiple recipients>; Mon, 04 Aug 2014 13:44:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wPBLSy2C94IbG6D+WAf+DkWtT1LLKVBzAuHod1qqHUU=; b=UkEY0hcw3FfJWPBkkdJ1PbbnoJfaqg7rd5zht4lw8K80bkP7nageMF4idhC3HAc91T RSjVEqLBCiLUKBehCVQcCB6Ba2rAyIUjfXPwWpJASk8XoQ/pqbhnhONdDExYYM7tEc+f ijwYtrV3Rxc/gs1tPhl2vUhZcGgwJKgol7cmVY0VnAvopsJhVEa30gNTjTPIvGPVs9sx qkgssKlsIydvY3YREZ6zPfidTGXqqfRVs84VsBPmwAnJNvLG/Sz3TMRElrgiJQJzGAJ6 LvT8jmRzWY7RS+FSEvTWlW5F07Eyq2EHOH6vRIZ1dSRAf0wNaHrYwB8uUK07Uzj0yDiv sY5w==
X-Received: by 10.66.66.101 with SMTP id e5mr6021587pat.100.1407185086836; Mon, 04 Aug 2014 13:44:46 -0700 (PDT)
Received: from [192.168.178.23] (202.195.69.111.dynamic.snap.net.nz. [111.69.195.202]) by mx.google.com with ESMTPSA id ya1sm1352974pbb.91.2014.08.04.13.44.44 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 13:44:46 -0700 (PDT)
Message-ID: <53DFF0BD.8020409@gmail.com>
Date: Tue, 05 Aug 2014 08:44:45 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ralph Droms <rdroms.ietf@gmail.com>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <E045AECD98228444A58C61C200AE1BD842D1A13E@xmb-rcd-x01.cisco.com> <00DFB20D-0A21-4AB7-B56B-F0E0F6DC01B3@gmail.com>
In-Reply-To: <00DFB20D-0A21-4AB7-B56B-F0E0F6DC01B3@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/-mAF3bmDJcIMpIYz4_O-vsfCmV8
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "Pascal Thubert \(pthubert\)" <pthubert@cisco.com>, "ipv6@ietf.org" <ipv6@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Aug 2014 20:44:49 -0000

Ralph,

On 05/08/2014 07:44, Ralph Droms wrote:
> On Aug 4, 2014, at 2:52 PM 8/4/14, Pascal Thubert (pthubert) <pthubert@=
cisco.com> wrote:
>=20
>> Hi Ralph:
>>
>> This is exactly section 3.=20
>>
>> The section provides a scope of applicability (the RPL domain) and the=
 changes from RFC 6437 that become acceptable within that scope.
>=20
> I disagree.  Section 3 explains how draft-thubert-6man-flow-label-for-r=
pl can be interpreted as following RFC 6437 rather than describing the sp=
ecific ways in which it updates RFC 6437.
>=20
> For example, as Philip wrote:
>=20
>> "but the RFC also indicates a violation to the rule can be accepted fo=
r compelling reasons, and that security is a case justifying such a viola=
tion.  This specification suggests that energy-saving is another compelli=
ng    reason for a violation to the aforementioned rule."
>>
> This is *not* what 6437 says. It says for compelling operational securi=
ty reasons, not compelling reasons, of which one case is security.

It also says that there may be stateful ways of using the flow label.
It's almost a matter of taste whether the RPL usage is a change to
the phrase that you quote, or a stateful usage within an RPL domain
(reverting to stateless use when leaving RPL). I agree that the draft
could usefully be explicit about this.

   Brian

>=20
> - Ralph
>=20
>=20
>> Cheers,
>>
>> Pascal
>>
>>> -----Original Message-----
>>> From: Ralph Droms [mailto:rdroms.ietf@gmail.com]
>>> Sent: lundi 4 ao=C3=BBt 2014 20:11
>>> To: Pascal Thubert (pthubert)
>>> Cc: Routing Over Low power and Lossy networks; Michael Richardson;
>>> ipv6@ietf.org
>>> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03=

>>>
>>>
>>> On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert)
>>> <pthubert@cisco.com> wrote:
>>>
>>>> The change is now done, Ralph.
>>>>
>>>> The only difference between draft-thubert-6man-flow-label-for-rpl-03=

>>>> and draft-thubert-6man-flow-label-for-rpl-04 is
>>>>
>>>> Updates: 6437 (if approved)
>>> I suggest adding a section to your doc that explains exactly what is =
being
>>> updated in RFC 6437.
>>>
>>> - Ralph
>>>
>>>> Cheers,
>>>>
>>>> Pascal
>>>>
>>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ralph Droms
>>>> Sent: samedi 2 ao=C3=BBt 2014 22:57
>>>> To: Routing Over Low power and Lossy networks
>>>> Cc: Michael Richardson; ipv6@ietf.org
>>>> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-0=
3
>>>>
>>>>
>>>>
>>>> On Aug 2, 2014, at 4:48 PM, "Pascal Thubert (pthubert)"
>>> <pthubert@cisco.com> wrote:
>>>> That sounds right, Michael,
>>>>
>>>> I agree that "updates 6437" is a right thing to do.
>>>>
>>>> though slightly on the overkill side.
>>>>
>>>> I disagree that it is overkill.  In my opinion, draft-thubert-6man-f=
low-label-
>>> for-RPL pretty clearly contradicts RFC 6437, so "updates 6437" is an
>>> appropriate action.
>>>> And this is consistent with what Brian suggested. This can be added =
during
>>> the rfc editor process I expect?
>>>> It should be added as soon as possible, certainly before it goes to =
the IESG.
>>> In my opinion, the change might warrant a new or extended WGLC; that
>>> action is up to the chairs, of course.
>>>> - Ralph
>>>>
>>>>
>>>> Pascal
>>>>
>>>> Le 2 ao=C3=BBt 2014 =C3=A0 21:09, "Michael Richardson" <mcr+ietf@san=
delman.ca> a
>>> =C3=A9crit :
>>>>
>>>> Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>>>> OTOH you need to understand that there is no need for a bis to updat=
e
>>>> a MUST in an RFC. We recognize the imperfection in our work and are
>>>> always ready to revise and amend after due consideration.
>>>>
>>>> Perhaps this document UPDATES 6437 then?
>>>>
>>>> --
>>>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software
>>> Works
>>>> -=3D IPv6 IoT consulting =3D-
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------=

>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------=

>>>>
>>>> _______________________________________________
>>>> Roll mailing list
>>>> Roll@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/roll
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>=20


From nobody Mon Aug  4 17:19:05 2014
Return-Path: <pal@cs.stanford.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FED81A0AB5; Mon,  4 Aug 2014 17:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 5Vakddq1MdTs; Mon,  4 Aug 2014 17:18:58 -0700 (PDT)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC76C1A0010; Mon,  4 Aug 2014 17:18:58 -0700 (PDT)
Received: from [76.14.66.110] (port=52151 helo=[192.168.0.103]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XESSv-00019f-5Q; Mon, 04 Aug 2014 17:18:57 -0700
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <53DFF0BD.8020409@gmail.com>
Date: Mon, 4 Aug 2014 17:18:59 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <0DC174C1-1D60-4A4B-97E0-064B7971CB7F@cs.stanford.edu>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <E045AECD98228444A58C61C200AE1BD842D1A13E@xmb-rcd-x01.cisco.com> <00DFB20D-0A21-4AB7-B56B-F0E0F6DC01B3@gmail.com> <53DFF0BD.8020409@gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 126b1dc68df40fcb6eeab1e6794671ae
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/S5XRJgWOcDx3nV4XGgtso3xNdtg
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "ipv6@ietf.org" <ipv6@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Aug 2014 00:19:00 -0000

On Aug 4, 2014, at 1:44 PM, Brian E Carpenter =
<brian.e.carpenter@gmail.com> wrote:

> It also says that there may be stateful ways of using the flow label.
> It's almost a matter of taste whether the RPL usage is a change to
> the phrase that you quote, or a stateful usage within an RPL domain
> (reverting to stateless use when leaving RPL). I agree that the draft
> could usefully be explicit about this.

I'm a bit confused -- the MUST statement is in Section 2, entitled "IPv6 =
Flow Label Specification". There doesn't seem to be any text that =
suggests this restriction is dependent on stateless operation. My =
interpretation, based on the title and its placement in the document, is =
that the text in this section applies to any and all uses of the flow =
label. How am I reading this wrong? Should I be reading the final MUST =
("=85 MUST choose labels that conform to Section 3 of this =
specification") in Section 4 to implicitly mean that Section 2 doesn't =
necessarily apply? Or is it optional for stateless as well?

My (admittedly naive) reading is that Sections 3 and 4 related to how =
source nodes choose a flow label. (S2: "To enable Flow-Label-based =
classification, source nodes SHOULD assign each unrelated transport =
connection and application data stream to a new flow.")  This is =
distinct from what forwarding nodes do to flow labels, which Section 2 =
covers.=20

Phil



From nobody Mon Aug  4 18:06:53 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E251A0ACC; Mon,  4 Aug 2014 18:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 76Wz-vSjlwEk; Mon,  4 Aug 2014 18:06:48 -0700 (PDT)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBC01A0ACB; Mon,  4 Aug 2014 18:06:48 -0700 (PDT)
Received: by mail-pa0-f43.google.com with SMTP id lf10so321625pab.16 for <multiple recipients>; Mon, 04 Aug 2014 18:06:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=q3omwt7IwTjZ2G84U2AQvkDRX6XjIWAp8WbO3+0v+Pw=; b=yG8rrpJHwVj/2VilCTgFCElebPRdky9FV3pqiOYxzQtUTIceIDFE1F7/HAOBG9BKrP cNBhAchk+n/97fuILhXrcV15bsca4dvy4b0DQqcPTUO28gAyutT+3n3AAS3ILs516BzF 0EdCZW6GgOE34xE6I1HvRMFwzAEC0NMd5ozCG4ig9uwFMUm191eOUHk/9oRT6jcsY3s2 TQf1p+41jovPHqb4EZSeEbtTYQtv4q31g8FEDA1DdICkQZ4LBjx18/WCIs35NNyk28TQ QA491yO4U8yZ/J22ypYmWHrfBfEW05Vg8Sj8R8GVJiZQKTTeNOpbdzY4Z+XTyaVL5iAY Q2qg==
X-Received: by 10.68.87.101 with SMTP id w5mr418371pbz.130.1407200807284; Mon, 04 Aug 2014 18:06:47 -0700 (PDT)
Received: from [192.168.178.23] (202.195.69.111.dynamic.snap.net.nz. [111.69.195.202]) by mx.google.com with ESMTPSA id up2sm115836pbc.21.2014.08.04.18.06.44 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 18:06:46 -0700 (PDT)
Message-ID: <53E02E25.2030701@gmail.com>
Date: Tue, 05 Aug 2014 13:06:45 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Philip Levis <pal@cs.stanford.edu>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <E045AECD98228444A58C61C200AE1BD842D1A13E@xmb-rcd-x01.cisco.com> <00DFB20D-0A21-4AB7-B56B-F0E0F6DC01B3@gmail.com> <53DFF0BD.8020409@gmail.com> <0DC174C1-1D60-4A4B-97E0-064B7971CB7F@cs.stanford.edu>
In-Reply-To: <0DC174C1-1D60-4A4B-97E0-064B7971CB7F@cs.stanford.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/kXjgIMnlcgthKKjJe48YtDPdhzI
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Aug 2014 01:06:50 -0000

Philip,

On 05/08/2014 12:18, Philip Levis wrote:
> On Aug 4, 2014, at 1:44 PM, Brian E Carpenter <brian.e.carpenter@gmail.=
com> wrote:
>=20
>> It also says that there may be stateful ways of using the flow label.
>> It's almost a matter of taste whether the RPL usage is a change to
>> the phrase that you quote, or a stateful usage within an RPL domain
>> (reverting to stateless use when leaving RPL). I agree that the draft
>> could usefully be explicit about this.
>=20
> I'm a bit confused -- the MUST statement is in Section 2, entitled "IPv=
6 Flow Label Specification". There doesn't seem to be any text that sugge=
sts this restriction is dependent on stateless operation. My interpretati=
on, based on the title and its placement in the document, is that the tex=
t in this section applies to any and all uses of the flow label. How am I=
 reading this wrong? Should I be reading the final MUST ("=E2=80=A6 MUST =
choose labels that conform to Section 3 of this specification") in Sectio=
n 4 to implicitly mean that Section 2 doesn't necessarily apply? Or is it=
 optional for stateless as well?

I think you're right that it could have been worded more precisely.
My personal mental model has always included something like the
RPL application (i.e. a specific usage of the flow label within
a closed domain) *and* generic stateless use by default, but I
don't think that model has ever been the general consensus, so
what is supposed to happen at the boundary between such a closed
domain and the rest of the Internet has never been written down.

   Brian

> My (admittedly naive) reading is that Sections 3 and 4 related to how s=
ource nodes choose a flow label. (S2: "To enable Flow-Label-based classif=
ication, source nodes SHOULD assign each unrelated transport connection a=
nd application data stream to a new flow.")  This is distinct from what f=
orwarding nodes do to flow labels, which Section 2 covers.=20
>=20
> Phil
>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>=20


From nobody Mon Aug  4 21:00:34 2014
Return-Path: <markzzzsmith@yahoo.com.au>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EB71B2807 for <ipv6@ietfa.amsl.com>; Mon,  4 Aug 2014 21:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.201
X-Spam-Level: **
X-Spam-Status: No, score=2.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 7l_cMnvuUPPv for <ipv6@ietfa.amsl.com>; Mon,  4 Aug 2014 21:00:29 -0700 (PDT)
Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1291B2805 for <ipv6@ietf.org>; Mon,  4 Aug 2014 21:00:29 -0700 (PDT)
Received: from [98.139.212.149] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 05 Aug 2014 04:00:28 -0000
Received: from [98.139.212.224] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 05 Aug 2014 04:00:28 -0000
Received: from [127.0.0.1] by omp1033.mail.bf1.yahoo.com with NNFMP; 05 Aug 2014 04:00:28 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 277371.2157.bm@omp1033.mail.bf1.yahoo.com
Received: (qmail 60336 invoked by uid 60001); 5 Aug 2014 04:00:28 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024;  t=1407211228; bh=qpTo88WZatGniYe14yXDxESUwPD4oOQKv9FI6pUWHgg=;  h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=jKxHmafcpale6tI6tWvPVLN6m/6to5Ep0tKdjKrNIKbzUcAiSbgWVK/513+WHoZrqj03Zq6wzJxnm4XUCjGIJwU419ucxQR9hDb2936mUgktGk3jbWRIq3O8wM70ltQ7T2eUeKR4jreqLVhGR8AFEq68apeitRcL1fUpjvAAhmw=
X-YMail-OSG: TIJ7nF4VM1mauVC3xzeJO5469jxU.q5wG23Nq7bUQn8eheg cf2gFQ2gBm5ZBAfQlRhWnUwE0_LIs4CWdJmPqU6WaRZCg_fh9Djxzq9fssUy FMW7TE0GV2Lf9e6pf7gR59wTSqgGMjWr_89cG4Mhq78L12ZL_ZuId13dx3cU VlI68hFW7DrK.ArcuMbSbOSuk5YrKfxr4j4hz_lnZj2YMPfrY9jcndbXca.3 9QMAlIforfI4.68mnPxRyMcHo6TzHj2AQGnGniaFVvRs0GGdkrrdJ956101D F5TjSWsUi._6X3fL0Pz7wWyI6YT9yuh.nyduAzTlcMDuEaJS_NRrd6k3CAgB ZUySB7XIMJUarGklb9EaG5IC.iAj9wOZR7lPeVrEK40V3a489I98iyjHOUXn sz2Pa0WYFjcdZtEDi6PnIWD4sVopwG2xUoFXbRUl32BpGInvzNG2H77QLbdo hIqtW9yQKvX09GBxQQwj6XqAYiMzOZcMa8lP0BDp3yy3q3J_DnTPPThernqo QFiXbPnpoTyNy9q3c6BKrgVhhLoC.Psun9UTqRFYBNV_CTxlVQWP7LeaTTWt fEw--
Received: from [150.101.221.237] by web162201.mail.bf1.yahoo.com via HTTP; Mon, 04 Aug 2014 21:00:28 PDT
X-Rocket-MIMEInfo: 002.001, SGksCgpJIHdhcyBhc2tlZCB0byBkbyBhIGRldGFpbGVkIHJldmlldyBvZiB0aGUgJ3doeTY0JyBkcmFmdC4gSGVyZSBhcmUgbXkgdGhvdWdodHMgYW5kIGNvbW1lbnRzLiBTb3JyeSBmb3IgdGhlIGRlbGF5LCBJJ3ZlIGJlZW4gYSBiaXQgaWxsIG92ZXIgdGhlIGxhc3QgZGF5IG9yIHNvLgoKR2VuZXJhbAp.fn5.fn4KCkkgdGhpbmsgaXQgY292ZXJzIHRoZSB0b3BpYyB3ZWxsLCBhbmQgYW5zd2VycyB0aGUgZnVuZGFtZW50YWwgcXVlc3Rpb25zIG9mIHdoeSBJSURzIGFyZSA2NCBiaXRzIGFuZCB3aHkgdGhlaXIBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.198.689
Message-ID: <1407211228.81108.YahooMailNeo@web162201.mail.bf1.yahoo.com>
Date: Mon, 4 Aug 2014 21:00:28 -0700
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Subject: Detailed review of "Analysis of the 64-bit Boundary in IPv6 Addressing"
To: 6man Mailing List <ipv6@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/nC6jpLZxgKH7cBTJ-g3GdHkmHHI
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Aug 2014 04:00:32 -0000

Hi,=0A=0AI was asked to do a detailed review of the 'why64' draft. Here are=
 my thoughts and comments. Sorry for the delay, I've been a bit ill over th=
e last day or so.=0A=0AGeneral=0A~~~~~~=0A=0AI think it covers the topic we=
ll, and answers the fundamental questions of why IIDs are 64 bits and why t=
heir 64 bit size should be preserved. I could not think of any areas of rel=
ated discussion that were missed.=0A=0ASuggested Changes=0A~~~~~~~~~~~~~~~~=
=0A=0AMy suggested changes are limited to what I think might be some better=
 wordings or grammar (sometimes trivial), additional references and some re=
ordering of sections of text.=0A=0ABelow is in draft top-to-bottom order.=
=0A=0A=0A1.=A0=A0Introduction=0A=0A- additional comma=0A=0A"IPv6 addresses =
were originally chosen to be 128 bits long to provide=0A=A0 =A0flexibility =
and new possibilities, rather than simply relieving the=0A=A0 =A0IPv4 addre=
ss shortage*,* by doubling the address size to 64 bits."=0A=0A=0A=0A- chang=
e 'done' to 'completed' (or 'complete' - both sound right, so I'm not sure =
which is better)=0A=0A"The notion of a /64 boundary in the address was intr=
oduced after the=0A=A0 =A0initial design of IPv6 was done, following a peri=
od when it was=0A=A0 =A0expected to be at /80."=0A=0Ato=0A=0A"The notion of=
 a /64 boundary in the address was introduced after the=0A=A0 =A0initial de=
sign of IPv6 was *completed*, following a period when it was=0A=A0 =A0expec=
ted to be at /80."=0A=0A=0A=0A- additional commas=0A=0A"The addressing arch=
itecture*,* as modified by [RFC7136]*,*=0A=A0 =A0states that "For all unica=
st addresses, except those that start with=0A=A0 =A0the binary value 000, I=
nterface IDs are required to be 64 bits long."=0A=0A=0A=0A2.  Advantages of=
 a fixed identifier length=0A=0A- change 'wide-area' to 'aggregate'=0A=0A"A=
n immediate effect of fixing the IID length at 64=0A=A0 =A0bits is, of cour=
se, that it fixes the subnet prefix length also at 64=0A=A0 =A0bits, regard=
less of the wide-area prefix assigned to the site=0A=A0 =A0concerned, ..."=
=0A=0Ato=0A=0A"An immediate effect of fixing the IID length at 64=0A=A0 =A0=
bits is, of course, that it fixes the subnet prefix length also at 64=0A=A0=
 =A0bits, regardless of the *aggregate* prefix assigned to the site=0A=A0 =
=A0concerned, ..."=0A=0A=0A=0A- add 'simpler and'=0A=0A"Network design is t=
herefore much=0A=A0 =A0 =A0 more straightforward."=0A=0Ato=A0=0A=0A"Network=
 design is therefore much *simpler and*=0A=A0 =A0 =A0 more straightforward.=
"=0A=0A=0A=0A- change 'the next /64' to 'another /64 from the pool'=0A=0A"A=
dding a subnet is easy - just take the next /64."=0A=0Ato=0A=0A"Adding a su=
bnet is easy - just take *another /64 from the pool*."=0A=0A=0A=0A3.  Argum=
ents for shorter identifier lengths=0A=0A- roughly express the magnitude of=
 space not used to make it clearer there is both plenty available for /56s =
& /48s and also plenty left for other schemes=0A=0A"With only=0A=A0 =A02000=
::/3 currently committed for unicast addressing, we still have=0A=A0 =A0mos=
t of the address space in reserve."=0A=0Ato=0A=0A"With only=0A=A0 =A02000::=
/3 currently committed for unicast addressing, we still have *close to 7/8t=
hs*=A0=0A=A0 =A0of the address space in reserve."=0A=0A=0A3.4.  Concerns ov=
er ND cache exhaustion=0A=0A- add ref to RFC3756, "IPv6 Neighbor Discovery =
(ND) Trust Models and Threats"=0A- split long sentence=0A=0A"A site may be =
concerned that it is open to neighbour discovery (ND)=0A=A0 =A0cache exhaus=
tion attacks, whereby an attacker sends a large number of=0A=A0 =A0messages=
 in rapid succession to a series of (most likely inactive)=0A=A0 =A0host ad=
dresses within a specific subnet, in an attempt to fill a=0A=A0 =A0router's=
 ND cache with ND requests pending completion, in so doing=0A=A0 =A0denying=
 correct operation to active devices on the network."=0A=0Ato=0A=0A"A site =
may be concerned that it is open to neighbour discovery (ND)=0A=A0 =A0cache=
 exhaustion attacks [RFC3756], whereby an attacker sends a large number of=
=0A=A0 =A0messages in rapid succession to a series of (most likely inactive=
)=0A=A0 =A0host addresses within a specific subnet*. This is an* attempt to=
 fill a=0A=A0 =A0router's ND cache with ND requests pending completion, in =
so doing=0A=A0 =A0denying correct operation to active devices on the networ=
k."=0A=0A=0A=0A- remove or better place the 'hosts likely use DHCPv6' text =
is it seems out of context by itself, or isn't really relevant=0A=0A"Hosts =
would likely use DHCPv6, or be manually configured with=0A=A0 =A0addresses.=
"=0A=0A=0A=0A4.1.  Interaction with IPv6 specifications=0A=0A- make it clea=
rer that there would be considerable time effort involved in updating RFCs=
=0A=0A"Regardless of implementation issues, the RFCs themselves=0A=A0 =A0wo=
uld all need to be updated if the 64-bit rule was changed, even if=0A=A0 =
=A0the updates were small."=0A=0Ato=0A=0A"Regardless of implementation issu=
es, the RFCs themselves=0A=A0 =A0would all need to be updated if the 64-bit=
 rule was changed, even if=0A=A0 =A0the updates were small*, which would in=
volve considerable time and effort*."=0A=0A=0A=0A- add a ref to RFC6177, "I=
Pv6 Address Assignment to End Sites"=0A=0A"First and foremost, the RFCs des=
cribing the architectural aspects of=0A=A0 =A0IPv6 addressing explicitly st=
ate, refer and repeat this apparently=0A=A0 =A0immutable value: Addressing =
Architecture [RFC4291], Reserved=0A=A0 =A0Interface Identifiers [RFC5453], =
ILNP [RFC6741]."=0A=0Ato=0A=0A"First and foremost, the RFCs describing the =
architectural aspects of=0A=A0 =A0IPv6 addressing explicitly state, refer a=
nd repeat this apparently=0A=A0 =A0immutable value: Addressing Architecture=
 [RFC4291], *IPv6 Address Assignment to End Sites [RFC6177]*, Reserved=0A=
=A0 =A0Interface Identifiers [RFC5453], ILNP [RFC6741]."=0A=0A=0A=0A- It se=
ems the only difference between MLDv1 and MLDv2 is that the MLDv2 RFC expli=
citly stated the fe80::/64 prefix and how the lower 64 bits of the LL addre=
ss are to be used to select a querier - MLDv1 has the same link-local addre=
ss use rules, just not in as much detail. So perhaps make the MLDv2 text be=
tter focus on the explicit statement of the fe80::/64 prefix (the current t=
ext made me wonder if MLDv1 messages might not be required to come from LL =
addresses.)=0A- Delete duplicate 'length' - "prefix length of length /64"=
=0A=0A" The MLDv2 protocol [RFC3810] mandates all queries be sent with the=
=0A=A0 =A0fe80::/64 link-local source address prefix and subsequently bases=
 the=0A=A0 =A0querier election algorithm on the link-local subnet prefix le=
ngth of=0A=A0 =A0length /64."=0A=0Ato something like=0A=0A"MLDv1 [RFC2710] =
and MLDv2 [RFC3810] protocols mandate that all queries are sent with a link=
-local source address, with exception to MLD messages sent using the unspec=
ified address, when the link-local address is tentative [RFC3590]. At the t=
he time of publication of [RFC2710], [RFC2373] specified link-local address=
es with 64-bit interface identifiers. MLDv2 [RFC3810] explicitly stated the=
 use of the fe80::/64 link-local prefix, and based the=A0querier election a=
lgorithm on the link-local subnet prefix of=A0length /64."=0A=0A=0A=0A- Hig=
hlight that support for 'on-link' anycast is a basic IPv6 neighbor discover=
y capability, and therefore applications would expect it to be availale.=0A=
=0A"This could of course be fixed in the way=0A=A0 =A0described for /127 in=
 [RFC6164], i.e., avoiding the use of anycast=0A=A0 =A0within a /120 subnet=
."=0A=0Ato=0A=0A"This could of course be fixed in the way=0A=A0 =A0describe=
d for /127 in [RFC6164], i.e., avoiding the use of anycast=0A=A0 =A0within =
a /120 subnet. Note that support for "on-link anycast" is a standard IPv6 n=
eighbor discovery capability [RFC4861][RFC7094], and therefore applications=
 and their developers would expect it to be available."=0A=0A=0A=0A4.2.  Po=
ssible areas of breakage=0A=0A- Possibly change 'breakage' to 'failure' thr=
oughout this section.=0A=0A(The informality of 'breakage' appeals to me, ho=
wever it is probably a bit too informal for this sort of document. I though=
t it might not be a real word, however apparently it is, and is referring t=
o unused and therefore highly profitable service(s), such as unused calling=
 card credit. ) =A0=A0=0A=0A=0A- make the following read a bit better=0A=0A=
"[RFC3972] has defined a detailed algorithm how to generate 64-bit=0A=A0 =
=A0 =A0 interface identifier from a public key and a 64-bit subnet prefix."=
=0A=0Achanged to=0A=0A"[RFC3972] has defined a detailed algorithm *describi=
ng* how to generate *a* 64-bit=0A=A0 =A0 =A0 interface identifier from a pu=
blic key and a 64-bit subnet prefix."=0A=0A=0A=0A- change 'Breaking' to 'Ch=
anging' to make it read a bit better=0A=0A"Breaking the /64 boundary would =
certainly break the current CGA=0A=A0 =A0 =A0 definition."=0A=0Ato=0A=0A"*C=
hanging* the /64 boundary would certainly break the current CGA=0A=A0 =A0 =
=A0 definition.=0A=0A=0A- I think the follow link-local text in the last pa=
ragraph of the section should instead be another bullet point in the previo=
us list, reworded appropriately.=0A- While I certainly agree all hosts shou=
ld use same length LL prefixes/IIDs, I'm not sure I understand why it would=
 be a problem if they didn't. As far as I can tell, other than the formatio=
n of the LL address, prefix lengths and therefore IID lengths are never use=
d in LL related operations. The egress interface has to be supplied when us=
ing an LL address, rather than a longest match route table lookup determini=
ng it, so the link-local prefix length/IID length doesn't matter for that, =
and other related operations such as NS/NA don't seem to use prefix length =
for any validation, including of LL addresses. So I think more or clearer e=
xplanation of the problem would would be useful.=A0=0A=0A=0A"There is howev=
er the rather special case of the link-=0A=A0 =A0local prefix.  While RFC 4=
862 is careful not to define any specific=0A=A0 =A0length of link-local pre=
fix within fe80::/10, [RFC4291] does define=0A=A0 =A0the link-local IID len=
gth to be 64 bits.  Operationally there could=0A=A0 =A0be a problem unless =
all hosts on a link use IIDs of the same length=0A=A0 =A0to configure a lin=
k-local address during reboot.  Typically today the=0A=A0 =A0choice of 64 b=
its for the link-local IID length is hard-coded per=0A=A0 =A0interface, and=
 systems behave as if the link local prefix was=0A=A0 =A0actually fe80::/64=
.  There might be no way to change this except=0A=A0 =A0conceivably by manu=
al configuration, which will be impossible if the=0A=A0 =A0host concerned h=
as no local user interface."=0A=0A=0A4.3.2.  Other Observations=0A=0A- The =
first paragraph is referring to forwarding, the second paragraph seems to b=
e referring to packet filtering, and then the third paragraph is again refe=
rring to forwarding. I think it would be better if the second and third par=
agraphs were swapped, so that the two paragraphs discussing forwarding were=
 next to each other.=0A=0A- The ordering of the paragraphs made me a little=
 confused about what type of 'filtering' was being discussed on the second =
paragraph. I presume it is packet filtering, so perhaps making it clearer w=
ould be better after the paragraph has been moved:=0A=0A"It has been report=
ed that at least one type of switch has a content-=0A=A0 =A0addressable mem=
ory limited to 144 bits, which is indeed a typical=0A=A0 =A0value for commo=
dity components [TCAM].  This means that filters=0A=A0 =A0cannot be defined=
 based on 128-bit addresses and two 16-bit port=0A=A0 =A0numbers; the longe=
st prefix that could be used in such a filter is a=0A=A0 =A0/112."=0A=0Acha=
nged to=0A=0A"It has been reported that at least one type of switch has a c=
ontent-=0A=A0 =A0addressable memory limited to 144 bits, which is indeed a =
typical=0A=A0 =A0value for commodity components [TCAM].  This means that *p=
acket* filters or *access control lists*=0A=A0 =A0cannot be defined based o=
n 128-bit addresses and two 16-bit port=0A=A0 =A0numbers; the longest prefi=
x that could be used in such a *packet* filter is a=0A=A0 =A0/112."=0A=0A=
=0A=0A4.4.  Implementation and deployment issues=0A=0A- Reference to RFC594=
2, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes"=
=0A=0A"It does this (even if=0A=A0 =A0technically it violates the protocol)=
 because if there is no router=0A=A0 =A0on the link, the hosts effectively =
would fail to communicate each=0A=A0 =A0other with the configured addresses=
 because the "on-link assumption"=0A=A0 =A0was removed in [RFC4861]."=0A=0A=
to=0A=0A=0A"It does this (even if=0A=A0 =A0technically it violates the prot=
ocol) because if there is no router=0A=A0 =A0on the link, the hosts effecti=
vely would fail to communicate each=0A=A0 =A0other with the configured addr=
esses because the "on-link assumption"=0A=A0 =A0was removed in [RFC4861]*[R=
FC5942]*."=0A=0A=0A=0A- I think 'deployed at' reads a bit better=0A=0A"Fina=
lly, IPv6 is already installed on many sites, with a large number=0A=A0 =A0=
of staff trained on the basis of the existing standards, supported by=0A=A0=
 =A0documentation and tools based on those standards."=0A=0Achanged to=0A=
=0A"Finally, IPv6 is already *deployed at* many sites, with a large number=
=0A=A0 =A0of staff trained on the basis of the existing standards, supporte=
d by=0A=A0 =A0documentation and tools based on those standards."=0A=0A=0A=
=0A4.5.  Privacy issues=0A=0A- I'm not really sure the following text is re=
levant, as it discussing how a level of privacy could be achieved with much=
 shorter IIDs, which is venturing down the path of assuming IID lenghts wil=
l be changed, contrary to what this draft is saying and justifying shouldn'=
t happen, and therefore solutions need to be developed to how to get what w=
e've already got with 64-bit IIDs.=0A- Alternatively, if this text is to re=
main, then I think it is necessary to point out that there is not any curre=
ntly defined automated recovery procedure from DAD failure. Currently the f=
ailed address is not to be used and a system message is to be logged, or in=
 the case of a link-local addr DAD failure, IPv6 is to be completely disabl=
ed on the interface according to RFC4862. (If anybody wants to automate DAD=
 recovery, Appletalk would be an example of how to deal with it.)=0A=0A=0A=
=0A5.  Security Considerations=0A=0A- Add example /120 prefix qualifier in,=
 as the last sentence of the previous paragraph made me think the following=
 paragraph was again talking about a /64.=0A=0A"However, assume that an att=
acker finds one valid address A and then=0A=A0 =A0starts a scanning attack =
by scanning "outwards" from A, by trying=0A=A0 =A0A+1, A-1, A+2, A-2, etc."=
=0A=0Achanged to=0A=0A"However, assume that an attacker finds one valid add=
ress A *in a /120* and then=0A=A0 =A0starts a scanning attack by scanning "=
outwards" from A, by trying=0A=A0 =A0A+1, A-1, A+2, A-2, etc."=0A=0A=0A=0AT=
hat's it I think.=0A=0A=0ABest Regards,=0AMark.


From nobody Mon Aug  4 21:37:23 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471A91B2870 for <ipv6@ietfa.amsl.com>; Mon,  4 Aug 2014 21:37:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-pS8oWyZUa9 for <ipv6@ietfa.amsl.com>; Mon,  4 Aug 2014 21:37:17 -0700 (PDT)
Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 349CE1B2831 for <ipv6@ietf.org>; Mon,  4 Aug 2014 21:37:17 -0700 (PDT)
Received: by mail-pd0-f173.google.com with SMTP id w10so596998pde.4 for <ipv6@ietf.org>; Mon, 04 Aug 2014 21:37:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=l3XxSRsbjmp8aTzkrhQrpxqd1Vb2Sx41dUcvgA1Jvv0=; b=M/5zte5JEfrTuhqxsOTzeUwhl1m/nh8lFkxB7R1lVgZLnlWkn/blic4J6Osh4b6h95 RqdvakJ3tuvellRRANf6OEbv8bTdlAg4Eec1w/JIUc1nEbvEjX42EgeVqbMbOf3P63BJ yi3RPGRgtRiG7eyYDHqbS+Z3o30+2zK3raBuBPQGukUq4GMbUbgEP++9HRlyZNR316aO zwAmrByeFQp5bI/GyDiXwjE8aEVUKaJzM5XKQeNYMZJqs5e2ZIIsFXAuVfpQgRbJInUa n1yjAK+X1OflPHQitKd00CaVdPTNhBhRL4XCEpV4aiBPL4q8jt2ZvMPfiaPJkEK80VFw 8s6w==
X-Received: by 10.70.108.194 with SMTP id hm2mr1223888pdb.115.1407213436853; Mon, 04 Aug 2014 21:37:16 -0700 (PDT)
Received: from [192.168.178.23] (202.195.69.111.dynamic.snap.net.nz. [111.69.195.202]) by mx.google.com with ESMTPSA id u1sm794272pdm.82.2014.08.04.21.37.15 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 21:37:16 -0700 (PDT)
Message-ID: <53E05F7C.7080101@gmail.com>
Date: Tue, 05 Aug 2014 16:37:16 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Subject: Re: Detailed review of "Analysis of the 64-bit Boundary in IPv6 Addressing"
References: <1407211228.81108.YahooMailNeo@web162201.mail.bf1.yahoo.com>
In-Reply-To: <1407211228.81108.YahooMailNeo@web162201.mail.bf1.yahoo.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/RNuZCshPurBtpIfkvapyzt9RiRc
Cc: 6man Mailing List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Aug 2014 04:37:22 -0000

Mark,

Wow, what a conscientious review. Thanks.

With the reviews now in hand, we will produce an updated draft
in the reasonably near future.

Regards
   Brian + co-authors


On 05/08/2014 16:00, Mark ZZZ Smith wrote:
> Hi,
> 
> I was asked to do a detailed review of the 'why64' draft. Here are my thoughts and comments. Sorry for the delay, I've been a bit ill over the last day or so.

<snip>


From nobody Mon Aug  4 21:46:55 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BA01B28A4 for <ipv6@ietfa.amsl.com>; Mon,  4 Aug 2014 21:46:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 Fa6fLRsCABqd for <ipv6@ietfa.amsl.com>; Mon,  4 Aug 2014 21:46:52 -0700 (PDT)
Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ED301B2870 for <ipv6@ietf.org>; Mon,  4 Aug 2014 21:46:52 -0700 (PDT)
Received: by mail-pa0-f48.google.com with SMTP id et14so635351pad.7 for <ipv6@ietf.org>; Mon, 04 Aug 2014 21:46:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=R8fvuC8YCJO30bwj6NxZR+ZoFhoAXptabJ37EHBmksw=; b=ZZi8HTMHZTBsH+88GFiB/FDM8FUXShivknLyOsC8YHRhBo/EJTSbYTcATUFUmctIkx PxkMQWPIkgI15ejvSpWEpqTgI4Hk553XhiAweIYIp8wLRofvSQMJlNIfBYmnrSueqLv7 8e0zdGuZQ+1xh914FtKGujtJWE48CMjx/1u0cCrc+4hFe1KLOFKDSmRMXQAU+mTsgYix tSKDCDmVLPPbgnyeGVZ3yDZ60PPJUWoPLSTJuW6bX+cC7+CR7d3aJZ5euPco5LXI8KlQ v0Q6fMH0HUBNDGZ9XTF6DwZr7evytRqHIYpi10YDxezjHgg9gpWXN4murkPsiTb87vTv nlsQ==
X-Received: by 10.70.9.195 with SMTP id c3mr1293256pdb.21.1407214012363; Mon, 04 Aug 2014 21:46:52 -0700 (PDT)
Received: from [192.168.178.23] (202.195.69.111.dynamic.snap.net.nz. [111.69.195.202]) by mx.google.com with ESMTPSA id am2sm513363pbc.59.2014.08.04.21.46.50 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 21:46:51 -0700 (PDT)
Message-ID: <53E061BB.7050003@gmail.com>
Date: Tue, 05 Aug 2014 16:46:51 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: 6man <ipv6@ietf.org>
Subject: Re: Detailed review of "Analysis of the 64-bit Boundary in IPv6 Addressing"
References: <1407211228.81108.YahooMailNeo@web162201.mail.bf1.yahoo.com>
In-Reply-To: <1407211228.81108.YahooMailNeo@web162201.mail.bf1.yahoo.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/k5Fue4moFgvNNBxJtgrJrw_Go6M
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Aug 2014 04:46:54 -0000

One query on Mark's review:

> - roughly express the magnitude of space not used to make it clearer there is both plenty available for /56s & /48s and also plenty left for other schemes
> 
> "With only
>    2000::/3 currently committed for unicast addressing, we still have
>    most of the address space in reserve."
> 
> to
> 
> "With only
>    2000::/3 currently committed for unicast addressing, we still have *close to 7/8ths* 
>    of the address space in reserve."

I think we had something like that earlier, and we pulled it because
in practice ::/3 and f000::/3 have significant allocations (multicast
and other stuff). So is "close to" 7/8 accurate?

   Brian


From nobody Mon Aug  4 22:55:10 2014
Return-Path: <markzzzsmith@yahoo.com.au>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29671B28F1 for <ipv6@ietfa.amsl.com>; Mon,  4 Aug 2014 22:55:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 pv-fO1rVIVXj for <ipv6@ietfa.amsl.com>; Mon,  4 Aug 2014 22:55:08 -0700 (PDT)
Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C02FE1B2839 for <ipv6@ietf.org>; Mon,  4 Aug 2014 22:55:07 -0700 (PDT)
Received: from [66.196.81.171] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 05 Aug 2014 05:55:07 -0000
Received: from [98.139.212.223] by tm17.bullet.mail.bf1.yahoo.com with NNFMP;  05 Aug 2014 05:55:07 -0000
Received: from [127.0.0.1] by omp1032.mail.bf1.yahoo.com with NNFMP; 05 Aug 2014 05:55:07 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 26975.47660.bm@omp1032.mail.bf1.yahoo.com
Received: (qmail 95294 invoked by uid 60001); 5 Aug 2014 05:55:06 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024;  t=1407218106; bh=pBVg/q07PDzaNtBOuHI6TuXLbLc43Yn3LoyTGAJUS4Q=;  h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=o74G/vUqqcouQHX6dAR8eKv73zqsYuFuaJKFh4WJ1he5EFg8bRgfbljW2QQ3jtIHZ2itsjXTWxi0vjR5GgfCRsUWQJq1mtLp7uh0akQo6ZyzF2T9VvQse7jwYvt0N/RggoUUVjc6VzYOnZX358Yf/AOcjZ7H5JeSXDHVzwZGUGM=
X-YMail-OSG: cpl3.UoVM1l_rGSLMj3GM7LgOsUHhO26Y0oN09mYxcpx7Lp M.aTHb33_GNGtZtA8AwZVfHTFMMP3vvoXqmAFI9pWtVcv3V7fBn6spTEmFEI Od8rk4bb0hPHIeh7_PjODaS7ElarluwWzJQF3cre6e7ajsds7Bd.d4MZORcV 3HOJGDu5RtWKnH_pule77ElnUbugZiWo7OLOhsES9kJXnnkUotyCktq4FKyR ZL7_xsVJez7eIDdR2YLcvxA.unhnG86YcscKklMA.1V6W3q22QXekHqBvmbh 0JFn7bdwOKfN0QFg7KC7ktBLtWOalmcCQw3nYuKThzAWBIHwSFcUjoGCEYPI NEK5UpRq5rtZLkbxBW9nZJXJGkVD4l59h5xc.wq4ted2hKQtto7rUoCC7Bro IpO_eQFdIKif6O3OIrhdivNglitDmM1qrKEmXV07nLC.mGtRTChCq7X9vr8W Pu55i22LLuebnKAcft2S62M9LvAYPDBc7k_VbyKrwH.njFdIhYXAMOlfYtwm BWbrv7B9ExodItrfFypQNgw.fMhSYXKkh7TzMMu4JPne6BltRfu4sl.fJdLR i
Received: from [150.101.221.237] by web162206.mail.bf1.yahoo.com via HTTP; Mon, 04 Aug 2014 22:55:06 PDT
X-Rocket-MIMEInfo: 002.001, CgoKCgo.X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPgo.VG86IDZtYW4gPGlwdjZAaWV0Zi5vcmc.IAo.Q2M6IE1hcmsgWlpaIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1PiAKPlNlbnQ6IFR1ZXNkYXksIDUgQXVndXN0IDIwMTQgMjo0NiBQTQo.U3ViamVjdDogUmU6IERldGFpbGVkIHJldmlldyBvZiAiQW5hbHlzaXMgb2YgdGhlIDY0LWJpdCBCb3VuZGFyeSBpbiBJUHY2IEFkZHJlc3MBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.198.689
References: <1407211228.81108.YahooMailNeo@web162201.mail.bf1.yahoo.com> <53E061BB.7050003@gmail.com>
Message-ID: <1407218106.3429.YahooMailNeo@web162206.mail.bf1.yahoo.com>
Date: Mon, 4 Aug 2014 22:55:06 -0700
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Subject: Re: Detailed review of "Analysis of the 64-bit Boundary in IPv6 Addressing"
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man <ipv6@ietf.org>
In-Reply-To: <53E061BB.7050003@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/x-K9xiJY0bOen2cARI4Gd3mxWHs
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Aug 2014 05:55:09 -0000

=0A=0A=0A=0A=0A>________________________________=0A> From: Brian E Carpente=
r <brian.e.carpenter@gmail.com>=0A>To: 6man <ipv6@ietf.org> =0A>Cc: Mark ZZ=
Z Smith <markzzzsmith@yahoo.com.au> =0A>Sent: Tuesday, 5 August 2014 2:46 P=
M=0A>Subject: Re: Detailed review of "Analysis of the 64-bit Boundary in IP=
v6 Addressing"=0A> =0A>=0A>One query on Mark's review:=0A>=0A>=0A>=0A>=0A>=
=0A>> - roughly express the magnitude of space not used to make it clearer =
there is both plenty available for /56s & /48s and also plenty left for oth=
er schemes=0A>> =0A>> "With only=0A>>=A0 =A0 2000::/3 currently committed f=
or unicast addressing, we still have=0A>>=A0 =A0 most of the address space =
in reserve."=0A>> =0A>> to=0A>> =0A>> "With only=0A>>=A0 =A0 2000::/3 curre=
ntly committed for unicast addressing, we still have *close to 7/8ths* =0A>=
>=A0 =A0 of the address space in reserve."=0A>=0A>I think we had something =
like that earlier, and we pulled it because=0A>in practice ::/3 and f000::/=
3 have significant allocations (multicast=0A>and other stuff). So is "close=
 to" 7/8 accurate?=0A>=0A=0AMy thinking was that I think most people would =
have to calculate how much of the total IPv6 address space 2000::/3 represe=
nts, to then be able to evaluate how much remains, and I think a fair numbe=
r of people won't go to that effort. So I think saying something like 'clos=
e to 7/8ths' or perhaps 'more than 3/4ths of the address space in reserve' =
helps make it more reader friendly, and hopefully helps reduce the fairly c=
ommon fear that using /64s, /56s or /48s will make the IPv6 address space r=
un out quickly.=0A=0ARegards,=0AMark.=A0=0A=0A>=A0=A0=A0Brian=0A>=0A>=0A>=
=0A>


From nobody Tue Aug  5 01:11:48 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88891B292D; Tue,  5 Aug 2014 01:11:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 x63rRy_OJ2NG; Tue,  5 Aug 2014 01:11:32 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 133E21B292C; Tue,  5 Aug 2014 01:11:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2141; q=dns/txt; s=iport; t=1407226293; x=1408435893; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GLhN0aA6RY2A+DdFY9yxHXOiL44gy6konrHxwjuhaSg=; b=EygSvjm/f5tPINH9WztVp5NR1Gmo2KC6JFIlRtUSgAT2usQI7fUkb/dz WJOzGUkv9ngm6YxARBuSwgyJVWlsRb+9XQPP+vVRI5emRaH6lXG3BXjVo sxxEOSGoH18dErKRuLvL5/FlnJa0y0me77vXcItdQjdip56axtPZo+O+4 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AksFAICQ4FOtJA2D/2dsb2JhbABbDoJ/gSkE0zABgRUWd4QDAQEBBHkMBAIBCA4DBAEBAQodByERFAkIAQEEAQ0FCIgmAxG8OQ2GYxeNH4FWCR0xBwaDKYEcAQSKVY8tkD6GKIMLQmyBBUE
X-IronPort-AV: E=Sophos;i="5.01,804,1400025600"; d="scan'208";a="345162482"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP; 05 Aug 2014 08:11:32 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s758BVx3005452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Aug 2014 08:11:31 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 5 Aug 2014 03:11:31 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Philip Levis <pal@cs.stanford.edu>, Ralph Droms <rdroms.ietf@gmail.com>
Subject: RE: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoAAAz3YlABynPRA=
Date: Tue, 5 Aug 2014 08:11:30 +0000
Deferred-Delivery: Tue, 5 Aug 2014 08:11:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu>
In-Reply-To: <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.75.33]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/WaVkmMybf65jjoqymj8p6N5wbd4
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Aug 2014 08:11:40 -0000

I think I see what you are saying, Phil.

I can split 1.3 to isolate the deviations to 6437.

I also need to move the following text from section 3 in that new section=20

  This may seem contradictory with the IPv6
   Flow Label Specification [RFC6437] which stipulates that once it is
   set, the Flow Label is left unchanged; but the RFC also indicates a
   violation to the rule can be accepted for compelling reasons, and
   that security is a case justifying such a violation.  This
   specification suggests that energy-saving is another compelling
   reason for a violation to the aforementioned rule.

Proposed update for that text:

   This specification updates the IPv6
   Flow Label Specification [RFC6437], which stipulates that once it is
   set, the Flow Label is left unchanged. [RFC6437] also indicates that=20
   a violation to the rule can be accepted for compelling reasons,=20
   but limit those compelling reasons to security related issues.  This
   specification indicates that energy-saving is another compelling
   reason that justifies a violation to the aforementioned rule.

What do you think?

Cheers,

Pascal


> -----Original Message-----
> From: Philip Levis [mailto:pal@cs.stanford.edu]
> Sent: lundi 4 ao=FBt 2014 20:23
> To: Ralph Droms
> Cc: Pascal Thubert (pthubert); Michael Richardson; Routing Over Low power
> and Lossy networks; ipv6@ietf.org
> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
>=20
>=20
> On Aug 4, 2014, at 11:10 AM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
>=20
> >
> > On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert)
> <pthubert@cisco.com> wrote:
> >
> >> The change is now done, Ralph.
> >>
> >> The only difference between draft-thubert-6man-flow-label-for-rpl-03 a=
nd
> draft-thubert-6man-flow-label-for-rpl-04 is
> >>
> >> Updates: 6437 (if approved)
> >
> > I suggest adding a section to your doc that explains exactly what is be=
ing
> updated in RFC 6437.
> >
> > - Ralph
>=20
>=20
> I agree. I think some of the text in 1.3 can be re-used for this purpose.
>=20
> Phil


From nobody Tue Aug  5 10:26:04 2014
Return-Path: <anand@ece.iisc.ernet.in>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90EA1A0453; Tue,  5 Aug 2014 10:18:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.908
X-Spam-Level: 
X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=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 xcWHVeKYF15p; Tue,  5 Aug 2014 10:18:47 -0700 (PDT)
Received: from relay.iisc.ernet.in (relay.iisc.ernet.in [203.200.35.65]) by ietfa.amsl.com (Postfix) with ESMTP id 929B01A0439; Tue,  5 Aug 2014 10:18:44 -0700 (PDT)
Received: from ece.iisc.ernet.in (mail.ece.iisc.ernet.in [10.32.1.10]) by relay.iisc.ernet.in (8.14.4/8.14.4) with ESMTP id s75HIRT0031589; Tue, 5 Aug 2014 22:48:27 +0530
Received: from [10.3.1.91] ([10.3.1.91]) by ece.iisc.ernet.in (8.13.6/8.13.6/SuSE Linux 0.8) with ESMTP id s75HHGBM032391; Tue, 5 Aug 2014 22:47:16 +0530
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <1E250FB9-1BBD-4074-9296-C269D6C409D7@ece.iisc.ernet.in>
X-Mailer: iPad Mail (11B651)
From: Anand SVR <anand@ece.iisc.ernet.in>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Date: Tue, 5 Aug 2014 22:48:25 +0530
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-IISc-MailScanner-Information: Please contact the ISP for more information
X-MailScanner-ID: s75HIRT0031589
X-IISc-MailScanner: Found to be clean
X-IISc-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.899, required 6.5, autolearn=not spam, BAYES_00 -1.90, MIME_QP_LONG_LINE 0.00)
X-IISc-MailScanner-From: anand@ece.iisc.ernet.in
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/mzgVqzPZc_cHqLWb0vAHtwsr3Yc
X-Mailman-Approved-At: Tue, 05 Aug 2014 10:26:01 -0700
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Aug 2014 17:18:51 -0000

Hi,

The discussion has been very interesting, more so because it is bordering o=
n the legality of the usage of the word MUST. I agree with Philip's take on=
 this. But after reading the RFC, I got this impression that the RFC meant =
to be a facility or a feature with certain usage guidelines. The MUST usage=
 is more to imply stronger than SHOULD so as to discourage people from modi=
fying it. I suppose at the time of writing, the authors might not have fore=
seen that in some point in future the value can be changed for other reason=
s. Therefore the use of MUST MUST be taken with the right spirit it is mean=
t to be taken rather than literally :)=20

Anand


> On 05-Aug-2014, at 1:41 pm, "Pascal Thubert (pthubert)" <pthubert@cisco.c=
om> wrote:
>=20
> I think I see what you are saying, Phil.
>=20
> I can split 1.3 to isolate the deviations to 6437.
>=20
> I also need to move the following text from section 3 in that new section=
=20
>=20
>  This may seem contradictory with the IPv6
>   Flow Label Specification [RFC6437] which stipulates that once it is
>   set, the Flow Label is left unchanged; but the RFC also indicates a
>   violation to the rule can be accepted for compelling reasons, and
>   that security is a case justifying such a violation.  This
>   specification suggests that energy-saving is another compelling
>   reason for a violation to the aforementioned rule.
>=20
> Proposed update for that text:
>=20
>   This specification updates the IPv6
>   Flow Label Specification [RFC6437], which stipulates that once it is
>   set, the Flow Label is left unchanged. [RFC6437] also indicates that=20
>   a violation to the rule can be accepted for compelling reasons,=20
>   but limit those compelling reasons to security related issues.  This
>   specification indicates that energy-saving is another compelling
>   reason that justifies a violation to the aforementioned rule.
>=20
> What do you think?
>=20
> Cheers,
>=20
> Pascal
>=20
>=20
>> -----Original Message-----
>> From: Philip Levis [mailto:pal@cs.stanford.edu]
>> Sent: lundi 4 ao=C3=BBt 2014 20:23
>> To: Ralph Droms
>> Cc: Pascal Thubert (pthubert); Michael Richardson; Routing Over Low power
>> and Lossy networks; ipv6@ietf.org
>> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
>>=20
>>=20
>>> On Aug 4, 2014, at 11:10 AM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
>>>=20
>>>=20
>>>> On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert)
>>> <pthubert@cisco.com> wrote:
>>>=20
>>>> The change is now done, Ralph.
>>>>=20
>>>> The only difference between draft-thubert-6man-flow-label-for-rpl-03 a=
nd
>> draft-thubert-6man-flow-label-for-rpl-04 is
>>>>=20
>>>> Updates: 6437 (if approved)
>>>=20
>>> I suggest adding a section to your doc that explains exactly what is be=
ing
>> updated in RFC 6437.
>>>=20
>>> - Ralph
>>=20
>>=20
>> I agree. I think some of the text in 1.3 can be re-used for this purpose.
>>=20
>> Phil
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>=20
> --=20
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>=20

--=20
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


From nobody Tue Aug  5 12:12:50 2014
Return-Path: <farmer@umn.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407C71B2B41 for <ipv6@ietfa.amsl.com>; Tue,  5 Aug 2014 12:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 PUf-KQgxeBFp for <ipv6@ietfa.amsl.com>; Tue,  5 Aug 2014 12:12:42 -0700 (PDT)
Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 61E8B1B2B24 for <ipv6@ietf.org>; Tue,  5 Aug 2014 12:10:58 -0700 (PDT)
Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com [209.85.213.172]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for <ipv6@ietf.org>; Tue, 5 Aug 2014 14:07:09 -0500 (CDT)
X-Umn-Remote-Mta: [N] mail-ig0-f172.google.com [209.85.213.172] #+LO+TS+TR
X-Umn-Classification: local
Received: by mail-ig0-f172.google.com with SMTP id h15so7506186igd.5 for <ipv6@ietf.org>; Tue, 05 Aug 2014 12:07:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=bhgJFW0jdWQ16AtkVg/hJ4BF9vIGQMn/PZom93tFN/4=; b=npsTu4Azlle3EIQYb9yGnOyfxc8BxuTJPE2JzouEZJBUx8ssx/ZCZHDTMYPU/gKu2I /8kOvKCFqQIjl1AUQ1ymeYQqptHJ/QmIof5BCs/BV/dtiba+V/t3/BwoYFtcl+/3IYEm aC13z8/29MNSSSphEPVRI0LxemcuGzKB7njGE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=bhgJFW0jdWQ16AtkVg/hJ4BF9vIGQMn/PZom93tFN/4=; b=iGa+X1DstO1elMNAhAh/KJp87/HSp503NWpe6PIzbd13DShT/uDVi7NcxlJLbubnA3 LXJ8RmfgDlJZ8BZtaZes4bIOF/Ssyba6y8AppLVlWy2styefRRyFqeAA5Dv4gVUzJPtA EvSuZOORIrJRCiVm1hf8Kpv760YYAkDLsPeSZiHeU8doDoYE8DMfS/BiUaX2jqX5q9qP XDkrKES3goWiZ8Yw94Ysf708M7rSkhuqAiQniAiqxVTiT0z/5YZx9MgFwiBjKQzKMJFX FewZoa0fu6aS45cpNq6VnCTZ/1ou5LrvgC6G6WFH5YbIMWOE72OESQKRY9i29SFLUMeU U6TA==
X-Gm-Message-State: ALoCoQl7CnWRuDLHRn4jm0/dD2Kc5O8RCPZ1AzK1AX5HvvRUkUNkIebmFIkRvVz8EV3x3Fi6iXNPkuYzJsbiksCnKR5cu9iDr1rdO1GRxsp2OxtGJsUwPPM=
X-Received: by 10.43.69.202 with SMTP id yd10mr8274205icb.36.1407265629160; Tue, 05 Aug 2014 12:07:09 -0700 (PDT)
X-Received: by 10.43.69.202 with SMTP id yd10mr8274179icb.36.1407265628949; Tue, 05 Aug 2014 12:07:08 -0700 (PDT)
Received: from x-160-94-249-201.uofm-secure.wireless.umn.edu (x-160-94-249-201.uofm-secure.wireless.umn.edu. [160.94.249.201]) by mx.google.com with ESMTPSA id lq10sm10641501igb.22.2014.08.05.12.07.04 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Aug 2014 12:07:07 -0700 (PDT)
Message-ID: <53E12B54.1010805@umn.edu>
Date: Tue, 05 Aug 2014 14:07:00 -0500
From: David Farmer <farmer@umn.edu>
Organization: University of Minnesota
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>, Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man <ipv6@ietf.org>
Subject: Re: Detailed review of "Analysis of the 64-bit Boundary in IPv6 Addressing"
References: <1407211228.81108.YahooMailNeo@web162201.mail.bf1.yahoo.com> <53E061BB.7050003@gmail.com> <1407218106.3429.YahooMailNeo@web162206.mail.bf1.yahoo.com>
In-Reply-To: <1407218106.3429.YahooMailNeo@web162206.mail.bf1.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/N8j-iMP_uUqBgptDu-UhVyoeGdg
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: David Farmer <farmer@umn.edu>
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Aug 2014 19:12:44 -0000

On 8/5/14, 00:55 , Mark ZZZ Smith wrote:
>
>
>
>
>
>> ________________________________
>> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
>> To: 6man <ipv6@ietf.org>
>> Cc: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
>> Sent: Tuesday, 5 August 2014 2:46 PM
>> Subject: Re: Detailed review of "Analysis of the 64-bit Boundary in IPv6 Addressing"
>>
>>
>> One query on Mark's review:
>>
>>
>>
>>
>>
>>> - roughly express the magnitude of space not used to make it clearer there is both plenty available for /56s & /48s and also plenty left for other schemes
>>>
>>> "With only
>>>      2000::/3 currently committed for unicast addressing, we still have
>>>      most of the address space in reserve."
>>>
>>> to
>>>
>>> "With only
>>>      2000::/3 currently committed for unicast addressing, we still have *close to 7/8ths*
>>>      of the address space in reserve."
>>
>> I think we had something like that earlier, and we pulled it because
>> in practice ::/3 and f000::/3 have significant allocations (multicast
>> and other stuff). So is "close to" 7/8 accurate?
>>
>
> My thinking was that I think most people would have to calculate how much of the total IPv6 address space 2000::/3 represents, to then be able to evaluate how much remains, and I think a fair number of people won't go to that effort. So I think saying something like 'close to 7/8ths' or perhaps 'more than 3/4ths of the address space in reserve' helps make it more reader friendly, and hopefully helps reduce the fairly common fear that using /64s, /56s or /48s will make the IPv6 address space run out quickly.

Yes, we should do the math for them. I like "more than 3/4ths of the 
address space in reserve", the important concept to communicate is the 
vast majority of IPv6 addresses space is reserved. Where the exact mark 
is located at is unimportant.

-- 
================================================
David Farmer               Email: farmer@umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================


From nobody Tue Aug  5 19:26:35 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA971A0AF2 for <ipv6@ietfa.amsl.com>; Tue,  5 Aug 2014 19:26:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level: 
X-Spam-Status: No, score=-4 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, GB_I_INVITATION=-2, SPF_PASS=-0.001] autolearn=ham
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 2l_hHikL2qUx for <ipv6@ietfa.amsl.com>; Tue,  5 Aug 2014 19:26:32 -0700 (PDT)
Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4BF21A0AE4 for <6man@ietf.org>; Tue,  5 Aug 2014 19:26:28 -0700 (PDT)
Received: by mail-oa0-f50.google.com with SMTP id g18so1395327oah.9 for <6man@ietf.org>; Tue, 05 Aug 2014 19:26:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gv2+ieY3dAQQK/XBh6jvnxi7YSuwOl0sMURnjrj7/LE=; b=I9heO1UuPNCRhNeZ9f6mgEF/zde+3yO+JoYWryWLatNU9uQyT+c+Lz/L+4kFj2XsAo WyJecYPttnLV4W09mIjcEkcsAUZvJ8sT/leicDeCOW0IYRHCYPd2iQdbJtydHkIn0Svt ukk4oWYL2ctCflIgfendNPZuzptB+BtAS1KSDw+WP4JmnF9mxkGv61Ja/zsnmH1lL5O0 ZcMdYkBw6v89ra50pPrjINnQT2n5gsdGXve0nIOzayM2yALE1pcVl4kN4SmBqotInPpk wgX2ej9BfoZVWl0cEiTAF7ccWsy32tUM8OyWGKD0g+m6L3BgVk37PVY1VXLXdslWfdDb Lg1w==
X-Received: by 10.182.114.131 with SMTP id jg3mr11299614obb.9.1407291988185; Tue, 05 Aug 2014 19:26:28 -0700 (PDT)
Received: from [172.24.60.8] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id le8sm7646431obb.8.2014.08.05.19.26.26 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Aug 2014 19:26:27 -0700 (PDT)
Message-ID: <53E19257.1010702@gmail.com>
Date: Wed, 06 Aug 2014 14:26:31 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
Subject: draft-kampanakis-6man-ipv6-eh-parsing-01.txt
References: <20140602170733.22309.62074.idtracker@ietfa.amsl.com> <1C9F17D1873AFA47A969C4DD98F98A7513BA2B0E@xmb-rcd-x10.cisco.com>
In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A7513BA2B0E@xmb-rcd-x10.cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/cy7IymFoS2-RDenm3ezVPQcV5WE
Cc: "6man@ietf.org" <6man@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 02:26:34 -0000

Panos,

A few residual comments:

> 1.  Introduction
...
>    [RFC2460]
>    describes some IPv6 EH recommendations of the order and allowed
>    occurrences of headers, but it does not provide other guidance on how
>    EHs should be parsed. 

I apologise for plugging my own RFC, but I think it's important to insert
something like this here:

 [RFC7045] updates RFC 2460 by specifying the required behavior of
 middleboxes when handing an EH chain, but it does not go into detail
 about the parsing process.

(The reason is that we really need all those middlebox implementors to
look at the IETF's latest thinking on this. There is a lot of code
out there based on careless reading of RFC 2460.)

>  Guideline 2: From Section 5 of [RFC7112], when parsing an EH chain,

That still reads as if you are quoting RFC 7112, but you are not.
I suggest:

 Guideline 2: As a consequence of Section 5 of [RFC7112], when parsing an EH chain,

You still have this phrase twice:

> field is not an Upper Layer (UL) protocol (i.e.  TCP) 

I hope you mean "(e.g. TCP)" because this would apply to any
protocol, not just TCP.

Also, you could add a note that the current list of defined EH values
is maintained by IANA in the "IPv6 Extension Header Types" registry
created by RFC 7045. This registry is intended precisely as a
convenient reference for implementors.

> 4.  Parsing malformed EHs
...
>    If the data of the last EH or the UL
>    Header plus its data does not align with the original IPv6 Header
>    Payload Length the packet MUST be dropped unless another policy step
>    already discarded it.

I think this is inconsistent with a statement in RFC 2460:

> 4.7 No Next Header
> 
>    The value 59 in the Next Header field of an IPv6 header or any
>    extension header indicates that there is nothing following that
>    header.  If the Payload Length field of the IPv6 header indicates the
>    presence of octets past the end of a header whose Next Header field
>    contains 59, those octets must be ignored, and passed on unchanged if
>    the packet is forwarded.

Unless I have misunderstood something, your guideline 5 needs
an exception for the No Next Header case.

(Or we could decide that the case described in RFC 2460 is an
invitation to buffer overflow attacks, and change the rule,
but that would need a formal standards track update.)

Regards
   Brian


From nobody Tue Aug  5 20:19:59 2014
Return-Path: <i.grok@comcast.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107121B28B3 for <ipv6@ietfa.amsl.com>; Tue,  5 Aug 2014 20:19:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 4_uXcSkDZaSX for <ipv6@ietfa.amsl.com>; Tue,  5 Aug 2014 20:19:56 -0700 (PDT)
Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by ietfa.amsl.com (Postfix) with ESMTP id 233201B2C35 for <ipv6@ietf.org>; Tue,  5 Aug 2014 20:19:56 -0700 (PDT)
Received: from omta23.emeryville.ca.mail.comcast.net ([76.96.30.90]) by qmta07.emeryville.ca.mail.comcast.net with comcast id bEWY1o0031wfjNsA7FKwgD; Wed, 06 Aug 2014 03:19:56 +0000
Received: from odin.ulthar.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by omta23.emeryville.ca.mail.comcast.net with comcast id bFKs1o00d2Ekl488jFKuRT; Wed, 06 Aug 2014 03:19:55 +0000
Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ulthar.us (8.14.7/8.14.5) with ESMTP id s763JqVQ008601 for <ipv6@ietf.org>; Tue, 5 Aug 2014 23:19:52 -0400
Received: (from draco@localhost) by odin.ulthar.us (8.14.7/8.14.7/Submit) id s763Jqmn008600 for ipv6@ietf.org; Tue, 5 Aug 2014 23:19:52 -0400
Date: Tue, 5 Aug 2014 23:19:52 -0400
From: Scott Schmit <i.grok@comcast.net>
To: ipv6@ietf.org
Subject: Re: Detailed review of "Analysis of the 64-bit Boundary in IPv6 Addressing"
Message-ID: <20140806031952.GA8494@odin.ulthar.us>
Mail-Followup-To: ipv6@ietf.org
References: <1407211228.81108.YahooMailNeo@web162201.mail.bf1.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="gKMricLos+KVdGMg"
Content-Disposition: inline
In-Reply-To: <1407211228.81108.YahooMailNeo@web162201.mail.bf1.yahoo.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407295196; bh=5KAoDsv9n2u6GF0hqRnO5LHDgbyeGgEceCtfSmVqgAk=; h=Received:Received:Received:Received:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type; b=rxC0BknMns2jfCCwwzDTMvawl3okAaXUwXzFaetAnqHMGbHD7p8+fJg+ldtQP9TGZ LyDNgqVsA32n/tELLTDpWZrnnB/Gb01GJ36KEL6mkB6gBNEqHuHNpfK6qjElgF3jZl vX/UPRurl+18DMWtxzxCOdC1UjU0q5JlmF3mA8fUc60jMe4VG2xxfWLBP5B6d/+Ex9 Urda0vFVZIwX/v+9PZ61kbzlMm2M8fafIlxhkyFomEPWzfUEs+RUDsrGSaFxHnp9P4 e7rrVa5LqqHUfKFyRctWhDMWjq0N+s0GHVEfihvw9UeOFV+YryeiPvNvWmE1VPUTma pDujAlHORZg3g==
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/45B0NU10xbAGJHKJuW7yqWI5dAI
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 03:19:58 -0000

--gKMricLos+KVdGMg
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 04, 2014 at 09:00:28PM -0700, Mark ZZZ Smith wrote:
> 1.=A0=A0Introduction
>=20
> - additional comma
>=20
> "IPv6 addresses were originally chosen to be 128 bits long to provide
> =A0 =A0flexibility and new possibilities, rather than simply relieving the
> =A0 =A0IPv4 address shortage*,* by doubling the address size to 64 bits."

This changes the meaning of the sentence and no longer reads correctly.
Before, it was saying that the IETF could have doubled the 32-bit IPv4
addresses in IPv6 to relieve the address shortage, but instead jumped to
128 bits to add flexibility.

Now it says that the IETF chose to make IPv6 addresses 128 bits long for
flexibility by doubling the address size from 32 bits to 64 bits--which
doesn't even make sense.

--=20
Scott Schmit

--gKMricLos+KVdGMg
Content-Type: application/x-pkcs7-signature
Content-Disposition: attachment; filename="smime.p7s"
Content-Transfer-Encoding: base64

MIIPLwYJKoZIhvcNAQcCoIIPIDCCDxwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
DGAwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe
Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE
ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg
U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0
ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp
pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9
b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q
zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX
9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/
4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E
BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw
HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG
AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu
Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB
FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC
AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py
TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm
CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz
uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm
z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT
5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp
sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076
khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8
J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX
un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBiQwggUMoAMCAQICAwo/3zANBgkqhkiG
9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE0MDYxNjAw
NDQ1NVoXDTE1MDYxNjE3MzYyNFowQDEbMBkGA1UEAwwSaS5ncm9rQGNvbWNhc3QubmV0MSEw
HwYJKoZIhvcNAQkBFhJpLmdyb2tAY29tY2FzdC5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQC3HoziY3IySZbVkCfbjfgjTKO5CISA2+1GKzBNbzycTCXBWLnHvzrlFPlI
17z3noLux8ebSYz+TFiCUuVdwKkFOpN0WWxGzD6K/Hb0AJtKZp62YKtyRkCV51n5NrEepo28
hFkRhjgSkZA9t/4vtaWt0Ds8pIpUoQ1sNaUDWzjJ3UALl7m6b3XZmIouND+jq1AQv0ivMLuk
QNXO2a0KcuRVHDhAEdBvTi9LSePi8+Q8UWWBOeWmGhiKwL5X98Ne03GKxxQnLXDJbrX+cNcC
uaZIPdrmhbZCo+zegLfrApLRu9/6ox6/dnRsvmMpGcjNKLCgKoEh4cwyb+mhyzPXWlpXAgMB
AAGjggLYMIIC1DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcD
AgYIKwYBBQUHAwQwHQYDVR0OBBYEFKtASVM24m5BiMPABLNlKft1oxbCMB8GA1UdIwQYMBaA
FFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB0GA1UdEQQWMBSBEmkuZ3Jva0Bjb21jYXN0Lm5ldDCC
AUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFy
dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3
YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVt
ZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUg
aW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9i
bGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j
cnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz
cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNV
HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEBALTg
t4rndUh0up2qJuskCTx4iRQd59+R0kOm7vJa94t+fSa8Wip4WeVOJZaHs1XIp17yoLTzcXN9
+L5lTC7HaHrBGOdB8su0muQyS///XwbDgn3/9+D0stPJZYLMrfRSm/FzQEk5j5McmODTCq8a
tQrlQilnBDcY00CYKBTKGAleOPjQ8yg/QVb/uqNuKE88+mfEdc6AKykYg7VXqxdL54ylqR3o
P8+PsP1YgCE2wqWWfGUp6hxIKa2XGtqVdHqL1yc5equX97TiUiIQ51j+nmU8tXTuR7OPRA1B
cHA+jx6rchpnZMEJn9DYPFOvkkC86mxOCax9r5HOtdidcw8uZSoxggKXMIICkwIBATCBlDCB
jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy
ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz
IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMKP98wCQYFKw4DAhoFAKCB2DAY
BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA4MDYwMzE5NTJa
MCMGCSqGSIb3DQEJBDEWBBSGydCR8wOgG7cTkulWmNs45TGuyjB5BgkqhkiG9w0BCQ8xbDBq
MAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4G
CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAN
BgkqhkiG9w0BAQEFAASCAQBMV8ibo6+9kz+I2WSKN0PiZLLqN/jph6z28gTXPkz9QuV/9j//
+zUq8xnqP3ueDxY4tICqkvS3e4YZUOeUVdNZ3ap6IV62YMa3SqWQAmVg/2WvGyVUYkf/7s7F
7XepUwJKGr6fI55w3ZOsnNYWkk7S/6V7NE5UnINi+wI7a+KRBqCUT7q5WcYKrpsIHYBHD7qj
+4n1ztYJWjvjF0RCuaN0blX7C6UGkCfyMK3OWoWpVmSQGApW0imk+2nyJokksH9HRKafnlKL
F6DzYQ/UtKmj0zZMqL1w7fKCdyh2VTBxZ/7ZJr0i08I9GVYi/sOMNTAlpqwyk8cdLU9WJoA1
Ihwx

--gKMricLos+KVdGMg--


From nobody Tue Aug  5 20:47:06 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3FC1B2C39 for <ipv6@ietfa.amsl.com>; Tue,  5 Aug 2014 20:47:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 1Ts-5wSl3-uj for <ipv6@ietfa.amsl.com>; Tue,  5 Aug 2014 20:47:03 -0700 (PDT)
Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7021B2C1E for <ipv6@ietf.org>; Tue,  5 Aug 2014 20:47:03 -0700 (PDT)
Received: by mail-pd0-f182.google.com with SMTP id fp1so2515536pdb.13 for <ipv6@ietf.org>; Tue, 05 Aug 2014 20:47:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4l0Qfx3xryZX8PwWvh7gXBj2C0OjbBHrIMFxXzH4bKo=; b=PwkGqwlFZKm5b4+W4K3jgvz2LzjHDQuhs0JwNszwYL5VgF0za05l2/lZbjRTIkOqk9 ol/Ne/U51Tcgqyrd19yN+jgpkqfMaWxfwH1n1abirWFrBOYTIrgo88Fjwf/itCc9V2Yu zPt6tR86zH+aneaVLmjxhYrJdp548qIvQ50/BGTQdhjjdbc49q2dz847ibvDa7y/Hkqm +cQ/j9F1rokl2UfMpICpp6vcsS8p8P5wDQOsZbevN6WSJKwW5uymd6ye0maaHxHOP1oZ 9+lhX5mwp7S+MmkBWmvwqRpK6suvJDTBJtevISFtrtS6dwK8tXqkwvPS41CY5/pYtlaW qhPw==
X-Received: by 10.68.69.109 with SMTP id d13mr8563824pbu.111.1407296822707; Tue, 05 Aug 2014 20:47:02 -0700 (PDT)
Received: from [192.168.178.23] (135.199.69.111.dynamic.snap.net.nz. [111.69.199.135]) by mx.google.com with ESMTPSA id wp3sm3559551pbc.67.2014.08.05.20.47.00 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Aug 2014 20:47:02 -0700 (PDT)
Message-ID: <53E1A539.7070105@gmail.com>
Date: Wed, 06 Aug 2014 15:47:05 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: i.grok@comcast.net
Subject: Re: Detailed review of "Analysis of the 64-bit Boundary in IPv6 Addressing"
References: <1407211228.81108.YahooMailNeo@web162201.mail.bf1.yahoo.com> <20140806031952.GA8494@odin.ulthar.us>
In-Reply-To: <20140806031952.GA8494@odin.ulthar.us>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/m8_op_Se9Qq50MnWByzFHGj7brQ
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 03:47:04 -0000

On 06/08/2014 15:19, Scott Schmit wrote:
> On Mon, Aug 04, 2014 at 09:00:28PM -0700, Mark ZZZ Smith wrote:
>> 1.  Introduction
>>
>> - additional comma
>>
>> "IPv6 addresses were originally chosen to be 128 bits long to provide
>>    flexibility and new possibilities, rather than simply relieving the
>>    IPv4 address shortage*,* by doubling the address size to 64 bits."
> 
> This changes the meaning of the sentence and no longer reads correctly.
> Before, it was saying that the IETF could have doubled the 32-bit IPv4
> addresses in IPv6 to relieve the address shortage, but instead jumped to
> 128 bits to add flexibility.
> 
> Now it says that the IETF chose to make IPv6 addresses 128 bits long for
> flexibility by doubling the address size from 32 bits to 64 bits--which
> doesn't even make sense.

I think Lynne Truss, would agree with you. I will tune the sentence
accordingly.

    Brian


From nobody Tue Aug  5 21:57:45 2014
Return-Path: <pal@cs.stanford.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA3E1B280C; Tue,  5 Aug 2014 21:57:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.201
X-Spam-Level: 
X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 qRdRm7y9aNfl; Tue,  5 Aug 2014 21:57:38 -0700 (PDT)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF681B280E; Tue,  5 Aug 2014 21:57:35 -0700 (PDT)
Received: from [76.14.66.110] (port=57734 helo=[192.168.0.103]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XEtI3-0005Zz-MS; Tue, 05 Aug 2014 21:57:34 -0700
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <1E250FB9-1BBD-4074-9296-C269D6C409D7@ece.iisc.ernet.in>
Date: Tue, 5 Aug 2014 21:57:30 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <ADC094E3-9D88-4CE6-BC96-901DD29B8A0D@cs.stanford.edu>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <1E250FB9-1BBD-4074-9296-C269D6C409D7@ece.iisc.ernet.in>
To: Anand SVR <anand@ece.iisc.ernet.in>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 5d5bd4b8133540f30bea22ef470d169d
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Vx0llI3jUS6wW6HvNw2JOA9iWuM
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 04:57:43 -0000

I totally agree that the document leaves the question open of whether =
there could be future uses. The use of the flow label in that way =
doesn't go against the spirit of the document and so we shouldn't reject =
the idea out of principle. But it does go against the letter of the =
document -- hence the need for an Updates: or other explicit note that =
this is the case.

Phil

On Aug 5, 2014, at 10:18 AM, Anand SVR <anand@ece.iisc.ernet.in> wrote:

> Hi,
>=20
> The discussion has been very interesting, more so because it is =
bordering on the legality of the usage of the word MUST. I agree with =
Philip's take on this. But after reading the RFC, I got this impression =
that the RFC meant to be a facility or a feature with certain usage =
guidelines. The MUST usage is more to imply stronger than SHOULD so as =
to discourage people from modifying it. I suppose at the time of =
writing, the authors might not have foreseen that in some point in =
future the value can be changed for other reasons. Therefore the use of =
MUST MUST be taken with the right spirit it is meant to be taken rather =
than literally :)=20
>=20
> Anand
>=20
>=20
>> On 05-Aug-2014, at 1:41 pm, "Pascal Thubert (pthubert)" =
<pthubert@cisco.com> wrote:
>>=20
>> I think I see what you are saying, Phil.
>>=20
>> I can split 1.3 to isolate the deviations to 6437.
>>=20
>> I also need to move the following text from section 3 in that new =
section=20
>>=20
>> This may seem contradictory with the IPv6
>>  Flow Label Specification [RFC6437] which stipulates that once it is
>>  set, the Flow Label is left unchanged; but the RFC also indicates a
>>  violation to the rule can be accepted for compelling reasons, and
>>  that security is a case justifying such a violation.  This
>>  specification suggests that energy-saving is another compelling
>>  reason for a violation to the aforementioned rule.
>>=20
>> Proposed update for that text:
>>=20
>>  This specification updates the IPv6
>>  Flow Label Specification [RFC6437], which stipulates that once it is
>>  set, the Flow Label is left unchanged. [RFC6437] also indicates that=20=

>>  a violation to the rule can be accepted for compelling reasons,=20
>>  but limit those compelling reasons to security related issues.  This
>>  specification indicates that energy-saving is another compelling
>>  reason that justifies a violation to the aforementioned rule.
>>=20
>> What do you think?
>>=20
>> Cheers,
>>=20
>> Pascal
>>=20
>>=20
>>> -----Original Message-----
>>> From: Philip Levis [mailto:pal@cs.stanford.edu]
>>> Sent: lundi 4 ao=FBt 2014 20:23
>>> To: Ralph Droms
>>> Cc: Pascal Thubert (pthubert); Michael Richardson; Routing Over Low =
power
>>> and Lossy networks; ipv6@ietf.org
>>> Subject: Re: [Roll] WGLC for =
draft-thubert-6man-flow-label-for-rpl-03
>>>=20
>>>=20
>>>> On Aug 4, 2014, at 11:10 AM, Ralph Droms <rdroms.ietf@gmail.com> =
wrote:
>>>>=20
>>>>=20
>>>>> On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert)
>>>> <pthubert@cisco.com> wrote:
>>>>=20
>>>>> The change is now done, Ralph.
>>>>>=20
>>>>> The only difference between =
draft-thubert-6man-flow-label-for-rpl-03 and
>>> draft-thubert-6man-flow-label-for-rpl-04 is
>>>>>=20
>>>>> Updates: 6437 (if approved)
>>>>=20
>>>> I suggest adding a section to your doc that explains exactly what =
is being
>>> updated in RFC 6437.
>>>>=20
>>>> - Ralph
>>>=20
>>>=20
>>> I agree. I think some of the text in 1.3 can be re-used for this =
purpose.
>>>=20
>>> Phil
>>=20
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>=20
>> --=20
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>=20
>=20
> --=20
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>=20


From nobody Wed Aug  6 02:40:33 2014
Return-Path: <markzzzsmith@yahoo.com.au>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1FE1B2982 for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 02:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 x4X7cUHZbWZo for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 02:40:27 -0700 (PDT)
Received: from nm39.bullet.mail.ne1.yahoo.com (nm39.bullet.mail.ne1.yahoo.com [98.138.229.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A2A1B28AD for <ipv6@ietf.org>; Wed,  6 Aug 2014 02:40:27 -0700 (PDT)
Received: from [127.0.0.1] by nm39.bullet.mail.ne1.yahoo.com with NNFMP; 06 Aug 2014 09:40:26 -0000
Received: from [98.138.100.118] by nm39.bullet.mail.ne1.yahoo.com with NNFMP;  06 Aug 2014 09:37:30 -0000
Received: from [66.196.81.170] by tm109.bullet.mail.ne1.yahoo.com with NNFMP;  06 Aug 2014 09:37:29 -0000
Received: from [98.139.212.215] by tm16.bullet.mail.bf1.yahoo.com with NNFMP;  06 Aug 2014 09:37:29 -0000
Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 06 Aug 2014 09:37:29 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 780505.3144.bm@omp1024.mail.bf1.yahoo.com
Received: (qmail 17554 invoked by uid 60001); 6 Aug 2014 09:37:29 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024;  t=1407317849; bh=64RuW0EXI5EeNRBF5P/Bh6xp2i+yt6EVd+gthuUgc1g=;  h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kH7gFrsihM1duGyTMaulmJP42iGNEuAaFedg1m9qUKb9Pe92Y/g6HERftE8Cjtt6kAJ1tcy1zSNPrF+HVpNwzLiQuoO1cYK8GknraKNYetcP4rVA1wIvSj9FPk0CP4fhYb5S6Xf9Gbe1zmcebd33pJdwD/r6tBH8W2gqkcQ53HU=
X-YMail-OSG: 3rFmtxoVM1nlB6.hDMPzXmtUtE_IE8i3V7l0kpNJH3WJ0JT 75Q3HQFd.Qxcvsq7rS.x_0lmTIRdN5Ge_Pei3_0l5KDr06DvHCpwQAp00d6l ZMmarrjT8R4OVrP6nimtrA.54FD4kJzOBGa4auqrXuNUQWc8IMeingaFG10D Z0EFz4e5a1xTDmtqMTO7DevBe618bujCQ7Y6FhV_Zuk7oZB9hj_uz7DNjxDT 0K_RQSchJSYVd103ZSSXswhGL67AWdRvHe5gSZGhRvw1ZEPOCNBij8P7uZSE 383iAuTiO5WBXX2V1qRtApMACfsJhSmBvm3lfM44cQQaQTfc4ECi37yaRVVq szrCF2cjvbKuHQLEcPR4.IHD0XvieVniCVZQ7NZxPVLavfiMQGRdkn0FGWQg B9iXyyJUQlqKp4ZhC.lK28w1AXfkL5hXCCVbGC51lRn5FWPphlBFgzAkTP8S qkaGpGQBrweAMZib8lGLkcwECAW1lPqKnohxd6T444EXzeMDSRM70cail5PO M2a5nGrOCq_CRDzjLVi61oZuNkpmT_0eXGIMt4B7bGqZBwBt0FUUUNWU1_eF 7g4gGZC4dAAg-
Received: from [150.101.221.237] by web162203.mail.bf1.yahoo.com via HTTP; Wed, 06 Aug 2014 02:37:29 PDT
X-Rocket-MIMEInfo: 002.001, SSBwdXQgdGhlIGNvbW1hIGluIHRoZXJlIGJlY2F1c2UgSSB0aGluayBpdCB3YXMsIGFzIG15IHZhcmlvdXMgdGVhY2hlcnMgdXNlZCB0byBzYXksIGEgYml0IG9mIGEgInJ1bi1vbi1zZW50ZW5jZSIuIENvbW1hcyBzZXJ2ZSBhcyBwYXVzZXMgaW4gc2VudGVuY2VzLCBhbmQgaXQgc2VlbWVkIHRvIG5lZWQgb25lIGF0IHRoYXQgcG9pbnQuCgpJJ3ZlIGZvcmdvdHRlbiB0b28gbXVjaCBFbmdsaXNoIGdyYW1tYXIgdG8ga25vdyBleGFjdGx5IHdoYXQgdGhlIHByb2JsZW0gaXMsIGhvd2V2ZXIgcGVyaGFwcyB0aGUBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.198.689
References: <1407211228.81108.YahooMailNeo@web162201.mail.bf1.yahoo.com> <20140806031952.GA8494@odin.ulthar.us> <53E1A539.7070105@gmail.com>
Message-ID: <1407317849.12698.YahooMailNeo@web162203.mail.bf1.yahoo.com>
Date: Wed, 6 Aug 2014 02:37:29 -0700
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Subject: Re: Detailed review of "Analysis of the 64-bit Boundary in IPv6 Addressing"
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, "i.grok@comcast.net" <i.grok@comcast.net>
In-Reply-To: <53E1A539.7070105@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Yw-QcbasTHixMUsloCYh0VTYy2c
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 09:40:29 -0000

I put the comma in there because I think it was, as my various teachers use=
d to say, a bit of a "run-on-sentence". Commas serve as pauses in sentences=
, and it seemed to need one at that point.=0A=0AI've forgotten too much Eng=
lish grammar to know exactly what the problem is, however perhaps the deepe=
r problem is that the sentence is trying to saying two different but relate=
d things instead of one (IPv6 addresses are 128 bits for these additional r=
easons; we could have just doubled the IPv4's address size to solve the lac=
k of addresses problem).=0A=0APerhaps something like this:=0A=0A=0A"IPv6 ad=
dresses were originally chosen to be 128 bits long to=A0provide=A0flexibili=
ty and new possibilities. This was instead of doubling the 32 bit IPv4 addr=
ess size to 64 bits to solve the near term problem of the lack of Internet =
addresses."=0A=0A=0A=0A=0A=0A----- Original Message -----=0A> From: Brian E=
 Carpenter <brian.e.carpenter@gmail.com>=0A> To: i.grok@comcast.net=0A> Cc:=
 ipv6@ietf.org=0A> Sent: Wednesday, 6 August 2014 1:47 PM=0A> Subject: Re: =
Detailed review of "Analysis of the 64-bit Boundary in IPv6 Addressing"=0A>=
 =0A> On 06/08/2014 15:19, Scott Schmit wrote:=0A>>  On Mon, Aug 04, 2014 a=
t 09:00:28PM -0700, Mark ZZZ Smith wrote:=0A>>>  1.=A0 Introduction=0A>>> =
=0A>>>  - additional comma=0A>>> =0A>>>  "IPv6 addresses were originally ch=
osen to be 128 bits long to =0A> provide=0A>>> =A0 =A0 flexibility and new =
possibilities, rather than simply relieving the=0A>>> =A0 =A0 IPv4 address =
shortage*,* by doubling the address size to 64 =0A> bits."=0A>> =0A>>  This=
 changes the meaning of the sentence and no longer reads correctly.=0A>>  B=
efore, it was saying that the IETF could have doubled the 32-bit IPv4=0A>> =
 addresses in IPv6 to relieve the address shortage, but instead jumped to=
=0A>>  128 bits to add flexibility.=0A>> =0A>>  Now it says that the IETF c=
hose to make IPv6 addresses 128 bits long for=0A>>  flexibility by doubling=
 the address size from 32 bits to 64 bits--which=0A>>  doesn't even make se=
nse.=0A> =0A> I think Lynne Truss, would agree with you. I will tune the se=
ntence=0A> accordingly.=0A> =0A> =A0 =A0 Brian=0A> =0A> =0A> --------------=
------------------------------------------------------=0A> IETF IPv6 workin=
g group mailing list=0A> ipv6@ietf.org=0A> Administrative Requests: https:/=
/www.ietf.org/mailman/listinfo/ipv6=0A> -----------------------------------=
---------------------------------=0A> 


From nobody Wed Aug  6 02:48:36 2014
Return-Path: <tjc@ecs.soton.ac.uk>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A341B2982 for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 02:48:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.222
X-Spam-Level: 
X-Spam-Status: No, score=-1.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=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 UnLt3qDDA_CT for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 02:48:22 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291EB1B2CF9 for <ipv6@ietf.org>; Wed,  6 Aug 2014 02:48:22 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s769m8Qo028538; Wed, 6 Aug 2014 10:48:08 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s769m8Qo028538
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1407318489; bh=zMWNDoO2c4FtFAg00Vymbz2V+2w=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=JF459hCOF4NcAlwev4GlQNTbUwGAdhicPJV+NsgE4Z7P6y4h/R5gJOQ5WKgNuD9s7 FI9QIwDfsJTE2aaYvU+eEkMHp33E+UxOQkgPjJ/Djw07upNSmo0VWwE3iwuPFCiWce Oa5dxiRi54R2XxKJDF21QCvjdbikzZBBTO5JfhGE=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP (valid=N/A) id q75Am72364002161eN ret-id none; Wed, 06 Aug 2014 10:48:08 +0100
Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s769m4FS000767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Aug 2014 10:48:05 +0100
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Detailed review of "Analysis of the 64-bit Boundary in IPv6 Addressing"
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <1407317849.12698.YahooMailNeo@web162203.mail.bf1.yahoo.com>
Date: Wed, 6 Aug 2014 10:48:05 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <EMEW3|b0d4803f6851b159149ab8024cf92c3fq75Am703tjc|ecs.soton.ac.uk|756EB00E-8334-409B-B2F0-67A81DD1CB7D@ecs.soton.ac.uk>
References: <1407211228.81108.YahooMailNeo@web162201.mail.bf1.yahoo.com> <20140806031952.GA8494@odin.ulthar.us> <53E1A539.7070105@gmail.com> <1407317849.12698.YahooMailNeo@web162203.mail.bf1.yahoo.com> <756EB00E-8334-409B-B2F0-67A81DD1CB7D@ecs.soton.ac.uk>
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
X-Mailer: Apple Mail (2.1878.6)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=q75Am7236400216100; tid=q75Am72364002161eN; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: s769m8Qo028538
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/DXcuerAaPrTYB6kGYvpJjhUFpMU
Cc: "i.grok@comcast.net" <i.grok@comcast.net>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 09:48:25 -0000

Hi,

On 6 Aug 2014, at 10:37, Mark ZZZ Smith <markzzzsmith@yahoo.com.au> =
wrote:

> I put the comma in there because I think it was, as my various =
teachers used to say, a bit of a "run-on-sentence". Commas serve as =
pauses in sentences, and it seemed to need one at that point.

I think it=92s fine to have no comma, and indeed necessary.

The sentence can be flipped to read more clearly:

=93Rather than simply relieving the IPv4 address shortage by doubling =
the address length to 64 bits, IPv6 addresses were chosen to be 128 bits =
long to provide flexibility and new possibilities."

But this is a minor not in the bigger picture :)

Tim

>=20
> I've forgotten too much English grammar to know exactly what the =
problem is, however perhaps the deeper problem is that the sentence is =
trying to saying two different but related things instead of one (IPv6 =
addresses are 128 bits for these additional reasons; we could have just =
doubled the IPv4's address size to solve the lack of addresses problem).
>=20
> Perhaps something like this:
>=20
>=20
> "IPv6 addresses were originally chosen to be 128 bits long to provide =
flexibility and new possibilities. This was instead of doubling the 32 =
bit IPv4 address size to 64 bits to solve the near term problem of the =
lack of Internet addresses."
>=20
>=20
>=20
>=20
>=20
> ----- Original Message -----
>> From: Brian E Carpenter <brian.e.carpenter@gmail.com>
>> To: i.grok@comcast.net
>> Cc: ipv6@ietf.org
>> Sent: Wednesday, 6 August 2014 1:47 PM
>> Subject: Re: Detailed review of "Analysis of the 64-bit Boundary in =
IPv6 Addressing"
>>=20
>> On 06/08/2014 15:19, Scott Schmit wrote:
>>> On Mon, Aug 04, 2014 at 09:00:28PM -0700, Mark ZZZ Smith wrote:
>>>> 1.  Introduction
>>>>=20
>>>> - additional comma
>>>>=20
>>>> "IPv6 addresses were originally chosen to be 128 bits long to=20
>> provide
>>>>     flexibility and new possibilities, rather than simply relieving =
the
>>>>     IPv4 address shortage*,* by doubling the address size to 64=20
>> bits."
>>>=20
>>> This changes the meaning of the sentence and no longer reads =
correctly.
>>> Before, it was saying that the IETF could have doubled the 32-bit =
IPv4
>>> addresses in IPv6 to relieve the address shortage, but instead =
jumped to
>>> 128 bits to add flexibility.
>>>=20
>>> Now it says that the IETF chose to make IPv6 addresses 128 bits long =
for
>>> flexibility by doubling the address size from 32 bits to 64 =
bits--which
>>> doesn't even make sense.
>>=20
>> I think Lynne Truss, would agree with you. I will tune the sentence
>> accordingly.
>>=20
>>     Brian
>>=20
>>=20
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Wed Aug  6 04:17:23 2014
Return-Path: <tjc@ecs.soton.ac.uk>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C891A8BAF for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 04:17:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.178
X-Spam-Level: 
X-Spam-Status: No, score=0.178 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=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 n2OkGSEWxrYh for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 04:17:17 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5121A031A for <ipv6@ietf.org>; Wed,  6 Aug 2014 04:17:16 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s76BHBA4024806; Wed, 6 Aug 2014 12:17:11 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s76BHBA4024806
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1407323832; bh=dvcE2jID0EbF5p7vjuKnTYDi0s8=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=30FWES8b5k/R4L2ln4MNJJqvua46iopYNCOgSjuP3+bXJi8q4OSEab1nVamy6+xZ6 RuggOfxbABV6GBYB1hSin7RQefS1k3C9euzdvN5zhI+Fjzo55uwj2KzTMJRv/vD9eX d4VMeu3rRd4qmS36EhkMGmENpv7sM0+rwFqI1EeM=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP (valid=N/A) id q75CHB2364003072mc ret-id none; Wed, 06 Aug 2014 12:17:11 +0100
Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s76BH9U6028260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Aug 2014 12:17:10 +0100
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Detailed review of "Analysis of the 64-bit Boundary in IPv6 Addressing"
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <1407211228.81108.YahooMailNeo@web162201.mail.bf1.yahoo.com>
Date: Wed, 6 Aug 2014 12:17:10 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <EMEW3|7096758603784b89c823bb054ad36e3aq75CHB03tjc|ecs.soton.ac.uk|83E8FF54-2A51-488A-BC75-024EDA295621@ecs.soton.ac.uk>
References: <1407211228.81108.YahooMailNeo@web162201.mail.bf1.yahoo.com> <83E8FF54-2A51-488A-BC75-024EDA295621@ecs.soton.ac.uk>
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
X-Mailer: Apple Mail (2.1878.6)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=q75CHB236400307200; tid=q75CHB2364003072mc; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: s76BHBA4024806
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/VjBKTACrp1to5FNAuvKdwh4z1gg
Cc: 6man Mailing List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 11:17:22 -0000

Hi,

Some comments in-line, mostly on the bits I originally wrote...

On 5 Aug 2014, at 05:00, Mark ZZZ Smith <markzzzsmith@yahoo.com.au> =
wrote:

> Hi,
>=20
> I was asked to do a detailed review of the 'why64' draft. Here are my =
thoughts and comments. Sorry for the delay, I've been a bit ill over the =
last day or so.
>=20
> General
> ~~~~~~
>=20
> I think it covers the topic well, and answers the fundamental =
questions of why IIDs are 64 bits and why their 64 bit size should be =
preserved. I could not think of any areas of related discussion that =
were missed.
>=20
> Suggested Changes
> ~~~~~~~~~~~~~~~~
>=20
> My suggested changes are limited to what I think might be some better =
wordings or grammar (sometimes trivial), additional references and some =
reordering of sections of text.
>=20
> Below is in draft top-to-bottom order.
>=20
>=20
> 1.  Introduction
>=20
> - additional comma
>=20
> "IPv6 addresses were originally chosen to be 128 bits long to provide
>    flexibility and new possibilities, rather than simply relieving the
>    IPv4 address shortage*,* by doubling the address size to 64 bits."
>=20
>=20
>=20
> - change 'done' to 'completed' (or 'complete' - both sound right, so =
I'm not sure which is better)
>=20
> "The notion of a /64 boundary in the address was introduced after the
>    initial design of IPv6 was done, following a period when it was
>    expected to be at /80."
>=20
> to
>=20
> "The notion of a /64 boundary in the address was introduced after the
>    initial design of IPv6 was *completed*, following a period when it =
was
>    expected to be at /80."
>=20
>=20
>=20
> - additional commas
>=20
> "The addressing architecture*,* as modified by [RFC7136]*,*
>    states that "For all unicast addresses, except those that start =
with
>    the binary value 000, Interface IDs are required to be 64 bits =
long."
>=20
>=20
>=20
> 2.  Advantages of a fixed identifier length
>=20
> - change 'wide-area' to 'aggregate'
>=20
> "An immediate effect of fixing the IID length at 64
>    bits is, of course, that it fixes the subnet prefix length also at =
64
>    bits, regardless of the wide-area prefix assigned to the site
>    concerned, ..."
>=20
> to
>=20
> "An immediate effect of fixing the IID length at 64
>    bits is, of course, that it fixes the subnet prefix length also at =
64
>    bits, regardless of the *aggregate* prefix assigned to the site
>    concerned, ..."
>=20
>=20
>=20
> - add 'simpler and'
>=20
> "Network design is therefore much
>       more straightforward."
>=20
> to=20
>=20
> "Network design is therefore much *simpler and*
>       more straightforward."
>=20
>=20
>=20
> - change 'the next /64' to 'another /64 from the pool'
>=20
> "Adding a subnet is easy - just take the next /64."
>=20
> to
>=20
> "Adding a subnet is easy - just take *another /64 from the pool*."
>=20
>=20
>=20
> 3.  Arguments for shorter identifier lengths
>=20
> - roughly express the magnitude of space not used to make it clearer =
there is both plenty available for /56s & /48s and also plenty left for =
other schemes
>=20
> "With only
>    2000::/3 currently committed for unicast addressing, we still have
>    most of the address space in reserve."
>=20
> to
>=20
> "With only
>    2000::/3 currently committed for unicast addressing, we still have =
*close to 7/8ths*=20
>    of the address space in reserve."
>=20
>=20
> 3.4.  Concerns over ND cache exhaustion
>=20
> - add ref to RFC3756, "IPv6 Neighbor Discovery (ND) Trust Models and =
Threats"
> - split long sentence
>=20
> "A site may be concerned that it is open to neighbour discovery (ND)
>    cache exhaustion attacks, whereby an attacker sends a large number =
of
>    messages in rapid succession to a series of (most likely inactive)
>    host addresses within a specific subnet, in an attempt to fill a
>    router's ND cache with ND requests pending completion, in so doing
>    denying correct operation to active devices on the network."
>=20
> to
>=20
> "A site may be concerned that it is open to neighbour discovery (ND)
>    cache exhaustion attacks [RFC3756], whereby an attacker sends a =
large number of
>    messages in rapid succession to a series of (most likely inactive)
>    host addresses within a specific subnet*. This is an* attempt to =
fill a
>    router's ND cache with ND requests pending completion, in so doing
>    denying correct operation to active devices on the network.=94

If you=92re to break the sentence, I=92d say =93Such an attack attempts =
to fill=85=94

In the para below I=92d change "An example would be to use a /120 =
prefix=85=94 to =93One potential way to mitigate this attack would be to =
consider using a /120 prefix=85=94

> - remove or better place the 'hosts likely use DHCPv6' text is it =
seems out of context by itself, or isn't really relevant

>=20
> "Hosts would likely use DHCPv6, or be manually configured with
>    addresses.=94

It is relevant, but I would change the line to:

Given SLAAC assumes a 64bit network boundary, in such an approach hosts =
would likely need to use DHCPv6, or be manually configured with =
addresses."

> 4.1.  Interaction with IPv6 specifications
>=20
> - make it clearer that there would be considerable time effort =
involved in updating RFCs
>=20
> "Regardless of implementation issues, the RFCs themselves
>    would all need to be updated if the 64-bit rule was changed, even =
if
>    the updates were small."
>=20
> to
>=20
> "Regardless of implementation issues, the RFCs themselves
>    would all need to be updated if the 64-bit rule was changed, even =
if
>    the updates were small*, which would involve considerable time and =
effort*."
>=20
>=20
>=20
> - add a ref to RFC6177, "IPv6 Address Assignment to End Sites"
>=20
> "First and foremost, the RFCs describing the architectural aspects of
>    IPv6 addressing explicitly state, refer and repeat this apparently
>    immutable value: Addressing Architecture [RFC4291], Reserved
>    Interface Identifiers [RFC5453], ILNP [RFC6741]."
>=20
> to
>=20
> "First and foremost, the RFCs describing the architectural aspects of
>    IPv6 addressing explicitly state, refer and repeat this apparently
>    immutable value: Addressing Architecture [RFC4291], *IPv6 Address =
Assignment to End Sites [RFC6177]*, Reserved
>    Interface Identifiers [RFC5453], ILNP [RFC6741].=94

Seems reasonable.

> - It seems the only difference between MLDv1 and MLDv2 is that the =
MLDv2 RFC explicitly stated the fe80::/64 prefix and how the lower 64 =
bits of the LL address are to be used to select a querier - MLDv1 has =
the same link-local address use rules, just not in as much detail. So =
perhaps make the MLDv2 text better focus on the explicit statement of =
the fe80::/64 prefix (the current text made me wonder if MLDv1 messages =
might not be required to come from LL addresses.)
> - Delete duplicate 'length' - "prefix length of length /64"
>=20
> " The MLDv2 protocol [RFC3810] mandates all queries be sent with the
>    fe80::/64 link-local source address prefix and subsequently bases =
the
>    querier election algorithm on the link-local subnet prefix length =
of
>    length /64."
>=20
> to something like
>=20
> "MLDv1 [RFC2710] and MLDv2 [RFC3810] protocols mandate that all =
queries are sent with a link-local source address, with exception to MLD =
messages sent using the unspecified address, when the link-local address =
is tentative [RFC3590]. At the the time of publication of [RFC2710], =
[RFC2373] specified link-local addresses with 64-bit interface =
identifiers. MLDv2 [RFC3810] explicitly stated the use of the fe80::/64 =
link-local prefix, and based the querier election algorithm on the =
link-local subnet prefix of length /64.=94

Seems good.

> - Highlight that support for 'on-link' anycast is a basic IPv6 =
neighbor discovery capability, and therefore applications would expect =
it to be availale.
>=20
> "This could of course be fixed in the way
>    described for /127 in [RFC6164], i.e., avoiding the use of anycast
>    within a /120 subnet."
>=20
> to
>=20
> "This could of course be fixed in the way
>    described for /127 in [RFC6164], i.e., avoiding the use of anycast
>    within a /120 subnet. Note that support for "on-link anycast" is a =
standard IPv6 neighbor discovery capability [RFC4861][RFC7094], and =
therefore applications and their developers would expect it to be =
available."
>=20
>=20
>=20
> 4.2.  Possible areas of breakage
>=20
> - Possibly change 'breakage' to 'failure' throughout this section.
>=20
> (The informality of 'breakage' appeals to me, however it is probably a =
bit too informal for this sort of document. I thought it might not be a =
real word, however apparently it is, and is referring to unused and =
therefore highly profitable service(s), such as unused calling card =
credit. )  =20

Agree, =93breakage=94 is not the best word.

> - make the following read a bit better
>=20
> "[RFC3972] has defined a detailed algorithm how to generate 64-bit
>       interface identifier from a public key and a 64-bit subnet =
prefix."
>=20
> changed to
>=20
> "[RFC3972] has defined a detailed algorithm *describing* how to =
generate *a* 64-bit
>       interface identifier from a public key and a 64-bit subnet =
prefix."
>=20
>=20
>=20
> - change 'Breaking' to 'Changing' to make it read a bit better
>=20
> "Breaking the /64 boundary would certainly break the current CGA
>       definition."
>=20
> to
>=20
> "*Changing* the /64 boundary would certainly break the current CGA
>       definition.
>=20
>=20
> - I think the follow link-local text in the last paragraph of the =
section should instead be another bullet point in the previous list, =
reworded appropriately.
> - While I certainly agree all hosts should use same length LL =
prefixes/IIDs, I'm not sure I understand why it would be a problem if =
they didn't. As far as I can tell, other than the formation of the LL =
address, prefix lengths and therefore IID lengths are never used in LL =
related operations. The egress interface has to be supplied when using =
an LL address, rather than a longest match route table lookup =
determining it, so the link-local prefix length/IID length doesn't =
matter for that, and other related operations such as NS/NA don't seem =
to use prefix length for any validation, including of LL addresses. So I =
think more or clearer explanation of the problem would would be useful.=20=

>=20
>=20
> "There is however the rather special case of the link-
>    local prefix.  While RFC 4862 is careful not to define any specific
>    length of link-local prefix within fe80::/10, [RFC4291] does define
>    the link-local IID length to be 64 bits.  Operationally there could
>    be a problem unless all hosts on a link use IIDs of the same length
>    to configure a link-local address during reboot.  Typically today =
the
>    choice of 64 bits for the link-local IID length is hard-coded per
>    interface, and systems behave as if the link local prefix was
>    actually fe80::/64.  There might be no way to change this except
>    conceivably by manual configuration, which will be impossible if =
the
>    host concerned has no local user interface."
>=20
>=20
> 4.3.2.  Other Observations
>=20
> - The first paragraph is referring to forwarding, the second paragraph =
seems to be referring to packet filtering, and then the third paragraph =
is again referring to forwarding. I think it would be better if the =
second and third paragraphs were swapped, so that the two paragraphs =
discussing forwarding were next to each other.
>=20
> - The ordering of the paragraphs made me a little confused about what =
type of 'filtering' was being discussed on the second paragraph. I =
presume it is packet filtering, so perhaps making it clearer would be =
better after the paragraph has been moved:
>=20
> "It has been reported that at least one type of switch has a content-
>    addressable memory limited to 144 bits, which is indeed a typical
>    value for commodity components [TCAM].  This means that filters
>    cannot be defined based on 128-bit addresses and two 16-bit port
>    numbers; the longest prefix that could be used in such a filter is =
a
>    /112."
>=20
> changed to
>=20
> "It has been reported that at least one type of switch has a content-
>    addressable memory limited to 144 bits, which is indeed a typical
>    value for commodity components [TCAM].  This means that *packet* =
filters or *access control lists*
>    cannot be defined based on 128-bit addresses and two 16-bit port
>    numbers; the longest prefix that could be used in such a *packet* =
filter is a
>    /112."
>=20
>=20
>=20
> 4.4.  Implementation and deployment issues
>=20
> - Reference to RFC5942, "IPv6 Subnet Model: The Relationship between =
Links and Subnet Prefixes"
>=20
> "It does this (even if
>    technically it violates the protocol) because if there is no router
>    on the link, the hosts effectively would fail to communicate each
>    other with the configured addresses because the "on-link =
assumption"
>    was removed in [RFC4861]."
>=20
> to
>=20
>=20
> "It does this (even if
>    technically it violates the protocol) because if there is no router
>    on the link, the hosts effectively would fail to communicate each
>    other with the configured addresses because the "on-link =
assumption"
>    was removed in [RFC4861]*[RFC5942]*."
>=20
>=20
>=20
> - I think 'deployed at' reads a bit better
>=20
> "Finally, IPv6 is already installed on many sites, with a large number
>    of staff trained on the basis of the existing standards, supported =
by
>    documentation and tools based on those standards."
>=20
> changed to
>=20
> "Finally, IPv6 is already *deployed at* many sites, with a large =
number
>    of staff trained on the basis of the existing standards, supported =
by
>    documentation and tools based on those standards."
>=20
>=20
>=20
> 4.5.  Privacy issues
>=20
> - I'm not really sure the following text is relevant, as it discussing =
how a level of privacy could be achieved with much shorter IIDs, which =
is venturing down the path of assuming IID lenghts will be changed, =
contrary to what this draft is saying and justifying shouldn't happen, =
and therefore solutions need to be developed to how to get what we've =
already got with 64-bit IIDs.

I think it=92s arguing that if the IID is shorter,=20

> - Alternatively, if this text is to remain, then I think it is =
necessary to point out that there is not any currently defined automated =
recovery procedure from DAD failure. Currently the failed address is not =
to be used and a system message is to be logged, or in the case of a =
link-local addr DAD failure, IPv6 is to be completely disabled on the =
interface according to RFC4862. (If anybody wants to automate DAD =
recovery, Appletalk would be an example of how to deal with it.)

I think this is a good point for short IIDs, but needs to be captured in =
a new section 4.6 =93DAD implications=94 (or similar), as it=92s not a =
privacy issue.  However, I would again assume in (say) a /120, that =
addresses would be assigned by DHCPv6, or manually, and there would be =
no RFC 7217 or RFC 4941 addresses used (I recall 7217 is agnostic to IID =
length but 4941 assumes /64).

> 5.  Security Considerations
>=20
> - Add example /120 prefix qualifier in, as the last sentence of the =
previous paragraph made me think the following paragraph was again =
talking about a /64.
>=20
> "However, assume that an attacker finds one valid address A and then
>    starts a scanning attack by scanning "outwards" from A, by trying
>    A+1, A-1, A+2, A-2, etc."
>=20
> changed to
>=20
> "However, assume that an attacker finds one valid address A *in a =
/120* and then
>    starts a scanning attack by scanning "outwards" from A, by trying
>    A+1, A-1, A+2, A-2, etc.=94

Yes.

Thanks!
Tim

>=20
>=20
>=20
> That's it I think.
>=20
>=20
> Best Regards,
> Mark.
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Wed Aug  6 05:40:32 2014
Return-Path: <rja.lists@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1AB1B29BD for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 05:40:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 WNPm-2o3-Ozc for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 05:40:30 -0700 (PDT)
Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F991A0004 for <ipv6@ietf.org>; Wed,  6 Aug 2014 05:40:30 -0700 (PDT)
Received: by mail-qa0-f43.google.com with SMTP id w8so2363433qac.16 for <ipv6@ietf.org>; Wed, 06 Aug 2014 05:40:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=/OuBtNn8s6WoZ/tcHNFo2FBkO4xXbJsCbl4fOtj3TVg=; b=b0NtZTZ9XM2mnLRmKxVSmrpaiCi6SIR1MUz28fqMOZPaLueenNQIBjOOeaJUjbpT/w OJfI/+1P8wIbtOpt9Dvc1YgVDBHlXI46FIqfbgtTTkOnVhoGSAeplOyORPq1OgDRje46 RSJCuOgwbiYPa/00ZQ35/LZKomENtx+qOJ0D3qsJMYADZImuE3pJyfs9Xqu/hr6d+5B4 84DHPpJgP50qxbGE4S2RDPQs3PHUa9DNYXtd6Ok/NMHrbbrxUP4oICeNFAQQIccKEmc7 /oxOfNmNeJgsz9b+cs4EW7JY24TFxvH1dNJG9xE0lnsBlwHP5iNKFtY9B3Yb1BGQ0Il3 Bg7g==
X-Received: by 10.224.43.10 with SMTP id u10mr16562363qae.20.1407328829382; Wed, 06 Aug 2014 05:40:29 -0700 (PDT)
Received: from [10.30.20.8] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id i5sm1458658qaz.3.2014.08.06.05.40.28 for <ipv6@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 05:40:28 -0700 (PDT)
From: RJ Atkinson <rja.lists@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Detailed review of "Analysis of the 64-bit Boundary in IPv6 Addressing"
Date: Wed, 6 Aug 2014 08:40:29 -0400
Message-Id: <15E55D44-7334-4A3A-A4AC-A519FC5936AA@gmail.com>
To: ipv6@ietf.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/E6y8fkea22pVI0f70sztmnAj3UI
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 12:40:31 -0000

Earlier, Mark ZZZ Smith suggested:
> - change 'done' to 'completed' (or 'complete' - both sound right,
> so I'm not sure which is better)

Having lived IPv6 for 20 years now, I don't think that "complete'
or 'completed' is really historically accurate.  My sense is
that 'done' in this document should more have the meaning of 
'perform' or 'undertaken', rather than 'complete', if we're
trying to be historically accurate.

So, if 'done' is too ambiguous, I'd suggest s/done/undertaken/
as a more accurate description of the sequencing and history.

Yours,

Ran


From nobody Wed Aug  6 05:43:41 2014
Return-Path: <rja.lists@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05971B2A02 for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 05:43:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 tl_TdFlpQsw5 for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 05:43:27 -0700 (PDT)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387311B2A04 for <ipv6@ietf.org>; Wed,  6 Aug 2014 05:43:27 -0700 (PDT)
Received: by mail-qg0-f51.google.com with SMTP id a108so2467762qge.38 for <ipv6@ietf.org>; Wed, 06 Aug 2014 05:43:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=742UbXfuaamaQq5dJDC7gZNA5dLvlnjRlC8cobEDJqA=; b=uFh/fJdozTclT8OZioF21vG/W6xM19mUi5wMHUThGFYg1kuRgxpteCgtlS1ME3bg+m 3ICRLfVQCBreVb+AzEsrnn4ofbgJihRRqS3gG/g6YjH5fYtU/uNUdt9FUpI07tQfBC5x qsC6/8pVmp9hkTjeLshjlvci22ORjtOD4auj9rjAnyak9ryF4MVnc411x/YBEZxkhlRQ X7Bzx9oEY4asAJJFhAIYXpt+GZ/rUXtld7iomwOLQT4GMXPcshoMOsUIb8ZDHbqyGmSo 93ioTfNevygtqBMbNWIEiAtrmaCAJQFO7VzfOrDKSTBSZVhz0dSSXlXP4Rra5lCxUVba KrPg==
X-Received: by 10.140.49.201 with SMTP id q67mr3538520qga.7.1407329006412; Wed, 06 Aug 2014 05:43:26 -0700 (PDT)
Received: from [10.30.20.8] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id t3sm1457389qak.18.2014.08.06.05.43.25 for <ipv6@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 05:43:26 -0700 (PDT)
From: RJ Atkinson <rja.lists@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Detailed review of "Analysis of the 64-bit Boundary in IPv6 Addressing"
Date: Wed, 6 Aug 2014 08:43:26 -0400
Message-Id: <F600C381-FE35-436D-8FAA-D7099238356E@gmail.com>
To: ipv6@ietf.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/dq7Z30g4ZluSA-94dFIoN62RK4U
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 12:43:34 -0000

I agree with Tim Chown's comments to the IPv6 list from earlier today,
including but not limited to the need for a new subsection 4.6 on 
"DAD Issues".

Yours,

Ran


From nobody Wed Aug  6 05:52:43 2014
Return-Path: <rja.lists@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5DC1B2A0A for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 05:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 kIcZ3C4d1BQC for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 05:52:38 -0700 (PDT)
Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A39B1B29BD for <ipv6@ietf.org>; Wed,  6 Aug 2014 05:52:38 -0700 (PDT)
Received: by mail-qa0-f53.google.com with SMTP id v10so2330433qac.40 for <ipv6@ietf.org>; Wed, 06 Aug 2014 05:52:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=WKBu90SSYZuaLYeA6gKLqndIpIYGAY/oC7NXqBnCMOI=; b=KlDpL8wCQy15wZJ2Sot+T8LIBW/rlGMz428BjJCWaDU7jlYtXlfEL0i9GhppxpItUD jckuzoUwLg+26nCKOS4QSXHkPx/S9Tw+PEe8soPCswZYTIzxTjfVisVKzjYF9adIfr85 cd69nVJKt42ZYSHlc3XOMB0Pgk2AUS7jigCT2C7axIG1hFJgVZcX9TXG6lXuQTFL4H/1 65UFgXePxpaMxAbpLVtR6VV1tcEGgVtCNUSbB0Mm/3XAN7oGtKwwpsafK8+ytsiup7bu WJPKuchUxMrhYFV7+VE6XJ92KKOdlzBmBNBSK6J5HQwpD73GcV/ybouBLe8WYu2jY5e/ 6+cA==
X-Received: by 10.140.102.142 with SMTP id w14mr2925569qge.101.1407329557643;  Wed, 06 Aug 2014 05:52:37 -0700 (PDT)
Received: from [10.30.20.8] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id 103sm908969qgi.39.2014.08.06.05.52.37 for <ipv6@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 05:52:37 -0700 (PDT)
From: RJ Atkinson <rja.lists@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Detailed review of "Analysis of the 64-bit Boundary in IPv6 Addressing"
Date: Wed, 6 Aug 2014 08:52:37 -0400
Message-Id: <34C23327-E5EF-40C6-AD88-85810BC0014E@gmail.com>
To: ipv6@ietf.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/C9w6n8AQZKG-UiUW6mc0KMNuzIw
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 12:52:40 -0000

On August 5th 2014, David Farmer wrote, in part:
> Yes, we should do the math for them. ...the important concept
> to communicate is the vast majority of IPv6 addresses space is reserved.

I agree that it is very helpful to explicitly provide an
(approximate) fraction to indicate that the vast majority 
of IPv6 address space is reserved.

Purely by way of example, I am comfortable with text of the form 
"close to X/Y of the address space is reserved at present" 
or "approximately X/Y of the address space is reserved at present".

ALSO, I think we need to make clear that of the non-reserved
global unicast address space, the vast majority of that also
is not yet allocated.

In short, the document ought to be crystal clear that we are in
no serious danger of running out of IPv6 address space.  While
thoughtful management is always sensible, we really do have enough 
IPv6 address space that users really ought to be delegated enough
global unicast addresses for internal subnetting - by delegating 
IPv6 routing prefixes shorter than /64 (e.g. while retaining support 
for SLAAC).

Yours,

Ran Atkinson



From nobody Wed Aug  6 06:04:43 2014
Return-Path: <rja.lists@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7231B2A06 for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 06:04:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 WZ_2hxDYC-7i for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 06:04:39 -0700 (PDT)
Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5509F1B29FC for <ipv6@ietf.org>; Wed,  6 Aug 2014 06:04:39 -0700 (PDT)
Received: by mail-qg0-f54.google.com with SMTP id z60so2580189qgd.41 for <ipv6@ietf.org>; Wed, 06 Aug 2014 06:04:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=k9EGUnx8bpVb3sAhXWu9zcbgCGIzNVDKR3YF68gXKMA=; b=XEq5Wv+cDYgYZP54PIEKQa2xjXYZfzb8RT9ZS6ln13GX+pkJ4RLwcXU7sjLgKOQX45 d8TqR8xhaB6zbRov3wjCz6hTcJjUifGGOkbR88cJoAThTF75BRIw0QS38ACLd+6Ir2kS xDVp2jG3Ii0YQiq8RJmEf21tak0PBExXSy5W3yyimoPdz1b33bBO/fPCEAbKWZJUlLkf D2dW9mN4YCZwD4AP3XIQagWcHvloYv1vLISyoAha70mz1z0zq0NhIpdskKKXJuVnbdxs J+3ZOTtPXDPlYtR2/DlfchAyYF9mXjF1kUgzkNr0DucYqrCYcTKXGlJwwJPF96W9BN6u HlHw==
X-Received: by 10.224.69.136 with SMTP id z8mr16368425qai.60.1407330278515; Wed, 06 Aug 2014 06:04:38 -0700 (PDT)
Received: from [10.30.20.8] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id 70sm944702qgx.24.2014.08.06.06.04.38 for <ipv6@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 06:04:38 -0700 (PDT)
From: RJ Atkinson <rja.lists@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
Date: Wed, 6 Aug 2014 09:04:38 -0400
Message-Id: <08821EDB-4B73-414D-A3A5-832E99E330AE@gmail.com>
To: ipv6@ietf.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/1Vm-cqvKWrBZ5Vvzh2f94rjQ5G8
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 13:04:41 -0000

SCOPE:
  This note is both a general comment and also a specific comment
  on the "Analysis of the 64-bit Boundary in IPv6 Addressing" draft.


As a consultant, I deal with a range of different network user groups.

Large enterprises are very comfortable maintaing and configuring lots
of infrastructure (e.g. DHCP servers, sophisticated address plans).
Most colleges/universities seem to be very similar to large enterprises
in this regard.  Obviously, exceptions do exist.

The number of large enterprises is dwarfed by the number of small
enterprises that are connected (or starting to connect) to the Internet.
However, many small enterprises can't afford to maintain or configure
any infrastructure.  They don't have a full-time IT person.  They
pay per-hour for on-call IT help instead.  They buy next-day on-site 
support for their PCs/Macs when they buy the hardware.  A number of the 
small enterprises that I deal with find SLAAC the biggest benefit of IPv6.  
SLAAC permits them to provide bare-minimum, one-time, configuration 
to 1 device (usually a site border-router/firewall that nearly always 
costs less than US$ 1000, and often costs less than US$ 150).  Some
use MS Windows Server, but a growing number of the small enterprise
sites that I see don't really have a "server" at all.  They've 
outsourced their public web page and their SMTP relay to some
service provider (sometimes their ISP, other times some different
firm).  Enabling and managing a DHCP server just is not practical 
or cost-effective to many small businesses.

Small enterprise users are possibly the least represented category
of IPv6 (and IPv4) users within the IETF.  SLAAC is really important
to these users.  It would be nice if the WG would keep this user
community (and SLAAC's importance to them) in the front of our
minds.

Yours,

Ran Atkinson




From nobody Wed Aug  6 07:34:37 2014
Return-Path: <pkampana@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB0A1B2BAD for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 07:34:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.502
X-Spam-Level: 
X-Spam-Status: No, score=-16.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 FBgJ6vuep-Jq for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 07:34:35 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D26361B2D47 for <6man@ietf.org>; Wed,  6 Aug 2014 07:34:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3806; q=dns/txt; s=iport; t=1407335654; x=1408545254; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FIa/Oci0Trexr9Qk8dXZsBwYbg//45SJAk5kifVLOa4=; b=hf1HOqIxcJ9hCFCSriLJJHBhfECdfDtKuvGx7MGyPIR2LXXBN2Tlw7bq kl9peFqQsopUBh0W/ZB5rFaDc2grTSXL1jOtC4iU4rjq0CSxVXRNg8Ive F3vm0gLmhMVR47rDUcK0ERyZY16DX9s/UhgbHH1MrX+NPTvy2yCM71IhD U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmQFADQ84lOtJA2H/2dsb2JhbABagw2BKQSCc9B6ARl3FneEAwEBAQMBIxFFBQcEAgEIEQQBAQMCBh0DAgICHxEUAQgIAgQOBQiIJgMJCKxTkCQNhmUXgSyLc4F8FhsHBoJzNoEcBZcZS4InkEGGK4NUbAGBRQ
X-IronPort-AV: E=Sophos;i="5.01,812,1400025600"; d="scan'208";a="66990397"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP; 06 Aug 2014 14:34:13 +0000
Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s76EYCIp029125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Aug 2014 14:34:12 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Wed, 6 Aug 2014 09:34:11 -0500
From: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: RE: draft-kampanakis-6man-ipv6-eh-parsing-01.txt
Thread-Topic: draft-kampanakis-6man-ipv6-eh-parsing-01.txt
Thread-Index: AQHPsR3Va/vhzIUY9EupZu/C91gJKpvDpJsg
Date: Wed, 6 Aug 2014 14:34:10 +0000
Message-ID: <1C9F17D1873AFA47A969C4DD98F98A7513C2C78E@xmb-rcd-x10.cisco.com>
References: <20140602170733.22309.62074.idtracker@ietfa.amsl.com> <1C9F17D1873AFA47A969C4DD98F98A7513BA2B0E@xmb-rcd-x10.cisco.com> <53E19257.1010702@gmail.com>
In-Reply-To: <53E19257.1010702@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.150.29.201]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/88dqgZvyvtxLqfDLD8taPgyeh5k
Cc: "6man@ietf.org" <6man@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 14:34:36 -0000

VGhhbmsgeW91IGFnYWluIGZvciB0aGUgY29tbWVudHMgQnJpYW4uDQpJIHdpbGwgdGFrZSBjYXJl
IG9mIGFsbCBvZiB0aGVtIGluIHRoZSBuZXh0IGl0ZXJhdGlvbi4NClBhbm9zDQoNCg0KLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJp
YW4uZS5jYXJwZW50ZXJAZ21haWwuY29tXSANClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwNSwgMjAx
NCAxMDoyNyBQTQ0KVG86IFBhbm9zIEthbXBhbmFraXMgKHBrYW1wYW5hKQ0KQ2M6IDZtYW5AaWV0
Zi5vcmcNClN1YmplY3Q6IGRyYWZ0LWthbXBhbmFraXMtNm1hbi1pcHY2LWVoLXBhcnNpbmctMDEu
dHh0DQoNClBhbm9zLA0KDQpBIGZldyByZXNpZHVhbCBjb21tZW50czoNCg0KPiAxLiAgSW50cm9k
dWN0aW9uDQouLi4NCj4gICAgW1JGQzI0NjBdDQo+ICAgIGRlc2NyaWJlcyBzb21lIElQdjYgRUgg
cmVjb21tZW5kYXRpb25zIG9mIHRoZSBvcmRlciBhbmQgYWxsb3dlZA0KPiAgICBvY2N1cnJlbmNl
cyBvZiBoZWFkZXJzLCBidXQgaXQgZG9lcyBub3QgcHJvdmlkZSBvdGhlciBndWlkYW5jZSBvbiBo
b3cNCj4gICAgRUhzIHNob3VsZCBiZSBwYXJzZWQuIA0KDQpJIGFwb2xvZ2lzZSBmb3IgcGx1Z2dp
bmcgbXkgb3duIFJGQywgYnV0IEkgdGhpbmsgaXQncyBpbXBvcnRhbnQgdG8gaW5zZXJ0IHNvbWV0
aGluZyBsaWtlIHRoaXMgaGVyZToNCg0KIFtSRkM3MDQ1XSB1cGRhdGVzIFJGQyAyNDYwIGJ5IHNw
ZWNpZnlpbmcgdGhlIHJlcXVpcmVkIGJlaGF2aW9yIG9mICBtaWRkbGVib3hlcyB3aGVuIGhhbmRp
bmcgYW4gRUggY2hhaW4sIGJ1dCBpdCBkb2VzIG5vdCBnbyBpbnRvIGRldGFpbCAgYWJvdXQgdGhl
IHBhcnNpbmcgcHJvY2Vzcy4NCg0KKFRoZSByZWFzb24gaXMgdGhhdCB3ZSByZWFsbHkgbmVlZCBh
bGwgdGhvc2UgbWlkZGxlYm94IGltcGxlbWVudG9ycyB0byBsb29rIGF0IHRoZSBJRVRGJ3MgbGF0
ZXN0IHRoaW5raW5nIG9uIHRoaXMuIFRoZXJlIGlzIGEgbG90IG9mIGNvZGUgb3V0IHRoZXJlIGJh
c2VkIG9uIGNhcmVsZXNzIHJlYWRpbmcgb2YgUkZDIDI0NjAuKQ0KDQo+ICBHdWlkZWxpbmUgMjog
RnJvbSBTZWN0aW9uIDUgb2YgW1JGQzcxMTJdLCB3aGVuIHBhcnNpbmcgYW4gRUggY2hhaW4sDQoN
ClRoYXQgc3RpbGwgcmVhZHMgYXMgaWYgeW91IGFyZSBxdW90aW5nIFJGQyA3MTEyLCBidXQgeW91
IGFyZSBub3QuDQpJIHN1Z2dlc3Q6DQoNCiBHdWlkZWxpbmUgMjogQXMgYSBjb25zZXF1ZW5jZSBv
ZiBTZWN0aW9uIDUgb2YgW1JGQzcxMTJdLCB3aGVuIHBhcnNpbmcgYW4gRUggY2hhaW4sDQoNCllv
dSBzdGlsbCBoYXZlIHRoaXMgcGhyYXNlIHR3aWNlOg0KDQo+IGZpZWxkIGlzIG5vdCBhbiBVcHBl
ciBMYXllciAoVUwpIHByb3RvY29sIChpLmUuICBUQ1ApDQoNCkkgaG9wZSB5b3UgbWVhbiAiKGUu
Zy4gVENQKSIgYmVjYXVzZSB0aGlzIHdvdWxkIGFwcGx5IHRvIGFueSBwcm90b2NvbCwgbm90IGp1
c3QgVENQLg0KDQpBbHNvLCB5b3UgY291bGQgYWRkIGEgbm90ZSB0aGF0IHRoZSBjdXJyZW50IGxp
c3Qgb2YgZGVmaW5lZCBFSCB2YWx1ZXMgaXMgbWFpbnRhaW5lZCBieSBJQU5BIGluIHRoZSAiSVB2
NiBFeHRlbnNpb24gSGVhZGVyIFR5cGVzIiByZWdpc3RyeSBjcmVhdGVkIGJ5IFJGQyA3MDQ1LiBU
aGlzIHJlZ2lzdHJ5IGlzIGludGVuZGVkIHByZWNpc2VseSBhcyBhIGNvbnZlbmllbnQgcmVmZXJl
bmNlIGZvciBpbXBsZW1lbnRvcnMuDQoNCj4gNC4gIFBhcnNpbmcgbWFsZm9ybWVkIEVIcw0KLi4u
DQo+ICAgIElmIHRoZSBkYXRhIG9mIHRoZSBsYXN0IEVIIG9yIHRoZSBVTA0KPiAgICBIZWFkZXIg
cGx1cyBpdHMgZGF0YSBkb2VzIG5vdCBhbGlnbiB3aXRoIHRoZSBvcmlnaW5hbCBJUHY2IEhlYWRl
cg0KPiAgICBQYXlsb2FkIExlbmd0aCB0aGUgcGFja2V0IE1VU1QgYmUgZHJvcHBlZCB1bmxlc3Mg
YW5vdGhlciBwb2xpY3kgc3RlcA0KPiAgICBhbHJlYWR5IGRpc2NhcmRlZCBpdC4NCg0KSSB0aGlu
ayB0aGlzIGlzIGluY29uc2lzdGVudCB3aXRoIGEgc3RhdGVtZW50IGluIFJGQyAyNDYwOg0KDQo+
IDQuNyBObyBOZXh0IEhlYWRlcg0KPiANCj4gICAgVGhlIHZhbHVlIDU5IGluIHRoZSBOZXh0IEhl
YWRlciBmaWVsZCBvZiBhbiBJUHY2IGhlYWRlciBvciBhbnkNCj4gICAgZXh0ZW5zaW9uIGhlYWRl
ciBpbmRpY2F0ZXMgdGhhdCB0aGVyZSBpcyBub3RoaW5nIGZvbGxvd2luZyB0aGF0DQo+ICAgIGhl
YWRlci4gIElmIHRoZSBQYXlsb2FkIExlbmd0aCBmaWVsZCBvZiB0aGUgSVB2NiBoZWFkZXIgaW5k
aWNhdGVzIHRoZQ0KPiAgICBwcmVzZW5jZSBvZiBvY3RldHMgcGFzdCB0aGUgZW5kIG9mIGEgaGVh
ZGVyIHdob3NlIE5leHQgSGVhZGVyIGZpZWxkDQo+ICAgIGNvbnRhaW5zIDU5LCB0aG9zZSBvY3Rl
dHMgbXVzdCBiZSBpZ25vcmVkLCBhbmQgcGFzc2VkIG9uIHVuY2hhbmdlZCBpZg0KPiAgICB0aGUg
cGFja2V0IGlzIGZvcndhcmRlZC4NCg0KVW5sZXNzIEkgaGF2ZSBtaXN1bmRlcnN0b29kIHNvbWV0
aGluZywgeW91ciBndWlkZWxpbmUgNSBuZWVkcyBhbiBleGNlcHRpb24gZm9yIHRoZSBObyBOZXh0
IEhlYWRlciBjYXNlLg0KDQooT3Igd2UgY291bGQgZGVjaWRlIHRoYXQgdGhlIGNhc2UgZGVzY3Jp
YmVkIGluIFJGQyAyNDYwIGlzIGFuIGludml0YXRpb24gdG8gYnVmZmVyIG92ZXJmbG93IGF0dGFj
a3MsIGFuZCBjaGFuZ2UgdGhlIHJ1bGUsIGJ1dCB0aGF0IHdvdWxkIG5lZWQgYSBmb3JtYWwgc3Rh
bmRhcmRzIHRyYWNrIHVwZGF0ZS4pDQoNClJlZ2FyZHMNCiAgIEJyaWFuDQo=


From nobody Wed Aug  6 10:54:33 2014
Return-Path: <farmer@umn.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2031A03E3 for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 10:54:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 gtlKaeaMvGwp for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 10:54:24 -0700 (PDT)
Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 5A70E1A03DF for <ipv6@ietf.org>; Wed,  6 Aug 2014 10:54:21 -0700 (PDT)
Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for <ipv6@ietf.org>; Wed, 6 Aug 2014 12:54:15 -0500 (CDT)
X-Umn-Remote-Mta: [N] mail-ie0-f182.google.com [209.85.223.182] #+LO+TS+TR
X-Umn-Classification: local
Received: by mail-ie0-f182.google.com with SMTP id y20so3274143ier.41 for <ipv6@ietf.org>; Wed, 06 Aug 2014 10:54:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Tz3JsWwslKrJHYNoamOOvm+bHFQuoTAOhy4IjL0yj3Y=; b=sw4NClHwazcLiRbG/KDPsZYQTydiZgnBTEUaBX7Ud0uttQscVkYt2VcWldBdrgNcvD 9H8Adaq0cZ8mTEUV/K5DWhVUzBHSwVpvCYT0wa3INoDi14W5vgtC3oWa53Z1DlN/bu+2 POlmBGEHlclnU1DTwWIBe7cDcgncc9wpUhGSg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Tz3JsWwslKrJHYNoamOOvm+bHFQuoTAOhy4IjL0yj3Y=; b=LwA7LcbIBNI6b7KijdcDJpTFbsKGXFnWSnUxMBuIL4NiryLT0glU+/8Zdp77dBy2cN wF/hi42RoP0+myVLpOSYEFxvr5JkQ8Wjg4ziRoDLTfIcjo9ywqqTkJOQcd2O4SIj9GNb ovpHLARPL4O9xxtXtZf5f+nkcuMvq85+AXMkGoyGIOVft1MYaap9OKXN/dAG/CczGQmw YMA6+5594865ahkYIb07idJmcQNbSKjaK1YBG3jQIOJn8GheuWlFByo5avF0R6x45aQY Nrr2/c9EKE1dB3kCiIDvKglN4P3SlSirqOyP4eW8P9JHAYhsmNS+3fSqxzzRZrq3Gbz2 DwCw==
X-Gm-Message-State: ALoCoQn3haIfxDiadAP5CybXosGAFTgWCMHOvi0ja10e7z0Y9dv4gmT/4z5IrsHkkZjRx7n2b+hdizPiVg/+kK5ey9B02EDFR8u6E6bARZqAWy56tfSRDNQ=
X-Received: by 10.42.68.66 with SMTP id w2mr16869024ici.74.1407347654860; Wed, 06 Aug 2014 10:54:14 -0700 (PDT)
X-Received: by 10.42.68.66 with SMTP id w2mr16869004ici.74.1407347654648; Wed, 06 Aug 2014 10:54:14 -0700 (PDT)
Received: from x-160-94-246-132.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:f430:ef39:875f:77af]) by mx.google.com with ESMTPSA id qd8sm3849771igb.1.2014.08.06.10.54.10 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 10:54:11 -0700 (PDT)
Message-ID: <53E26BC1.7090509@umn.edu>
Date: Wed, 06 Aug 2014 12:54:09 -0500
From: David Farmer <farmer@umn.edu>
Organization: University of Minnesota
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: RJ Atkinson <rja.lists@gmail.com>, ipv6@ietf.org
Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
References: <08821EDB-4B73-414D-A3A5-832E99E330AE@gmail.com>
In-Reply-To: <08821EDB-4B73-414D-A3A5-832E99E330AE@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/uj72O78wk4Ec1g_D9_wGMdR6yRI
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: David Farmer <farmer@umn.edu>
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 17:54:26 -0000

Ran,

I agree with the concept that SLACC is extremely important to minimize 
technical infrastructure and network management effort, especially in 
small enterprises.  However, I'm puzzled by how you intend this comment 
to apply to the why64 draft.

Are you suggesting SLACC should be modified to work with IID length 
other than /64?  Like DHCPv6 or manual configuration can?

Or, are you suggesting that the simplicity of SLACC with a singe IID 
length of 64 is important for minimizing technical infrastructure and 
network management effort, especially in small enterprises?  Maybe 
adding something to that effect in section 2.

Thanks

On 8/6/14, 08:04 , RJ Atkinson wrote:
> SCOPE:
>    This note is both a general comment and also a specific comment
>    on the "Analysis of the 64-bit Boundary in IPv6 Addressing" draft.
>
>
> As a consultant, I deal with a range of different network user groups.
>
> Large enterprises are very comfortable maintaing and configuring lots
> of infrastructure (e.g. DHCP servers, sophisticated address plans).
> Most colleges/universities seem to be very similar to large enterprises
> in this regard.  Obviously, exceptions do exist.
>
> The number of large enterprises is dwarfed by the number of small
> enterprises that are connected (or starting to connect) to the Internet.
> However, many small enterprises can't afford to maintain or configure
> any infrastructure.  They don't have a full-time IT person.  They
> pay per-hour for on-call IT help instead.  They buy next-day on-site
> support for their PCs/Macs when they buy the hardware.  A number of the
> small enterprises that I deal with find SLAAC the biggest benefit of IPv6.
> SLAAC permits them to provide bare-minimum, one-time, configuration
> to 1 device (usually a site border-router/firewall that nearly always
> costs less than US$ 1000, and often costs less than US$ 150).  Some
> use MS Windows Server, but a growing number of the small enterprise
> sites that I see don't really have a "server" at all.  They've
> outsourced their public web page and their SMTP relay to some
> service provider (sometimes their ISP, other times some different
> firm).  Enabling and managing a DHCP server just is not practical
> or cost-effective to many small businesses.
>
> Small enterprise users are possibly the least represented category
> of IPv6 (and IPv4) users within the IETF.  SLAAC is really important
> to these users.  It would be nice if the WG would keep this user
> community (and SLAAC's importance to them) in the front of our
> minds.
>
> Yours,
>
> Ran Atkinson


-- 
================================================
David Farmer               Email: farmer@umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================


From nobody Wed Aug  6 11:27:20 2014
Return-Path: <rja.lists@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5451A064C for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 11:27:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 OO5lBw83paIM for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 11:27:17 -0700 (PDT)
Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D171A0390 for <ipv6@ietf.org>; Wed,  6 Aug 2014 11:27:16 -0700 (PDT)
Received: by mail-qa0-f53.google.com with SMTP id v10so2913887qac.12 for <ipv6@ietf.org>; Wed, 06 Aug 2014 11:27:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=YvLXttuyUGnnbpnWvYTMHZVy8C/JkZ3zjE5CuoT7JLk=; b=096pOHxFSoNSPHHS2tp/SS+Q2R37BPp5h3ByQ3af2vk6CrWHTHB9BsczRylEy3geSK Zex8wDmHAngrXFv7Nja/w+2dxcJImVAP94DjyXI4mnlB3x7riV6C80YWaZHOtrkNDJBZ l/pmkPM5dCrMklhNg1z+NkbsPfDAHFQCbtbFQkpPnB+NLq+3kkBuQUWPgel0P1oIomKj nERoxtgjmPKUQyXjHmSlW2A0lup2QsFFVt4YcvLC4OLA+N4TFmwBnQCQj015hCahBpKz Ta2LK7iT3gU3rp0RTmrQWJ/iEOBfe88OaqUJ3uX7pGQU39rLxgsAz6cU/Agj6JrHSTOA pDeg==
X-Received: by 10.224.47.67 with SMTP id m3mr19072082qaf.28.1407349631538; Wed, 06 Aug 2014 11:27:11 -0700 (PDT)
Received: from [10.30.20.8] ([173.79.6.58]) by mx.google.com with ESMTPSA id j3sm1767988qgj.48.2014.08.06.11.27.10 for <ipv6@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 11:27:10 -0700 (PDT)
From: RJ Atkinson <rja.lists@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
Date: Wed, 6 Aug 2014 14:27:08 -0400
Message-Id: <776E0CDC-3D76-4066-9AC6-2BA151C0312E@gmail.com>
To: ipv6@ietf.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/AyxlYXpUnfYPrwb30JKHniVuOZs
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 18:27:18 -0000

On 06  Aug 2014, at 13:54 , David Farmer wrote:
> Or, are you suggesting that the simplicity of SLACC with
> a single IID length is important for minimising technical
> infrastructure and network management effort, especially in
> small enterprises? 

Yes, to the *edited* text above. 

(Of course the same comment also applies to a number of other
deployment scenarios, for example residential networks,
but my note was focused on "small enterprises".)

Yours,

Ran


From nobody Wed Aug  6 11:38:30 2014
Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC521A02E5 for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 11:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
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 UVzMSZdokwYj for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 11:38:26 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28AA81ADDB5 for <ipv6@ietf.org>; Wed,  6 Aug 2014 11:38:24 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s76IcMGV031952 for <ipv6@ietf.org>; Wed, 6 Aug 2014 20:38:22 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5FBD0208A5D for <ipv6@ietf.org>; Wed,  6 Aug 2014 20:41:21 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4E9E92043C8 for <ipv6@ietf.org>; Wed,  6 Aug 2014 20:41:21 +0200 (CEST)
Received: from [127.0.0.1] ([132.166.86.6]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s76Ic05K006932 for <ipv6@ietf.org>; Wed, 6 Aug 2014 20:38:21 +0200
Message-ID: <53E27607.6070105@gmail.com>
Date: Wed, 06 Aug 2014 20:37:59 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
References: <776E0CDC-3D76-4066-9AC6-2BA151C0312E@gmail.com>
In-Reply-To: <776E0CDC-3D76-4066-9AC6-2BA151C0312E@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/1dyJRUND2wpqU1VWuwPSN4rKgb8
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 18:38:28 -0000

Le 06/08/2014 20:27, RJ Atkinson a écrit :
>
> On 06  Aug 2014, at 13:54 , David Farmer wrote:
>> Or, are you suggesting that the simplicity of SLACC with
>> a single IID length is important for minimising technical
>> infrastructure and network management effort, especially in
>> small enterprises?
>
> Yes, to the *edited* text above.
>
> (Of course the same comment also applies to a number of other
> deployment scenarios, for example residential networks,
> but my note was focused on "small enterprises".)

Whereas I consider the small enterprise perspective very enriching, I 
disagree with the conclusion on SLAAC.

Other than big and small enterprises, there are many single users who 
need to grow their networks beyond what their suppliers consider to be edge.

The 64 length of Ethernet-and-kin IIDs imposed on SLAAC are a break to 
that growth.

Alex

>
> Yours,
>
> Ran
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>



From nobody Wed Aug  6 11:44:43 2014
Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4F81B27B3 for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 11:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.683
X-Spam-Level: 
X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
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 SHbnuf9_4DMD for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 11:44:38 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 330E71B2792 for <ipv6@ietf.org>; Wed,  6 Aug 2014 11:44:38 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s76IiaFT010223; Wed, 6 Aug 2014 20:44:36 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 546C8202836; Wed,  6 Aug 2014 20:47:35 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 48B542007FF; Wed,  6 Aug 2014 20:47:35 +0200 (CEST)
Received: from [127.0.0.1] ([132.166.86.6]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s76IiUdN008958; Wed, 6 Aug 2014 20:44:35 +0200
Message-ID: <53E2778E.9090301@gmail.com>
Date: Wed, 06 Aug 2014 20:44:30 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: =?UTF-8?B?RGFuIEzDvGR0a2U=?= <maildanrl@gmail.com>
Subject: Re: updated draft-petrescu-autoconf-ra-based-routing-05.txt - RAs for routing between moving networks
References: <53CE3624.3040007@gmail.com> <CAAfuxnLJq2pvpUThQ7tzhAEfyuFE-aNuVXE1H1=gtbAfnygzxA@mail.gmail.com>
In-Reply-To: <CAAfuxnLJq2pvpUThQ7tzhAEfyuFE-aNuVXE1H1=gtbAfnygzxA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/WvGmiaUYf65W9YWsf-IfY0GPHo0
Cc: Ipv <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 18:44:41 -0000

Le 04/08/2014 15:44, Dan Lüdtke a écrit :
> Hi Alexandru,
>
>> Each Mobile Router multicasts special RAs on the egress interface,
>> containing the Mobile Network Prefix that is assigned to its
>> moving network.
>
> Could there be a situation where "normal" and "special" RAs are being
> sent by the same router?

Yes, certainly.  For example a MR in a vehicle may send a special RA on
the egress interface (e.g. 802.11p connecting to other vehicles) and a
normal RA on the ingress interface (e.g. 802.11ac inside the vehicle,
towards the passengers' tablets).

> If so, how will they differ despite the M-Bit set? Will this lead to
> routers sending two types of RAs? Is there a special reason why we do
> not mark the individual Route Information Option with a M-Bit but the
> whole RA?

Right, that is a good point.  An encoding where that is performed may be
better than in the whole RA.

Can the RIO contain a new flag (is there some place in it)?  The reason
there is a special bit (M) in the RA header is that it is there that we
found a place to encode a new functionality, at a time when the RA Flag
Expansion bits was beco,ing an RFC.  Maybe it was not the right place.

> I tried to do a sketch how to implement this draft into the "ratools"
> daemon, at came accross the mentioned questions.

This is very good to do.  May I ask in which context are you trying to
implement this?  For what kind of applications?

Alex

>
> Cheers
>
> Dan
>
> On Tue, Jul 22, 2014 at 12:00 PM, Alexandru Petrescu
> <alexandru.petrescu@gmail.com> wrote:
>> Hello,
>>
>> We have updated the draft "RAs for routing between moving networks"
>>
>> http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-05
>>
>>
>>
>>
This draft describes an extension to be carried by RAs containing IP
>> prefixes to be exchanged between mobile routers ('exchanged' - as
>> opposed to 'announcing' prefixes active on links).
>>
>> The implementation of this extension allows 1-hop neighboring
>> vehicles to establish IP paths between any pair of onboard
>> IP-addressable devices; one potential application is a live
>> videostream sent by an IP camera in a large vehicle to an IP
>> display in the following vehicle, to help during view-obstructing
>> situations.
>>
>> This -05 update is minor - just added a reference to another draft
>> which may present similarities.
>>
>> Alex
>>
>> --------------------------------------------------------------------
>>
>>
>>
IETF IPv6 working group mailing list
>> ipv6@ietf.org Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>>
>>
>
>



From nobody Wed Aug  6 14:59:08 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AD51B28AB for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 14:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 Ztma0lK_1emA for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 14:59:05 -0700 (PDT)
Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A673E1B28AA for <ipv6@ietf.org>; Wed,  6 Aug 2014 14:59:05 -0700 (PDT)
Received: by mail-pd0-f179.google.com with SMTP id ft15so3965691pdb.24 for <ipv6@ietf.org>; Wed, 06 Aug 2014 14:59:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hYDOcaCJtigT0KQJ3V0CKxS6Z/QXUa78URqtwx7YBUo=; b=tHz07sS0FVDzOR+MlTiau3fPfHIBeVAkEkEvmXwXKUeXNPI46czXUQJEZ1G9NGECOX H9Dex4ZyCFVvy/Dpu5tzad1+zkk3yxysZFzl7dmf9U2uV0eKkDKFOMZbItAYUESa3L7M 9aWWFGR19aPfzGFSFfWRlH9eYfEuhg3z08esdF2dHBvW3T+p9kmHOhjvJO2VLFcKOn0a 9vW4L39go0B8keInRss04qFJPIy94qbyC6dPkMnI+0bAvB+0/q0DVmvYJRFg7Aae2JaT fsCuldImaOMx6gtIYH+/RTsx3/e1H4x+hdOB8HYLj3QX29oujwFy1jUlzHjds36YBcKk c8IQ==
X-Received: by 10.66.122.175 with SMTP id lt15mr414221pab.77.1407362345266; Wed, 06 Aug 2014 14:59:05 -0700 (PDT)
Received: from [192.168.178.23] (44.197.69.111.dynamic.snap.net.nz. [111.69.197.44]) by mx.google.com with ESMTPSA id y1sm2259049pbw.87.2014.08.06.14.59.03 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 14:59:04 -0700 (PDT)
Message-ID: <53E2A52C.3050808@gmail.com>
Date: Thu, 07 Aug 2014 09:59:08 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: RJ Atkinson <rja.lists@gmail.com>
Subject: Re: Detailed review of "Analysis of the 64-bit Boundary in IPv6 Addressing"
References: <34C23327-E5EF-40C6-AD88-85810BC0014E@gmail.com>
In-Reply-To: <34C23327-E5EF-40C6-AD88-85810BC0014E@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/53r-l3ETIhR3b0skAEqYPusptAs
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 21:59:07 -0000

On 07/08/2014 00:52, RJ Atkinson wrote:
> On August 5th 2014, David Farmer wrote, in part:
>> Yes, we should do the math for them. ...the important concept
>> to communicate is the vast majority of IPv6 addresses space is reserved.
> 
> I agree that it is very helpful to explicitly provide an
> (approximate) fraction to indicate that the vast majority 
> of IPv6 address space is reserved.
> 
> Purely by way of example, I am comfortable with text of the form 
> "close to X/Y of the address space is reserved at present" 
> or "approximately X/Y of the address space is reserved at present".
> 
> ALSO, I think we need to make clear that of the non-reserved
> global unicast address space, the vast majority of that also
> is not yet allocated.

Agreed, but that is a moving target so this has to be phrased
with care.

> 
> In short, the document ought to be crystal clear that we are in
> no serious danger of running out of IPv6 address space.  While
> thoughtful management is always sensible, we really do have enough 
> IPv6 address space that users really ought to be delegated enough
> global unicast addresses for internal subnetting - by delegating 
> IPv6 routing prefixes shorter than /64 (e.g. while retaining support 
> for SLAAC).

I agree, but I'd personally like the text to be as objective as possible,
since the actual allocation policy is in the hands of IANA and the RIRs.
We do already refer to RFC6177, which discusses this topic.

   Brian

> 
> Yours,
> 
> Ran Atkinson
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 


From nobody Wed Aug  6 15:09:17 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D030A1B28DA for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 15:09:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 lqzxhAnlv1lR for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 15:09:13 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34DC71B28D8 for <ipv6@ietf.org>; Wed,  6 Aug 2014 15:09:13 -0700 (PDT)
Received: by mail-pa0-f46.google.com with SMTP id lj1so4113508pab.19 for <ipv6@ietf.org>; Wed, 06 Aug 2014 15:09:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=nGm2tXwgD14TABVuRT1aOt6ZW2WShcmTVLPsB6gvefk=; b=kW2AB+w1A08WYFUeilGPPDBLYSExb1btU4XtIrN2QR58jYG9sbFAbNWIh4fRLpP2Xp nndza7gHUETMk4ROPE8lAKNobqreJz6FLmWDP3tujLPZ60ze9+sLCFxl0gYvCULUeuRQ t6Q4tIGHa5GJbbqxxMoASuXDwATH8Uy9zVrT7yePcW/k05WXOW3uPYQ73/LBFsHHU07q Lzpd9f8A6inJZXs2SyxscwqQ62XAqn9SFvIrutN0oYPTp9dGKsnMIlzE4Iuu4DHpgmNX K8m23azJBDpYjLohTS3Zz2Oa5Vox/8rJ/oxV+aw1G/9klLbjeUafJnbdwf41ZFRwpS1Q 20/g==
X-Received: by 10.70.38.4 with SMTP id c4mr13929713pdk.108.1407362952683; Wed, 06 Aug 2014 15:09:12 -0700 (PDT)
Received: from [192.168.178.23] (44.197.69.111.dynamic.snap.net.nz. [111.69.197.44]) by mx.google.com with ESMTPSA id fq4sm3330854pdb.71.2014.08.06.15.09.11 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 15:09:12 -0700 (PDT)
Message-ID: <53E2A78D.9060705@gmail.com>
Date: Thu, 07 Aug 2014 10:09:17 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
References: <776E0CDC-3D76-4066-9AC6-2BA151C0312E@gmail.com> <53E27607.6070105@gmail.com>
In-Reply-To: <53E27607.6070105@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/A5-Rt9B1vLufvt1uD5JWatagyxQ
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Aug 2014 22:09:15 -0000

On 07/08/2014 06:37, Alexandru Petrescu wrote:
> Le 06/08/2014 20:27, RJ Atkinson a =C3=A9crit :
>>
>> On 06  Aug 2014, at 13:54 , David Farmer wrote:
>>> Or, are you suggesting that the simplicity of SLACC with
>>> a single IID length is important for minimising technical
>>> infrastructure and network management effort, especially in
>>> small enterprises?
>>
>> Yes, to the *edited* text above.
>>
>> (Of course the same comment also applies to a number of other
>> deployment scenarios, for example residential networks,
>> but my note was focused on "small enterprises".)

We already have some language about the benefits of simplicity,
which I personally see as important for any size of network,
not excepting campus networks. (I have discussed this exact point
with colleagues managing address space for a large campus). Ran
is undoubtedly correct that the benefit is even greater for small
networks which probably have part-time, non-expert managers, or
fly-by support technicians who look after dozens of such customers.
Short of 100% autonomic configuration, simplicity and homgeneity
is highly desirable.

>=20
> Whereas I consider the small enterprise perspective very enriching, I
> disagree with the conclusion on SLAAC.
>=20
> Other than big and small enterprises, there are many single users who
> need to grow their networks beyond what their suppliers consider to be
> edge.
>=20
> The 64 length of Ethernet-and-kin IIDs imposed on SLAAC are a break to
> that growth.

I could only agree to that if everything is zero-conf. Such users
can't handle complex choices. Anyway, that is out of scope for this
draft, isn't it?

   Brian (anxious to start editing the next version...)


From nobody Wed Aug  6 19:29:03 2014
Return-Path: <slblake@petri-meat.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA091A0538 for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 19:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham
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 22WjZGzN2KLp for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 19:28:58 -0700 (PDT)
Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915571A0640 for <ipv6@ietf.org>; Wed,  6 Aug 2014 19:28:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=petri-meat.com; s=default;  h=Content-Transfer-Encoding:Mime-Version:Content-Type:References:In-Reply-To:Date:Cc:To:From:Subject:Message-ID; bh=xIA5JFNH7Rn3Tdow3pAIPq6Zwnh/jhEfwdIXmcuOtCk=;  b=Sxa9wMnkq08hskIgrFA6fDOGvOlweGxytPk5Wn0V6/uAzQdGhr7CA6kMDgTjaek2KpibC26wFsgH9ICMjA7aY+AFSOnKHBLiCsL+3ZhJ4meIe4JL3O5EpuChwy8Jxm8V;
Received: from cpe-098-027-048-172.nc.res.rr.com ([98.27.48.172]:41419 helo=[192.168.144.57]) by elom.tchmachines.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from <slblake@petri-meat.com>) id 1XFDRo-00063O-2j; Wed, 06 Aug 2014 22:28:56 -0400
Message-ID: <1407378535.24444.3.camel@tachyon.blake>
Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
From: Steven Blake <slblake@petri-meat.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Date: Wed, 06 Aug 2014 22:28:55 -0400
In-Reply-To: <53E27607.6070105@gmail.com>
References: <776E0CDC-3D76-4066-9AC6-2BA151C0312E@gmail.com> <53E27607.6070105@gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - elom.tchmachines.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - petri-meat.com
X-Get-Message-Sender-Via: elom.tchmachines.com: authenticated_id: slblake+petri-meat.com/only user confirmed/virtual account not confirmed
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/9dj-orseUw3Bsz4xFZe9hyod99o
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Aug 2014 02:29:01 -0000

On Wed, 2014-08-06 at 20:37 +0200, Alexandru Petrescu wrote:
> Le 06/08/2014 20:27, RJ Atkinson a écrit :
> >
> > On 06  Aug 2014, at 13:54 , David Farmer wrote:
> >> Or, are you suggesting that the simplicity of SLACC with
> >> a single IID length is important for minimising technical
> >> infrastructure and network management effort, especially in
> >> small enterprises?
> >
> > Yes, to the *edited* text above.
> >
> > (Of course the same comment also applies to a number of other
> > deployment scenarios, for example residential networks,
> > but my note was focused on "small enterprises".)
> 
> Whereas I consider the small enterprise perspective very enriching, I 
> disagree with the conclusion on SLAAC.
> 
> Other than big and small enterprises, there are many single users who 
> need to grow their networks beyond what their suppliers consider to be edge.
> 
> The 64 length of Ethernet-and-kin IIDs imposed on SLAAC are a break to 
> that growth.

How so?  Are you saying that there are single users that aren't able to
get sufficient space (say /56 or shorter) from their providers?


Regards,

// Steve


From nobody Wed Aug  6 19:46:57 2014
Return-Path: <jmh@joelhalpern.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263CC1A03CC for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 19:46:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 BSYF2rq3CAFc for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 19:46:53 -0700 (PDT)
Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD391A03AA for <ipv6@ietf.org>; Wed,  6 Aug 2014 19:46:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 9F7E3341E05; Wed,  6 Aug 2014 19:46:51 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net
Received: from Joels-MacBook-Pro.local (pool-70-106-134-155.clppva.east.verizon.net [70.106.134.155]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id DE748341E04; Wed,  6 Aug 2014 19:46:50 -0700 (PDT)
Message-ID: <53E2E89D.2080300@joelhalpern.com>
Date: Wed, 06 Aug 2014 22:46:53 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Steven Blake <slblake@petri-meat.com>,  Alexandru Petrescu <alexandru.petrescu@gmail.com>
Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
References: <776E0CDC-3D76-4066-9AC6-2BA151C0312E@gmail.com> <53E27607.6070105@gmail.com> <1407378535.24444.3.camel@tachyon.blake>
In-Reply-To: <1407378535.24444.3.camel@tachyon.blake>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Si2EBRekRKLKPRRwDWBXZ4w3yfI
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Aug 2014 02:46:55 -0000

It strikes me that if we start permitting subnet lengths longer than 64, 
than any operator who is so stingy that they are currently giving out 
/64s will likely switch to giving out whatever other length we tell them 
is the longest permissible.

Hence, I really don't think the answer to oeprator misunderstqnding is 
changing the prefix rules.

Yours,
Joel

On 8/6/14, 10:28 PM, Steven Blake wrote:
> On Wed, 2014-08-06 at 20:37 +0200, Alexandru Petrescu wrote:
>> Le 06/08/2014 20:27, RJ Atkinson a écrit :
>>>
>>> On 06  Aug 2014, at 13:54 , David Farmer wrote:
>>>> Or, are you suggesting that the simplicity of SLACC with
>>>> a single IID length is important for minimising technical
>>>> infrastructure and network management effort, especially in
>>>> small enterprises?
>>>
>>> Yes, to the *edited* text above.
>>>
>>> (Of course the same comment also applies to a number of other
>>> deployment scenarios, for example residential networks,
>>> but my note was focused on "small enterprises".)
>>
>> Whereas I consider the small enterprise perspective very enriching, I
>> disagree with the conclusion on SLAAC.
>>
>> Other than big and small enterprises, there are many single users who
>> need to grow their networks beyond what their suppliers consider to be edge.
>>
>> The 64 length of Ethernet-and-kin IIDs imposed on SLAAC are a break to
>> that growth.
>
> How so?  Are you saying that there are single users that aren't able to
> get sufficient space (say /56 or shorter) from their providers?
>
>
> Regards,
>
> // Steve
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


From nobody Wed Aug  6 22:43:42 2014
Return-Path: <markzzzsmith@yahoo.com.au>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EE31A0AE0 for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 22:43:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 7npEdSO8GTQN for <ipv6@ietfa.amsl.com>; Wed,  6 Aug 2014 22:43:38 -0700 (PDT)
Received: from nm9-vm0.bullet.mail.bf1.yahoo.com (nm9-vm0.bullet.mail.bf1.yahoo.com [98.139.213.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948011A0AD1 for <ipv6@ietf.org>; Wed,  6 Aug 2014 22:43:38 -0700 (PDT)
Received: from [98.139.215.140] by nm9.bullet.mail.bf1.yahoo.com with NNFMP; 07 Aug 2014 05:43:37 -0000
Received: from [98.139.212.244] by tm11.bullet.mail.bf1.yahoo.com with NNFMP;  07 Aug 2014 05:43:37 -0000
Received: from [127.0.0.1] by omp1053.mail.bf1.yahoo.com with NNFMP; 07 Aug 2014 05:43:37 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 820121.97919.bm@omp1053.mail.bf1.yahoo.com
Received: (qmail 37724 invoked by uid 60001); 7 Aug 2014 05:43:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024;  t=1407390217; bh=9oTGgCvJlt5x7MZ1p1nFRT2z+T3ZI0Jk6SRziNtQEYY=;  h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lP8wxI0OwKAuAQQoy4KbEwL9pbtfTS7En/z1jM7v6XDT+EZDzgvB/GWSfeh2XLsUMMTjp6X+AwCNIPA8tjg9f61UH7gRnaVVMgKtXdKxlSWPxoECdBRYLni/spho3QAPnpb0RFgYSQHdsdi1Y9vX66ooOIEQ2rgIlYAgYVJUuJE=
X-YMail-OSG: RHXPyTgVM1m1ZDeD_RkP2u8alTS4U2crRRKRwpMz3LqWHmV ttWNb1e8FdzN1BLJ09qRbnrcVJ3mWmFuL0So1gjLChsVJdwDzNZ_RfqY1fkJ GxfmoG7ZQgh9fbzzGvA_hmEpyZyu1s85QdyNZy.4vMtWpAduz89QITyKgzIE psykLeDwEcoLeZFfzc_8fChuGI2xs8sViRvlfDRYEoCY924HbjvVyrG3Ymbo CBz9mT1XDamykhPzRsV84YMd7h0PBv5qyXtVlNuczG5jO8YAblQheq_rdPqU IpgG0Cw4Yvt7DRiYAMK_hmhm66cAbwDbslthsjzWvgk5ThHNxq6rtvwSWzGH e9VI0ii82ZisqLbZxsOJZCUQdVQLXuhjN1g2Iz3uH_P_v7r1cLOnAtcM9wDy _4zSs4oqznwz3VgKgBAx1Q9GVfvsG6HFI8VLg2dvtLfUsKA7EzswmmYwskey LXvu.k.pp8Hryg4nVr7Gg0St.9il9C8FDhqrhl0SqcV_ZIMhzgKUEBI8lDO4 LWom9dXOX1TQpiBFSSwp.DnhSN285MnFVJXG9pQwDGQvBLkNoAPJExdMuElz i
Received: from [150.101.221.237] by web162206.mail.bf1.yahoo.com via HTTP; Wed, 06 Aug 2014 22:43:37 PDT
X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20.Cj4gVG86IFN0ZXZlbiBCbGFrZSA8c2xibGFrZUBwZXRyaS1tZWF0LmNvbT47IEFsZXhhbmRydSBQZXRyZXNjdSA8YWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbT4KPiBDYzogaXB2NkBpZXRmLm9yZwo.IFNlbnQ6IFRodXJzZGF5LCA3IEF1Z3VzdCAyMDE0IDEyOjQ2IFBNCj4gU3ViamVjdDogUmU6IEltcG9ydGFuY2Ugb2YgU0xBQUMgKFJlOiBBbmFseXNpcyBvZiA2NC0BMAEBAQE-
X-Mailer: YahooMailWebService/0.8.198.689
References: <776E0CDC-3D76-4066-9AC6-2BA151C0312E@gmail.com> <53E27607.6070105@gmail.com> <1407378535.24444.3.camel@tachyon.blake> <53E2E89D.2080300@joelhalpern.com>
Message-ID: <1407390217.16488.YahooMailNeo@web162206.mail.bf1.yahoo.com>
Date: Wed, 6 Aug 2014 22:43:37 -0700
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Steven Blake <slblake@petri-meat.com>, Alexandru Petrescu <alexandru.petrescu@gmail.com>
In-Reply-To: <53E2E89D.2080300@joelhalpern.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/ZQH0LqGJqyH1Z897uqFaXH6NIfw
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Aug 2014 05:43:40 -0000

=0A=0A=0A=0A----- Original Message -----=0A> From: Joel M. Halpern <jmh@joe=
lhalpern.com>=0A> To: Steven Blake <slblake@petri-meat.com>; Alexandru Petr=
escu <alexandru.petrescu@gmail.com>=0A> Cc: ipv6@ietf.org=0A> Sent: Thursda=
y, 7 August 2014 12:46 PM=0A> Subject: Re: Importance of SLAAC (Re: Analysi=
s of 64-bit Boundary in IPv6 Addressing)=0A> =0A> It strikes me that if we =
start permitting subnet lengths longer than 64, =0A> than any operator who =
is so stingy that they are currently giving out =0A> /64s will likely switc=
h to giving out whatever other length we tell them =0A> is the longest perm=
issible.=0A> =0A> Hence, I really don't think the answer to oeprator misund=
erstqnding is =0A> changing the prefix rules.=0A>=A0=0A=0AAgree, it is a sl=
ippery slope.=0A=0AOperators who're thinking this way might be just trying =
to continue the practice where different levels of service were dependent o=
n address attributes e.g., residential customers get dynamic addresses, bus=
iness customers get static addresses/routed prefixes at a much higher cost.=
=0A=0AI think operators who try to continue this sort of practice, by creat=
ing artificial IPv6 address scarcity, will find their competitors quickly s=
tealing business from them because of it. They should think about find some=
thing else about their service to win customer business with.=0A=0ARegards,=
=0AMark.=0A=0A> Yours,=0A> Joel=0A> =0A> On 8/6/14, 10:28 PM, Steven Blake =
wrote:=0A>>  On Wed, 2014-08-06 at 20:37 +0200, Alexandru Petrescu wrote:=
=0A>>>  Le 06/08/2014 20:27, RJ Atkinson a =E9crit :=0A>>>> =0A>>>>  On 06=
=A0 Aug 2014, at 13:54 , David Farmer wrote:=0A>>>>>  Or, are you suggestin=
g that the simplicity of SLACC with=0A>>>>>  a single IID length is importa=
nt for minimising technical=0A>>>>>  infrastructure and network management =
effort, especially in=0A>>>>>  small enterprises?=0A>>>> =0A>>>>  Yes, to t=
he *edited* text above.=0A>>>> =0A>>>>  (Of course the same comment also ap=
plies to a number of other=0A>>>>  deployment scenarios, for example reside=
ntial networks,=0A>>>>  but my note was focused on "small enterprises".)=0A=
>>> =0A>>>  Whereas I consider the small enterprise perspective very enrich=
ing, I=0A>>>  disagree with the conclusion on SLAAC.=0A>>> =0A>>>  Other th=
an big and small enterprises, there are many single users who=0A>>>  need t=
o grow their networks beyond what their suppliers consider to be =0A> edge.=
=0A>>> =0A>>>  The 64 length of Ethernet-and-kin IIDs imposed on SLAAC are =
a break to=0A>>>  that growth.=0A>> =0A>>  How so?=A0 Are you saying that t=
here are single users that aren't able to=0A>>  get sufficient space (say /=
56 or shorter) from their providers?=0A>> =0A>> =0A>>  Regards,=0A>> =0A>> =
 // Steve=0A>> =0A>>  -----------------------------------------------------=
---------------=0A>>  IETF IPv6 working group mailing list=0A>>  ipv6@ietf.=
org=0A>>  Administrative Requests: https://www.ietf.org/mailman/listinfo/ip=
v6=0A> =0A>>  -------------------------------------------------------------=
-------=0A>> =0A> =0A> ----------------------------------------------------=
----------------=0A> IETF IPv6 working group mailing list=0A> ipv6@ietf.org=
=0A> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A=
> --------------------------------------------------------------------=0A> 


From nobody Thu Aug  7 00:50:28 2014
Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155121B2900 for <ipv6@ietfa.amsl.com>; Thu,  7 Aug 2014 00:50:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
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 rNfiX6ZDZ_MJ for <ipv6@ietfa.amsl.com>; Thu,  7 Aug 2014 00:50:25 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C55D01B28F7 for <ipv6@ietf.org>; Thu,  7 Aug 2014 00:50:24 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s777oJ4e001756; Thu, 7 Aug 2014 09:50:19 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 77025202C5C; Thu,  7 Aug 2014 09:53:19 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6B7DA200C00; Thu,  7 Aug 2014 09:53:19 +0200 (CEST)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s777o8M9022848; Thu, 7 Aug 2014 09:50:19 +0200
Message-ID: <53E32FAE.7030908@gmail.com>
Date: Thu, 07 Aug 2014 09:50:06 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
References: <776E0CDC-3D76-4066-9AC6-2BA151C0312E@gmail.com> <53E27607.6070105@gmail.com> <53E2A78D.9060705@gmail.com>
In-Reply-To: <53E2A78D.9060705@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/xReUZsRPmfMy8B3HmmOIyUsUKf0
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Aug 2014 07:50:27 -0000

Le 07/08/2014 00:09, Brian E Carpenter a écrit :
> On 07/08/2014 06:37, Alexandru Petrescu wrote:
>> Le 06/08/2014 20:27, RJ Atkinson a écrit :
>>>
>>> On 06  Aug 2014, at 13:54 , David Farmer wrote:
>>>> Or, are you suggesting that the simplicity of SLACC with a
>>>> single IID length is important for minimising technical
>>>> infrastructure and network management effort, especially in
>>>> small enterprises?
>>>
>>> Yes, to the *edited* text above.
>>>
>>> (Of course the same comment also applies to a number of other
>>> deployment scenarios, for example residential networks, but my
>>> note was focused on "small enterprises".)
>
> We already have some language about the benefits of simplicity, which
> I personally see as important for any size of network, not excepting
> campus networks. (I have discussed this exact point with colleagues
> managing address space for a large campus). Ran is undoubtedly
> correct that the benefit is even greater for small networks which
> probably have part-time, non-expert managers, or fly-by support
> technicians who look after dozens of such customers. Short of 100%
> autonomic configuration, simplicity and homgeneity is highly
> desirable.
>
>>
>> Whereas I consider the small enterprise perspective very enriching,
>> I disagree with the conclusion on SLAAC.
>>
>> Other than big and small enterprises, there are many single users
>> who need to grow their networks beyond what their suppliers
>> consider to be edge.
>>
>> The 64 length of Ethernet-and-kin IIDs imposed on SLAAC are a break
>> to that growth.
>
> I could only agree to that if everything is zero-conf. Such users
> can't handle complex choices. Anyway, that is out of scope for this
> draft, isn't it?

Right, this risks turning into an argumentation of why SLAAC is
important, presumably vs. DHCP.  This argumentation is out of scope of
this draft discussing 64bit lengths.

Alex


Alex

>
> Brian (anxious to start editing the next version...)
>
>



From nobody Thu Aug  7 00:56:19 2014
Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7A71B2952 for <ipv6@ietfa.amsl.com>; Thu,  7 Aug 2014 00:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
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 2PZRsG73QXZh for <ipv6@ietfa.amsl.com>; Thu,  7 Aug 2014 00:56:16 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C081B28FA for <ipv6@ietf.org>; Thu,  7 Aug 2014 00:56:16 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s777uEOs003690; Thu, 7 Aug 2014 09:56:14 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3F682202C5C; Thu,  7 Aug 2014 09:59:14 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 33AB0202C56; Thu,  7 Aug 2014 09:59:14 +0200 (CEST)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s777uDAi025923; Thu, 7 Aug 2014 09:56:14 +0200
Message-ID: <53E3311D.4070902@gmail.com>
Date: Thu, 07 Aug 2014 09:56:13 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Steven Blake <slblake@nc.rr.com>
Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
References: <776E0CDC-3D76-4066-9AC6-2BA151C0312E@gmail.com>	 <53E27607.6070105@gmail.com> <1407378288.24444.2.camel@tachyon.blake>
In-Reply-To: <1407378288.24444.2.camel@tachyon.blake>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/0Xl_FMansoVv9Lfb-DV2nhNsodM
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Aug 2014 07:56:18 -0000

Le 07/08/2014 04:24, Steven Blake a écrit :
> On Wed, 2014-08-06 at 20:37 +0200, Alexandru Petrescu wrote:
>> Le 06/08/2014 20:27, RJ Atkinson a écrit :
>>>
>>> On 06  Aug 2014, at 13:54 , David Farmer wrote:
>>>> Or, are you suggesting that the simplicity of SLACC with a
>>>> single IID length is important for minimising technical
>>>> infrastructure and network management effort, especially in
>>>> small enterprises?
>>>
>>> Yes, to the *edited* text above.
>>>
>>> (Of course the same comment also applies to a number of other
>>> deployment scenarios, for example residential networks, but my
>>> note was focused on "small enterprises".)
>>
>> Whereas I consider the small enterprise perspective very enriching,
>> I disagree with the conclusion on SLAAC.
>>
>> Other than big and small enterprises, there are many single users
>> who need to grow their networks beyond what their suppliers
>> consider to be edge.
>>
>> The 64 length of Ethernet-and-kin IIDs imposed on SLAAC are a break
>> to that growth.
>
> How so?  Are you saying that there are single users that aren't able
> to get sufficient space (say /56 or shorter) from their providers?

Certainly yes, there are single users that aren't able to get sufficient
space, like a /56.  These users are not facing real 'providers'.

The easiness of putting SLAAC on, with Ethernet, is what end users get
in a wifi hotspot area, for example.  At that place the 'provider' is
actually a sysadmin, or more the other-craft-man turned sysadmin for a
few dozens minutes just to action the just unwrapped Access Point.

However, the end users of that hotspot have more than one device to
connect - a Personal Area Network, made of WiFi and Bluetooth devices.
(tablet plus watch, for example, or other IoT Internet of Things).  Or a
vehicle.

Alex

>
>
> Regards,
>
> // Steve
>
>



From nobody Thu Aug  7 01:49:43 2014
Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8121B2928 for <ipv6@ietfa.amsl.com>; Thu,  7 Aug 2014 01:49:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
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 PSZLaTfxbefc for <ipv6@ietfa.amsl.com>; Thu,  7 Aug 2014 01:49:41 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E781A0393 for <ipv6@ietf.org>; Thu,  7 Aug 2014 01:49:40 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s778ncmu023120; Thu, 7 Aug 2014 10:49:38 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5A9E1201576; Thu,  7 Aug 2014 10:52:38 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 4D136200C37; Thu,  7 Aug 2014 10:52:38 +0200 (CEST)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s778nIhT031284; Thu, 7 Aug 2014 10:49:38 +0200
Message-ID: <53E33D8E.6030604@gmail.com>
Date: Thu, 07 Aug 2014 10:49:18 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Steven Blake <slblake@petri-meat.com>
Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
References: <776E0CDC-3D76-4066-9AC6-2BA151C0312E@gmail.com> <53E27607.6070105@gmail.com> <1407378535.24444.3.camel@tachyon.blake> <53E2E89D.2080300@joelhalpern.com>
In-Reply-To: <53E2E89D.2080300@joelhalpern.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/KcJzNKW1Qd66wykP7OBVpksf0Hw
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Aug 2014 08:49:43 -0000

Le 07/08/2014 04:46, Joel M. Halpern a écrit :
> It strikes me that if we start permitting subnet lengths longer than 64,
> than any operator who is so stingy that they are currently giving out
> /64s will likely switch to giving out whatever other length we tell them
> is the longest permissible.
>
> Hence, I really don't think the answer to oeprator misunderstqnding is
> changing the prefix rules.

In a sense I agree.  If one changes the 64 barrier to, say 65, then the 
barrier will just move, but not disappear.

Operator misunderstanding - yes, that can be blamed, but only as long as 
there is a real operator acting as one would expect an operator to act. 
  When the operator is more like a non-professional operator (but 
respected professional in that other art), then it is hard to put the 
blame on a human, and easier to put on the architecture.

I think there should exist ways to deal with it such as to not appear as 
a barrier, and to not be moving either.

No, not variable-length addresses.

But maybe stating that (1) the prefix length must not be 128 and (2) if 
the prefix length is 127 then the provider must offer a freely available 
alternative to NAT.

Alex

>
> Yours,
> Joel
>
> On 8/6/14, 10:28 PM, Steven Blake wrote:
>> On Wed, 2014-08-06 at 20:37 +0200, Alexandru Petrescu wrote:
>>> Le 06/08/2014 20:27, RJ Atkinson a écrit :
>>>>
>>>> On 06  Aug 2014, at 13:54 , David Farmer wrote:
>>>>> Or, are you suggesting that the simplicity of SLACC with
>>>>> a single IID length is important for minimising technical
>>>>> infrastructure and network management effort, especially in
>>>>> small enterprises?
>>>>
>>>> Yes, to the *edited* text above.
>>>>
>>>> (Of course the same comment also applies to a number of other
>>>> deployment scenarios, for example residential networks,
>>>> but my note was focused on "small enterprises".)
>>>
>>> Whereas I consider the small enterprise perspective very enriching, I
>>> disagree with the conclusion on SLAAC.
>>>
>>> Other than big and small enterprises, there are many single users who
>>> need to grow their networks beyond what their suppliers consider to
>>> be edge.
>>>
>>> The 64 length of Ethernet-and-kin IIDs imposed on SLAAC are a break to
>>> that growth.
>>
>> How so?  Are you saying that there are single users that aren't able to
>> get sufficient space (say /56 or shorter) from their providers?
>>
>>
>> Regards,
>>
>> // Steve
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>



From nobody Thu Aug  7 04:34:32 2014
Return-Path: <lorenzo@google.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8ED81B292E for <ipv6@ietfa.amsl.com>; Thu,  7 Aug 2014 04:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 cB7pFYbDs-ir for <ipv6@ietfa.amsl.com>; Thu,  7 Aug 2014 04:34:17 -0700 (PDT)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0CF1B2A7A for <ipv6@ietf.org>; Thu,  7 Aug 2014 04:34:02 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id rl12so4509207iec.1 for <ipv6@ietf.org>; Thu, 07 Aug 2014 04:34:01 -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:content-type; bh=KZgrHYay1YDyWfMoFMDzC+sdZcCxJ2FTolbeCPaKAl0=; b=YNoedSQ8pQzbveyd344G5XH5qpTfx2w4x8owuqwVv7GiIF2BpmFwniOzHfUVbaSvIe 15KVt0qvL07NSML76lOJEGM0vSW/NdIzx4QOlWoONoxY5JKDkK7EVy4FFeTGvaMSuwbj cQZe6WDavzt8jMqfYZxicYVRcyyW+6NK0mTKX8d24otBEeE/WFj1/p6unp5KAtRqR15h idouZER8ZLN/vUtZchwBWc2SHTeMNVEKFpdTuaAZtYNFRKa16buvwOEMcOhZw8cnp1kP pQTEMzjWe8++h0v6YMPx/E7J9hDoqMoLEciBP3QDXAyckLT0YJGwGEILb6dZu/acM/yb NuYg==
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:content-type; bh=KZgrHYay1YDyWfMoFMDzC+sdZcCxJ2FTolbeCPaKAl0=; b=f1tB1HJ29o5G9KnrGh1meQQ9Mkho6dTAELLAAoE7LOKyegi5C3x72LPw7Ns6S/bybd qpCSlKwTngMF8I08aHCXOdtt4x+o+EjBG91TbTzPQZ00ZjIgZcBrB9f8JrXcOHzDsXvZ ofRRUMM/oMZ7NyY2znIcKauBj1I1SEpCW5E5A0mZdUsMfbFCIifXh1Y+EYz+ByM5UGSB lwEr9cnHv+p2yPK+RBmV2wr4rKqFdGJq6KKHZwG9uMuKhBQT4w5JsGhJAVWrf6N6Lc0u Edrhw7rrmFzaeAVsRXrrS0gn89E5ZYOjh+PVRXs4B+IGr95CRzH2Sp2AKCNiBoHOEryH wIow==
X-Gm-Message-State: ALoCoQkWxRTvLSa/xEN3JJrfK2rg9mPYZXxZ3dxNxJaDHyN9B4ieMQA7qhdJh1rGH14yzvoSMqKu
X-Received: by 10.50.143.73 with SMTP id sc9mr57092656igb.29.1407411241803; Thu, 07 Aug 2014 04:34:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.5.6 with HTTP; Thu, 7 Aug 2014 04:33:41 -0700 (PDT)
In-Reply-To: <53E2E89D.2080300@joelhalpern.com>
References: <776E0CDC-3D76-4066-9AC6-2BA151C0312E@gmail.com> <53E27607.6070105@gmail.com> <1407378535.24444.3.camel@tachyon.blake> <53E2E89D.2080300@joelhalpern.com>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 7 Aug 2014 20:33:41 +0900
Message-ID: <CAKD1Yr3zF3s=iFuRr3pN+k-hw0d04iL23DHU7WqEUZmGBe-itg@mail.gmail.com>
Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Content-Type: multipart/alternative; boundary=001a1134cb0e1f324205000877f1
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/LtAFxnUxtMA0d2vQ3Y1vXQDzljY
Cc: Alexandru Petrescu <alexandru.petrescu@gmail.com>, IETF IPv6 Mailing List <ipv6@ietf.org>, Steven Blake <slblake@petri-meat.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Aug 2014 11:34:19 -0000

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

On Thu, Aug 7, 2014 at 11:46 AM, Joel M. Halpern <jmh@joelhalpern.com>
wrote:

> It strikes me that if we start permitting subnet lengths longer than 64,
> than any operator who is so stingy that they are currently giving out /64s
> will likely switch to giving out whatever other length we tell them is the
> longest permissible.
>

And after a short while, the race to the bottom ends at /128, and we're all
forced to implement NAT because customers don't want to pay twice to
connect two devices to the same network.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Aug 7, 2014 at 11:46 AM, Joel M. Halpern <span dir=3D"ltr">&lt;<a href=
=3D"mailto:jmh@joelhalpern.com" target=3D"_blank">jmh@joelhalpern.com</a>&g=
t;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">It strikes me that if we start permitting su=
bnet lengths longer than 64, than any operator who is so stingy that they a=
re currently giving out /64s will likely switch to giving out whatever othe=
r length we tell them is the longest permissible.<br>

</blockquote><div><br></div><div>And after a short while, the race to the b=
ottom ends at /128, and we&#39;re all forced to implement NAT because custo=
mers don&#39;t want to pay twice to connect two devices to the same network=
.=C2=A0</div>

</div></div></div>

--001a1134cb0e1f324205000877f1--


From nobody Thu Aug  7 06:44:12 2014
Return-Path: <farmer@umn.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D181B2B11 for <ipv6@ietfa.amsl.com>; Thu,  7 Aug 2014 06:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 W6p8QXYzajLk for <ipv6@ietfa.amsl.com>; Thu,  7 Aug 2014 06:44:08 -0700 (PDT)
Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id D79AD1B2AF8 for <ipv6@ietf.org>; Thu,  7 Aug 2014 06:44:07 -0700 (PDT)
Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for <ipv6@ietf.org>; Thu, 7 Aug 2014 08:44:06 -0500 (CDT)
X-Umn-Remote-Mta: [N] mail-ie0-f179.google.com [209.85.223.179] #+LO+TS+TR
X-Umn-Classification: local
Received: by mail-ie0-f179.google.com with SMTP id rl12so4661340iec.10 for <ipv6@ietf.org>; Thu, 07 Aug 2014 06:44:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0JNLyTUiUkdjX3xqn12rZSwikm3O2ojreQvHND19my4=; b=Lo8VQcrsdzctlSrqyPYfEMsa0GgNhlakDGYE/vgXzd5ktpjBbkOqwJ1ZedrD3fcG5N pyUsuYn0WFVrVCKsmxsu7/Q+99UmFQV+KadHVDsZ3UsWfE0oLFew9VSlWB6IgzLx8JXQ nNT0BHZVvRuXzRuYBdag8zN1ucI+8mi35rm+Y=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=0JNLyTUiUkdjX3xqn12rZSwikm3O2ojreQvHND19my4=; b=VzffrajY0Nj2psR2mYTuex7lUsrSXW4kZJ3FfpBgqfQI16Xx/QarFAO2Wa9mPzUtva TLmCvqDVN2IXfxsAvq2T3mmrIlorq5PAM43MmZWyPVYd0cTqDb1Mb0UpxckwWvcnsjyR EE+3Q1mwbKaiwkdOivdzWb1W/uJZebGzAGHsKogWTyNunrnd1Z6n9LarDZjDqoMrgo3c 4bOaAwhrRH2OYiDkJkpPqNeZE/0HDMv+9iNjmePwJ/1Pr5VXQii544E32+GI41hFbv9Y EpS9cY5Ep9a5dI8OU0c2kP/4VtJZQojosv3FpppWQqJL/4+bBh0BjJHFsN2ez3PrFTTy 4u8Q==
X-Gm-Message-State: ALoCoQkvvTrhXviG8+tPcE30wXDF1lsI1WGwusOVMA/d5yM+6VTI5nSBxZMEQ/ffhbT0rTGsS4J6cs5C+e+IP0Nc+VA7RN/8bGzNsJbhKoCa4x7XsFV8QPs=
X-Received: by 10.42.201.134 with SMTP id fa6mr3850931icb.73.1407419045100; Thu, 07 Aug 2014 06:44:05 -0700 (PDT)
X-Received: by 10.42.201.134 with SMTP id fa6mr3850906icb.73.1407419044930; Thu, 07 Aug 2014 06:44:04 -0700 (PDT)
Received: from oit201651646.local ([2601:2:5b00:34f:8173:eb0c:b535:9bc9]) by mx.google.com with ESMTPSA id ot2sm20850604igb.20.2014.08.07.06.44.01 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Aug 2014 06:44:02 -0700 (PDT)
Message-ID: <53E3829A.9060002@umn.edu>
Date: Thu, 07 Aug 2014 08:43:54 -0500
From: David Farmer <farmer@umn.edu>
Organization: University of Minnesota
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Lorenzo Colitti <lorenzo@google.com>
Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
References: <776E0CDC-3D76-4066-9AC6-2BA151C0312E@gmail.com> <53E27607.6070105@gmail.com> <1407378535.24444.3.camel@tachyon.blake> <53E2E89D.2080300@joelhalpern.com> <CAKD1Yr3zF3s=iFuRr3pN+k-hw0d04iL23DHU7WqEUZmGBe-itg@mail.gmail.com>
In-Reply-To: <CAKD1Yr3zF3s=iFuRr3pN+k-hw0d04iL23DHU7WqEUZmGBe-itg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/lHBBXwEaSsKhVTK4EnoGXMsoCDQ
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: David Farmer <farmer@umn.edu>
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Aug 2014 13:44:10 -0000

On 8/7/14, 06:33 , Lorenzo Colitti wrote:
> On Thu, Aug 7, 2014 at 11:46 AM, Joel M. Halpern <jmh@joelhalpern.com
> <mailto:jmh@joelhalpern.com>> wrote:
>
>     It strikes me that if we start permitting subnet lengths longer than
>     64, than any operator who is so stingy that they are currently
>     giving out /64s will likely switch to giving out whatever other
>     length we tell them is the longest permissible.
>
> And after a short while, the race to the bottom ends at /128, and we're
> all forced to implement NAT because customers don't want to pay twice to
> connect two devices to the same network.

Do we have to drop the NAT-Bomb?  There is no consensus to change the 64 
bit IID at this time, but 64 is not a magic number.  Considering 
alternative IID sizes or even a variable length is NOT equivalent to 
condoning NAT.

Can we have a conversion without hyperbolic NAT-Bombs, please.

Thanks

-- 
================================================
David Farmer               Email: farmer@umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================


From nobody Thu Aug  7 06:48:32 2014
Return-Path: <lorenzo@google.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567AF1B2B2D for <ipv6@ietfa.amsl.com>; Thu,  7 Aug 2014 06:48:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 P0Zb8GP-yYMy for <ipv6@ietfa.amsl.com>; Thu,  7 Aug 2014 06:48:30 -0700 (PDT)
Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D36D1B2B28 for <ipv6@ietf.org>; Thu,  7 Aug 2014 06:48:30 -0700 (PDT)
Received: by mail-ie0-f179.google.com with SMTP id rl12so4668450iec.10 for <ipv6@ietf.org>; Thu, 07 Aug 2014 06:48:29 -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:content-type; bh=dwU/KB3TxxzueEldFpoJVNtkaPC8J9PeAreFD4C00Lg=; b=WAnjQISYHVYw4cyZrSednOOdJE0rm/sEHEc1Mtl+X+NYqaaKo+w9oapU0bn7e4T9ow T/5geTntMK2AsUTCgjQST0Fl/lULzqOVceGfZVdk3wMfHmNTIBmGpQRvgw1q7rRaWgfX NmQBJN95CoNReSMydCdg7Zbs6uA1ALjZZruVqq8fckutxHxohUVSvA5/ph9Xmqj+JoOd oX5KwuFAlY4qiU4v0z70DldgkbecWMaypnh9AnOOHiJO2HPZGQdh0qItevxybvpNAk8w lX3TdB4bNlj2sMsqv6vqI/NzXZMPbeX8b2mdOfcBZc3ahWbsJw/ogVoob07A9aPvYJer noww==
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:content-type; bh=dwU/KB3TxxzueEldFpoJVNtkaPC8J9PeAreFD4C00Lg=; b=cTGeuMbT5I1h5B0ktFBF/a9cK8etdyL3xM10moAiXnBdVoPWKx5wvupyyGIfdE41Gd EXL5xjUaIAn/yo9Oc7etdrNFo7UFs/QdfaeiQD4bOCBjv8YIBUEW+/Dtvhi8QKykQ6zw 1eCXVd0pbkjivG0HoPXtEBtW6SSbBQ79fc8DsM02N6qcsfaQ5LCDlyTbjafoI/lNiH4X FMWRtfDgFeGIPsjf51+PNGfpnScQNNKrVcpycTkWyjUJ5iDw1O19jDcc5ML0qLLAohvS 4IiLZZGs3MuR6rAcvt/uP1y/Ago7TpX0g2FUCZzeX7KikDJbEYRqHWJiq2Nw3MP17nWv 9YQg==
X-Gm-Message-State: ALoCoQmMC13f865IjJsZc5vxJDjn+7zKuagypUujh9n/GwvJ1u8kMCa3gNTgM0TBQGRRSTIKnzYC
X-Received: by 10.50.128.234 with SMTP id nr10mr68582235igb.3.1407419309452; Thu, 07 Aug 2014 06:48:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.5.6 with HTTP; Thu, 7 Aug 2014 06:48:08 -0700 (PDT)
In-Reply-To: <53E3829A.9060002@umn.edu>
References: <776E0CDC-3D76-4066-9AC6-2BA151C0312E@gmail.com> <53E27607.6070105@gmail.com> <1407378535.24444.3.camel@tachyon.blake> <53E2E89D.2080300@joelhalpern.com> <CAKD1Yr3zF3s=iFuRr3pN+k-hw0d04iL23DHU7WqEUZmGBe-itg@mail.gmail.com> <53E3829A.9060002@umn.edu>
From: Lorenzo Colitti <lorenzo@google.com>
Date: Thu, 7 Aug 2014 22:48:08 +0900
Message-ID: <CAKD1Yr2nY_hxD2US=MC3=926Yd_KyVrM3m+M41Ap4aVfm1rMTw@mail.gmail.com>
Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
To: David Farmer <farmer@umn.edu>
Content-Type: multipart/alternative; boundary=047d7b10d131fd9d8e05000a5747
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/2y9CbvvEuufBh3oj-7PXb9AQXdg
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Aug 2014 13:48:31 -0000

--047d7b10d131fd9d8e05000a5747
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 7, 2014 at 10:43 PM, David Farmer <farmer@umn.edu> wrote:
>
> And after a short while, the race to the bottom ends at /128, and we're
>> all forced to implement NAT because customers don't want to pay twice to
>> connect two devices to the same network.
>>
>
> Do we have to drop the NAT-Bomb?  There is no consensus to change the 64
> bit IID at this time, but 64 is not a magic number.  Considering
> alternative IID sizes or even a variable length is NOT equivalent to
> condoning NAT.
>

Of course it's not equivalent to condoning it. The road to hell is paved
with good intentions :-)

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Aug 7, 2014 at 10:43 PM, David Farmer <span dir=3D"ltr">&lt;<a href=3D"=
mailto:farmer@umn.edu" target=3D"_blank">farmer@umn.edu</a>&gt;</span> wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"h5">And after a short while, t=
he race to the bottom ends at /128, and we&#39;re<br>
all forced to implement NAT because customers don&#39;t want to pay twice t=
o<br>
connect two devices to the same network.<br>
</div></blockquote>
<br>
Do we have to drop the NAT-Bomb? =C2=A0There is no consensus to change the =
64 bit IID at this time, but 64 is not a magic number. =C2=A0Considering al=
ternative IID sizes or even a variable length is NOT equivalent to condonin=
g NAT.<br>

</blockquote><div><br></div><div>Of course it&#39;s not equivalent to condo=
ning it. The road to hell is paved with good intentions :-)</div></div></di=
v></div>

--047d7b10d131fd9d8e05000a5747--


From nobody Thu Aug  7 07:08:29 2014
Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36161B2B52 for <ipv6@ietfa.amsl.com>; Thu,  7 Aug 2014 07:08:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
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 ozbhtxjcuARH for <ipv6@ietfa.amsl.com>; Thu,  7 Aug 2014 07:08:17 -0700 (PDT)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 144E81ABB17 for <ipv6@ietf.org>; Thu,  7 Aug 2014 07:08:16 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s77E8FLD001438 for <ipv6@ietf.org>; Thu, 7 Aug 2014 16:08:15 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D4F91204469 for <ipv6@ietf.org>; Thu,  7 Aug 2014 16:11:15 +0200 (CEST)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C3C3C203A17 for <ipv6@ietf.org>; Thu,  7 Aug 2014 16:11:15 +0200 (CEST)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s77E8Equ027903 for <ipv6@ietf.org>; Thu, 7 Aug 2014 16:08:15 +0200
Message-ID: <53E3884E.8040503@gmail.com>
Date: Thu, 07 Aug 2014 16:08:14 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
References: <776E0CDC-3D76-4066-9AC6-2BA151C0312E@gmail.com> <53E27607.6070105@gmail.com> <1407378535.24444.3.camel@tachyon.blake> <53E2E89D.2080300@joelhalpern.com> <CAKD1Yr3zF3s=iFuRr3pN+k-hw0d04iL23DHU7WqEUZmGBe-itg@mail.gmail.com> <53E3829A.9060002@umn.edu> <CAKD1Yr2nY_hxD2US=MC3=926Yd_KyVrM3m+M41Ap4aVfm1rMTw@mail.gmail.com>
In-Reply-To: <CAKD1Yr2nY_hxD2US=MC3=926Yd_KyVrM3m+M41Ap4aVfm1rMTw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Bq-acQC-KfaS32XK55jNGLLqLyg
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Aug 2014 14:08:19 -0000

Le 07/08/2014 15:48, Lorenzo Colitti a écrit :
> On Thu, Aug 7, 2014 at 10:43 PM, David Farmer <farmer@umn.edu
> <mailto:farmer@umn.edu>> wrote:
>
> And after a short while, the race to the bottom ends at /128, and
> we're all forced to implement NAT because customers don't want to
> pay twice to connect two devices to the same network.
>
>
> Do we have to drop the NAT-Bomb?  There is no consensus to change the
> 64 bit IID at this time, but 64 is not a magic number. Considering
> alternative IID sizes or even a variable length is NOT equivalent to
> condoning NAT.
>
>
> Of course it's not equivalent to condoning it. The road to hell is
> paved with good intentions :-)

One good intention is Prefix Delegation.

But unfortunately Prefix Delegation distributing /64s to whomever asks
is not making for an intuitively simple - aggregated - addressing
architecture.

Alex

>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



From nobody Thu Aug  7 10:35:11 2014
Return-Path: <pal@cs.stanford.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D0C1A00BB; Thu,  7 Aug 2014 10:35:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 cEk2slCS8zdO; Thu,  7 Aug 2014 10:35:01 -0700 (PDT)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3769D1A00B9; Thu,  7 Aug 2014 10:35:01 -0700 (PDT)
Received: from [76.14.66.110] (port=52176 helo=[192.168.0.103]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XFRad-00064l-I7; Thu, 07 Aug 2014 10:35:00 -0700
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com>
Date: Thu, 7 Aug 2014 10:35:01 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <23EA0E40-A503-4F7E-A4A9-7A33D43A215D@cs.stanford.edu>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com>
To: Pascal Thubert (pthubert) <pthubert@cisco.com>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 37a9e86f2e4d2511d38563a73d487f50
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/F0LtXfRgtOliwzZQyPbArv31IrI
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Aug 2014 17:35:03 -0000

Seems reasonable to me, although a bit cumbersome. I'd suggest

  This document updates the IPv6
  Flow Label Specification [RFC6437], which stipulates that once the =
Flow
  Label is set, forwarding nodes do not update it unless there are =
compelling
  security reasons to do so. This document argues that saving energy in =
LLNs=20
  is another sufficiently compelling reason to modify the Flow Label.

Phil

On Aug 5, 2014, at 1:11 AM, Pascal Thubert (pthubert) =
<pthubert@cisco.com> wrote:

> I think I see what you are saying, Phil.
>=20
> I can split 1.3 to isolate the deviations to 6437.
>=20
> I also need to move the following text from section 3 in that new =
section=20
>=20
>  This may seem contradictory with the IPv6
>   Flow Label Specification [RFC6437] which stipulates that once it is
>   set, the Flow Label is left unchanged; but the RFC also indicates a
>   violation to the rule can be accepted for compelling reasons, and
>   that security is a case justifying such a violation.  This
>   specification suggests that energy-saving is another compelling
>   reason for a violation to the aforementioned rule.
>=20
> Proposed update for that text:
>=20
>   This specification updates the IPv6
>   Flow Label Specification [RFC6437], which stipulates that once it is
>   set, the Flow Label is left unchanged. [RFC6437] also indicates that=20=

>   a violation to the rule can be accepted for compelling reasons,=20
>   but limit those compelling reasons to security related issues.  This
>   specification indicates that energy-saving is another compelling
>   reason that justifies a violation to the aforementioned rule.
>=20
> What do you think?
>=20
> Cheers,
>=20
> Pascal
>=20
>=20
>> -----Original Message-----
>> From: Philip Levis [mailto:pal@cs.stanford.edu]
>> Sent: lundi 4 ao=FBt 2014 20:23
>> To: Ralph Droms
>> Cc: Pascal Thubert (pthubert); Michael Richardson; Routing Over Low =
power
>> and Lossy networks; ipv6@ietf.org
>> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
>>=20
>>=20
>> On Aug 4, 2014, at 11:10 AM, Ralph Droms <rdroms.ietf@gmail.com> =
wrote:
>>=20
>>>=20
>>> On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert)
>> <pthubert@cisco.com> wrote:
>>>=20
>>>> The change is now done, Ralph.
>>>>=20
>>>> The only difference between =
draft-thubert-6man-flow-label-for-rpl-03 and
>> draft-thubert-6man-flow-label-for-rpl-04 is
>>>>=20
>>>> Updates: 6437 (if approved)
>>>=20
>>> I suggest adding a section to your doc that explains exactly what is =
being
>> updated in RFC 6437.
>>>=20
>>> - Ralph
>>=20
>>=20
>> I agree. I think some of the text in 1.3 can be re-used for this =
purpose.
>>=20
>> Phil


From nobody Thu Aug  7 10:45:00 2014
Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA871A0010 for <ipv6@ietfa.amsl.com>; Thu,  7 Aug 2014 10:44:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
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 5EcngtMv3EFM for <ipv6@ietfa.amsl.com>; Thu,  7 Aug 2014 10:44:56 -0700 (PDT)
Received: from blv-mbsout-02.boeing.com (blv-mbsout-02.boeing.com [130.76.32.232]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837E11A0005 for <ipv6@ietf.org>; Thu,  7 Aug 2014 10:44:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s77Hit1w023954; Thu, 7 Aug 2014 10:44:55 -0700
Received: from XCH-PHX-211.sw.nos.boeing.com (xch-phx-211.sw.nos.boeing.com [130.247.25.140]) by blv-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s77HijqF023383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Thu, 7 Aug 2014 10:44:45 -0700
Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.6]) by XCH-PHX-211.sw.nos.boeing.com ([169.254.11.251]) with mapi id 14.03.0181.006;  Thu, 7 Aug 2014 10:44:44 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: RE: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
Thread-Topic: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
Thread-Index: AQHPsedjz8sSUdPe40minw4ir8jvzpvE5TqAgACTMICAACRhAIAAAS8AgAAFngD//8X+cA==
Date: Thu, 7 Aug 2014 17:44:44 +0000
Message-ID: <2134F8430051B64F815C691A62D9831832CEC84E@XCH-BLV-504.nw.nos.boeing.com>
References: <776E0CDC-3D76-4066-9AC6-2BA151C0312E@gmail.com> <53E27607.6070105@gmail.com> <1407378535.24444.3.camel@tachyon.blake> <53E2E89D.2080300@joelhalpern.com> <CAKD1Yr3zF3s=iFuRr3pN+k-hw0d04iL23DHU7WqEUZmGBe-itg@mail.gmail.com> <53E3829A.9060002@umn.edu> <CAKD1Yr2nY_hxD2US=MC3=926Yd_KyVrM3m+M41Ap4aVfm1rMTw@mail.gmail.com> <53E3884E.8040503@gmail.com>
In-Reply-To: <53E3884E.8040503@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.247.104.6]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/SYPOX2PCocGau8jTU1HGBrKVaYQ
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Aug 2014 17:44:58 -0000

Hi Alex,

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Alexandru Petrescu
> Sent: Thursday, August 07, 2014 7:08 AM
> To: ipv6@ietf.org
> Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6=
 Addressing)
>=20
> Le 07/08/2014 15:48, Lorenzo Colitti a =E9crit :
> > On Thu, Aug 7, 2014 at 10:43 PM, David Farmer <farmer@umn.edu
> > <mailto:farmer@umn.edu>> wrote:
> >
> > And after a short while, the race to the bottom ends at /128, and
> > we're all forced to implement NAT because customers don't want to
> > pay twice to connect two devices to the same network.
> >
> >
> > Do we have to drop the NAT-Bomb?  There is no consensus to change the
> > 64 bit IID at this time, but 64 is not a magic number. Considering
> > alternative IID sizes or even a variable length is NOT equivalent to
> > condoning NAT.
> >
> >
> > Of course it's not equivalent to condoning it. The road to hell is
> > paved with good intentions :-)
>=20
> One good intention is Prefix Delegation.
>=20
> But unfortunately Prefix Delegation distributing /64s to whomever asks
> is not making for an intuitively simple - aggregated - addressing
> architecture.

My understanding is that DHCPv6 Prefix Delegation can be used
to delegate prefix lengths up to and including /128, and I have
identified good uses for such "long" prefixes. But, they must
not be assigned to links on which SLAAC is intended to operate;
for that we need /64.

Thanks - Fred
fred.l.templin@boeing.com

> Alex
>=20
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> > Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>=20
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Thu Aug  7 12:29:57 2014
Return-Path: <roman@czyborra.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FF31A0A93 for <ipv6@ietfa.amsl.com>; Thu,  7 Aug 2014 12:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.95
X-Spam-Level: 
X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_26=0.6] autolearn=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 63Gzocn5Vp3e for <ipv6@ietfa.amsl.com>; Thu,  7 Aug 2014 12:22:35 -0700 (PDT)
Received: from new.woffs.de (new.woffs.de [IPv6:2a02:2770:7:0:21a:4aff:fe20:b137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7FA91A0AF9 for <ipv6@ietf.org>; Thu,  7 Aug 2014 12:22:33 -0700 (PDT)
Received: from new.woffs.de (czyborra@localhost [127.0.0.1]) by new.woffs.de (8.14.4/8.14.4/Debian-4) with ESMTP id s77JMSM2020222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Aug 2014 21:22:28 +0200
Received: from localhost (czyborra@localhost) by new.woffs.de (8.14.4/8.14.4/Submit) with ESMTP id s77JMRIJ020218; Thu, 7 Aug 2014 21:22:27 +0200
X-Authentication-Warning: new.woffs.de: czyborra owned process doing -bs
Date: Thu, 7 Aug 2014 21:22:27 +0200 (CEST)
From: Roman Czyborra <roman@czyborra.com>
To: Lorenzo Colitti <lorenzo@google.com>
Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
In-Reply-To: <CAKD1Yr3zF3s=iFuRr3pN+k-hw0d04iL23DHU7WqEUZmGBe-itg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1408072039380.17789@new.woffs.de>
References: <776E0CDC-3D76-4066-9AC6-2BA151C0312E@gmail.com> <53E27607.6070105@gmail.com> <1407378535.24444.3.camel@tachyon.blake> <53E2E89D.2080300@joelhalpern.com> <CAKD1Yr3zF3s=iFuRr3pN+k-hw0d04iL23DHU7WqEUZmGBe-itg@mail.gmail.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: MULTIPART/Mixed; BOUNDARY="===============6236561538251940482=="
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.9 (new.woffs.de [127.0.0.1]); Thu, 07 Aug 2014 21:22:29 +0200 (CEST)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/WpYm4psULRBh3dbAxOhXjgdfS68
X-Mailman-Approved-At: Thu, 07 Aug 2014 12:29:56 -0700
Cc: ISC AFTR <aftr-users@lists.isc.org>, IETF IPv6 <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Aug 2014 19:22:37 -0000

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--===============6236561538251940482==
Content-Type: TEXT/Plain; format=flowed; charset=UTF-8
Content-Transfer-Encoding: 8BIT

/me loves your Italian humor :)

2014-08-07[Thu]13:33 Lorenzo Colitti wrote:
>
> On Thu, Aug 7, 2014 at 11:46 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>       It strikes me that if we start permitting subnet lengths longer than 64, than any operator who is so stingy that they
>       are currently giving out /64s will likely switch to giving out whatever other length we tell them is the longest
>       permissible.
> 
> And after a short while, the race to the bottom ends at /128, and we're 
> all forced to implement NAT because customers don't want to pay twice to 
> connect two devices to the same network. 

In my sad State of the Union address I must bitch that http://edis.at/ 
currently hands out 1 IPv4 opening a /48 slice in 6to4 paired with for 
each of my 0f10 front toes exactly one NATtable /128 slice in modern IPv6 
like [2a03:f80:ed15:ed15:ed15:ed15:ed15:c30] just to name the shortest.

At least http://netcup.de/ is generous enough to hand me one usable /64 
slice next to my self-administering 6to4 /48 so I hope that will suffice 
to configure me a static "poor man address family transition routing" with 
plain ip -{4,6} {tunnel,route} from http://packages.debian.org/iproute and 
ip6tables --jump SNAT from http://packages.debian.org/ipfilter replacing 
the ftp://ftp.isc.org/isc/aftr/ flunking in coming up to serve me.

Ciao belle: Romano Czyporro

--===============6236561538251940482==
Content-Type: APPLICATION/pdf; name=edis.kuendigung.pdf
Content-Transfer-Encoding: BASE64
Content-ID: <alpine.DEB.2.02.1408072122270.17789@new.woffs.de>
Content-Description: inet6-depleted vzserver termination
Content-Disposition: attachment; filename=edis.kuendigung.pdf

JVBERi0xLjcKJeLjz9MKNSAwIG9iaiAvRGV2aWNlUkdCCmVuZG9iaiAKNCAw
IG9iaiAKPDwKL0NvbG9yU3BhY2UgNSAwIFIKL0ZpbHRlciBbL0ZsYXRlRGVj
b2RlXQovTGVuZ3RoIDU0NjgKL1dpZHRoIDgyCi9CaXRzUGVyQ29tcG9uZW50
IDgKL0hlaWdodCAxMDYKPj4Kc3RyZWFtCnja7dz7k1XVlQfwvyuVqpT5wR/z
qpiqxKRSSaUcnZmq5AfMlKU1k0CNxrcGFRUERVsR5aEIyEsaRHmpvJpX000D
3U3zaFoa6ObVPObD+Y6nzlz6dl9oCMa5q7pO7bPP2nuv1157rb337atXm9CE
JjThuwPnz5/fv3//mTNnLhZw7ty5kZGRS5cuXbhwIa8XClAeHBzs6OgYGhry
evbs2XxNK51cvnxZffBPnjyZJqlR0GGJGQT9eDXWlStXtO3v7z969OixY8cG
BgaOHz9+tACvXxfga09Pz65du5CqXsMJcn3kyJGFCxeuXbv2k08++eCDD95/
//19+/Zt37592bJl69at+/DDDxcvXvzWW2/B8XXGjBnz58/36b333nv77bfV
QJg9e7YaAoG/cuVK5VmzZi1dulSH2ip89dVXe/bsWb16ta9z585dvnx5a2vr
ggULNPfJcEZ/44033nzzzUWLFunwo48+Up46darnkiVLNIS8YsUKQ7e0tPhK
LBPk+vTp06TX19eHgM2bN+/cufPAgQM93d3bt27ZvWtne3v75k0bV61csW3b
VtTOnzevra1t5862Na2ta9e07tmz+6stW9asWaPt3r17N27cqIxrFH722Wde
IRPgli1bduzYsaGAsNnV1fXpp59iRz1xGXTTpk3r16/3NcheIXhFQHd3txr9
I4xgyYGpTJBrtq3/Q4cOESDzU9N/5sKGrq9Xt5/Y1nuqs3949b4TazoGuk4M
n7sw0t538uzFS+3HhtZ2Dnza+bWXdHKlAsPDwyw25eu/VoeuVzMqcg1CPXbG
+FQFM27r1q2skYJOnzp15NT5f52z47FlHc9+sn/+1r7/+mjvpAW7Zm/s+dP7
be9v6XtsecfTq/bfM+PLJ1Z0Tv/8EOQJynyCwFARb74zBobBGJirGmbDKlTW
E4J6juXEiRNcx6WLFz7rHLj77+tf39A9e1PPqr39/7loz7Jdx6C9s7n33+fs
+OuS9k/29k9e2j5lafu/vLP9046By4WbirPimoqyusvF66Vv6j1HGMAt55qh
fvHFF5kmuDYXcG2OsF5TTGWDqj8xdOGRRXsmL2n/76X7cPr48o5/m7PjqRWd
/7Fw9/Ldx//e2vX5/oEnl3dMWdJ+7+tfLW47evLrAT7h4KFDBw8e6u7uOXSo
u6OzU7mr60BnZ+fhw4d92rN3776ODpZ/+5TOyeMX41E6UXAIFp0GuQbDFy4d
ODHceXyob/Dc18MXu/qVhweGL16+cnXw7Ii5vL9/2N/A0AVd0iCFZrErtD2C
u6Hh4eh9pICsYo0TcBNgfaRohs28Mc6LWuMm7vS+/YBxtm054O0tEwosbewm
FDHxpf/bACxt27ZtFj7zmnOrh4ZZwQ8ECyvhnDp1ypO1pMDL6WegADXqRWV3
mrOxIEvnYAFZiEcFrvv1118XMGBcLCQ2E0Fx+wInntCKtnv3bjXz5s37+OOP
1TOeO8gRM7biJO49V0BCXEvYqQK4F3rh2xMJ1+vKlI89fPnll1yf4MrCjd9U
KiuIsjgKElDPJO4U1zynOWvyiqm4LKSiULzX29uLqs8//xyRhMAg4YjbBdtj
rNd642mTQSSJACnEAxNgfDUczzvF9dUipgJorkYIJQuhLa+BO0hqE75twB5M
BDkIP8AN8gxnC/BaPhO4At6A5/cKX1zEw6s0lbh93ob/VK9SAWY8qg75HAWt
tFWv5mQBelAz+A0o+5RCPpUQfP0MNwbjGrl58cILL0yaNMnz+eeff+yxxx59
9NGnnnqKh3/llVdkuxLbxx9//MEHH3zggQd8ffbZZ5988kmvU6ZMmTx58kMP
PaTtE088ITriZ/Tw0ksvyZol5lLm11577d133+UVZeWy9Tlz5sip5aSWBrm2
DN0oPqmxXuhZE4Gl8nPPPTerABm9hih55513eN2IfVzA1NhccwtC2fcLQKEE
X/8KCJPSYm3x4sWoUolIVKHWK1Il+xY1jGgIE9d79uzxacGCBVjDKecPmY8V
GyMYghWQ71X2NZk1BletWpUEnNAsFty1fiT1EPhkzYVbIhBPXroRruGMyzUE
DL744ovTp0+nppkzZ7788stUMGPGDM9nnnlGAb8+KdAybXr6pAnGrfVos8pj
Ac2+Utmrr75KPp6Uzmw+KQB30FpaWohFQ0842a4xqCcyfNXE67Rp0yDok7WQ
Q9blTJwqpObmuEaSseh37ty5Rqc+g3o1OtYUGDkbWLp0KcmQAGQsQKNEwYxl
1AJKHYJ/fGHEck/dGqpnD7RmYVWOKqlVpeyY0rNxZFDap3FWR8uU7pVhCKI+
LQCyzmVzRtSDV8GVjNKgnjfHtc6pklRfKcCc8qRx9OdJy+RAd4Rg+itTCvap
zBMXLHx9ARBYgidTh0lWJIAvjLAKXaGTNJiQQYlI/xDMEXNBP2YTUcNnS4bz
1Se6MJBWRiEfT5UwoZG8QfnPm+CavvRvOLyjJ66MH8vsZgm4wDjfAoei8UIv
5in5e/Lh/LNyVJNNSNytKYBV0LIafCl4pU1mg3L4kvRsk3L+OskGaQpWlmyZ
isHyTAE+nCMFpNVNeDNOXlAal4sSswmnxJgInDo8EamgkswV4FAl3rGgVVdX
l9WNq8FF9gapT9xOC9C04rIyr3G9tABt+UM2XLMYmadnCqhW6jzPQE39za1c
tw/KALIaFZdltAl6a5pwEXw1hdbrE6c8vGd2wO4Ua7cWWB2H1lNAtMYYcmRw
tTBLdmXaemXnDN6naij+zwgY5Lr5ZL7CMr1//356JwQeA4+4Eyhy3ewhWwEK
XjP3TY0btWrLgXlnPnI+6wowQ63CCmT+D+P62pHQ4CClXiySvWx/4+XaBsjg
YLY1Tpw82dnVxSQSKtfswN8QEJ2lk0gJlu/Fr4I1UecTP2QZFc62tZ3btevi
4cOnVq48vXr10KZNI8eOnVq2TLn/1VcHWlpGjh7lFAYXLTq/b9/lM2dOLV06
tHlz//TpX8+e3bthA0c/cRqYB05ZV8ksIaRsHt0Oro+/9BIWTq9Z0/WrXx38
wx/a77rr5Lx5+3/+8wO/+13Pn//c/cc/9k2Zgt+93//+4UceOd/V1fGjH/U+
8kjXr399YubMHffee35wcOI0mBd4tNbg19ptWll2rarM29wRCylgX2h0oz3H
7Ygi+Fsz0RA67DlypOfFF3tefvmoCO2ee9rvv3/vffft/s1v2n/6U1xf4/33
vz85f/6xqVMP3n9/589+drq1tfPHP+59+GF/9H7gt7+9cOjQLZD88eMiRgED
78GZoC076ii0dOKa8VsvbsLa+VtWZOG2gie1sfoLfGc9/PCjP/zhX++6a/L3
vvfYXXc9/cADk3/wg7V33919331Hnnji4tGjIwMDXb/8Zd/kyV333nv06af3
/+IXh//yl86f/OTI3/7WM2kSvzZxrs1rhGEZd3TNeeYQlnLPnz9P0Sa7+nM3
Ppalh+VgnHvMRpyu1Ii8Fz377JKpUxe2tHz49tsfk8bChUfWrz+3c+fF3l4N
Lw8Nndu2jS+72Nd3rq3t7NatFzo7r038Vasu1l/NbwgsfEjCbGb04K2YNSXX
5o41YseOHfpPFsmczJdD3d3b29r4JTUciMCyp7eXbZhu145xe3raO64BtI7O
Tp96Dh9meLeKsKuFN2PMZp85ePDgQeNaFKwj1w5xhoayiSG4LS8qqPQpey/a
5vrBqD3rSmIujrUy0jjzjtMQjop+k0wldpVTsP+2AnK+D5lALNwSPTGtr7eW
a5Qk6kaGzmVGRmHw8hoEW8SZpSgaAShkFVgQSzMMaIxWpI34evLUUBOdmClc
h5lC77nDoB8ZBGlzdOxNpT6JN7cycp2Aw2EhWlHHrY2uY1cnCjC6/jkuWXzy
mmQEQYhyfeUK4pwZgNd6ITGDEeqgX1sKFUqRAAPGnUwkDkR05BMVkypmk7ES
ryEg58gSZpI77N+SEMLikji2BsrKHFBeX66ipT570dlFD5gaubaBU+bBacRc
k7jhxddsLGAw22jZwcgxhJRNq2Ss2DcNiUurclc8Y2V7vIQybh8DTE9aOzEx
oHR2aD5S3MYCGDAtI5XiGDAtdxVAiRTKbnkqBu8T08KIAsnQeDZJcg8hwTbL
90kBPlPMpAA6kbablSq9lsRgZ4yjrkA2fsvdp+xHKeinLFe3qvJaxUwBqXSE
cWRQDe9EUzlIKm9S1UDNHsjY0F9AWqUhAcbpsXwEDHwD0MZdZHPxjGyJlAfL
ymIWm6oqaZCQ8zWfvAYhKkssl/CGFggwMa16CqLcHJjmOClHcimkXFMYA9BD
QeUrTpFtFGwiIKFFgPMZV9dGpAutMIL4bPCi3yjZm/VKpApeGbAC98KomC6u
CVxlxJJjAsz65DX3r0ipPFkw3XLymHO0LIUgV/hyylaPzpokmlM1NUgV15aY
3iK2KTGv36+4nutRd5lozcrCSjGbHf72AngkZozZ1QXkrlrKuYGGBlzzYNwU
88uG5+cFMH6uDGbsR//J8niwOHbleozn8k8j/rkRrhlDeROyvFXCSFSijfow
xbGQKtkyV6bFmBV2FaDeUsLtdF67jXMwG/VaxU2pJB9lc4396DCzgJZzzS/b
gzR1vABfR11Qcq6aY9Y48Bxb51DbM6euVcxxdU3OiUlI3kwJp3RKNdwm86Yg
SmxpaeGjaAQXOscRM+BF8cWes/rkuhdkLKvUQ+6A+cQUG9FUPajqmtAYDDuM
qzcEssuvjVt46ckz6QiQJBOEEF18l54VkqEktMY+7fAqNE5KJAAtqYoFCGau
RGLZa/Z1k80l8NDc1wYT2Oq8NgtyblhGyNUwqUELr5pHFcqQg/Y5MayRjIJp
nskbF52LBDnvyBq6twBlXCeaNS9wp3LhwoVZzjT3Nctc3NpIBcpQJwVusLTw
fM3GUXDK4/t8asTCyWrUjfTqUQKmcnEFzc8884xMGc3SCgTjce7cub7GI/kE
jVh4M0865dNyChBj4MHiCWEyUQXxGEdH79URyZMPzC2yxDwkVq7vCNZbjg4N
kUOHsrmv467Xic0G6oN+zOUc3vHJrQUgAy85tfEUN2IhN4SzxuEdSYhX5v3M
cT6BBMICtLiyeLCcepeAa24h92F4GLIlbfMlQWDCsJw15PooNM8bilIa4Rqp
GCdSKRinl4M5cri2MfLuuwhYW0CuyljXIMTmc1smByIit9x4pJ1EF/UAL7EK
XV27s12EtSZIyTWCk8dBywGigW6Ia3PKtO2vD8bCddZZxjxnzhwmihcjKr/5
5pvIi7sOazNnzmQMyPAVwdk7IiufsMCnmeM5tKo3YqxXt/gin2xdapULEkCB
6GJvFgids/Cyee5djMt1LK0e5IYqGnAqDWfJjM1Ysqdcb8jSZmgIWMteq2k+
efJkVi1bjxBee+21HG/NmjWLKHyqjpusoQy2MVsaCUVjymShnSAr5KBQz0la
9V92pdtGuM6gY+RTzBW/ckPzF7/IYOrvvfceh6YmR6sIwDhK1FOumQifieYg
w/RXpqDMCzWlKrNTl401AEdDCGriQxLdcQ4lndE1Y0tax8wy68uvE9e1fnTL
XCk0lJu/sViAvBzO5o599I41lZmPkLFJCAlfkYda9cQFR6sc1jOh/BQCgkJO
h4HpnJBeoaprNbQMP6FjZNK4riGUSeWoIB4ws7CJ2ty3pJ3IgRlnLifnInk2
4InO3GCJilkgRvKTFtRi0CeWz0KYOl8BLTZPp5xGeUkpuQxkDQ1RZrUI1if8
WAI5s/Cyia/jcp2DpDHAuq9P42KQdnIrBnnK6M9FBaFX0nyVnjxVAlRfI42k
cp6WXX2WEUi5D1Nv9DJuGbW+bF6DcEt22DBFs7G9bBtmY998NOVZL3bYGwRs
KuccIX4vWmYqlM5asv4yFaLI4dq39hDWZEEkFWcnIXfvFcwvFsgGOFhKJIQc
PSvnd0kU7Ukyib25YvXKiamy/3lHLqgLYpPoJZYzi7MrDhjtbf3Vxp2FeKd3
CkjgITaeNm2atZUu7jR1twvKK9PZ1cnF8uRi3+Fbx40f918ZExrHHPe3eI30
MAbmuIzQr7l8+vRpUzteCORHlEn8s5WdrWkTP5cbc7/3dAWyRQA5rTi60+OB
3Px/T7S/OR/P6FwK386rVJGzZVS+ojZhava1qp+wM25+zaSTc2mbn9Pmat8b
b7yRrFksam3KJbFcX8R7tr+qeRlHLRa1rIs6tOKia7a+r9/9RrMRdWvFzx22
3E8zltfs7ZdQhsfpR1teCDJM45ZHA41nmtWrbkPfQLVcrQzUXIQLsqGJrq+v
r7wKmBqQ6+Upl3eHEA8HvkoWoqDb6ig1/V//KZU5Vy0rsdPIfjio/mji5kCw
kRMBSk+QnOQie0o5lMxPadQrmA6stFy4KV0hV/KudxFX/+/POqpXj8q5XNbn
Z+/j6nrsXYWbgGq+NlD8iL66DTJuc0o3Z7Pzlp1JUJ1TOWHJeURELdy9tXsp
/2Bg9qyCf8iNVl4id+/JoSpVNgOBT2AkCuLkG+LaSl1vKt1B4GNL35KpykvX
Q7ue/nHvDDehCU1oQhOa8M8F+XVG9RBzZEwoMas7fmW5Bq0ejNpnScAYlDTY
YSM3r3K1QEYg16v5WWjNLaDsNosYJV+iRE9Zg9xBQCh2qv7XptxMgOmZSy/X
/uNQAcoDldPJnIDnKBxmbl7JQJNzVU8q9QZT5KZ/gyY5zWly9VhWedzsA9fa
JmXYsGFDkoJRfw6ZH5igJ9cYchaT61XCQglFNt8yLvKylfpVAUlGPHNho2RH
AY/iyXXr1gkyP/jgA63E1XpDVZVrZTU5zkufCMhvBmuU1eBJLko2btxIXyL5
8krbqFxTx86dO7MJjFpiJ4Hs8SIjOiUx42It+VQ2imMSMYaqSPGS/xtA2itX
rkSAhpFezW8w9ZkbdxQkAVfIL92qN99uiGskkVtO0/KLPIXk6TVcs7Hin1/t
zH6vxKf8GQ7LLJvEAilaz3SxYsUKCHhPip1rybFJ+GyeZvGb//2Vf2SRWx9J
1Utechq+vYDc6U0Wpk9Dl/OrQa51TnRoM6Kec5E1wryeayPmRndu5ZUJYA0m
SlpbW/Or0pzmr169OhNWD6VCNTRryI39GPSzAnzVeYwcPVVd5x+C6SG/SDJK
LJ/My9sODXKdCwNI0hZfOV/OLyKrvCRNrjkFq+f3NKcv/Xhm5ySbaTUN85PM
bH8RSPbo0HD9EMHM3a34xtxpv2kLr8n660GOFBu5TBvM6h5CPcycQtbblKjB
zD/6q+5XjIrZSH6dLZfvGNzWfznVhCY0oQlNaEITmtCEJjShCU1owv9b+B9U
W7UuCmVuZHN0cmVhbSAKZW5kb2JqIAo3IDAgb2JqIAo8PAovV2lkdGggMTI3
NQovQml0c1BlckNvbXBvbmVudCA4Ci9OYW1lIC9NYTAKL0hlaWdodCAxNjUw
Ci9GaWx0ZXIgWy9GbGF0ZURlY29kZV0KL1N1YnR5cGUgL0ltYWdlCi9MZW5n
dGggMjA2MQovVHlwZSAvWE9iamVjdAovQ29sb3JTcGFjZSAvRGV2aWNlR3Jh
eQo+PgpzdHJlYW0KeNrtwTEBAAAAwqD+qedvBqAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4A3L
9IvwCmVuZHN0cmVhbSAKZW5kb2JqIAo2IDAgb2JqIAo8PAovV2lkdGggMTI3
NQovQml0c1BlckNvbXBvbmVudCA4Ci9OYW1lIC9JbTAKL1NNYXNrIDcgMCBS
Ci9IZWlnaHQgMTY1MAovRmlsdGVyIFsvRmxhdGVEZWNvZGVdCi9TdWJ0eXBl
IC9JbWFnZQovTGVuZ3RoIDI1Mjk1MAovVHlwZSAvWE9iamVjdAovQ29sb3JT
cGFjZSA1IDAgUgo+PgpzdHJlYW0KeNrsnQd4FdXWhtOIVFEQBQtVQEXkAqJg
4SJ6xd5FrGAnhQ5SREUpAtKr9N6bSU4igdCb1NADBAKBhPSQ3k77V87W9Y/T
zqQcEuB7PY9PmNkzs9vsWd8ua9vtAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhbgVl7KOOLgJ
uXr16sKFCz/55JNnn332wQcfrFy5ctWqVRs2bNiuXbvPPvts8eLFsbGx1y0y
27ZtE1X9v//9b1lnDHAVaNAAEx8f/8UXXzRu3LhixYr169cv6+gAAAAAoHSA
4AVlTn5+/pw5c1q2bGmk4rVt23b9+vVWq9XVsYLgvRVAgwYECQkJtWrVwjcO
AAAAuPmA4AVlCEndKVOm3H///ap1rGrVqlrVr2nTpn/++adL4wbBeyuABg0I
unfvzpWhYcOGTz75ZFnHqGxYuXKlyARqAPVDnjhxYvDgwW3atLn77rsrVKhw
7733tm3bdsSIEVFRUU6fEhMT88svvzz//PN16tS57bbbKlWq9MADD7z55ptz
5szJyclxenlubi6FfPHFF++77z5vb2969AsvvDBz5szs7GwjaUxISJgwYcKz
zz5Ll1PMa9eu/frrry9fvtxsNutfeOjQoZ49e7Zq1apGjRpeXl70/5YtW/bo
0ePgwYNOH5qYmPjbb79Rkul7R3GuWbNm8+bNe/Xq9ddffxW1jE6ePGm81bLZ
bKGhod9+++0jjzxyxx13UG7Xr1+/U6dOs2bNSktLU73kp59+KoZNSFfxHfbt
22fwqu+//14r5lTB6J7t2rWjukE5Vq1atcaNG3/22Wf06adEFTXTAAC3ONzs
XCkiZR1xcMMTGRn5+OOPS799Dz/88KBBg8jQunjxYl5eHoUpKCiIjY3dvn37
jz/++NRTT8m+lf7+/gYtnGIAwXsrAMELBNT4iJowceLEso5LmXH+/HmSFU4F
77Vr1z7++GN3d3dVCUOSimSvxWJRvdZqtZLUJZmppYBIvYaFhelEcvfu3Y0a
NVK9tkGDBrt27dK5loTS7NmztbpSSbxfunRJ9cL4+Pi33npLR7i98cYbcXFx
WkmmDKlSpYrWtZSZycnJxouJvpIGW63Tp08/+eSTWs8lpb9hwwblVSUXvAsX
LjR4largTU1N/eqrr3Suat++fUxMjPEcAwAAbkDKOiLg1mLZsmVSq+PVV18N
Dw93etWJEye6devm5eUlNVG0uqlLSH5+fpyDlJSUss4t4CrQAAIBS7CMjIyy
jkvZQC2etAdSS/CS0GjcuLFMgJDIlR355ptvVIfhfHx8ZCG9vb2lTTpBZaH1
9J07d1auXFkaWKa76SyF0Upjv3799PXXgw8+mJSUJLuK1G6TJk1kIZV6n7JF
qXkLCgpICzvNrtatW6enpxspJhKDderUMdJqhYWFKaU95bbsyNKlS2UXFk/w
/vLLL3yHIUOGGLxKKXgpH/7zn//IglWqVEl25P7777+ePj0AADc63HqUdUTA
LcSiRYukRoJ+n7wSksaPPfYY3+Gpp57KzMws6zSBGxI0gECAmtC3b1+poFCV
nLm5ua1ateIwJOU2b95MepC0bXR0dEBAwNNPP81nf//9d9nlFIDP1qhRY+LE
iZcvX6ZrSRWePXv2hx9+YF1Tv359MclHSk5ODh0XAe64447JkyeT5LFarfR/
+rt69eriVIMGDSieysjPmjWLn/7mm29u376dPhx0T/qgfPHFFyxgu3btKrvw
nXfeEac8PDy6dOlCOUPClp5L/6e/P/zwQzouAlBI2bW+vr780GbNmq1evfrC
hQt0bXJyMl37+eef81m6s9Myojzp1KmTkbp67tw5zhAvLy9S+nv37s3IyDCb
zadPn54/f/4DDzzAZ0+cOCG9NiIiYoMxxo8fL25y1113Xb16le/w7rvviuOU
Ofp3OHXqlCzmfK2bo/9hwYIFKSkpVElI6VOOvfTSS3z22WefxdxmAIBB8JUH
15mQkBDuz3/ttdeKNz5L3/1u3bpx7X3vvffKOlnghgQNIBDc4jXBZDLJRtBU
Be+4ceNYJa1bt04ZgKTctGnTRJhatWrJRi15eu19992nOiV13759np6eIgxp
Q9nZESNGiFO33347iTLZWZJOdFwEGDVqlOwsfWhq1qwpzo4cOVIplKZOncqq
VjrBODIykvNkyZIlqrkn7cIlPcvHDx48yMcHDhxIul557Y4dO+68804RhjSp
6v1J8e3evfuHH364++67pWWkU6D0bRVh6tatK9OzAhL7JO1FGBLRxqrJv7BY
LCQ5xR3++OMP6anmzZuL48uXLy/SPalYOXXt27dXTregguOSIgICAooRcwDA
Lcgt/pUH15nw8HCekPbNN9+UxNkyXfvFF19wBV6/fn1ZJw7ceKABBIJbuSaQ
9rzrrrtE8ll8KQUvNbn33HMPa0adG/r5+YlgpE344NWrVzmTldNoma+//lqE
+fbbb6XHSenw8O6cOXNUr+Ux3IYNG8okLUWYe1lVhwXp4H//+1+lsJ09e7Y4
2KFDB50kkzoTwebOncsH33//fXHwxRdf1PnYkbQXwd59913lWVKsbhpo3ZC0
vwjg7u5OglorWH5+Pk8eVhXF+vz222/8KZcep5RWrFhRnDp27FiR7skD4nQH
rTXRVFIffPCBCEZ/FDXaAIBbk5J/5anBqedg3759dsfQ29ixY5s2berl5fXZ
Z5/JAh88eLBfv37UxtaqVatChQr09WzduvV33313+PBhrfvTbcX9RctGbd2G
DRvo81G7du3bbruNjtNTjh49yuGpsV21ahV9OOgzUalSpZo1a7Zt27Znz55a
jaf9366qjSS53j+IfyYkJNCn+YEHHvDw8Jg3b540JEUmICDg888/pwypXr26
t7f3/fffT9/N0aNH67hcmDhxori/cJ+Sk5MzZcqUNm3akClCapFuNWjQoPj4
eA6fmZk5adIkuu29994rHvHcc89RKahO62Lo7Pz587t06fLggw+KuFGOUV59
9NFHoaGhWl9nWdqTkpKGDx/eokULukONGjXatWtHWS2d2iTLDe7hf+WVV7Rc
Yu7evfurr756+OGHKbF16tR5++232QfmpUuXDjo4f/683dHDzDek+qBMrywn
qfJs3rz5zTffpCP0PW3SpMnrr7++Zs0aVfvHqdOq7Oxssq9efvllyjeqihQB
yr1u3bpt375da56V7GWJjY0dOHDgQw89RCmlwqUinjx5snQU4OLFi0OHDm3Z
siWZo1RAjRs3pnxbt26d03lchw4d6tOnT/Pmzem29BbQIzp16kT2iVPXKJSx
P/zwA72V4olUq59//nmqXcp1bcahYlq5ciW9kg0aNKCMoig1a9bMx8dn69at
yoQUafmYcJOyfv168U9PT0/9BFJdYvtTHJG9+FR16d2kcqTSFO5bn3rqqREj
RugvFiuV15yyghLyxBNPUHnx+yVr/Qhq68hipzykxIq3gKE7hISEUFv02GOP
UfFRC0wNLFUequT0phtxfqvDrl27unfvThXp9ttvp+pKjQYZ88uWLSObWeeq
K1eujBo1irQANU2UnxRtugO93UFBQTp1WNbI0Nfh008/JbFDGUslQjVZNqyz
d+9eSjW9zpT5VapUoeboww8/PHLkiJF06dQuZeDjx4/TC0tVgtoliswdd9xB
Nfl///sftYHK7wuJDl6q+euvv2pFgHvtqBmRTnfh9sfNxX7z6PVkoUdfZ/5b
KXj/+usvbmy1fFIJqG0UCvrZZ5/lg/Th5hTpLJResGABK1Pp8f3794vjZDwo
ZzsL6DjvLXXgwAHpKV4Fo+MsgprW1g5+/PFHPshKuVevXjpJpg+fCMaDy/Rq
sAcw5cRdGa+++qqbY6WqcnmOcsGvU3OFWh4RgF5S/efyGDQ1+/aiQAJZLAem
9y4rK0t6ij5b4p5kEekbIUp4Fbl+zOk7zm9Nke4PALhlKbnglX4fqXF74YUX
+J4ff/wxB0tNTeXeTlXIort27Zry/lLdQV8Q6URWhsSLmFFDguiZZ55RvT99
ekwmk34mGMwHaeCoqCjprjrSnudjx47Rp1MrvfRpGzZsmKquZJuf/iBLW+bK
mNv5s2fPUmBSDVo9wKQv6NOjmoTAwEDZ5CgZpK1INOmnnRJIdqzyWrI5VTvw
ed4X3Vx11e3ly5eV/j3cHNPnxPQ2zk82ICMiItgeUE6Bk+YkZTVZLKqJJatM
aYDpC97g4GBeA6WE1LrqZhPSl4V0vWzfT0HHjh2F6+mpU6fK3LMwpNdUZ8cR
lJDPPvtMK2KUV71791YVKZQ/lEtKlyYCsu2VK/KMQBpBZ4dlSkh0dLRqkRlB
CF6ScuybRdbjJIWaIE4dKTVlfV6+fDmvepNBBTFhwgRVjVYqrzn9c+jQoXzV
fffdp1oJqdZJ3dtGRkby3c6cOaP09CKFxCZJiWKUIDXL7733ntZtydxVHUKi
JJNq4IEeJdSsaQ0qSQtlxowZPMdVyuDBg+2OXjstb67u7u5St7Fa6OSYNFh6
enrnzp11AlO5UPMi68QbO3asOEvv3enTp5VP37hxI8dWJjCvm+Cl+ime0qZN
G2oZdAQvfd3Eqddff93pbT/66CORLu5pmTlzpric3jKdC4OCglSfMmbMGHH8
888/17mcLQQKzwfpMy0OPvTQQ0XNH071c889pxOMzopgPMLLc6Fvv/12p3OZ
eByZqoTsFCno4f9GtYpKIdNLBBg/frz+c6lNEx/xtm3bGs8TqieiVadPs3JL
ptDQUG4ciprbbJZQe6sTjBpzfrOK+ggAwK2J05bTKdLv44cffii1AVjwxsXF
PfLIIzILQek/kMIo+8mlJp+/vz9/QZo2bSo1hEjPUkiWfvSdpcaWnRkK7rnn
HlWPu1pGjtNMI9X24IMPSi9nwbtr1y5eTyTw8PBQbkzw/vvvK7vK2RIeOHAg
29JkA8uELVmMJPPZhqc/KANlFjsJCqWVHhISIvMwqRq3GjVqKIuDz8bExFAA
cW1jB+y4w83RBSHr06a8ql27tjhLdrsyV8PDw/ljR/Lqyy+/HDFiBNk2YqSA
brhp0ya+v3Rsixcivfrqq1o5SX9QZnK6HnvsMXqENLFKRyU6gnfx4sXSxLqp
ed2kIyTwtV4WqidcUpR1vLhMQJr0+++/539SSCpZ2SNUpxSSNnniiSdkMVFq
2Pbt2ycmJkovJHuMs1FANUSpVsg2NvKCMIcOHeIZkgKlhK9Xr560W4Zy5kld
GjRowNeyX1BhXRMvv/yyVmTYpKS2gnez4luRBJYl301Bv379ZPcsldec/pC6
03HTELxHjx6V1QEWvFevXpXls5vGNtb0EhWpBJOTk2U6WulTl2Il2xSbEqvs
3qRskb01lHWqDus4wJo1a8QfJCfpFZBVnhUrVvzvf/+TZlqjRo2kj6BCdOoQ
z+8f+Co+In07lHuiUWRkyXFTuJylfGjXrp04RYJCVgdIRHOnWd++fWURK4bg
bfQPxst3+/btIhVUFmLxqY7g5bFO5YughNtbHlG9cuXKLgf79+/XuZD0nbiw
R48e0uOffvqpOK7TqUWQ3hTBSPnyQa5IX331lfHMEZBY5oLmjjIZ3HpQSN6G
eM+ePeIgfcSdPoXeIBHYyK5YXDG0AvB7ERQU5PRuYpYUfWWMO4D64YcfxP2l
npmZKVOmiLNvv/222WymEnn33XebN29OdUxsATxp0iRV3x05OTmcNP01Spcu
XRLB6IYG4wwAuMVx2nI6hb+PvPiC1MSQIUOo3Ra7A5C1QLKLH0SqJCwsTExJ
ov9v2bLl9ddf57MvvfSSrNXl776w3xo2bEi3FZYDaSjlHgcUbObMmewrg2xp
MVlIMHnyZGUSqkgoUqZxksnMJi0wbdo0YYImJSWx1ibjkD7c9NEXcSZJsnLl
ymbNmvFNRo8eLbs/W8IiyZR7ZIqIbKHksJsIhvIkNDRUDNtRMMqfhx56iM/K
FtFQMBbppCUnTJhAdoiIW1ZW1u7du6W9FsrPGZ8Sn1TKARbFGRkZ/fv35wCk
QaQX8sZ8r7zyijJLKd9YAH7xxRfS8V/KTLE8is3dli1bSq+l9IrjlSpVklUe
zsnnn3+erF/SViaTSSSWQu7YsUO62cS5c+dUK57M2qT8ZAlJlswff/wRHR1N
d6OSpdwjnc5aif6QOSHhl0WULGWX6IGhy+lx0qkCghdeeOHEiRNidICiTZYe
5xIJHKV9wmVHGoTewcOHD1OZ0oWUNMp/qVSkGiu9nP3MuDlmElJCyFChADEx
MWS98Po+N90JgTKoPvCaO4otvXrCmyuJzX379knferKLDN4zNTW1adOm4ioy
7HkCM5WCOEjKiMKoXsuZTxVMWZ/FyCmVC9X5M2fOFBQUUDwPHjzYs2dPqb6T
mmGl9ZqTJS808j333NO7d++xY8fStbJKSLqpRYsWbo6en65du5L0II3M0xJ4
TJ/sbZJOJ0+eFA0sveynT58mFcZJ6Nixo8GsFtWSx3Y9PT379OlDOUO1kTKH
/ujVqxcPN1M+SKdMszJyc3RjLl++XBQKZQ69PpRGjs+9996rnIXO11JxUM4s
WLBATIykR1PbruzAka5YoTz57rvvilG1+BLlqfnz5/PZN998k9oNkfOUHHpB
pk+fztWAYivbGfzs2bPseXjcuHHSU7xYleqJcuYnNWv8VaLPYgmToApV4Pvu
u09cwlVOR/DSN12cUvoiVvLNN9+IwCtWrDAYH7tjkg9npiwC7B1av9OGB82f
eOIJPkgvtTgoBv2p1aXmqEOHDnXr1iUVJubnUw5ozdPmGkVvwccff0wVICEh
gWojNWj0Nx3hvndq0vkqag3EwRo1ajjVkvSOiMCylcvFK2iqpSIAtd5O78Yf
QZ1lX1IoXSK9lHuqCyV4YOKZZ55RbufEebJ48WLZhZSlmf+gteJJQJ9CcZ/i
udsCANyCcPtzm2FkE4/5+yiMsdWrV8va9rVr13KA3377TTUaJLs4jGwndGlH
NzWwsqfTs9q2bcsBqlWrJpMtdoesfvjhh0UAmXeFEmaam6OD8fjx47IA3OCT
RlP1dUmGKPveJ/tNuiDX/u9ZnWSwyb7C9KnllUFuDs0lW0Fjd2xJwMNzMjeJ
JIL4uapLpylLuS+dvps6aR86dKjyct5nQTZ5jBSWlrlCBcSjSGSuK20DkvlS
0SHzwElfSbaBKXO0cpLUhHJBJdntPGrGJp9AS/DynPkffvhBdaIaqSQe9aOK
J11uJn1ZlD353Mkv8PHxUWbF0qVLOYBsrXRYWJg4Tkas6lR2Mqqlbr7YMQuJ
ER6UJINN+dCIiAiuck4XhTG8FSPlvHTyLcMmsZuBNW52x1vD8wYph6VzRClp
HEOS9spro6Oj+VnSKbjSDKfmRbYqVrB//34egqf3nd/HUnzN3RxzdJUrE6Wt
n5vDupMNzdsdLyynncSXataxfag/m1QGz6kgHS3zwiqQDovzo2NjY1kIU/Ol
utySioCrnHJpJN+TnqucMDlo0CBpnsheWwHPczY+qZJvqDzFnTOdO3dWfeVJ
1fIgoLJHiAe8qE3mzxMvQqS8Mt6JVOwkKKFqw458SXrzcR3Bu27dOnFK6RJK
BuVSo0aNROCZM2fqhCRdk56eTk3Z9u3bhw0bxi+arEeO4NFwHY8fdsesEn5V
+SDPc/79999NJhO73pLx6KOPnjx5UjU5AwYMkAWWTQKhf1IYafVITk7msyTk
9YuDW2YjXpicFnSPHj1EAGnnnio8VEooHV8roULp2LGjCK/ls1o670IfnbXt
OlCF4a5UpWoGAABVDLZLUnQEr+rKTR6R/PDDD3ViwoNTspUyUpNPdR8EqY/6
2bNnq96cd4sr0gCH00wjraS0kKk1Zltu1qxZWjfJzs4ms0EE+/nnn6Wn2BKu
VKmS6oeSrWgylrTWwbGRJhulZRtVdaRVwLslKqfScdplYzoMC2oyAPhgSkqK
UKxkzyh7brkESR5q9evyuJ7bv5cuCho3bixOyRyVSDWF6uC+NKNkpaAqeNnF
xwsvvKCzLIsHHN3+vW8CvywtWrRQHU1ge4/MRdlQkYDsDVbTYgYFI2YyULaT
6agVMVIf7OaLB8r57SDFp7U0mCwTEebee++1G4AUKI8La72VFIbTohVGmvAv
v/xSBCZxERISIgvAvTQyXzcC9uJClpK04LiY6J6yyiOFh424QEvxNXfTnmkp
bf2aNWumKh5JYIoAlJlaxUex5fsYKT4Bvxqy2RpSeFdQDsPTHakOK/viGJ7F
TWpdtoKeoyqb1CqgFo8DaEWMWyEqVoOJ1ckfreZFCi9UV3Vu3KFDB3H2mWee
oX9SeuvVqyeOKDfQKTZFKmLuZKZ6JW1qdARvamoqD2XOnz9f5+a8f5Cbdi+3
gHWxlLfeekvp5IEn7ctW/cvgri1qf/ggfzG7d++uuiScoZdI1d2ZctGHjG++
+UbZCcCj0koHnlJ4Yrmb2sKcYhR0YGCgCEAmik5fomz2nbJzSefOVOF1PFvy
Pe+5555JkyadO3eO6hgVjclk6tu3L895oK9VURdZUMXgKtqkSRP9gWAAAGDc
io6W4G3evLmywafA3BEqnCxpwfuvUcsvtX/Y5PP29lZt3Mj0FQHoQ6bliTQ4
OFiEKRXvH5wV/v7+yrOsFkk+6LuyZJNPOvnK/u+JuKoX8gyrp556Suvm3CMt
89xC2jPCgWwwVArvyagjeLXMGOkyHD64cuVKcUTpb4TKlOewqY4iCVjw/uc/
/1GeZREn9dctzUkSklp1gzNTllGqgnfw4MHioNPt/zjC0gEsflmGDx+uehWv
wB0yZIjWndu0aSPCSC1SUhbCkJPN91ayYsUKNjbEbNKnn35aHJk2bZrWVfTy
su9crTnDUngAiwSylktVwsfHR9xT6hZVFXZZ46bhz4R93VBDoVwgxvtCyh7E
93S6lTMPW/j6+tpL9TWngpMN/jJSwbt27VrVMLm5ueKN1vJQZ3dUD+VbqQ8Z
qDytQjmJhVm0aJEoQXZ8zdJPa+8YAb34PIdf1n3BUVVdgSttYbSsZYp8UdOr
E54qv8hhnT4udi2oOtZPRcNLqqdMmcIrcagB1688RcJ4kknaiFF4kh6yMU0d
wWt3+JkXZ0kY7tmzRxmAsmjhwoXS1c2qyzwZpeB97LHHVHtxedqAak8gw0Vf
sWJFPvjSSy9JH1G5cmV6+0hmJiUlxcTEbNy4Ueror0GDBrJHxMbG8twSHV54
4QXZi8x+uogZM2aoDov/9ddfUmcjRvrknRY0Nbk8IE7vo2q3OaWR56gIZD2o
SgoKCvi7tmXLFtUw9HqyyffMM8+oek2hKsdJbtGihfG1w9QgcIWhGqg/1g8A
AFKKahUo4e+jcJspg2dpGplaxk1ZWFgYH2STjxpG1as4wKOPPqp1Z6dbzBQv
00JDQ5Vn2VmH0+nTV65cESHJsJTKMbaEtfZB4ACqilsWxoirUin0heLpxzqC
V2d3P2Wl4vFB5UpGLhr6Lmt9+K5du8b3VHXWxINoWlOadRxsamWUap3h6Qo6
280IeGo3WcJ8kF8W2bx9ZQAtdWPXsEjJ/BAHnXplkU7uNZlMZBrxpO6S7D0k
g12/Sp3/FJv169ezEUUZq1pPKCG8wFk21470GidZNiWDjzudGsc+xlu1amUv
1de8Xbt2WtdyJaRrVR2bGyE/P59HXY039SQHRPhmzZoZfxZFksWO1vZkDA/Z
yxZHcFRV/fZLA+jsQlXU9Bb7U0i1MTAwkDsHVHWiXdLvwYtNqlSpojqFvtgY
TEJ6ejo3mMpOCX3BGxkZKXWGRi8jfeJJzlO5h4eHL126lPseGf0R3ocffljV
MzzdWTZdgXNYf4MtiokI5unpyQelcpUMiUuXLikvDAoK4qor7VJLS0vjLY3c
HD1jAQEBZ86cIcFI/6e/efhYfMWk3fX06nFXm5tDAK5Zs+bUqVN07dmzZ+la
9rbHlMoIr13SsenmEPg///yzWHpM3/c9e/ZMmTKFl28zTkd4eS6WTiQp+Qv+
QafJkq502717t9Mknzt3Tuomnd4dp/7oAABASrG/8gx/H1UdGPJXXmcCLcOz
a6RbtzvVqkbErIsEr+runDw3e+zYsfr3sVqtrDWklo9TrWpEzBoUvKmpqYcP
H6av8JgxY77++mv6Iks9weoIXjLjneYPH2HvXspJ77wiT3VFsICHC90UrqVE
EoShUqtWLdkQDGcCmdZFzSjVOsNGAhlp+kvd2XYi25Iv1zcmjQTQCsN7Z9Bz
9SMmNS9J5VHFYxPCeE+7Uz755BNxW31z1wiHDh3iKXBUP3XGi3nOoWztOQ/i
0+WySzgrVLeRkkIVT4S855577KX6mktXUMrgSti4cWOD2UW2NFnUZL1Pnjy5
Z8+enTp1Et7Ui9rUs7dbIxY4Q2Y829hOqxP746XaolooWhcaSUtR02swvNls
joqKCgsLmz179sCBA99++21eTqj/5lJu8PRvgdNp/EXFSBIoGl26dBHBPvjg
A2UZOW2CqGppbV7GPPLII7zEQH8Nr4A0LElpujP3tbopJl1wd5bOp8cuWZQq
Xa7Ot9Wf4st76Up719m3GN1Q7J+uhI5z9GRep6i2qG7eJ6VatWo8d6hU1vAK
2IuCDu+//z5PydBfw0vCn1fcqG5ZWCSo4glflG7OTJTExESyH6ROPKiKCo/i
AABgnKJaBUr4+yjbmULAQ3uqq7Fk8EQvqQ1ZngWv6qbqbNWorjiWwd60pKvD
roPgJcO7V69e0oWxqugIXp3ZfcpKxYsBlZsMsvWl6nxGwONTqvOZV61aJc4q
F/RxJtAdippRqnWGlZdxpEvJXCd4pTN+jTNt2jSqeOJvslHtpccrr7wibqvc
HLlISL221qtXT2cevl2ycoHMWh5noYrKs/uUEoOzQnXqnRQeOapQoYK9VF9z
0k1aF3IlfPLJJ/UfQeYo6cd27dop98qRYTDneQ9ZMYXbIGT5i6uaN2/uNDC/
ubLuUKdRNZKWoqZXPzzp3EWLFpH219oam9F5c0mpcQNCBVqK/UvGk8z9GA0b
NlTdGsZIE0SlrOV9182hoZKSknQ6OfVZsmQJ30r6vnBno2zdigxevs17exHs
bFyn59Pu2D9R1iDEx8dzb1VgYKDOtbzGoWLFijLPclevXpUulZXRqlWr8PBw
aifFP41snGS8bs+bN0+2AR/j7e1Nn0WLxcJbRupPW5o0aRJHuEgFqgVvvafl
3YVekMWLF0v76+6+++6ZM2c63dQYAACUFNUqUKL/fSyS4CUJJgJL/XiUZ8Gr
erZIlrDYaoSQ7l/jasE7YsQI2U6aZMOT+CWzs2fPnsuWLVu/fr1WdhmpMMow
7A5UOXGULQHVDhO7Y4kiO9VUnc/MNXDNmjWlmFGqdYbXkRmH7AplVEtd8Eo3
gjEOvWhF2izSOEXaCFILEq38glSpUkW2wZaS/Px89mzDzsl5ai4ZokoLn7PC
qeDlpaNVq1a1X5fX3G644QoJCZHtw+vu7l63bt3nnnvu66+/njp16sWLF428
uVKKtOkqUyTBu2HDBhGY1//KCkXrwuK1QvrohI+KiuIuC6ZWrVrt2rX75JNP
qDk9dOgQD1fpvLlSX3bUkjitz1qoOnpyCl2VmpoqFDc9XcsBl5EmyO7oAVi1
atVHH33UuHHj6tWr33XXXY8++qifnx8v7OVOTh1PX1pwL6h0lx/2XSBd8aSE
XYtLdRlPnp8xY4b+o9nVnigddkz92GOPOY025YAIrOqMYteuXf7+/nQfqjmU
Y5RvnTt3Jp0rFnGz50CnM0bsRazb1OhNnjz5pZdeql+/PrVd995775NPPklt
jhgkZS+I1MDqCEkKxt3jRobsjcA7DtDHQnmWXjppLwFFcvjw4cVe1gEAAEW1
CpTofx9///13cdbIlGYeFZJ6Pb3hBC9/rJ1+uegjwo5epR69XCp4pW406OM7
ffr0I0eOiD18jWRX8UxNHrtXuiTlDUS0TJHZs2fzDaU70Qh4UO/BBx9Uun8p
dcHL0lvmV9YgrhO8XKx9+/YtUpQoS8WFNWvWLEaKtOD1VqS2incHKk3uJ3HT
dWgmhXf34K1CuYLRi6kMz/d3OqWZNWO9evXs1+U1txtruMLDw3mKae3atYcN
G8Ybxaqm1GD+0/sowr/77rvGS+3MmTPiKiMz5HkQWTbE4zSqxWuF9NEKn5OT
w5OWK1as+O2335pMJqWTMadvbkJCwt133+0mgRSZlldtfYoteHk5eVEpxnpJ
zjQhUqgy5P6DUz9d3JpRM8IHeY601m44gsWLF4tgH3/8MR/kCTD6o7RE69at
RUjRNzVu3DjxTyMDryyrlVvOOYU3TqIvmtPARa3bOvAM8DZt2ugEYx8RlStX
Vp0YUAy4X125WTa9ROzA393d3d/fX2e1PgAAGKHkLaf+h55dKBtxWsW7P0jb
/BtO8PKCQafebHg/EWrSpQaq6wSv2Wzm9URDhgzRskhLXfDyYr3XX39dFpiN
3rfeekt5q6ysLFKyIgCJTVmEKQN5npvq7qulLnjZF6uRLQuVuE7wsmNtI0vA
pEgdgqWnp+uE3Lp1a5AD/TV0gj59+oh70h86wWJiYsQ9lT4/e/fuzREzvnUL
7x9UqVIlsrTz8vJ4Rp9yJyN7UZxWsRMYMR5xHV5zu7GGi/sWOnbsqOPPp6hN
PU/R1Pf7Tfol6B/o6UVyWsWrIwcMGFCkqBavFdJHKzwLf2o5o6KitC7Xf3Op
4XrzzTdFgPbt2/O86BEjRhiMnpSHH35YdXk+J0H1LF113QQv93uwxzOr1crT
uZ0OEfLQf6dOnfggzxbT94On2rnKlVnpNVFWTNxciOX2xRO848ePL1J2UeaI
7zI1EVoO26UUtW7rwF5W9HOV54STMNe/4Y4dO7Y5UPVwIoX3rqIikx7fs2cP
9+CRTSidFQMAAMWm5C2n/oc+NTWVH6HvkZJ9wlCbL9335IYTvDxvrX79+vpd
2bycSrY01XWClz0U1axZU2f8pdSnNJNWEkcqVKgg29SGT7kpJAnZzzwvzk3h
zPbSpUs8heyVV15RTU6pC94ePXqIg/oOZygyU6dO/dWBdK8H1wnepKQkcVBn
L11BeHi4iBjZfqJ+8houVb9zgpSUFN6/Un9KoYCXpD300EM6b0Hfvn1FMJk7
KVYZbo6RGuOrHSntvOZr1apVXJNr166tuqkZP8XptkQ8/2TYsGH26/Ka2401
XLy5j87mQdJ22GBOJiQkiPBeXl46Gx7xvpykc4U/MUqmOKK/VSsVB+/XKRu+
dxrV4rVC+miFZ/drU6ZM0bmcHfmqvrkLFiwQZ6tXrx4TEzN58mRuD3VKrag4
TTIJ3tucwe7QKW58kP3oLlq0aI4D/c4xdsEk3XuaK4ZyczoZ7OO9a9eufPDI
kSPiYMOGDbUm39LxBg0aiGDSPWu4+XrjjTd0niv14CdmPfEy8yJNaaarxJFN
mzaJ7Dpz5ozOhaGhoeJCnd0EilTQycnJ4rm8skMValfpqypupbPtAklXbvxV
96KSwkPkTrte33rrLRFSOmSflpZGbbU4/tRTT2FgFwBQWhTVKlDi1EQnU1YE
kLnilMFeT59++mnp8RtO8FKLzR34UnfTMrKysnhm2vfffy895TrByx6KtPZ4
ErC329ISvKQIeCiWjD1pYOk3l0wsUmGRkZGUhwEBAcKG5MwkS2zWrFmZmZkX
LlwgvcaLFsng1xpLKnXBy9tskdGl4y6YRyjc/q3iXSd47ZLNiHX2PyWDkH1y
8raw/fr1E0eaNm2qqgrtkoEAsnyM7F5EYXjISctrDZmULHl69+7Nxzdu3Mj2
FUVSfxcSJTyH+f333+cdQ7QWonIx0RN1duWQ+gkXm4Reh9fcbqzh4mhobeJj
lwiuIjX1bLvqDG9xu81yfujQoeJI48aNdbZM5RpF8ZfF3GlUi9cK6aMVnjs6
tLYSszuEEo9rK9/cS5cuVatWTZwVnQDUHrZt21YcoUzWeumKSjGKWIl+E/Tq
q6+Kszre1y9evCgGcylPqDHn47xT2z333KOzlze1q9x7IB0Lpi8Fe5/T8gzA
m3FTSFkvWceOHcWprVu3aj2axzFZFycmJnLJ6k825jk2FJ6dVlEuiYM6rs6p
GTTYR8Q4LWi6Jw9V6zRr3C1Zv359nQW8EyZMEMHuvvtup32P7Bray8tLZ0bE
zp07RTD66EsHtbmrhGSvU78KAABgnJJ/Ip2a6NyoummvbeHvgptiB9IbTvDa
JbvwVKlSRXUzd/qmv/POO9zgyyb/uE7wZmRkaD1UUFBQ8PPPP3MC27dvX9S0
a4Xp37+/OEgfYpmvXS4dJSSIjh49yvJHCeloqU1VWhll16gzZBXwxHuyjlQ1
75EjR2rVqiXCkNiRjre6VPCyd1NSEKq1jszsb7/9lrOORJA4fuHCBR7WUd0c
iix2Np9k/oV04FVp999/v+oQIU97dpN4czp58iSv3qLCdTotVgmLU8oHFt1a
42iyyqZqoR04cID343j++ef5uKtfc7uxhoun2SudtglIBfDer4Tx4fKFCxeK
S+gFVPUpJ/XCxDNIY2Ji2CcevSOq8w0oXbyuWbmZuNNGptitUDHCc8OlNecz
IiKCl124KfQUtRj8wnbq1Ikz/9SpU+wBT9UXXzEoapJV0W+CeDdqeklVl73T
C8sOvrp37y49tWPHDo7hBx98oCrz6eA333wjwlCljYuLk57lCcYk0JTdOySi
uQNNupGugDshKYyyNaByIeNEtRBZBd95553Utqtm2qFDh7iFlK55lzqLU3VS
QU0EewNo1qyZwa4PIwXN3QuPPvqozGu0YPfu3fwO6myRYJd4IHz//fedxu3E
iRPcRUApUu3ZOHPmDH9Gpbs4UfL50zlt2jQjWQEAAAYp+SfSqYlOX/wXXniB
H/Tmm29SSDFfiP5PXxapa5qXXnpJ1tN4HQRvFQmlkmkk6Ni7EVk1ZNjTF1ak
Ky0tbcWKFfQh4Jv8+uuvsstd6rSKfS22aNFCOj2JPkzr1q2TbVR07733ysbX
im1qxsfHs0nQuXNnmdVNxgZrLqZ169ZCgHCvr4y3335bXxCVuuC1S1aJEmTa
kcwU33Qy7Ok7PmjQoKpVq3IAmY8Ulwpe0rM8m4JMDtIRZJ6RCUFZnZKSQvbe
U089xRF78sknpcbVgAED+NQbb7xBtpC4kEptzpw5Umc7shVVOu/OlStXuMRJ
ME6ZMkX05Ofm5lLEeOzVTSIEKAD7uqlUqVLxdnukmLOrVYHOKlQOI7bRJDOe
1Me5c+foJhTPgwcP9urVi4UJyWep2zRXv+Z2Y40bd2JQbtNDuVjpzaUXXLb3
q5tC+1OTyyUok+10Kx6IJA3bt29fquFUUlTTLly4QFWdl9pRDZG6shk+fDg/
rnnz5qtWrRJnKXOOHTtGWcqKmFoY5YQBp41MsVuhYoTntdvEL7/8wlN5KXMo
N0gFy7rjZDOf2ftutWrVoqOjpafobuIUZaOYNiCFyoLLhcqoJEkoEvpNECWf
twmjiPXv35+qU1ZWFrV+kZGRY8aM4Yk3VLIynUU159lnn5U2nsuXL6c8pIpK
dzh58uTChQulux0p34vs7Gwe5KWXi9siuvP27dv541W3bl3ltBAKww2g2JGH
Lqfn0hckODiYNZ2bYnUDVXWpA6Vu3bqFhYVR40YVgPRsaGgoT3IQpSzbIlZq
3pDMJ9VPrTG9CKTlFy1axMtJ6I2gJBgsIyMFvX//fhaelGlULc+fP08WF+Uh
NWs9evTgevviiy/qdIJRFvFrblCE0kvBMaTaQo+mFpWkfXJy8q5du4YOHco3
pLPS4V328S7eow3GKGZFBwDcYpT8E2nERKdvykMPPSSzu3iWF0OfMOU+m9dB
8ErjUFqZRuaKLIH0fZFKIUGXLl2K4Vu4JDpOOrmRqFGjBlmkbLe7OfrV6bvG
8pMMmFdffZV36DOSdq0wPInRzTGFVfaRJfODBGzt2rVJHJGZPXPmTB4/JfOA
bCEyV8iuJi1DUt3X19fpYqISZpROnWFLlalcubJSsJP5J7vQpYKXIIuaBaOA
bB7lzqGNGzeWOZ6irH7++eelYSg5yk2HKeFaZa1aJUwmE9s2WhlFxhhHRjq7
gGrmk87QmrwtHch203WaymFCQkKkO9gqS5PeX+WCOJe+5nZjjVtERITUYRHJ
EJISDRo0kCaBNCZPm6QSobLmEVuuTqo1KioqiiWGgKS9rEzpyObNm6VXUWKl
HRoCyhaZNqxevbrqW6xTowwGMBjGSHh6NaQqjBLbsGFDymFpJnTo0IGXgRCP
P/74uHHj7I7pClw00q0HBKQ+qO3lS2Sje9J5LwYnJhU1yao4bYK2bt0qrW+q
0MtLaVdeSyqP17boQ6pTdWk8iTXpdAVSTPQ54GFBN0cLozUOe+nSJemXTpXW
rVsrPZxTVjjdf1k8WjlfOjY2VtYmuymaF/qn/mLb4hU0+4rUeq6oePo7DvBU
bTddLwFScnNzeeq7DmRakMKVXsgetouE8XwDANzKlLzRMLhtX0pKCs/uU4Vs
QlV39zeo4CWOHj3KRqYSUhNk3qsunHGp4CWZOXLkSC2LhUREeHg4BZPJH542
bCTtWmEosS+99BKf7dmzp2w7pFLHRYLX7tgsSYwJqkJGnWxmvsDVgtfusK+k
EyqUfPzxx6qLcMlK+frrr5UWkUB0gygHApy+OxRJpb3HPPPMM9JhLy4Lg2gV
K2+i4eYYOlF2oynjb3e4cmWHVzLuv/9+VSfPdle+5k4rIRMcHKxlyVPMV69e
bf/3qKubZKG3vuC1O3pReJNZ1furjkyRWvn+++91lFGbNm1UNZG9nAleglo/
XvkugzTOsGHDSKvymkQBvWXUuPFV1JyqDqIdOHCAu1lkcwDKreC1OyYn161b
V6tkX3nlFdlYthRqoNhhtVaWsj89VSirtZ7eoEEDfae+p0+fbtWqldaju3Xr
lpWVpXphREQE+5pQpW3btlqu+y9fviwd2pbx0EMPFdUJtvGCnjFjhrLfUkAV
r1+/flrpZXi4ltpGnXW+MvLy8ui90Hq0m8MFpdKRV1Hb/5LXdgDArUPJGw2D
gldA3/c+ffq0aNHirrvuIkOU/k+2Yv/+/bW6ZO03suC1OyTehg0bunbt2rhx
49tvv71ChQp16tQh63HUqFE6TvtdKngFUVFR3bt3p280fcXIwGjYsOFnn30W
FBTEVhlZLK+99hppupo1a5Iq4ZnDRtKuE4Y+r9JPf+vWrfXdV5YQ1wleu8Mv
09ixY+kslSmVLIlcShqV9bJly7T8LF0HwWt39Gls3rz5q6++atKkSbVq1apU
qfLoo4++8cYbQ4YMUW5kLIPkG72hFP6OO+6gN7RWrVr0uBEjRmhpRiPvDklp
kldkBpM48vb2rlq16oMPPkj1bePGjTIVUFqClwQIT8NW7oSlGn/xz/j4eHo3
H3/8cUq4KNMXX3xx5syZ+mahi15ze1GcD2RkZNB9OnbsKDKZ/k8ZPnv2bK6K
ZIL6+/vXrl2b6gPZ/Js2bZJVJ/0aZTKZPv30U2ooxMpoyhmSLXPnzqXC1YkV
mfoktKkBEe8ItSdUJz///PPAwECdWZROa1QJW6FihKcinj9/PjWJVMSUvVS7
nnrqqZEjR0rLl+oJ5U/FihVJwlDLQHpf3JAyXMd7D68RptueOnVKWfRGSl/A
TpUNJlkVgx/07Oxsql0ffPABiXp6o+k78thjj5E4Ir3pdJE4Bdi/f//AgQPb
tGnzwAMPUISpUtEf9KpOmjRJx58Vk56ePn36dHrFRL2i/1O0Kf+NbI9eUFCw
YsUKag/r169Pj6aGrnnz5tToUdPnNNrbt2+nNFJKKb2enp6casor/VRT/QkO
DqaaT9WGzB6qEk2bNu3cuTO1G8Xo9S1S3aYqSu8g5S09kdJLefXkk0/+8ssv
+rtmMOxzT3XfQH3IbJgyZUqnTp0aNGhA4le0/N26daPGRDW72CN6kShqrAAA
AIDrANkqUs1Lqoq0j/G9OYy73AG3LGSN87I7LVdOAAAAAAAAAOAKzGbzjz/+
KF0y6ebwLDRgwICQkJCzZ88Ktx55eXlxcXGnTp0KDg4eMWLEO++8U79+/b59
+5Z19EF5h33J3nnnnTq7RwEAAAAAAACAi9i9e7fOqiiZHGaqVq2qs98oAARP
IfDx8SnruAAAAAAAAABuUWw2286dO1977TXepkSfOnXqdO3a9dy5c2UdcVB+
OXbsGFcYmRdQAAAAAAAAALj+ZGRkBAUF9erVq0OHDs2aNatVq5bwmNS8efP/
/e9/n3766bhx444fP44FvECV7Ozs2NhYq9V66tQp9pncrl07VBgAAAAAAAAA
ADc0Bw8eVM4HCA0NLet4AQAAAAAAAAAAJUIpeMePH1/WkQIAAAAAAAAAAEpK
dHT0k08+WalSpVq1ar388stbtmwp6xgBAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyjUXL150KxlJSUllnQgA
AAAAAAAAAEAOBC8AAAAAAAAAgJsSCF4AAAAAAAAAADclZrP5ijasanXCWCyW
sk4EAAAAAAAAAABQNFjwlnVEAAAAAAAAAACA0gSCFwAAAAAAAADATQkELwAA
AAAAAACAmxIIXgAAAAAAAAAANyXFELxWqzUgIODzzz9v2rRp9erVvb2977//
/g4dOowePTomJkbnwp9++okfR3+XUYqtVpvNYhVYkrPyDl5KWX3k6ujQSP9l
x96e9lebEdvrDQ6r2W+jh1+Qm2+Qm5/Lf/SgoOPxVpu6Z7CMPPNHsw56+1Nk
Aq9DZCr3DK7zXejDP23rOG7PZ7MPDlp3euau6E2nE87Gp+fmmy1WG2Wa2Wqz
22wlLIbMXPP932/Wj8xbsw4V9zlUxBYqZZuV/mcpsFhiUrMOXUqhfJ6+4+LQ
P850Xxj+9tS/2o3a0Xho2N0DQr39A918TS7MWN8gv5UncvPzKePKqNoDAAAA
AABwK1JUwXvs2LHWrVtrbWBUqVKlYcOGkZJUvbY8CF4SUNn5BWfi05cfiO62
OLzVrzsf6L+xSs9gT1+Tt6+poq+pgm+QJ/18Atx9XSyCyqXgpSR7+AZ5+QZ6
+wbd5hfkVfgLvrN3cOMhmzpO3D00MGLrmcSYlAySkyUsCBcKXhtdZEvPzY1M
SA88fnXwhpOvTNvX7Oft9w8Iub1XsGdhigK9/Sh1hWXtVVjcge6FPRsQvAAA
AAAAANxsFEnw7tq16/bbb5cqXA8PjypVqshk7/vvv6+6k9H1F7w2x8/ukBkk
g/LMlu3nkr9ZdvyB7zeT8HHzKRQjnv7/qBKfwMIhXd+/dd/1UJflUPA61Jnj
F/h3hvgFufubPPxMharQJ7Bir+DWY3YODzkblZJdOOJbqC6t9qLruFIUvIX6
tvA/m2Ps3pKQkbd4f8z7cw7R/T39g926B1Aq3P2DPPxN7tIESovb9VkKwQsA
AAAAAMD1x7jgTUpKqlOnjgjs5eXVo0eP8PBwIWyvXbu2cuXKZs2a8d1Gjx6t
vMPIkSOr/AP9fX0SaCvUQdbs/PyQE3FvzTxQs3eIp48Y0Ssvv3IneA38bvMN
ajAodMC6U6fj0vMKLMXQcaU6wltYxHkFBcdi0gatO9Hkpy1VSaRfxy4LCF4A
AAAAAADKJ8YFr7+/vwhZuXLlbdu2KQPk5+e/++67Ioy3t3d8fHxZJ64Qq812
Ki7t62VHa/Xb6O4b6OFLUijI3a8ciccbUfBSHnr4Bnj5mZr8tHXilvNpuQW2
Ik4+LkXBS2o3ISN/8B+nHxy6xctRvp5+/wzmlpMfBC8AAAAAAABlgUHBm56e
zlOXZ82apRUsOzu7YcOGItjPP/9ctkkjHZRvsWyMSGg5fJt7eVKLN4Hg/f/I
+wZW9g/+YNbBswkZZo2126qUiuC12q1mq2VvVEr7cXs9XboIF4IXAAAAAACA
GxCDgjcgIEAEq1u3rur6XIbksAj5xBNPlGG6SChl5uaP23y+0AevWH9a5qrn
JhS8hZPD3R2un1qO2rnjTLzFalTQlVzwknjMKShYfiC6/g9hXuVs1B6CFwAA
AADllqSkpIMHD+7atSs6OlrfsDeIzWaLjIzcvXv3tm3b6I/8/PyyTiIA/49B
wTtw4EAR7JtvvtEPeeXKFV7nm5OTc90TZBOaIjvf8tum81X7/unuZ8gxkfv/
T4U1efsFVe4RVL1PyJ0DNtYaGFpr4Ma7B4bePXCTi361B4aGRiRZrcUUvIV6
0z+o5oCSxrDmdxvv6PtntV4hFf1NlA8ejt//e3nS1rwiAOVbox+2bjub5Gg2
ncu6kgjev52Q2W1hpxPuHbTpnxianBVxoTwX6SKBXMnfVK1n8B39/nRkXWHu
1Rm8+f4hmylWrvgNCTyTV5BX4t2cAAAAAHDDULduXW9jnD17lq9av369aphK
lSqJnUDHjBmTmJio+sS8vDwR2M/PT3k2KiqKLPmqVatKnc16enq2aNFi6tSp
ZrO5GGncu3fvhx9+KPNq6+7u3qhRo3HjxmVkZLgobwMDA0VKDYaPj48X4YcP
H64TLC0tTQT7/vvvXRRzcP0xKHipJotgY8eO1Q9ptVpvu+02Efj8+fPXOTm2
Qv9FhbvsTt9xqaJ/sPGZzBW6B1buFfT4L1u7LTo6fvO5NYcv745MPhGTFpWc
E5WcfSk5y3W/i8nZ2QVmm019PrBTwUvyrenQsN0XUkoWjeyzcRkHL6ZuOhU3
b0/04D9OvzH9r0ZDwrwLd2gykIf/xK3pz9uORKcZkXUlErwOf8xXrmU/PmK7
l2HnVKR2K/Uwtfpl20fzj4z489yivy6Gno47dDE1Ii79oiMHEjJy03IKXPPL
z823YHQXAAAAuKW4++673YwRERHBV61Zs8ZpeBKtM2bMUD4xNzdXa4iK5Cdp
W3G2Tp067dq1a9++fYMGDfhgq1atkpKSjKeuoKDgiy++kApn0uNNmjSpXLky
HyQhvGjRIlfk7YYNG4xvNEPExcWJ8D/++KNOsGvXrolg3333nSuiDcoEg4K3
U6dOIti6deuc3vPhhx8WgQ8cOHDdE2TLN1vXHI6pPWiTh7FNZzz8ghr9tKXv
mlM7zyVevZaTV2ARu9uQahab7tiuDxrpcSp4Pf1Mj/645UJSZgmfb3W4szZb
HSm32TJy8s8nZK47HNt59qFa34W6GxO8nr6mDuN2xaXlOh3kLYngpQjm5OX3
X3+6QuFwrQGp6xdUre+fn8w/vOVMUsy1rJx8c2F6GUfSrTYxN8BFotTm6NBw
3f0BAAAAUO4QgvfFF1+84gzp6CoL3tWrV0vDREZGbtu2bdCgQdWrV9fSblqC
Nzg4WBxv2bLlzp07paeuXr3ap08fcbZjx44Gk5aXl/fqq6+Kqx599NGVK1dK
B3Ojo6MHDx7Mw76u0LwQvMA4rhC8LVq0EIH37t17nZNDmiUyMfPhn7c6k7om
D1+Tp1/gnX039lxz8nhMalGdDF83DAjeoEd/3BqVlOmS/LTZc/Pzt55JeHfO
wYo9TZ4GpKWXTwBJ0Zz8AqtNT9+VTPDazidm3D9ks1Op64iSqUbf4MlbI0nn
lnVhAgAAAOAWQgjeN954o0hXseBV3RWFSExMbNOmjQizefNm6SktwfvMM8+I
gd2UlBTVe5KOLpL13rt3bxG+e/fuWquAjx8/LnKgUqVKpDdLN28heIFxDAre
Ll26GJzSTMqR/TlL1yNcH3ILzN8uPerVPUh/RFIs1205fEfgsVgSdEVyL3yd
KVvBa3c4uzZbbek5BfP3Xq4rFsw6WSdruqt/6LrwywVmi8sEr2XRvmij89V9
Ar9ccrTQYVR57dMAAAAAwE2JiwSv3bEitUaNGhTm8ccflx5XFbxkAlWoUIEO
du3aVeuGSUlJ4sIRI0Y4jeHRo0c9PDwo8FtvvaUf8o8//hC31V8Sm52dHR0d
nZ6eLjteUFAQGxubnJysvEQpeLOysugmWquGIXhvZQwKXip0rRUBMqhaipDu
7u6uW6iuREzK3XQ6sU7/jZ46fpYKVVKhKGv3284TselWW/mVuoIyF7zSHN50
KrHFL9u8nGvMoE5T9qXl5OpozJIIXovN6r/ymJuRxcWO39L9V8p/QQMAAADg
JsN1gpcg4SaCHT58mA+qCl6LxeLl5UUH33vvPZ0bTpgwYfjw4aGhoU5jSMKZ
7ubt7X316lX9kFar9YsvvujcubNUZubk5LR3kJKSsmfPHjH6zOuIxYzrmJiY
Tz75hJcD33nnnYMHD5a6w5UK3tWrV//nP//hmzz00EMTJ04ksSyNCQTvrYxB
wcv9M/Xr19f3Xj537lwRkire9UyIYxQy9/Xp+4W/ZS3B6+FjcvcNeGzE9uMx
qRbLDTDHtfwIXrvDW9Tu8yn3Ddqkv82Tu5+pkl9g0Imrdm2ZWRLBa7bZXpq2
3+g+Tb5BS/+K1tr1CQAAAADARbhU8IaHh4tgJFT5oNaU5ubNm4vRKDLUSzjn
jYTkHXfcQXcjGVu8O2RmZopITpkyxcPDg1Rt27ZtmzZtKg5WqFBhwYIFIusa
NWpEp3ju6Ndff803YcE7bNgw8UfFihWrVavG0ua///1vVlYWh4fgvZUxKHjT
0tK4j4XeFK1gVK+oZhqZulDqWK3WXedTqvQ2iYm1mi6qfE21+4fujEym8PYb
YY5ruRK8RIHVPG/PpWr9QvS3AaJYfTz3UHa+5qzmkgjeAovlvxP3GfFIVvjr
HvDN0mNmi/kGKGwAAAAA3ES4VPCScS6Cffrpp3xQS/CuXbuWbf4mTZoMGjRo
69atFLgYiWKhPXv27OJlCwteEuDdunVjWbp69WqO5L333rt7925xPCEhoVWr
ViJ8dna2OMiCl6hXr9727dvN5kKvpCdPniSpK45/9dVX/FAI3lsZg4KX8PX1
FSGrVKkic+8myMvLe+edd7hzJjY29nomxGy19l170sPZNNcKfkGD158qz4t2
ZZQzwWuz2CxpOXkfLTjk2b1wZrjWoKqXf1CTwZuPxaTZNFxXlUzwWp+fvM/g
CK+7b1C9gZs3n07MN1tsmNgMAAAAgOuFELxiEFOHTp06Sa8yKHgJ4a755Zdf
5iM62xItWbJEtlsumetPP/30kCFDNm3aRGa8wUSZTCZxucxfliAlJWWfBvwI
Frxt27a1/tsmb9++vWra2cs0yW1xhAUvZQIpYmlgi8XSsWNHIZAvXrwoDrLg
9fLy0i8OCN6bD+OCl+rSPffcwy9Inz59jh8/LmppWlraihUrmjVrxnf79ddf
lXcYOXJklX+gv0s3IZdTs54Yud3Dz8murM1/2X4mPs1qvWGG+8qZ4CXtWriB
z+HoazV7h3ho74Hr7tggeMbOS9TmWG2lLHip+LotOurmY2yEt9BBWVDTH7es
OHglp6DAho2BAAAAAHBdMLgPL6k86VXGBW+DBg0oWIcOHfiIjuC1OxbPrly5
8pNPPqlbt64sDnfeeae/v39qaqrTRC1atEhcourPWWcTYdaeLHinTZsmu/zL
L7+k4/fdd5/s+Pnz58UlJJzFERa8v/zyizIaBw8eFGd5vjcLXoNA8N5MGBe8
xM6dO6Vz490ce0xXrVpVVkO6dOmius73p59+4jD0d+kmZMuZxFr9Qjy0VY97
4bBj8OANp/PNN9Ls1vImeAVZ+QXvzTrg6WxS8duzD2Tn51rUxtOLLXjpgMVq
mbEjyulovuxXve+fb83cv/pw7Jm4zLScXMvfu/CSILf+vROx1WYp3IbY9vcG
zAAAAAAAJUAI3ueffz5Sl5iYGOlVBgUv2Sre3t4U7O233+aD+oJXSnR09JIl
S7766qsHHniA7fN69epRfPQvZMc+QUFByrMhISF1/02dOnW0BC8Fll1O0abj
zz77rOw4XasleEnbqsazdu3adPbjjz8W/2TB6+Pjo1MWR44cgeC9+SiS4LU7
/JBL3aDJqFSp0s8//2zVmDDsUsE7ZWuUl5+mKvQgwesTVK1vyNEr1wr1142j
Zsqn4CVFOHdfdKWewfoas/Gwrem5+fbSHuElwXs2PuM+Y/vwSuY2myr4BHr3
MDX+fnOnyXv9Vh6bsOX86gOXt51LiojPTMjIS87MTcnMSs/KysnLM1sw+RkA
AAAAJcKla3hJJotg/v7+fNC44JWyf//+5557TnW4WQkPno4ZM8bIzY8fP64l
eP/8809ZYCF4lXHQEbxao9LC+fOLL74o/smCd8iQITqxxRrem5KiCl67wz0U
1bGuXbs2btz49ttvr1ChQp06dahmjho1Sn/drksF77eLjlb0DXDz0ZpkG1jB
N7Dd6F2nrmZcSM6OKmc/HedO5VPwWiy2A1GJdQeH6mvMO/v/efxKurVUR3jt
DrmdZ84fuTGyUo8gD7+ijPP6iC2YC92aefgGefkGevsFVuwZXK1vSO1Bmx75
ZdvT43a9+ft+31XHR/wZOX/f5cDj8Xujrp1JyLqalksFYaZ0FK4CtjoKS/yf
ImgrHBMujJfNfgP1pAAAAADAxbhU8G7cuFEEW758OR9UFbyHDx8m013/bmSt
vfDCC+Lay5cv64Q0m81iwqd0KrUOvPzWRYKXJKrqc8Uy3ldffVX8E4IX3AQ8
8+uOCj6B2tvvFg7yVu8V/OCgTY3L2a/J4E1bTidYrer75pRPwWuz2eLTc1uP
3qUvMKv0CAoIj7GoJa0kgleQnmt+f84BT19TEQRvUX5e/kHVe5ju7R3SqN/G
h77f0mLkjg4T9nww93CvVSd+DT4zZ+eloOPxBy5dOxOXGZOSmZGXZ7Zac81m
u9UC0QsAAAAAu4sF77vvvkthbrvttqSkJD6oKnj79u1LRygy+s/lxblbt27V
D9mlSxcR8tixY06T8+2337pU8B46dEj1uffdd5+bxFEzBC+4Cbjnu1Axb1ln
Da+HQ8WUt593j6DgE/Fa88DLqeC1280W26vTD+hrxtsK/VZFlfoIL3MlNfft
WQcq9HCJ5hUVpoJ/4a9wUNgvkIrAwyfQ89sAz28C3H0C3f2CKvcOeWDI5jYj
t78z+/DQoDNrj1y5mpaTbzZbsQQYAAAAuOVxneANDAwUYb788kvpcVXBO3Pm
TP3lrgJSgiLY2bNn9WPIs5TbtWtXUFCgE/LUqVMVKlRwqeAdNWqUTgznzZsn
jkDwgpsAd3+XDPNdhx+pqqDj8VbbDTXCay/07/TJwiP6SavgGzRq4znVzYBK
LngLJxBbLUmZuYM3nKrVf6O7T5Cno1ujDArR8VDPHqZKvUPqDtn8+fwjKw7F
XE7JItlrdfyHmc4AAADALYgrBK/ZbJ42bZpwV1W7du3k5GTpWVXBm5SUJCYh
N2/eXGvF66VLl4R3qUcffdRIJPv06SMe9NZbb5GAVQ1D+rpevXq8ntFFgrdG
jRqyRFmt1k6dOtGpypUr84RnCF5wE1DmuvWWErx2xx5nXy4J108aKdDvA86o
7gFVKiO8Nofyzswv2BSR8Mb0/bV6hxSOwxZpVW9p/zx9Tbf5BlXuGdJy+LZf
gs+eic8o3P/XDhdYAAAAwC2HELxNmjT50RkkcvkqFryfffaZNEz//v27dOnC
Wx3RH4cPH5Y9Uctp1ZQpU8Tx+vXrz5o169ixY1lZWXaHNoyJiSEFLZSpu7u7
0/nMAtLdr732mrgn6e4xY8ZERESITS5IX2/fvv3zzz8XZ3v06OFSwUs0btz4
wIED4ukXLlx48cUXxfHhw4fzHSB4wU2Auxjdc9mKTgheKYU602L5YqkRwRth
c5ngtf/tKKpwF6Fcs3Xb2aQP5x+uNTDU0zew0C2Vn8n97xFY7cXdrhnwdWxD
HOTmE9jox60zd13Myhf7/2KgFwAAALiFMLgPL9G5c2e+SmcrWwHJ0o8//vjK
lSvKJ+p4aSbNW7FiRel9qlev7uHhwf+sVq2a1P+VU8gUHDhwoJeXF9/B09Pz
9ttv53/WrFlz6dKlFPKRRx5xkeB9/PHH33//fXHqjjvukGb4hx9+KN0mFYIX
3AR4kNS9AdXuDSt47VaL5bNFh50IXr+g7wNdK3ilWG3W9JzccwnpM3ZceG/O
oWY/hlXvHVLB1+TtE+jhW0bDvr5BVf1NXecdOZ+UZbaaoXkBAACAW4cBAwZ8
Y4y5c+fyVUeOHFEN4+vrO2zYsCVLliQmJmo90Ww2i8DLli1Tno2JiaEoNW/e
XCp777zzztatW0+dOlVrZrI+Fy5c6NWrV6NGjaT3bNmy5fDhw3k6MWntV155
JSEhQfwzLy9PRPLUqVOyu1G06fj48eNlx5OTk8UlUVFR4sjRo0fpn2PGjLFa
rZMmTWrQoAE/vUWLFosWLbL924hMT08XdwgICNBJTk5OjghGgtqFNQOAYnFX
v2BPH0MCpLz9PHxvPMFLws1ssb40fb9+bnv5mX4yqfs9cIXgpZaNGj36v8Vm
zSkwn0/M3BSRMGHzha7zDj/yy7ZaA0Or9v3ztl7BHv6mf9UEyRPdHb/SFbwe
foFevkHPjN99Oj4Dq3kBAAAAUObk5+fHxsZGRkaKic2lQnZ2NqnR6Oho0rNl
kqikpKRz586RsC2TpwNwHWjxyzYvnwCdmavuvqaaA0LrD9lc/n5hYWeSbjAv
zTZrfHpOq1936Ms9bz/TpG3nbWqq1RWCVyOqNovVlpNviYhLX3ckeuq2C0MC
Iz5bFP7SlP1tRu1o/EPY3QM2Vepl8vAzefoEen4T4PltoEf3gL937PU3VSh0
o21yOGo2OabNF3MWAd3/1cn7Yq7lFLrwgg9nAAAAAAAAQFH44PcDt/kEupFU
0RhoI8Hyc/CZi0k50Snl63cpJTu7oMCqoYHKp+C1Wm1/RSU9MGiTvsqr7B+8
7shlF+3DWyRI9hZYLDkFZjPFhvRvQUFqVnZcWtbl1KzziVnhMRmbIxJW7r8y
ZcuFoQGnv1527I2ZB56dsOfxkdubDw1r1H/jPX1CKvUIJrXrXsyp0YVzqiv6
B3dffiw7n8oaPqwAAAAAAAAARWDoH6e9C5fxaugRn8DbfIO+XRyea7bYHCOO
5ehXqOk0dV05Fbw227y90ZV6OhnuvKPfxmOX06yu2ZaoiNhk/3DsGSQdfJaW
iV0MCidl5ken5ByPzdh5PnnD0bip2y92X368w6TdDwwNq9Ir2NOvcFzYManA
yLBvoeOs2/uE7IpMgeAFAAAAAAAAFImlB2Iq9gjWXIDpG+jhY2o4dHNCZs6N
JTbKp+DNzs//aM5BDx8nw51Nf96WkZuvKuevu+AtKbZCFWzNyc/JzMlNzMjd
eCqu39rjD/+0xatw2NfwxGZfU9eF4Tm6W7QDAAAAAAAAgIzD0akNB27y9Nca
awskVeLdwzR/z8V8843kLLd8Ct7jsWl39dvoVOh9OP9ITn6uxVoeRnhLis2B
xWa12qy2wm3rrPkWy7nEzCEBEdX7BBsVvP6mh38IOxVnyJ0CPcKii63c5I7Z
YnYaGWnMlSvWC/PWYrGXM8T2W5JouyrDRfJviLIGAAAAAABlQkpWXseJe/Ql
mLtf0CtT/0rKyL2BrMdyJngLPS7lm8191p6s0N3koZvVt/kHL90fQ5rNWqZO
q1xNnsUyLPiMd0+jmrdaL1PIiQTnGW2zHT58OMgUFGQy0S8wMIj+CjIF8y84
5M+wLVuOhIcnp6RYrGUmiOi5Z8+e/SMwgGJi1Y5DTk7ulq3bKNqBQSb67d37
l+wmERFnAwICjx8/WVBQUFZpIRluNv+/cqc/MjIzQjdvcsQ5OCDQdOz4SeEG
vNTz8Nq1ayZRso78CZSUNR03BYdsDgs7cPBg7NWrheLX6ipv3xQTs0Nfuzin
AQAAAABAkSGbf+SfZzydjTlW7RU8f88la/nXUf9QzgSvPd9iCToWW3tQaKH7
Ji2Xxb6BXv6mlsO2nU/KcqxXvYkFr63AbI1MSGs1eochwVu4S1HQrF3RTtNF
0mP//v1r1q2dPXfOr6PH/Dp67PQZvy9dtmKZ47d02fLZc+aO/W3cqF/HTJk6
/ciRIwVlNE06MzOTYjJm7LjJU6YlJiZpicFCwbtl2x8BgRMnTaE4L1u+UprS
3NxcSh0dnzZ9xtWrV7U8lruaw0fCSWlmZGZxxDIyM0nwrlyzdsy48SN/HbMx
dLMrBlvphikpKWvXrV+2fMXY38ZTWf82bsLiJUu5rBcvXjp16nSqBuMnTArZ
uDErK8tFfQLZOTkhf4bu3bff1VkNAAAAAACKCgmr47FpNQdsdOwdo7m21MM3
8MEfwiLiM//xXFXeKUeC11ZomV9Ny2k/bg/LN6189vQN6rfulNli1crkm0Xw
ikExa5f5h40JXpOXb+DY0HNGulxIW5GMvRITI0TQ5s1hJAzzHNAfGRkZp0+f
njx1KunE6dNnxsXFFVUE2SQUO/kUobXrNvw2fuKixUsyM9X38uOnUIpI844Y
+SspO2kAs9m8avVaUnl0PDU1VV/wGomwarp0rhJxW7167bTpM1OvpcpOXUtL
mzN33iiJ4DWeb8aD5efnp6enL1+xksp6xsxZKSmpef+Qk5OTlJS04Y+A0WN+
G/Xr6J27dhXjWeKUfpjk5JRJk6fSg5xGGAAAAAAAXGcsVmtWbm63RUdJarlr
e80lOezlE9Bx4t6o5Cwycss61s4pL4K30Eq2JaRnd1twxNvZMLq7X9Bd/UKO
xabrdCncNIKXpGue2dJ5nkHBG+jla5oQdsH4HIO09Ixx4yeSCNq6dZtMqpAw
3LJ1KwkxOnvkSLiqkNESOLxotORzdLOzcy5ciEpLT1cVqoUdAmYzD4yGbtrs
ELwrlTeJirqYnpGhHxkx61h/mJVOiWDSpIn0al1Fpy5GX5o6bfqMmb+T4pad
zczMXLBwkVTwaq1EVsbW+ArcwlXh+fmBQSYqzZm/z87K+lfvAd0hPj6B9DhF
Y/6ChVqLoLViJaqBTnzE2b/2Hxw5avQffwQ6jS0AAAAAALjOFA4/2m37olLr
D9zoqTf4WLg7DIniZ8fvOR2XUcLhretAORC8Dq1rs11Jzeo899BtPUzufiZ3
PVkX6OFn6rn6RG6BWSdrbwrBa3NMabbsu5DY4MctBgWvt59p2cErBpNF2Z6e
njl+wiRVwUv/PHQknE6RCNq7d19iYuLVq3GO39Vr166R2ktPzzh58lT40aNS
Eee4Z3pExJkdO3du3hy2a/fuc5GRLK8Kp9emptJNYukuf98tLikpmdRQRkYG
H3EcTEr454mxsVfpnzZF5FOvpYaHH6WY07MiI8/n5eWR4B0+YhQLXkpQYmKS
eFxMbKx4kLg2OSWFn0VhSMAmJiUdOHgwbMuW7Tt2nD17Ljc3T5ljWdnZ5y9c
2L1nDyVtz9699HdOTi5dS2nctn37kfDw3LxceSRTrx09dnzW7Nmjx4wlzUt3
jouLp19BgVmEIcG7cNFiIXiFMN+5c9eWrVv37dtHCVf1ZFVQUBAbG3vggCO2
23ecPh1BJaI/q0QI3iBNwWtNvXZt9py5FI158xfIVG16RsbZc+coW8LCwv7a
v/9SdDRltezmVD2OhB/dtm07FcfRY8eSkpMpDOUPpY4iRgnZsWPHxEmTSfCu
WLn6alwc/SjDXfLeAAAAAACA4lJgsQxYd8rTJ8Bdd2tUd99AL7+glsO3rTx4
JSsvj+xhu+scwZSMshW8lCeUpdn5BXuiUl6avNfLz4lrJnffAE+fwObDtx2/
klJgs97EI7y2wspmLbCYz8alPT95n8Gdidz9g+r037TrQorxB6WlZ/49wrtt
uxiy5NE6qrebNoeJEd6Dhw6tXLlq2vSZEyZOnjBhUkjIxrNnIxcsXDx9xu+j
x/y2YNHiVIfgIiFGCnTu3Hljfxs/ddqMufMWTJk6fey4CYsWLSZJKIb/goP/
nDR5Kqls+tHdKNjqNWuzs7NJ302fPnPipCl0kAKsXLVmydLl4okUcvnKldJh
a4reiRMnfp81m+JGERg3YSKl4o+AwHXrNkhHeM0W69JlK+gR4iarVq8hoSek
HwWe5ngcHV+yZClp1WkzppMiE/Kf4r9+Q0Bm5v+vZqWrSKJTlH4bP3He/IVr
166fNXvub+MnULaQUJ2/YNHvs+ZQXu0/eFAaScrDLVu2UtzGjC1cEE1RnUwp
nj6T8i0hIfHvuuoY4aWHrlv/B/0cyZ9CEaDAlA9HjoT/e8y00APVhj/+oKjS
2YWLlhRGY9x40rCHDx8pbGo0kAnetLR0swMqMovDk1RERMSEiZMokqGbNvFV
hcfPRMydN58eMWv2nEWLl06ZOm38hImr16xJSEgQsaI7h4cfo0wePfa3yVMK
x7HHT5w8Y+asgIAgSjWJcXrukiXLxo2fQCkSeUuh6EeZWdbvGQAAgJKSk5Mj
60SVnqJvXFlHUB36hFHc6AtV1hEBoBxiu3Itt9Uo5x6EPBzug6r1Cv5o/uFN
p+Icw5HlcYfeMha8NvvJ2GvfrT9d+7tQL99Ap7LO09dUrUfw6kMxVqvFatfL
zxtd8JK4u5iYOWHL+SbDtrgbkLp/1zo/03PjdyWm5xh/EAvezZvD6MOU+w8p
KSmHDh0mBUSnSMvEXo0jnRUXn7Bixcpfx4wlqUJi9kj4sT83biKJNH7ipKiL
F0n4HDocPnrsONKf27ZvT0tLI7lEV23cGDrmt/GkSc9GnnOM/2acizw3bfp0
UkOz58yLjr6cXjhd2UKfS1KUpE8pPn/tP3jNQTw9ceVqEkqLliyRDkBHXYwa
P2ECPWvFylVnz567Ghd//PjJ32fPJTE1ctRoyQiv7Z+brKKELF22XAheehnp
oZScNWvXUzTGTZy4YNHC48ePJyYlxickhIZuooP00EOHD/OIcGpq6px58+gg
CXbKKEoafSjXrtswavRY0sgxsXEUc9LaYVu3Sqq3zRGBtCsxsZs2h4mcLIyt
A/YDJgQv3ZkiHxhkir58OSU19VxkJIloOkjCkB7Nac/Mylq+YgUVwfIVKxOS
Ekmx5uXlHTx0iEQoZXv40aNaU0qkU5pJcUdEnLn4D5GRkfv++ouUKj1u1eq1
VHB8FZUUFQeV7+49u7MdqU5KTl6zdu2vY36bO28e5SEdobRMmVZYmnv3/fV/
7N0HeE3n4wfwBEGQULtUiVYp2lLUj1LaKpVSHapqtEapWaOo0epQe4QYtUfs
LTGSiNg7YkRkJ0SWBAkiRJb/N/fl/Z+eu86NSFS/nydPnnvPec973vuec+89
33vWzaREFEMf4vVO161XCLxZmVkJCQnR0dHLlq/U7eHdKHoAA/P7fUZERE/q
zTffLFCggMFRb7/9tpWVVX430LC4uDi0bezYsXkzuzt37syaNatXr16dOnX6
+eefL1y4kN8dQGRCVlpGprv/tarj9hXIvnqV+bNN8Vd6pEcb5xNLDl8+czUp
7ta9+2nZ5/aavTNmbknPTMvCRruRZGc28BYasLPur/sjEpKfqA0Z6emZGbqT
HpFUs5LupobE39l1MWHA2gsO47xsBu0yE+Wys7AbetL2x13Dt1xKSU03u5xy
JfBmZol9X09puWSfBZp9D5isLHGi7s27qZdvJJ++kuRyMur7Vede+dW78I+m
rtylOqgAJQsP3Ol88HKGJVchloF3ltOchYsWyz9kIgQopJiFi5bgY1nsZExL
S9/j7jFpylRxkDMGHj16bPZs59Vr1yUmJSUkXP974WKMQgxUXtUZ8dll9VpM
hQSHtCt2H2NCVO402zkmJla8s7IPi71+AzUgECF4y8n37duPlLTKZbXcn5h8
N3n9hg3ibFNkLlEsIyMzNDRsjvNc1VWaxXsNlWD46jVrReB9tHwzMw8dOpy9
z3HGDAR2GRURUdEMpD9XN7eMx6chn7/gh5KI7VeuXJE1h4WHi12WlwICz507
5+rqeu3aNQMrUvbpq6dRoelzeNFLiNKyzZcCAqZNz87dkVej5G73kydPib3n
0TExomH4j8y7Y4crWrJ02QpZg34bsvfw7tr9aEez8zznufN1f/Nmz5mLOjF8
1eo1gUFB4uducXXrlS6r0fluO3djoJwd8izWFszumG4d8PPzm4HMP2du3LVr
GY8vuoUVYJ+3N2aEnpFtWL1m3V8TJ/OiVUREz5NnJ/C+9957aIzGwpYGXosq
V4mIiKhQoQJ6qV69eo6OjmXKlMGsnZyc8qxniCyl2+LLWn0quuSwXQW0hRGr
gW4F+7sWHuBafoRHk8lHvl7qO8Y10Mk7bOWJy2tOXXnaf2tPXYlOvG9s/7L5
PbwDdr08eq+zd8gTNmP1qcjFh8OneAT1Xe/XZvaJ18Z52Q7eXag/+hBh1lzg
zQ50u4oM3Nl9+Zn4WymZGvaV50rgDY677XLiaS2X7A45Eu68P2zC7uAfN/t/
vexMK6cTb47fV/on90IDdtr0y37JGo9kfvzTxK4PnY4n3Lln8KxPY2TgXblq
9f6DBw8o/hBpAwICb95MFBU+DryeSEaISyK4IQfFxMTcun0bY8+dO4+Ag7+A
wKB/vmWyTpw8jamQqkJCQsXAGzduIlMj83p4eMqU5HPGFy256H9JuZvS2/uA
LvCukdcBjomNmenkhBmdOnVaedmo9PT0DRs36/bwrlc14MDBw2jAmjXrlIEX
w48dO445Ll6yJFkxHJkRvYH6t2zZKgIvoAbU7DTH+Vr8/0fahOvXp8/IPlL3
zJmz8oBw/U7GKPSA2cDr7rE3Q3H0MjL49Bkz0UWXr1yVl6FevXpN9jHkK10i
LkdGRcfIPyR6vBAUzj7Z2Ugb5B5e5NwLF/yCg0PEX1BQ8Bnfs+KwaszRc69X
9mHO6elhYWEItoioR4+dkDOKjo4Nj7i8aPFSFEb/IGuHh4eL/Lt4yTIPz71+
fhfj4xMQlpOSkg4dOiKP3H7IwEtE9Dx6dgJv06ZNa9eurbGwpYHXospV2rVr
V6RIkQMHDoind+7cQacVLFjQ4I/kRM+ALHH1qgfpWcuPRZYe4Wk9UNs+ON0O
OOuBbgV0ezMLItEM2Fl4wM4iA9ye9p/tALddF+MyMw3vFTUbeK0GZQfSXGkq
Kimku6lTAd3Bt9k5d0B275nfUT5gp+2gXd2X+yYkp2o8FTo3Am/mgv0RRX/Y
8fQWTWHdaoA+KaCL/I+6RaxRup3aVhp+CtCtXajErd6fB89H3bL0Mmki8CJt
7d9/MPOfVDfHUQZehKOUeylyuNjx5+2dvRfVabZzdEyMqhGhYREiC/v4nHm8
ozYLwQoREhlQXHAJcQwxc/GSpar7wHrrBd6AwMDs9DxjVmhYmOrlHDh46M8J
E/X38JoOvEuXL/9n4L2PlohAJ67GDD6+CONT0VcREZcfPr4LT0hIyCTdHt7Q
0FAT/a4x8KruwxtxOWKaIvA+zL5WVTpqyA62U6dnH2msOw9a/OH5lKnTpk6f
HqPX+bIN4hxeNMPgVZp1Ny3KPlgac/S76I+WnDt3DtWK+/Yq56U7JRlLM/uw
atSTlpbmtc97xoxZWEz4yz5aYNZsLMc97h5XrkSmZ2TItywDLxHR88eiwOvh
4TFy5MiOHTt+++2306ZNi4+Pl6MOHjzo5OSEbx85BF9MGOKjuzgGvj3xGN+2
QUFBkydP7ty5M7LqyZMnRclbt25hbLVq1SpUqIAHp05l3/B9/vz5R48exSzm
zp3brVu3oUOHurr+/xeQfuDF1zFK/vDDD1988UW/fv22bdsmGmOwcidDMDuD
/VCiRIlmzZoph0yfPh1zd3d3z++lR2QKNvBTUh+sPnX11XHeNoO0HneaL3+I
UTv9rmUauUeS+cCbr3/W2Ze83mU/ZNfgjRcT7tzTfmvjXAm88w5EFPzBTfsp
tPmxcLN3kRcZuLPRpEMnLydqvxuR9P8XrdK7SrPeOm848D7qLF3gRT3ZRynH
xqku83v5cuSjs2LP+Mq5xMTEiqs5nT7tg/LBISEzZs46deq0alpvReAVzl+4
mH108Uyn8PAIVSMRbC0KvEd1gXfZsuV3je/hFTO9cfPmsuUrMHDrth03b95M
SUmJi7u2dt16TL5585bU1FTtgRd1orbUxxfKMBF4xVHlMvA+SEufvyA78OKF
oEuvRsUo/qIjr17Fn7Hrb5i+SvND3fWpzpw5o7sV79Tdu9111x87J86JPnnK
55/zwt/VyMhIbEWI4/OxMRAWHrH/wKENGzct+HsRlqO4uPcspznnFKcpKQPv
/fv3r/MqzURE/37aA2+nTp3wtHbt2p9++mmtWrXwuGLFitHR0WLsjz/+iCH3
Fec0Xb58GUMQb/E4MDAQj7/77jsbG5uaNWt+8MEHJUuWtLa2njJlCsaikqZN
m9rZ2dna2uLBqlWrMLBYsWKfffZZuXLlKlWq9NFHH7344ouo4ZtvvhFf96rA
i/pRAJWj5tatW4ujjnv27Gms8tf+CXNB+TFjxuh3Ar5P169fL7O5MHDgQJT3
UVzokugZlKXbRZWRmXXmSlIrp+OFBuV/9nlOA6+bw9h9S49FJqemWXSk7n8k
8FoPdLP9cfeAdX6Xb6bkIO0+zL3AC2ey94Fm7w0MD7+smlCcADt9xsyg4GA5
EIlv85atqG3lylWIgTtcXRHEEpOSVNV6/3MPL4RHXBHx+aK/v+pOuBs3bVFe
tEqOesLA+1B3a55t23eIq0YvWrx0zdr18xYsnD1nrpfXvtu375juZFXgvXEz
cdGSpfLobo2BN7v/09NFw/A/JUV9rm5AYMCu3btEktVflFoCLxIuxuJv567s
k3ZDQ0PxYif8NcnX95yqMJb+/gMHzp47l56eHhUVtXnLtoiI7JOgMzIzb9+5
ffnKFYTfOc7zsvt83VrZsTLwouTFixedZs/JwRpLRETPFAReZLfxhiDPysB7
4sQJPO7Xr5+ccNu2bRjy999/i6daAi/MnDlTjL158ybiJzKvn5+fGKI66hiB
F+W7d+8ubmGA4NmjRw8MWbly5UO9wNurVy88PXPmjHiK7ylHR8eCBQvKK2OY
OKQ5Nja2atWq1atXV+6wNgidsGjRInQCmt25c+f8XnREWiGFRSfdneIZ+sov
3gX7P7o4c77noH9p4EV805246lYQ//u7lR7u3mWpz7mo2xZdhUl4XgNv9i7v
7KPBdxbo52Y/zL2N84kd52NSHpi/ipcR2Qeyiv1x3vsP6i6gpTtm32DRzKz0
tHR3d8/J2YHXBYFLdcpqTEzMHOe5k6dM9dq3T3eM8yP4otm2Yzuyz6LFS24q
DujFqEuXAmbOzD4b9/CRY8jd3vv3KysU9Xs/CryrHx86nYnvOFSFNu9wdcP3
lyiGuYRHRDjPnScuWvWobVnZzc7MyNx/4CAqWaO4aJWo6/DhozLwiiOXMBwv
7VHg3frokGaM2r7dFa8uNi7uxs2bQUFBZ8+eRXhPSkpCAXmstfFPCRl4FyUm
JiVcvz5nrnNQcNDDR7dFuIv+nDRpyqPA+/iM6YiIy9mBd+r0K1ciRWsx9tCh
Q1N0xzOHhIYqDztHHl+2fJnLmtXKTQVVG5BhXd124vWiGco7Iwv4Tnd1c5us
O1ZZXJ46JSVl6dLl6Ld16zfgsfKWVecvXJg+c9YZ33Po/5CQkFlOszdt3nrv
3v1HSygz+xRgD8/sK3ivdHFRBl7UtiM78GaePXsOM8rpektERM8KEXiLGYJY
JwMvUuHOnTuVZ636+vpi7IQJE8RTLYH37bffVs7a398fA/v27Sue6gdeOzs7
5a0H8N1XpkwZUYkq8J48eXKv4q58gFiKAihmsHIJWwJ169YtV65caGio2b56
7733RGyvUaPG+fPn83vREWmXfeXh9IzMs1eTRmwNqD7Oyzb7Fr3aTr1k4NVv
bf+dhQbuqjBsz2d/n/K8GJeYck+Xdi3ed/m8Bl4szRcG7a756/7+ay94XIq/
fud+OiJSjm7xjAiDT+kLfn7i7qjr1m+Mj4/H94LBe7mK29Uh623esg0p5u+F
i/EVgMKpqamyDCY8cPCQ7u6xzpcuXUJ5ZCgE6lOnTyNTT502w8fnjPJwZTzG
Vw+SLCpEgpvlNEf5PZh9NebkZLRwy9ZHc4yPT8AQcQzt8RMnxX18MMfrN27e
un07ODh0+YqVs+fMRaRaumwFQrE4F1hUIpq9ZOmyqKjoO7pKMDYxMdHVdefj
+y7FoqRoUkxM7MJFS1C/y+o1SUm3kH8xCg1A/PTa5x0QEBgUFBIYGBSIxBsS
GhwSFh4egQybavxefiLwiuO9IyIi0Od4uVFRURh+584dNAkJVHd1621oKpYL
UiSGnzt/Hi8QU/n6nrt9+47oarR52fKV4gpRISFheOEYdSXy6vqNm1BnQECA
wdydkX1/qFsxsXHLlq8QtyW6ejUa/Zb9d/3mtfgEvIodO9ym6376WLN2vfhB
W3chsgtoA/527toTn3AdsRqB3efMWee581euyv7RAwtdBF5015497rFxcehe
iI6OWbkq+wrPyrv6ombx28X169d37tqNbs/BektERM8UEXgNjtI/hxcbD15e
XrNmzeratWv58uUtDbzDhg1TzQJJEylSPNYPvM2bN1eVb9u2bfHixR8aOocX
32j4Gt24ceMvv/zy/vvvFyxY0GzgRWubNWuGCjUenIxtjISEhH379qHTChcu
fPz48XxbbESWebR5idibmZUVefP+gsNXms86Zj98t3V/3RWZBu4sOCg7pzy6
BlH/R5ckyrO/AgN27sy+aJXhwJucmt514WkbhKn+edekR3+PE1wB3UnQ1v1d
bQbvqvnb/pHbAk5EJKVlZIq9TzlIu5gi+X5aZQRekw34bKFPZpaJsIjAG17g
B1fr3F1e2f2889GDR4/F3y5xJri1bm0pOEh3DfDsbnGz7udacOCucqM8m04/
OnKb/86LsdeTH2RkZudcEztkTUPU2rNnj8gp4lpD2alzBr6CZodHXFZ3p+4O
NWvXrnOeOw+BSBRGqsXfyVOnlSWzM++hQ4h1U6dNX7Zs+fr1G3S7YrOv6nz6
9JnsKJ2lrtn37LkJf01Cna5uO5U3M7pzJ3nd+g1ijpiduBwWshIioW6vccbe
vV7Tps+YNHkKkjLqnz59pte+/W47d6M2TIJBW7duS0tLR2hVVoJEvMplTXxC
wrbtO+Y4z52ieznZl1+e7YzIj0S/YeMmvC5ROLse57l79nggMCIyT3w8UFyA
S/mHRL/Pe3+mkUMRMBy9KsL4zFlOaPbylSvv3b+P9LpixQonp9moFqPEXXfd
PTxDQkMXLlyExSGGI2/Om78AX6Zib/K1a/GI9pN1LUF0nb9goe4GT3N8z/pm
GTrsXzfJNcx9uq5C8YdJ5J/4xQMP/l60eP/+A+h55QI9fdoHletaPhupH/Wg
sMuadeLALRQIDg7GwB2ublgKM2Y6LVm6HH8orMvOa28qbiJ85OgxsfKgQszU
y8s7B6suERE9UzQGXgS9Fi1a4Kmtre3HH3+MULl48WJLA+8ff/yhmkXNmjVl
DtUPvO3atVOVR9BGPffu3VMF3h07dpQtWxZDqlat2r179zlz5nTp0sV04MW2
Qfv27QsVKuTp6Wlpp4l902hM/i03opxD/EASib997+zVW3P2R3Rfee6dSQcd
ft5bcugeZJbsKzP3d7Pt71a4/848+ys6cOdO/7gs43t4uy46VWLATps8aVWR
/ruKoEn93WwG7C40cFfRwbsq/uRR97f9H887MWbHpX2B8Vdv3rmf9sDCXtdb
ClmZt1Mzqo3xMt2Yzxadzr4/sdHAmDn3YEThH3YUyeVO2FW0/85i2avBTqwJ
RQagK7IvzGWty/5Ff9xVZtiel0d61h7n/c7kw44LTg5Y7zd7X6i7/7WI68nX
biU/SE/LYcRVd1HW1atX/S766//dvp2sX1iXa0JUJc/7XYiLV19RHyXjrsUf
P3Fq1273bdt27HH3OHXKJ+H6DeV1F5Xu3bt/0f8S/m7cuKHcO/ngwQPkPtUc
A4NCMFwcWIsH4eHhCE2Yi4fn3oDAwNTUB9ExcRf8LqLkBT//sPCIjMysoKB/
NPvixUuoJOXevfCICL+LF5WjgkPC8D0bEvaPmaK2yMiraA9aiFi3GhFu3fo1
ax/9IU0vW74CYVncqikmJsbYy8TwiIjLyM7bd7giGickXMdrTU1NxTe46jVG
Xr2adOuW/6VLquEImPJg7Nu3b+OFeHjsRWzftXsPevtafIKxWYvDldF+g4tb
9ElwSGhs7LXbd+7o79/HEOTlY8dP7Ny1G7NDh/tfCrh7N0U0Bv+x4HzO+CYl
3UpIuHHa5wyWuNvO3Z6eXug65ZnR2cv6/v1z5y647dzl6rrz5CkfVPLEKzIR
EeUzjYG3T58+4vxZGWmjoqJMB94jR46oAm+3bt2U9aelpRUpUgSpUzzVD7y1
atVSNalRo0Yvvvjiw3/u4cW3VYkSJVBYng4M48ePNx14xWm/q1evNt0/Xl5e
mHDLli3KgSkpKZhWtpzoXwd5JD17Z28mkm86wu+dexeik/YGJKw4GTXdI3TM
Fv8ha/y6Lvbpkld/3Raf8Y1MMnYf3ntpmbM9w7otOfPNojxpz6LTfVac/Wmd
3x9uQfMPRGw9f+345ZsR1++kPEhHJH98AqDFZ+yqF0EWXld6/3XnTTdm6t4w
3UmeRqtxv3it88LcXxyDVp8ftvb80LUXRqz3+2Vb4J9uQdM9w+YfvrzmdLSb
37WDITd8ryaFxt/GmpOann2SZmb2eZ26I+ez/+V0n66BXlIz3fkGy+sfQPv4
rkOZqmImTnFV3f/IxBz/v8yjqrNMe/j4XF39Zpsorw9hc/6ChevXb7iTnJz6
IPXBY/dT7yffTQ4ICp4ydbrT7DkI4AYPCNd/OWZfo6nXrleV6e41MSPTczE9
oYkCyuEmqsqNtZiIiPKZxsDbvHnzF154QTl269atysA7bNgwPL169aosMGTI
EFXgtbW1lQkUnJ2dlZexMnjRKm/v/z+a6NixYxgirhalDLwhISF4PHLkSGXz
2rZtayLwjh49GmOnTTN/MQpsG6Dkl19+qRzo6uoqrvSVn0uO6CnIvrBz9lVM
s//SM/L0z/SmZV63R9cDmU9/gzfd3OvKMHfZZzQy7Sn0gFgHHv3pQlumuLtz
Xq+SpFVQcNDU6TPWrl8vbteris/h4ZenTJm2eOlycRZwfjeWiIgo72gMvD/9
9BMejxs3zs/P7/z588i5pUqVEvcJEtdRdHFxwdPWrVtjLOLt77//7uDgUKBA
AWXgLViw4CuvvLJu3brDhw+PGTMGY1FGXk6kWbNmqBPpNUl3xwcEXpS3t7ef
N28eoi7SMR4XKVIECfThPwNvenp6mTJlKleuvHHjxoiIiP379yPt2tjYiFvl
ip+ylZWLuPrSSy9N+Kdly5YZ7IeOHTuifJ8+fby8vI4fPz5r1ixk/0qVKvH2
fERE9Iy4ffv2KpfVU6fNcFm95uChw+fOXwgMDL4UEHja58yu3Xvmzf/774WL
Q0PDuNeSiIj+a5BYVRdPlrp16yZHIdV+8cUX4hrFCKoItgiPrVq1wlNHR8eH
umPDBgwYIC4VhQItWrRAJm3SpIm4i5AIvH/++WevXr1EFEXJTz75RLnDd9q0
aYUKFZJ7jRF4v/rqqylTphQvXlzMt379+vLayDdu3EDbFix4dPnEQ4cOVa9e
XRSzs7P7448/EMyRjvF0+/btqsq3bt36tiGqI64lvHa8NLHHWbQcXaHlqs5E
RER5BpnX54zvtu07lixdjoQ7e87cOc7zFi1eumnzlpOnTycmJj35LIiIiJ5v
t27dCggIUJ6oi9yXqLhlYXJyMgqkpKgv8iAC7/Tp0x/qrvIRFBRk8DZ8iJbi
PhEPdYG3U6dOD3VRGnNR3p/IoCzd5U0iIiLkz9f37t0LDg6WV9RUVp4Dqamp
ITomzn4iIiIiIiKi/xpl4NVIBl4iIiIiIiKiZxYDLxERERERET2XYmNju3Tp
snv3bu2T9OrVa968efndcCIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIi
IiIiIiIiInqepaam5ncTiIiIiIiI6N/q6NGj8+fPd3Jycnd3z8jIUI198OCB
t7f3rFmzNm7cGBMTY6ySixcvogaDo4KCgpYvX45ZnDp1Skt70tPTly1b1rhx
49KlS1tZWRUvXrxu3bqTJ09OSkrK764iIiIiIiKif4fExMTmzZsjVBYrVqxU
qVJ4UKNGjYCAAFkgLCysXr16GG5nZyeKubi4GKyqY8eOL7/8smog4vOoUaMw
YaFChWxtbfHgiy++uHPnjokmIVPXrl0bJfG/X79+c+bMGT9+fNOmTTGkcuXK
ERER+d1nRERERERE9C/w9ddfI0guXrw4KysLT/fv349I+/rrr4ux6enpSJ1F
ihRxd3dHgdjY2AYNGqD8iRMnZA2IzEeOHOnTpw+G6wdeJycnDO/Vq1dycvKD
Bw+mTp2Kpz179jTWnrS0tDp16lhbW0+cOFG1r3nDhg1IzWibaCoRERERERGR
CSVLlkSGVQ5BOEUmvXLlCh7v3r0bj8eMGSPHBgUFYUinTp3kkNdee83qMVXg
RTKtUqVK+fLlEZzlwBYtWhQsWDAhIcFge0RA7t+/v8GxvXv3xlikcvE0MDDw
3Llz4sGsWbPi4+PF8KioqE2bNiFcz50798CBA8qAjPJH9Pj7++f3ciAiIiIi
IqJchjRatWpVZSB1dHREqIyNjcXjsWPH4vGZM2eUk9SuXfull16ST69fvx6n
g+SrCrwInpgcKVU5ECEUAxGlDbbnzTffLFy4sLFzddHO5OTktLQ08fSLL75A
+bVr14q4LcIvcm6RIkVsbGwqVapkbW2N4Y0bN8ZUsn4rPa1bt87v5UBERERE
RES5bMuWLUWLFm3Xrp2Hh8eBAwcGDhyIADhhwgQx9ttvv8XTW7duKSdp3759
wYIFMzMzVVUhCKsC74kTJzD5lClTlAP37NkjDqLWb0xKSgpG1a1bV2PjEXjt
7e3Lli27adOmmJgYNCkgIAA1tGnTRrT5zp07eC0YsmrVKjHJvXv3khW6du2K
ULx58+b8Xg5ERERERESUyxAShw4dqtzd6ejoiFQoxn744YfItqpJxDHPcXFx
quH6gRdpGiWXLFmiHOjj44OB48eP129MREQERnXo0EE5MDAw8J1/GjdunBiF
wIvySLvKwqhZeYiyOAb7r7/+0p8d6sGouXPn5vdCICIiIiIiotzXsWNHa2vr
0aNH+/r6IifOmTPH3t6+fv364kLKrVq1KlCggOoiUd999x1yYnR0tKoq/cC7
detW/Z25J0+exEAZWpWuXbuGUQ0bNlQODA8P76RgY2MjzyAWgTcxMVG/qqSk
pMOHD8+ePbtx48bKfdaSOLIaLzy/lwARERERERHlPg8PD4S+4cOHKweKU2LF
ccjikGbVGbXt2rWz6JDmyZMnKweKC2EtXLhQvz2o84UXXrC1tdWvXEhJSUEA
VwbeYsWKKQukpaX99NNPlSpVwizKlSv38ccfqw7SFjZs2ICYj+Se30uAiIiI
iIiInopZs2YhDO7cuVM5MDY2FgO7dOmCx7/88gsenzx5UlmgZs2aVapU0a9N
P/DGxMRgclWunD17Ngbu2bPHYJNExF6wYIHBsSKhmwi84ihlhNyzZ8+KIeLC
WcrA6+XlZWNj07ZtW+WluoiIiIiIiOh54u7ujjD4559/Kgfu2rULAydOnIjH
fn5+eDxq1Cg5VpwSO2zYMP3a9AMvNGnSpEyZMvK6yg91tyUqXbr0/fv3DTYp
MDCwcOHCJUuWDA4OVo1KTEx0cHAwHXibN29eqlQp5ZDjx48rA6+Pj0/x4sUb
NWqUkpKS391PRERERERET0tqaupbb71VpEiRpUuX3rp1CxnQzc2tUqVKCKRX
r14VZVq2bIkEihSclZUVExPz9ttvFypUKCIiQr82g4F348aNYifvnTt3MLsp
U6YYO4FXWr16dYECBdCqsWPHHjx4MC4u7ty5c/PmzStfvnz9+vUrVqxoIvD2
6NED9e/YsQMROzMzE4m+WrVq8rDt2NjYsmXL2traYhbuCp6envm9KIiIiIiI
iCiXRUZGfvzxx8qrNNerV095DHN0dDRCLobb2dnhv729/datWw1WZTDwPtQd
F21tbY2YXLRoUdTwzTffKHf4GnTgwAE0Q9kqhO5hw4bdvXu3W7duJgIvcvor
r7yC8hiOyFy5cmW0tmbNmuJ2wOKcYn3I1/m9HIiIiIiIiOipCAkJ2b59+4YN
G86fP6+6JrMQHBy8fv36Y8eOGTsU2bSkpCRPT0/MIjY2VvtUQUFBmzZtWrFi
BaZNTk4WA+/duyeuIG1Menq6t7e3i4vL8ePHRWuvXbuGxp8+fTofe5iIiIiI
iIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiI
iIiIiIiIiIiIiIiIiIiIiCgvpaend+/evVOnTsuXL8/7uffs2XPGjBn53QdE
RERERET0HNq+fbuVzksvvZSZmZmLNZ86dapv375hYWEmytjb23/66af53QdE
RERERET0HHJ0dLS2tm7Xrh0yr4eHRy7WvHr1atR55MgRE2X8/PwiIiLyuw+I
iIiIiIjoeRMdHV2gQIG2bdueOHEC4fSrr75Sjs3KykpOTk5LS1MOvH//fkpK
inLIjRs3jh49unfv3tDQUGWxpUuXok4MF+UzMjJQm9iJ7O/vf+nSJTzAKJRU
1nb79u0zZ864u7v7+vqqZk1ERERERESk0YQJE5BJt2/fjsc1atQoXLjwzZs3
5djAwECMdXJyUk7SunXrl19+WTxGeh0wYEChQoWsHmvRokViYiJGffDBB3Jg
pUqVMAQZVuzwFaMwIQaWL19eHtKcmpo6bNgwZW0VKlTYtWtXfncSERERERER
/ctkZWVVq1YNoTI9PR1P//rrL2RMZ2dnWcBs4J09ezYKDB069OzZs8HBwRMn
TsTT/v37Y9TVq1enTZuGp2vXrhWn8YrAW6dOnZYtW27cuBHlH/4z8E6aNAkF
hgwZcvny5aioKMRwzKh06dJoZ353FREREREREf2beHl5IWCOHj1aPI2MjMTT
t956SxYwG3i//vprFFAe4fznn3/+/fff4rHqHF4ReOvVq5eamirLKwMv8nKn
Tp2UF84aNWoUJomPj8/vriIiIiIiIqJ/E6RLxMkLFy4kP/buu+9iyNmzZ0UB
s4F35syZKNC0aVMXF5e4uDhV/QYDLxKxsowy8Cohfa9bt87BwQGT6NdMRERE
REREZMyNGzcKFy5sZYg4u/ahhsCbkZExbdo0PBUTVq9effjw4devXxdjDQbe
NWvWKGtTBt6bN2+OGDGiSZMmdnZ2BQoUqFu3bq1atRh4iYiIiIiIyCKIsciS
/fr126ywceNGW1vbUqVKiaOODQZeBFIZeKWAgIAlS5aIOxzVqFHjwYMHD40E
3vXr1ysnlIE3KyurYcOGNjY2gwcP3rdv37179zBw/PjxDLxERERERERkkTp1
6hQqVCghIUE1vGvXrjKWisA7depUOTYlJcXe3l4G3l9//XXSpEnKyZGgMYmf
n99DCwNvWFgYxg4aNEg5dsiQIQy8REREREREpJ246+7nn3+uP2rfvn0Y1apV
KzxOTEzE48aNG4tb5aanp/ft2xdDZOD96KOP8NTb21s8vXHjRrNmzZCjk5OT
Hz4OvHv37hVjTQfepKQkjG3Tpk1GRoYYtW3btmLFimFgZGRkfncYERERERER
/Tv06tULQdLgLW6zsrKqVKlibW0tYqYoWbFixQ8//LBSpUqOjo69e/eWgffC
hQv29vYo4ODgULNmTTywsbFZuXKlGCuyc9WqVbt06fLQXOCFoUOHokDJkiXf
f/99VPjqq6+OHDlSXDjax8cnv/uMiIiIiIiI/gUCAwPPnTsn96WqXLlyBWOT
kpLE0z179owdO3b8+PG7d+/GJNHR0ZcuXZKFb926tWTJktGjR48YMWLBggWq
w4+RqTF8+vTpeHznzh1ltYK/v39ERIR86u3t/euvv44ZM2bjxo2pqamZmZmo
HDWEhobmd58RERERERERERERERERERERERERERERERERERERERE9t/bv3z9Q
QZyN7ubmJoeMGDEiv9tIREREREREZDEnJycrhfT0dAwcN26cHFKyZMn8biMR
ERERERGRxRh4iYiIiIiI6LnEwEtERERERETPJXd3964K4hzeTZs2ySF9+vTJ
7zYSEREREREREREREREREREREREREREREREREREREeUyef0ojeWvX79ep04d
OdXrr78eHx8vx7Zo0UIMP3DggEXNMD3hb7/9Jue4bt067dXKCfHAYAHMzsqk
ggULvvTSS40bNx45cuTZs2ezsrKeUsfeunVr5cqVvXr1euONNypWrGhjY1Oi
RImXX365WbNmmLWnp2dmZmauvOScTajsqL59+2qvVk6IRax9qsuXL8+ZM+fL
L7987bXXypQpU6hQoVKlSjk4ODg6Ok6YMOH8+fMWvTQiIiIiIvpvsiiXJSUl
1a9fX06CMBIXF6cskAeBt3z58omJiRqrffLAq9KyZcvQ0NDc7djbt2+PGjXK
3t7e9KwR9xYvXmw29uZB4IUjR45orNbSwBsSEtK5c+cCBQqY7o2mTZsePHjQ
ohdIRERERET/Ndpz2Z07d/73v//J8q+88kp0dLSqTB4EXvj+++81VpvrgRds
bW23bduWWx3r4+ODntQ+d3SUcpd6Dl5yziZUdVTt2rUfPHigpVqLAq+Li0vx
4sW198agQYPEva6IiIiIiIj0acxlKSkpMpNCtWrVIiMj9YvlTeCFQ4cOaalW
e+CtVavWaj3IX3PmzBkzZkzz5s2V+xxtbGw8PDyevGPPnj2rzHcVK1YcPHiw
l5dXWFjYvXv3bt26FRAQsHz58jZt2qjCpmrHukUvOWcT6v8y8Oeff2qpVnvg
Xbx4sbL+unXrYhYnTpyIiopCuL5x48bp06dnzpyJ4cpinTp1YuYlIiIiIiKD
tOSy1NRUZeaqUqVKRESEwZJ5Fnhr1qyJVpmtVnvgNRvHYmNjv/vuO9kAe3v7
a9euPUnHXr16tVKlSqJM4cKFx48ff//+fWOFfXx8lEHv/fffN3Zsc54F3iJF
igQHB5utVmMPe3p6FixYUJSsUKHC2rVrjZ0ujeEYW7p0adkSS18pERERERH9
R5jNZWlpaR06dJDFkNFMnMT6tAMvQpZFMScXA6+watUqa2trMQnyb447NiMj
Q54NbWdnd/ToUbOzvn379rvvviurnT9/fs5ecs76SnaUchG0bNnS7FW8tPTw
lStX0Ala9l9Lly5dQi4WkyAp8zJWRERERESkz2wu+/rrr2UZRIygoCATtT3t
wDt48OBy5crJvaKBgYGmq831wAszZsyQHWKiN0x3LIKzGGtjY3P8+HGNs0YS
LF++vJjw5ZdfNngo79MOvO+9916rVq3kq1u+fLnparX0cM+ePUWZ6tWrmz5D
Wcnb21s2o2vXrha9WCIiIiIi+i8wkcsyMzN79OghC5QtW9bf3990bU878OLB
2rVrZZMQvkxftfhpBF7EzDfffFNMNW7cuBx07IMHDxwcHMRYjWfCSs7OzrLm
HTt25OAl56yvlB0VFhZWtGhR8bR06dKmI6rZHg4KCpLnR1t64eUvvvhCTFio
UKHr169bNC0RERERET33jOWyrKysAQMGyLHINRcuXDBbWx4EXjSsdevWsmFL
liwxUe3TCLywevVquZvV2DG9JgLv8uXLxahXX301LS3Noo66e/euPKh44MCB
OXjJOesrVUdNmjRJ495Vsz387bffigKmDxE3aN++fbIZmzdvtnRyIiIiIiJ6
vhnMZQhxI0aMkKNKlSrl6+urpbY8CLx4Gh4ebmtrK9tm4uJRTynwJicnFytW
TEx45coV7R0rfPrpp2LUrFmzLOolAWGzt87EiRNz8JJz1leqjkJOV15Ey9PT
01i1pns4IyPjhRdeEAU0rmNKDx48+P7770VvbNmyJQedSUREREREzzGDuWz8
+PFyuL29/enTpzXWljeBF6ZMmSJb2LlzZ2PVPqXACx988IGY0Ng9eY0FXmS0
EiVKiKNwb968adFMtcibwAvHjx+X1+9ycHBISUnJQQ+fOHFCjG3QoEGudwUR
EREREf3H6ecyZZZENNN+SaWHeRh409LS3njjDdnOPXv2GKz26QXeYcOGiQl/
/fVXjR2rmmOjRo0smqNGeRZ4oX///vJl/vzzzznoYTnTkSNHPo3eICIiIiKi
/zJVLlNeEwnatWtnUW15Fngf6nYOyj2MVatWvXv3rsYJlXIceBctWiQm7Nu3
r5aOleRFnn/88UeL5qhRXgbeW7duvfjii2J4wYIFDZ7lbbqHsYKZ3lFORERE
RESUY8pctnTpUis9Gzdu1F5bXgZeGDhwoGzniBEjtE8o5TjwolvEhF9//bXZ
jlUaNWqUGL5gwQKL5qhRXgZe2Lx5s3yljRs3zsjIsKiH33nnHTE2ICDgafQG
ERERERH9l8m0snbtWrnD9OWXX5bDS5cuHRcXp7G2PA68t2/frlSpktzDePbs
WY0TSjkOvO7u7mLC1q1bm+5Y1XB5p6cNGzZYNEeN8jjwZmVlyb20MHfuXIt6
uFq1amKsiSuPERERERER5YyMKgiM4kHt2rUTEhK+++47Oap9+/bGbr6jkseB
F7Zt2ybb2bBhQ9UexqcXeD08PMSEbdq0Md2xquGOjo5iOGrQ2Ccm6HdXHgde
iIyMLF68uBhrZ2cXFRWlvYflxa5TU1NNN89sV1gZuiA2ERERERH9l6kiQ82a
NcW+tsTERLnzFFauXKmltrwPvNChQwfZztmzZ2uf8GF+HNKMgCyGu7m5aeyT
ZzzwgpOTk2zSZ599pn1CeU/hO3fumG4eAy8REREREVlKmRdeffXVmJgYOWrP
nj1ylL29/dWrV83Wli+BFw0TN/qB4sWLR0ZGapzwYW5ctOqHH34w3bGq4V26
dBHDly1bprFPnv3Am56e3qBBA9kq5RWoTE8of1QJDw833TwGXiIiIiIispQM
Cw4ODvqRtnfv3rLARx99ZPbA5nwJvDBnzhzZTuUB2E8v8A4fPlxMOH78eNMd
qxo+ePBgMXzChAkWzVHpvffee6YCL/j6+hYoUECUqVy58u3bt7VMKO8tdeTI
kZx1BZY1Ay8REdGz6d69e8nJycY2IFNSUvTvspGRkZGsoxqenp6ebJLZ06Py
AF4pWpKWlpZfDTDWe5mZmaZ7D0vq4eNONth+E6OInnEyLFy+fFl/7K1bt6pU
qSLL/P3336Zry6/Ai3d3w4YNZTs3b96sccIcB94PP/xQTLh9+3bTHasaPmvW
LDG8bdu2Fs1R6c0333zWAu9DxY8AMHDgQC0Tfvrpp2Ls1KlTc9YViYmJDLxE
RETPpp49e+ILeufOnfqjYmNjra2t69Wrpxr+119/ia/1/fv3K4djK9T0gV69
evXK75f7MDAwEC1xcnLKrwYY6z0fHx/TvYdtSxRbvXq1laFrkBobFRwcPHr0
6C+//LJfv3579uwx0bBx48YNGTLE4KiIiAhHR0e5r0TJ09Pzjz/+6NSpE+pf
tWqV/t1ATNR/5MgRRz0jR460qAHCwoUL0bFPcbHRU2Y2LGBNk2WKFy8eFhZm
orb8Crxw7tw5ed2tF198EVFdy4Q5C7zJycnyakvKI6i1dOyZM2fE8BIlSqSn
p1vUS0JWVlbZsmWfwcCLbpHX98ZX2MmTJ81OKO9KnOP47+/vz8BLRET0bDp+
/Di+oD///HP9UTNnzsQoZ2dn5UBs5Dg4OIhLfHTt2lU5CllyiQKKoYxySI6P
FstF+Rt4TfTe9evXlX3VsmVLlEFIlEPE+WgWBd6lS5cWKlSoVKlSrVq1ql69
OsYOGjTIYMPEjxVvv/22wbH9+/fHWLRQORAbyZ999hmGly9fHluJderUwWP8
T0xM1Fj/lClTMLBWrVq1Fbp166axAdKNGzcqVqz46aef5sMSpVyiJSz07dtX
FmvevHlmZqaxkvKKTF5eXhY1o2nTpmJCgx9WGkPciBEjZDux6mqZMGeBV7zl
oWrVqsaO0jHWsXj/2tnZiVHG9g6bJj5LjQXeyZMni1H4ELOo2rFjx4oJDR5r
rbGjdu3aJdv2xhtvpKWlmZ7w9OnTYmzhwoVzdmci5e+9OZiciIiIniqkDMQi
/TRRr149fPvfvHlTOXDfvn34Qv/pp59q1KhRtGhREzvd3nnnnWfwqz9/A6/2
3hswYABK+vj4qIZrD7zh4eEFChT44IMPUlJSHuoOmUbERoGjR4+qJjxx4oSN
jY1+IL148eLixYvbt28vtuJUa8iyZctEbJd7dZHKMUQ/sRqrv2fPnsj+JmKL
6QZgC9/V1RVbxSLLM/D+q2kJC3i/KO/MO2vWLGMlu3fvLsqsW7fOomaIdQlC
Q0P1x2oMvHfv3pX3dYVjx449jcCLxCqPKP7ll19y0LGyl9577z2LekmYOHGi
icArPh+gb9++FlXbq1cvMSE+T56kozp16iSbh/RtekJ8iFWtWlUUMHY2tGkf
ffQRAy8REdEza/bs2VZ699EICAjAwI4dO6oKf/311xgeHBwsDs1duHChsWo1
Bt6rV68ifsbFxV26dGno0KGff/45sh4ikixw8OBBFFAeK4vtXgyRYXDFihWe
np6JiYkzZ85E/ho+fLg4hg3ZFtuBX3311eDBg/39/UVhGXiDgoL++OMPvJxR
o0YdPnxY1aqkpCRnZ2cksi5dusyYMUMZta5cuYLJ4+PjL1y4MGTIELFVdv/+
fQw00RuW9t6TB15xURrlGZHo6h9//NHd3V051bVr1ypVqtS5c+fy5curAumg
QYMq6dja2urnzU8++QQDlVfTfag7p69MmTIa62/atGndunVNdJfpBqSmplZ6
jIH3305jWBA/GQlFixbF29lgsd9//12U+emnn7S3ITo6WkxVqFAh8TORivbD
dPEuk+2sU6fOmDFjcj3wTps2Tc4iJCQkBx3r6+srx+7evVt7Rz3UnVWNd7qJ
wIvPbTGqQYMG2qvNysqqUaOGmHDv3r1P0lGxsbElS5aUq8rSpUtNTyiOaIJS
pUqp7uFr1tGjR60ULJqWiIiI8sDNmzcLFy78xhtvKAeKLTTVWZ+ipNgdEBkZ
iQINGzY0Vq3GwOvl5SV+VMdmRvv27ZFYxVbKjh07RAFkNDxFopSTIMSJH+3F
0+rVq7///vuvv/56mzZtMHmJEiWKFCkybty40qVLIz5/+eWX2HwtVqxYRETE
w8eB97PPPrO3t8ckH3zwAR5gyNixY2X9yMuVK1dGyMLY5s2b29jYYNNOZnCx
Kbt48WLMyM7OTuwOQBbDQMzRbD9r7L0nD7wvvvhi48aNTXd+eno6XiA2yO/e
vasfSKVvv/1WP2+ih/v166cqWbVqVSw+jfWjV7F0wsLC0HIXF5ezZ88aa6fB
BijnwsD7b6c9LIi3hoAPGYPnn546dUoUwBtZ/7J7xsiDaVu1amWwgEXnpXbu
3Fm2s1y5crkbeFetWmVtbS0m6dmzZ447Fh9xYmzZsmVVP16ZgFgq3pImAm9a
Wpo8ZPrcuXMaa0bIFZMUL15c+Zmfs45auHCh/iIwNiEiPL6DRBl8Sms/r/n2
7du1a9dm4CUiInrGiW0zX19f8RTbM0guSEyqaxCJfcFr1qwRT8UFXi5evGiw
TosCLzZvLly4IIYgASGiIvyKp1oCL56uX79ePD106BCeFixY8Pjx42KIONR2
/vz5DxXnnclgeOPGjSZNmmCIKJ+amvrKK684ODhcuXJFFPD398fWYJUqVUQb
ROBFdF22bJk8bw5TYS4IbiZeqUW994SBF1tr2B7u1KnTjh073n//fbQf6R51
4sUqJ0HfIu+L3UOWBl59YvOyd+/eWupH/LfSnf+LdmJxi4XSsmVLg9feYeB9
7mkPC8nJycoDhidOnKhfJjMzs1atWqJAnz59zN7G6KHuEmp4U4tJECcNlrEo
8MbFxckAJT154EW1PXr0kBViFgkJCTnu2NDQUHz2igJIbWbvQiv6Vv4yYCLw
PlScc403vonTN5QvTR5SbizFWxR40VR5UrZkYkJ8ichiX375pcG9/Cp4Xa1b
t1bNwuxURERElPe8vb2tFHdwwLYfnv7888+qYnXr1sX2lcyeK1asQLGhQ4ca
rNOiwKu6mNJrr72GDRXxWEvgBTkWIR1jsREih4iQKy6BIh6rdn0idWIgUtXD
x9s88n4igsiqnp6eDx8H3u7du1vayRb13hMG3qioKDyuWLGira3tDz/8MHPm
TGxAFixYsHLlyvKk7LVr16KMq6urePokgTc+Ph6xwkq3zzopKUlL/eJqaTVq
1MADJFZMNWXKFIRfLBr9Sz0z8D73LAoLMvWAjY3N+fPn9cts375dlunUqZOJ
g34Rh1euXFmiRAlRuH79+sYuNm7plYcXL15saeBFTl+tx8XFxdnZGTETYU3e
ZFb87GbwuF+LOlYe6wtlypRZtGiRiVub4bNX3sEHnydyt6nBwBsdHS1ORhC9
evDgQRO/PJw4cUIezFysWDFMa7qjNO4K9/f3l7+naZmwW7dusuQbb7yB7jXR
5qNHj77++uuiMLpCXp1bS8OIiIgoj+E7HZnxhRdeELfKRUSy0p1qqixz8uRJ
DKxXr57TY4iQVrpj4QxuIFkUeLFlqBxYu3ZtiwKvLCzI9CqEhoaqAq/+vW+w
uSJSsNh5gR4YpSCufyL2EYvAq7p4tVmW9t4TBt6IiAgr3amIp06dkgU2bNiA
gehPPL5w4QK2RceMGSPH5izw3rt3b/z48dhARW2//PKLXExm60dJpHLVUYvf
f/89ZoQNY+0NeMjA+1ywdO+YOEVdeOuttx48eKAqgM+0QYMGyTLIiXgXr1u3
DsHq2rVrKJ+QkHD8+PHp06fXrVtXFsP7MSgoyNhMLQ28mZmZzZo1syjwaof3
lzzv4wk7Vnk6sJXums/Dhw/39PTEx8jdu3eTk5PDwsLw6dG1a1dx9Tkr3c2M
9uzZ8/PPP5sIvLBp0yZ56LWV7pdGfNSj8JUrV7AIEhMT/fz8kLiVV3zCklL9
3miwo7Sf7Dxu3DjtgRffgJ9//rmyfKNGjSZOnIhVBRkcY2/evHnx4sUFCxbI
o8HhtddeQxfh1THwEhERPcvEXSSwfYL8heTbpEkTVYHevXujgJ2dnb2CuMPO
1q1b9Su0KPCqDgZ+2oFX/zDImjVrihvdisPw2rdv/4UesXkpAq88glojS3vP
WOBds2aN6cA7b968h7o4aaW7dYuqDDZTxTVkvvnmG8RhBMy+jxUtWhRb+3ig
f0NbY3kTzatWrVrBggWHDRsWHx+vHGVR/dKWLVsM/pjAwPvcszTwIoi98sor
ciqDlynOyMhQZl6z8Eli+mzTHNxb9tKlSzIk5mLgff/9903fidjSjl2yZIm8
pa9ZtWrVEmfcI/OaDrywcuVKuZ/XLHxAmb6wdg4C771791599VWNgfeh7vNE
3AdNI0dHR3GqyKhRoyxah4mIiCiPxcXFIbl8/PHHiHX4yl66dKlybHJycvHi
xatUqaK6iYynp6f4xtev8OkFXnHE9ZMEXtUJYg8ePChcuLC4JLXY2WHwpiRC
DgJvDnrPWOAV23v6R5vDpEmTrBSHEJcrV65ly5aqMmXKlGnUqNFD3UXJ3v4n
LH1sl+IBsqpqKoN5MyAgoGTJkjVr1jxz5ox+Y8zWf/78+X379qk6BNu6Vrpf
XbQ0QGLgfQ5ozGVKhw8flnsPsXYpD2ZQcnNze+ONN8zmrGHDht25c8f0HHMQ
eGH8+PFPHnjF+Qh4844YMQLvOC1nJVvasVevXv3qq69MN6N06dLOzs7yoJTb
t2/b29vjw03/QvdKSP1t27Y1XXOBAgU+//xzsyk+ZzcsFufsWDTh8ePHGzRo
YLrNr7/+uvK6jvhqKK6jvWFERESUxzp06ICtjmbNmiGYqLb9xHlev/76q2oS
BBZshmGq2NhY1ajcCrzYEEUBbIzJsUOGDHnCwIvtW+WVXsQpuuKw6tOnT+Mx
ZqqssFu3boUKFRI7MY0FXkRycUC4vhz0nrHAi+xcpEgRBwcH1eWnkpKSXn31
VTRSvi68BJRUJnex1ScOadZn6SHNHTt2LFas2LVr18wuYoP1i+MMt2zZoizT
rl07Gxsb5bI20QCJgZdMQzxEUBo9ejQ+3KpUqYJIgncKVsg6der06NFj2bJl
t27dyu82PiuioqLmzJnTpk0bpLmSJUviM+Tll19G0O7fv7+Hh4f+oePa4bMX
H9qOjo74xC5VqhQiPOIzPrWQc2fOnKm8gdozAqvN+fPnf/nll+bNm6PN+FrE
FwcajKf4MLfoZwciIiJ6RuzatUv8cK1/RSZxdpLBbRJxAyMZP6XcCrwuLi5W
uotQYdsDm0y///474h5C4pME3nLlyr322msbNmw4fPjwzz//jNrq1q0rr1SD
l48yvXr1QtuOHz8uDnKWOdFg4DV9W6Ic9J6xwPvw8dWusN3+119/7dixY/v2
7XiA4Gz1z1OhseGKDfuXXnpp+fLlJ06ccHZ2fuGFFypUqKBKypJFgRdbekWL
FrWzs/tAj7Hgqao/Li6ubNmyqGH27NknT57EuidOnTN4wDMDLxERERERPSEk
PgQWpJKjR48qh8fExDRo0KBHjx4GpwoJCcEknTt3Vg3/7rvvjAUopVOnTqGY
6oa/nTp1Qt4UjzMzM5H+xAUwkUxbtGiBrNSkSZOVK1eKAh06dJCFBVSIXCyf
IvphyLJly/D4ypUreLx///6uXbuKu5DY2Nh89dVXiYmJsjwCFCYX9+cFPBg/
frw8+BYRGDWIKzZLt27dwkD0nv4LzFnvTZs2DcMDAgIMTrV37953331XXq8V
nYPIr2rSQ92Vsho1aiSKoUz79u1N7EZp3bp1t27dDI5Cb6Axyr1gyJ5vG2Hs
iEH9+oODgx0dHeWZg4jwxm4Ho98AJay3GDt8+PCHRERERERE/0LJyclIf1pu
jKhdWloaMpeJg/QiIyOREFXnmT47EMzDw8PDwsLwwESxe/fuBQUFPcmxiE8V
uhcvwexNfomIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiI
iIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiI
iIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiI
iIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiI
iIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiI
iIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiI
iIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiI
iIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiI
iIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiIiI
iIiI/pvu3r2bTERERERE9G+DLJPfcYqedYlERERERET/QklJSfkdp+hZl98r
KRERERERUU4w8JJZ+b2SEhERERER5QQDL5mV3yspERERERFRTjDwkln5vZIS
ERERERHlBAMvmZXfKykREREREVFOMPCSWfm9khIREREREeUEAy+Zld8rKRE9
W9zc3KysrMqVK2eswL59++zs7FDGwcHh4sWLYuDhw4eL6HTp0gVPmzRpgse1
a9fO3bZ9/vnnmO+oUaPweObMmXj87rvv5neHUbbt27fXr1+/aNGibdu2ze+2
5IPY2NgSJUpY6Yj1UwUrKkZhpTVblVjJf/7556fU1KioqN69e1eoUAELy9PT
Mwc14MMBLXR1dX1KLVQSH0cGoRn4nBk6dOiVK1dya3bodtSMRZAHL42IcgsD
L5mV3yspET1bTAfe/fv329vbo0C1atVk2oVDhw6JrdCvvvoKTxs0aIDHr776
au62TWSBESNGJDLwPkv8/f1tbW2xOKytrdu3b58rdY4ePRoLd968efn94jRZ
vny5DGKvvPLKzZs3VQWencD7ww8/iHbijfwkgXf79u1PqYVKJgKvMvl6eHjk
yuwYeAU/P793dfK7IUSaMPCSWcZWni1btnTWoE+fPhMnTty4ceO1a9fyd20f
MmSIbNWMGTPytzHPjaioqKsKCQkJxkpiA8/Ly2vu3Ll//PHHnDlzdu7cef36
dbP152wqCYWVzUNrtUwVHx8vymtZaSMjI9euXTt16tS//vpr6dKlZ8+e1TKL
gICAZcuWYZLJkyevWrUqNDTUom6Pjo4WLdTfbNbvgZMnT65fv37SpEnOzs67
d+8ODg42UT42NvaqOdu2bTMWeJFqS5UqpZ92wdfX9wOd33//HU/79euHx926
dbPohZslssDw4cPx2N3dHXPBosndWVAOLFmyBMvFzs4uKCgot+p82rkvd7Vt
2xatFe8O8Pb2VhV4dgIv8jjqHzp0qEUftkoi8OKD4im1UEkE3jJlypz/Jx8f
HyTuYcOGFStWTPzIEBcX9+SzY+AVTp06Jdbk/G4IkSYMvGSWsZUHMdbsz6pK
FStW3Lp1az6u7a+++qpszGeffZaPLXluiOCjhEyqXwyhbN68eZUqVVIVLlu2
7G+//WZsmypnU6l8+umnymkLFCigZarmzZuL8j/++KOJYiEhIV27di1cuLCq
hQ0bNkRINzbViRMnEPRUkxQsWPCTTz7x8/PT0jxsyKG8mPDMmTPGiqGLFixY
gOCp/2bs0KEDmmFwqkaNGpl9L3fu3Nlg4D127Fjp0qUNpt08I7IAttXzZe5k
jNjb3rRp01ys818UeMPDw21sbNDaWbNmvfDCC3jQv39/VZlnJ/A++QHJooYt
W7Y8pRYqmT3DQpxMgTLOzs5PPjsGXoGBl/5dGHjJLGMrj6WBF/CNn1uHFeUA
A2/uioqKqlKlitnAi9jVsWNHE2vF//73v5iYmFyZSmXVqlWqqbQEXhcXF1ne
ROA9efJk+fLljTUPM8KWrf5UGzZs0A/IUokSJXbv3m26eQkJCWJXkenAGxER
gdxtogOtra0nTZqkP6E499Y0g4EXCbps2bJWurSrMbk/DSILmP6lgvLe0zi8
/F8UePFpgKYWLVo0MjLyu+++s9L9Aqz61e5ZC7wIkk9Yw6ZNm55SC5XMBl7o
2rUryvTr1+/JZ8fAKzDw0r8LAy+ZZWzlyUHghbp16+bX2s7Am7v69u2rv3z1
A+/QoUOVBQoVKqS/0/bTTz/NlamUkPj0A6npwIsE/ccff6CMLG8sN129elXV
Hnt7+5IlS6rmtXnzZuVUx48fV6VdbKRhG1g5BJWcO3fOWAsxqlmzZsryxgJv
mzZtVK/9xRdf1A+zql0wFy9e1PIu1g+8p0+fFr1dtWpV/bRrYtNINUps82ML
9tq1a7/99tvrr79ua2uLGTVv3nzjxo3K47fxeNGiRSiPHkMZfLBg2WEqkQUG
DRqUaCRkYcUYMmTIK6+8UqRIEdSM13L+/HlVM0xs8CtHiU1fkTtWrlzZtGnT
UqVKoZPr1as3depU1fHwJ0+exLwQc7AOVKtWbfjw4VjfTMdA5Za8h4dH69at
S5cujRWmdu3a48aN0//BJzY29pdffkGnoYy4XM/cuXNVh3HKHo6KiurRowca
3KBBA2PrGzoZawjWperVq6O7sM7jNc6fPz8+Pl5Vcvfu3Xg/Yh2wsbEpW7Ys
muri4iKWl/4plsrXi7fS2LFj33jjjeLFi2M5vvbaa1h2qqPu9dus/2lgMP2F
hISIYyH+/vtv/bGYr5XuGGPZRVgTevfu7eDggBeL9aphw4b4mlN1oFxPfHx8
WrVqha7G6pRoDpaF1eOz111dXUUlql2oMvCGh4f3798fbyWsKmXKlGnbtu2O
HTuUJfUDL7oaayC+1/BGQDdiPcFKMmDAAOUZFlrehqINSqZjL1ZCrHJ16tRB
P6An8T5dtWpV4uO3yYYNG2TJvXv3tm/fHsPRtzVq1Pj222/xjtBfXnhf1K9f
H68a6wPW5O7du6OfTfetlsCLDweU+eijj8wuRHFgDF7ICy+8gP5/6aWXvv76
60OHDsmqZOBNSEjA6iE6HO/6d955B19/+oceXbp0qVevXlWqVEFt+O/o6Lh9
+3bVqSiyPZ6enh9++CF6Ek166623VqxYgYE3btyYPXs2PlWKFSuG1RIzWrdu
nWouZpudaMnnldnVSf9LQU6o8RODKI8x8JJZxlYeVeCdNm2a6kQ/bFji2wTf
I6oPxqNHj+bL2s7Am4uw+W1tba3/racKvL6+vsiqciy+ysWmLLYBxE/uBjer
cjaVighlKvqBF/PCtgQ2fbEBg00sVXljgXfYsGHKOp2cnG7o7NmzB1saclTN
mjUxUE71/vvvy1HY0hAbsdicXrZsmTjLTOjYsaNyXkjNkydPHjp0qLjKk4rB
wHvw4EFlme+//x6b0GKUt7c3tmHkKGw7KSdEqJSjvvzyS2Mn5oukILcw0Qbk
OCsjaTfR8sC7adMmERCwjskL28KUKVNEMWw+4S2s3xuNGzcWu7+xbZZoKPBi
dqKpStiGxCJQNsPSwIuMJiYXV+sSsHkvN2ux9SiOaFVCykOot9IQeBHt5UHs
yrVLeT4s3iMICPp9gviAHCGLiR7eunUrNkRFAWOBF43/5ptvrAzBW1K5YT9q
1CiDxTp16oRQgLURy0UcWo+tazzu06ePfPdhndGfEO8O5bFA+m1GbahHHD9f
uXJlPEa0N/gqWrZsiTKffPKJ/ijRXXh3yJVf9euTgPeLsp/FQERj+Xua2cB7
4cIFUVKc1IOuE9MizSmLiZeJztQ/cgZGjx4tS6oCL5aUseNh0OHyC1fL2xCL
Bp0pPn7RP3iMxWfsdQUGBmIl1J8p3n3ibSJzGTYP9L8vsEorjzE+fPiw8s2u
LLZr1y4T3asl8Pbo0UPZ4cYWIvI71m39NqDx06dPF9OKdz3e3YjP+iURn5W/
kCDAKj8TJLREeb0LMXDVqlXiba78ZRIx9osvvhCPlf2zZs0aObmWZidq/rzS
sjphxXjzzTfFwMY6iZZ8YhDlPQZeMsvYyqMKvAZP3hTatWunLImNN4PFoqKi
8O2Aj/EtW7YgKWu8yBU+RQ8dOoQtZHy3Hjt2LDY21lhJg4EXc8FMV69eje0r
GQpU8P0VqiAjDDZjsAGD+R4/ftzY1TDCwsLkhNHR0foFMFNZQHlJJbwu5Uxl
b6BCfL+jwfv374+MjDTbP/hW9fLyQnlXV1d5awa0RNacg/s14MXWqFFD9GTv
3r1NrAZjxoyRo7B1qmwwXqByieA7/QmnUkJIlF/Q2OqW5fUD79SpU62MMxh4
8bX+4osvyjJ9+/ZVjt2+fbuyBrmp5u/vrxyu2uUkgo+AbR7lQqlTp46JFhoM
vMr35gcffKAae/HiRbkXG1tEyt/ef//9d9lvJlYA5Rbm2bNnxe42hBRjRzJb
Gnhr1apVvHhxdJG4KteRI0eQDTG8SJEi4o2GrTi5kYbGIOuh20W0EcQJkqrA
i83C6tWrY0iFChWQcLG5jgYjKGGrT/7gIEpaFHjRWvwfNmyYiEVozJdffqlc
+vhcEnv2GzVqtGPHjoiICHxijBw5Ep0v5ms68Ip7OSEYYnv40qVLBw4cwLxE
fMBLltuo4uU3bNhQzAIrxoQJE8SFkTFf+aklevh///sf/uOTWVwIzuDc0f9W
uvNQUA8+69Dz6C7ELvHSZMBcsWKFGNK2bVt3d3esumhhz549xcCxY8eKYvo/
PuAzTfz2gs342bNnI32gA/EaxZsL/Syv5GaszVqO7EU7RR+qPn5PnDghWigu
HoXVWCwLfLxs2LABs8Z3EN5HYsG1aNFC/nYhpkJj0Ld47yOPGDsdXvr111+t
/nkMs7gMMt4yyq858TJF2MQKjE94LG58dL/22mtipvv27RMlVS8cZUSBwYMH
Y7ljSWElXLlypUhz6DFL34YaD2nu0KGD+AwZPnw4Fjpai8Wn/AVDhLLdu3eL
RYB+OH36NNYQLD65K1kcZILuFT+JNGnSBGNRBh/7aIBYQ1566SUTV+czG3h9
fX1FhMQCNb0Q5dfZ0KFDkewuX76MysWPb/LtLN71YjHh0xVfrOht/P/kk09E
sT/++EPMBV/uoicRA9E/+DTDtop8ayivMyCGFC1aFCVRG14s4v/LL7+s/CbC
mxrDsQ6Iz9u3335bTq6l2YmaP69yvDpp/MQgyhcMvGSWsZVHe+D966+/lCXn
z5+vKnDw4MGPP/5YdbQnvqH69etn+vDObt266R+liW1jgwewqQIvkiA2xlSH
oaIZqqOAYN68ecoyyAv48lJd2wdff2itfnhU7rkTe51UlO3HVpAcjo1kZf34
DkJiwua9akcPvn3wzWKwf/B1g+8asRNEwJc72oBNLOUeGdU+Pi3k8cb4zpU7
LwyuBiggR+kfgfz999/LsWin3KTJ2VQStpQqV64sCmBDGhtjsnyuBF7V/lPV
rTewXomUIWC7QgxHS5RTYZtEORU2b5RjXVxc5KgcBF6xgS388ssv+gUcHBxk
hyh/I/rqq6/EcOQmEyuA3MLE0lfujTJ2yp6lgVe/V2U8QQqIiooSm5Hfffed
cumj5/H+Vb6VVCFLfGQhZQQEBCgrR/yUbysxxKLAa/X4LkgS3noitWHDD08d
HR2tdFvyqp/FnJycxOSmA6+Vbiem6jreCxcuFKPESd/iZ5b69eurLpPu4eEh
ftxAwFf1sNlzRb/++muDbwHxcrp27ZqoO9hSXNEX2Ud5MAP89NNPGF68eHFs
5ycaCryLFy+20v28g5VfOSG2w8VlnWSgM9ZmLYEXMUHsWxeH2kpi2dWsWVOs
Qt9++62Vbsex6jNc/n4lfxYQTxHf8C2QqAHqFxFDuSPY09NT1LN27Vo5UL7M
P//8U1kDOlDkPuRugy9cnF2ivxdbrCR4h4qnuRt4vb29xSRYjsrhWFHlx6/4
HBO/VKiOwsXa0qpVKwyvUaMGuujs2bNWuq9RVf/Le5mZuCyA/DiK+yf0Gz43
pk2bJpIaVkW5p97gQsQsxJsFkyjrxzemOJEE/xMV7/q2bdsq3254Rd27d8dw
rL3iVeBjwcrQ9774eRMbPPJFiQqbN2+u/EBDDBfDsXIqJxe/4eDlWNTsRM2f
VzlenbR8YhDlFwZeMsvgmoNPSHFSjDRjxow4PYm6T118ACpL7tixQ1kGn7EG
D44V8Km+Zs0aZXl8xeCbZenSpcosqQ+fsWKHqZxQbJgJyIkGj0cSX4Jbt25V
zlFulwrOzs76RycKyNQIMsqmKhuJjXD9LlIGXkQ5ORxfxMqaf//9d3FFIINd
hK8eVbX4ZsfWr8Hy+FYdPHiwfIpoI3s1TgMvLy+RDvB9ja0RBC5jqwGSlPLl
jxw5UlWV/EIXxG/CZqdatGiRcipfX19VAXFNGKvH24fK1Q8bBqrCCFATdZB8
J02ahAfKnxQGDhyo3wPz589XNsDf319VoHHjxnIsVjMxsFevXnJgpUqVVJPg
VSsPV0NYkKOwmTFRQXWwmTi6QAXvDlmgffv2qrGBgYHyiHFsist1FX0lj3YW
dwtCq1C/q6vr0aNHlZt2YgsTK57YKfPBBx+IPbAVKlQICwvT/7iwNPAiG6qK
YTtQHH0nDm8Qc9e/l5P8mUgcp6oKWeJHKrnPUUkeAC+eWhR4bW1t9Y+1ENt4
KIA+FJuje/bsUZVBl4rdYWYDr344RYeINzhWUTwV67zBi+KK3Tf4r+xhLHez
N7TCmmNlaDMVrwifcuLT1cfHR7yt9E+0RJ+InxNF0tEPvKJh6Hn9WYtjPN56
6y3TbdZ47SZxPrvyTAHUI45RkTvjsOpaGdkJ9d5771kpYotyBdNC/pal3BGM
BohzH5TXPhIvE8P1j27asGGDqES8v1QvHJ/DmzdvxiehaipxoIvc9Zm7gbdf
v37i60N/RZIHYKxcuTIgIMDKyA9oYuUBPBDvXKxIqp+4UfllHRM3vNNyH158
XGzcuFFOYnAhii96fKYZPEVdTIIQLd712GjR37MfHBwsfu0Uv65gkwOftPr3
wrt+/brYS4s5KtuD7lIWk2FfdRaY/MXVomYnavu8epLVScsnBlF+YeAlswyu
OWa/X+QnoTyuJrfgM3nKlClaSlasWFF7U7XTP5nORFPF3RCefWiqls0GK92W
w1NqQ5cuXXKxmNXjrSyNhRMVe1hMk7tBtTB4Op4+zFocbZtfsAJgM0weZdG/
f//u3bsrz6S2s7NDqrp06VLiP7cwW7Zsie0ZbJKJaTt06KC/AWxp4BUhTkVu
hIvjruX1Z1REBu/Vq1eiXsgS+w0N7piTv6Ko5mWiGYmPNyDr1aunX0xGEvSM
le6oXYMBU+wSMht4RberiP34YkeM6LeLFy/q//oxYcIEjHJwcFD28DfffGN2
80DsSLLSHcgxbdq08+fP678EcdI3NuwN1tC6dWurx8eR6gdeEdiXLFmiP6HY
e2hvby/maKzNGgOv2DOFFTju8R52sVAQrwIDAxN1p3iIVyqeqvz5559Wul9Q
xVNRct68eWY7UBC/LuLFqoaLH+KKFi0qg4B4mardecKNGzfEV4m435npF443
8pkzZ5ydncVZlk8p8Ir9s/IXAyV57bvly5eLdRgfHfprJj43xE8iWEDI+OKw
Eyx09ICrq6vZi/BLJr658GVdo0YNRDDVO8jgQhRLCk3VnwXWQ/EzLMKgeNcb
W+fFhRp+++03xE8xd4O/G4tLDci7kIv2qIKtXCiqJKtaWBqbnajt8+pJVict
nxhE+YWBl8wyuOZo3IoeN26c6f2wSsqr/ZgwatQo5RmUpskjIc3SHmOtdBe8
1VLsKQVed3d3jX2lnfbA+/QYvAyRPrkD1yyxda2xcKLmwCuPm9XC4BVLDDZV
7CTNL1gBTp48abZY6dKlPTw85KrSokULeUS0PP9X/yR9SwOvvDiVktwIF0ef
qk6dltAkjO3Ro0fiP0NWeHi4mFFERIT+VHhPKZthUeBt3769fjG5ASnujVWn
Th2DrcUnpJWGc3hVRwsL4uTZ2rVr47H+VYtVEPaVPYywbHbzABurY8aMUV7H
qWzZsu3atcNmrcxokydPtjJ0nrjQp08fK911kBINBd5SpUphyN69e/UnDAsL
E3MUOzSNtVlj4I2MjBSfw/KQe3G4NSKbeHrkyBHRzwa3z8USfP3118VT0TBP
T0+zHZioC6pmF418v5heNOLyUKKw/gvHWj1x4sQ2bdogiKkOQHpKgVccMaU6
UFyQP50tXboUQcnsp4p4v+PLWnldPnwj4yNx6NCh+/fvN93JWi5apWJwIYqL
jYwfP97gJOISZ3i94l2PYGuwmDidtnv37r6+vmZfuPzoEE+xFEwsFGPDNTY7
Udvn1ZOsTlo+MYjyCwMvmWVs5bH0tkTly5dfvXq1sgblhXrs7OxUv66rTmKV
Fxtct26d/nelFBAQoDyDUnmuivIcXlAe4JSod6Kx8iRK1Tm8LVu2VG1/YntP
jrW2tlb+NJ1b5/BWqVJFtaGuPDXVSpeC5ShxypjsWOVpntgUUeVK7efwYoNE
bMbgvzyaS3UjG+U5vEhGylHbtm1TVSgPaRMWLlyY46kEefFJ5Ra46XN49SnP
JTd4Dq/yKljVqlXTL/B/7H33fxXF9/4CAUKTKr2HTkRAiiAQmoBUBaQKAoII
BOkIiNRQ9Y30EgQiVUN/0QkgSCgiLUjvvbuvz+c/+D6vfT6Z7zhb7t4QkuB7
nh/u6969s7NnZs/MnmfnzDkDBgwQBaAAPCgizxguQcJlX4i6deu6iSc2bxJu
aYlMK4aqh7HNsE4yVq5cafgAeApjGoPLy/t/oVr05cZxaIVcs4elLfScPz1S
kQojnDTKjfByhYXLZDLJOnfuHC+k7J4m4uLiZDE8DH5uipcJr2NGTmFActXD
LR2bnyjNboSXCaO50hTwxRqs1oA97Ihr166hCdBYOv0ShQoV4t7h6dOnG+6E
lwOBa092wsvVPUfCe/fuXV6IDwU3mf2no6WzJYP0wiwnWYPC8196HbsR3rVr
1xrSih4FU7iJG/y8RRS+Ct6El3v5+QxVGo7Jn28PDGtbTfv27UeNGrV8+fKY
mBjDH+FVhqEfwiszKQViPTo6Olp+yrtBxBlA/0OvMGNXr15d5lndunXziPGb
ZMKr3ERGnXJjjnwhiV71JrwMR/bVV1+JKcUDsCU85PFJeH2Kbfqbr15dnbxn
DA2N1IImvBoB4aY8QRHeEiVK2MNPMZYF4ZhTVcS9N6wAETwo74UMDQ21x4lC
gZKJkP18ZMJrX3BRogbJkbUUwquE07F3hbz5JbkIL8wG5cTdu3fLBURQGmVT
rZ2yXbp0STaPfRJe2DA1atTgKZMmTRLHPQivSDdJyJScUAIX89yknWVabpDc
LIkulQlXshNexiYlKlSoYC/A9SPlinLwUkeHUvm1iUdqVJ+ENzY2Nm/evN6j
smnTpvLwgVUj/sqSJQu0GibNw4cP9+3bpyT/ZUBgu4UJzafCR0REyBzNw9IW
mxP50w/h5XBzc2mmYyR9BWWSde/ePV7IMc2K2PWsXEsp9uDBAxbzT3j5gg46
6UimmC0laS7NXFJv1qwZvnNHKnfqeSNYwisA+RMSEqKiosgWGSOItw9Tq+Mp
9IVgJBw3l2b0vP1ERjDIli2b7NL8KoSXL3Py5csH3sQtkKDbwsNZ3FY5/ZAA
34U2b96cP1nSJ+GFHhqWP/njx4/tfq3M2RcSEsLd6N4uzXyRi+eC0vBnz57R
4QeaoDxkFSbofxj6Ibx0ynV0aRZTNCYrvhxzfPZ5A/2DR+2nn35K56sZM2a4
lUwuwsv3pXQOUQA9ZIyFQ4cOebs009N71qxZ4H2GtA89CfL4JLw+xTb9zVfJ
ok7i6vYZw/890tBIXmjCqxEQjppjJDdgsLkFWVLg3585KI/W8+fP+ywJ20lE
O/TGa3JpNn073xq+HYD9uzTDdIfRmOyNMqzdiH6KMYakH7wml2Y5/U1A+FQA
XFrkGE0VQAGWLVvWPxFy8FjTsrflt080QR0tzDlz5rDM9OnTxUFhGtkNHhEw
nD/9EF5SSMegVSdPnmQEPAZOUUgWX3k5hq0mMTH+afDbY0CJtzH+Ce+VK1d4
ipxYlsA4oimYtKBVjMHFlXrGZXJcLT148GBMTAz3fprBEF7oA+RnCmwZt2/f
5ubuI0eO8M6mT5/eHuIG7JubpqlLdsLLLnJ8+cPtyVA5b5n9E96HDx+SMO7Y
sYM0k7u8BXjHHXfm0mdAeETwjvghvNB27mgQodoViMiEbJpH0KrNmzcbkvuQ
3HDuR8aQtHuNoucNJ4YScBj6IbzgsIaV8cr+JkdMAosXLwbVMlx8ANCWGAtQ
lUuXLqE5Ys1dBgmd2ENtR3IRXqpoqVKl7AGyRFTte/fuiaBVmG2UYpiRSDAx
daBbMEcpbjACsbGxaPjZs2c95PFJeH2Kbfqbr5KgTqKAnxnD/z3S0EheaMKr
ERCOmuPTiu7Xr59HBOakQTjbBIQmvIa1RulTVJ+EF6xBWVxOLvCZGxBcFPOD
d955x7+o/nuVoXh8Qsl75QZcWmaUyYiA67xEQNbAlRoZjhYmzLwmTZoYFtMX
BqFwA1C82q5fvy72OPOIH8IL85iR05S0ROCPjDVqJNIohWTRqgcLUxbyIKcI
z8UjjHw1duxYuRhYv3BK8U948Z2vMurVq6cQGbG90U9aIiX8tYiyxTSyjEzV
oEEDxboWKX6EI4R/wsuBZi+JOulKAcsWfcIldbTXLS0RvQjshJdZO2FaHz16
1FHmUaNGecvMTsZtDdgWoH379ob1uoy+FuINANG9e3fDYg1KAFuRlmjbtm08
wp9+CC83/xrudj60l8IwLLmYf7gmLiDSEolVZjvhzZgxo0JjQX/oNCLGqf9h
6Ifw7tixg6coaYmgqCLExMKFCyEVdwHYXx/R9wa6jZGLm87vdjLOXbHKCwoZ
yUV4YQPQXPnhhx/k4yK/D2+TePpjtpEdrUVaIrSXreBrqGHDhinvBLZs2cIa
RGxzR3l8El6fYpvBEF4/6iTEEK3zM2P4v0caGskLTXg1AsJRc574TkukuPvO
mTOHf124cCFY0x2GE06UtyV26NDhiTtoXoqfcloie64WhfD++OOP4i8lLVFC
QgImf/lcEZyQEJlikjEtEVi23KtomuKDDeuR/zL3nwCMJftFZedVP2mJYOwF
dadYpxK1Y+7cuUq14rlPbN++3c9Zis8zKsFBn2RZALfMrqvoVXyRXZod0xLJ
PtKgdfYCss9zuXLleFBeF65Zs6ZdV+UozR6K7aZsAkrsKVmTBRgAhwB/f5KY
lsgDuJDSh24W5uXLl/lWqmrVqowvCouISbUwBg8cOICfvI/gF0yRaQRDeM3E
WE+GNZBheMOOwnESbQ6ozp07mzaSBVOc28oKFSoUExNz5cqVixcvLlq0KGfO
nLTJxUbXtm3bGtaOCdB8Dg30aqNGjVA5Q7IERXh3795New98GSfeuXMHtYGm
wUzldcVWPgXyOyhw8NWrV6NvDx8+DBOaJq64NOosWLCgYUUDjo2NvXHjBhq7
atUqMnfwCOHt7J/wkpBiBhs/fvypU6dApdHPa9eu5ebN6tWrs9jy5cspIez/
ffv2gTBi7hJvpXCnWMxOeKEDrAq9Cq3GvIr6cV/ow4PbLVbwvQmvnWs7gltx
efuY+1X+9/Tp01wCxoBFB6L3cAQPL84GERERojzb5YfwcuMwdN4jVq3IEAc2
ymZSQsw8uNG43RCb2/8zZMggvPEVl2a+/+nWrdutW7dMazl78+bNIsUYtBqU
Nqhh6Ifw4nTOaVBFTImQDQNqzZo1fAHChU6meWKYa8gPRTp69OijR49OnDgh
tibRVxm1UVfr1q27detWaAKLDRkyhKruluPbTD7Cayam9wLQomPHjsHkQOV8
zQUxdu7caSaOet6mpk2bivlHvG2bNWsWa9u/fz8HPqajPXv2PHjwAHc5KiqK
57Zu3dpbHp+E16fYpm+XZp/qJMQQLzZ9zhgaGqkCTXg1AsJNeRQmK2/elIF5
Ty4mHMMwr8rHYcKdDASeyNgdhEdsHzvkPbz2qEEK4ZV925Q9vEpAHtNzW2Vy
7eFV4n2Z1rKUXEBshWPcVAG72xUgJ9bxs4c32CVd1gkbRg7YaF9DhM7IZ3Hd
LWlnKdlpA0IOdaUg4B5eRR/s+/5A9MS/whOP6xRE4cKFlVMwHOQgLYIm2BFw
D6/yQgD2mL0SmuIEw/wGhKKQhqeFKbbEikU6QYsMyyJiY4sXLy5eerCYT8IL
EsoFOwWNGzfGTGJYqaNMJ5IFLka7Wgb4INkQ6DCLwZYTaZFDQkI4iqGWMPzs
UZoDEl7TWpC1x6sHjeJrQ5EkV4Gw5B3d+MuXLy/rXlxcnKM7AbgMJmFRzD/h
BYuU95UrPSamQQxYedO6jC5duogXKfZ7YVoB6BzzduXOnVt2z3aTmc7JhkWZ
HT3VZchvF+0hEUwrHKKjQ84777wjr0zxYEDCe+fOHc4k6ByPYiCerBCawGZi
7MvvZgmwRbAJN+2Sp0QujhvWGxJoNdkiuDw32/ochn4Ir2mFJ5IDJAqMGTOG
baFV8OLFC7dUbngmircBu3btcsuVgAo9xEhGwgty57hjBd0o1I+jvl27dvIs
KtC7d2/59QvOcnRyq1OnDq7lLY9/wutHbNP3fOVTne7fv0/HGJD6XLlymb5n
DA2NVIEmvBoB4aY8PgmvspIrJyWXw/g4MgtHyEGGMc3as/VNmDDhw0SMGzdO
HE91wssYoTJE9g0iWQjvpk2b5OMiurXA48eP5X3Qr4/wAnKaiQYNGijV9u3b
V/ybJ08ecTwJZ6Uk4T1y5Ihc1apVq+R/Yd3JZrMwdxWeDn2Tz1LW62FauIkX
kPCKfVuEbCcLyPvlma348OHDHSVcvHhROUX40Ap4W5i0oGDBCt9RUO8mTZpA
99DDGPuwdW/fvg0ultkCy/gkvKbFs6Kjo1H+rbfewumg7ZiRQK9o1IEOmy4k
C3YaiFL16tVBYAsXLtyvX78bN27wLYEcy+7s2bPdunUrXbo0pMWlwUkZmbxo
0aK4nLzW44fwmtYaIiosW7YsTi9XrtyUKVMgLb2s5YEvQ1jyaOzPP/9ct25d
UDacDpaBmU02mIlLly6BGsM0pcw1a9acOnWqshcvqKBVz549W7Bgwfvvv4+O
Qp0gpzgdU4p9WyJEhf2Pi8IGxqhs2rQppix5ZdPxXphWMDHQmfDwcEyVaBpm
6cjISMX10U1mzJ8tWrTIli0bmL5YVvNA165dDcs+dwwCxpsOwgLlRGOzZ8+O
iWj69OlP/unbSeUPSHiFvzqGtkcxdBG4gGHRatFMkOUBAwZA00BI0aVQZqUS
u3Zt3rwZUyUKow+hY5h2qB5RUVHgLOgffGFJP8PQJ+E1rX2448ePx8DBaIJy
1qtXb/369eKWzZkzRzRzxYoVkBCSUEI0AWRfqe3PP/+EhQD1RudjXKNa3DLv
DjSTlfCa1gQOnYf8sC7Q/9D8zp07yzKIUY+SUI+KFSuiRWhXRESEovMEmgl2
DPFQW/HixcFMY2JiFJ8ER3n8E14/YpvBzFc+1QkPI7SIMwNP9D9jaGikMDTh
1QgIN+XxSXiVJDLyZMsNL0T58uXtTwrQjTaJgH3Ig4qDsZKWCCYQHXIIt7RE
KUZ48TgQx/EcVx5zMBXkE5OF8MKAlCkbrCZlV9rYsWPlE/0QXtjMR1yg8OtR
o0bhoOgB2XcaFpG83Ayp6IRJyG9CknDWhQsX3CQU8Yho6/KgYzJWIiDhhaLS
ICRg28u3FSxM7hBh1CnhrJV1HzmTEZrskbUwIOGFtSx2pBqWj6uS0QMWr7zo
wKiwCotXhhXMGNkLGrZoQBfoNwvMaWt/u/K6wXV/ZbOwQBIseQ0NDQ0NDQ0F
mvBqBISb8vgkvGfPnpWLiexCpm1VCyRUrFk8efKErokCIsbp/fv3Zc892Pag
wFznvXTpEkxW+SzZly9VCO+HH34o/9W5c+fjx4+DbR0+fLhv377c4COQLIQX
6NKli/xXeHj47t27Hz9+jDplx1rCfx5eR3ikJTKt5KeylxrYN5gFbhPupkhy
REDCVzzLDcmelghQlLNTp0779u27fPny3Llz5TTQStIihnsVGD16NJQBjVVq
w+3zEM9PWiJuQRWoXbv2pk2bIB4uN3XqVNmLXowssHgRasawnNaioqL+/PNP
dHtsbKwSUGvo0KGvojOpBYiNO6JweYJ7Th0jBr86IiIicF17CGX0OSclx+DA
pia8GhoaGhoayQFNeDUCwk15fBJexWuX/pMCvXv3lv8NDQ1FAZBWJRSz4gys
eIcaFu0tVKiQslkGjFI+K1UI7+zZsw3fSC7Cm5CQoJAaD7xWwgsMGjQooAx0
QH31sxzxOgjvrVu3ZHroCGij4hN4+PBheXuyI3Dj3PwtAyqbrAAi7Ko35IV1
sfHWG+XLl1d8Bt4U/PDDD0ZiGDH5+NWrV9ldind6coG7MOSuJugdAT1xTP9q
asKroaGhoaGRHNCEVyMg3JTHJ+F9+fIlI5ESGTNmlFflnj596hj5QUZkZKTd
2zlgYqCWLVsqSUBShfCi+UyX6YjBgwcne9AqIjY21o1b5cqVq2nTpuLn6ya8
6AHvDbYNGza0b8RO2lmOeB2El/3PkL+OAItZtGiR/awNGzbIS8AKoAz79u3z
Fs8P4TWtjWMe4hGffPIJoygLiOjHbggPD39zY4+AVzJJE0MZ4+cff/yB0c24
smXLllV6I7kgUtu0b98+Li7uxo0bBw8enDhxIuNiffbZZ24nasKroaGhoaHx
6tCEVyMg3JRn+fLl70rwCLMD004uyT2DAiCz8+fPlwNYCcrQokULxxizxLZt
22rXrm23yUuWLAnaZefIYNZChmHDhin/Xr58WRYSxET8he/yX/ZccjCe5QIK
I7h9+7bdexnUhuGkPvjgA3GiiCsCnDlzRq7T3g8JCQlyAXuWw8OHD9v7B/QW
Rj5D5SQL4UVv+FGDJUuWyGl3iHz58jHQkFvlSTtLwQ8//CDEe++99wKWr1mz
pijvHQkHd7ZHjx726LvodmZHdQQoarNmzZR4pPjZrl07P1zSW9kU8QYNGuQY
ubd69eoxMTGOZ0HTmDdWQcGCBSdNmvTEliXzzQKGieOLIJDK+Pj413fdMWPG
OL5AqFGjBtPUOkITXg0NDQ0NjVeHJrwaAZFi2nj8+PFly5aByyxYsGDnzp1u
bn4Krly5snr1apCa2bNnw5o9f/68R9LDVATk3LJlC+ScM2cO5Ewx4gDijF4F
lZ43b56I2Thw4EBhctevXz/FOgEcPDo6GsIsXLhw7969frJnJvmsFMODBw82
btw4d+7cGTNmrFy50ucC6PXr19euXQulhUqsW7fOI4jWK+L58+dg34sXL0YH
fv/99xgs9gjMdly6dAklUR7jEfoDMpg2h1USgOZ//vnn4eHhWbJkyZEjx7vv
vvvNN9+8vv4XiIuLa9WqVVhYWKZMmfLmzRsREQGd8V5Txr27c+eOByPW0NDQ
0NDQCAhNeDUCIrWVVCM4PHr0aIOE48eP28vIWWleU6AeDQ0NDQ0NDQ0NjVSH
JrwaAZHaSqoRHF68eCHvCy5SpMjly5fFvy9fvpT9mQ2n3cEaGhoaGhoaGhoa
/w5owqsREKmtpBpBY8iQITKlzZUrV8+ePSdMmNCvXz85myoQERHxr3FV1dDQ
0NDQ0NDQ0FCgCa9GQKS2kmoEDXDYvn37GoHQokWL+/fvp7awGhoaGhoaGhoa
Gq8LmvBqBERqK6lGErF3797OnTsXK1YsY8aMguRmypSpZMmSn3766bZt21Jb
QI03FQGjBx84cIB+9aVKlRJRvH7//ffMFrp164afderUwfdKlSolr2yffPIJ
rjt69Gh8/89//oPvH3zwQWp3WAoBdwTt3b59e2oLovGGQTwgZs6c6V0SBURh
cZCKp6QdD4h79+6tWrWqe/fu4eHhqAHPKXzie69evVauXPn48eOA0spInz59
8eLFIyIi1q9fn7xuS8o08scffyjNTzI4kdoRGhqKxzTmSbcuDfg2O7kk1ND4
10ATXo2ASG0l1XhV4Ol/9erVY8eOXbt2TTswa7w6vAnvoUOH3nrrLcNKECbH
rD5y5AjNsE8//RQ/33vvPXwvU6ZM8spGwjty5Ejzv5Xwbt261f8p69atQ/98
9dVXqS37P/DLL7+0adOmUKFCmTJlKlasWKNGjX7++Wf73HXq1CnQpcKFC6MY
Cnfp0uXkyZMe1aKGsLAwn/pw69Yt1OyTNfiU5ObNm4MGDapatWq2bNmKFi3a
pEmTX3/91eecvHnz5ubNm+fJkydz5swYNUOGDIGE9mLPnz+H2teqVStnzpy5
c+euXbv2vHnzXrx44V25oEg1a9b0LomaX53wXr9+ffjw4XKsCTvQ0tGjRzsm
Ww9I9Dp37pyMT7qUJ7wyMKHZO0ETXg2NYKEJr0ZApLaSamhopC14EF6w2ly5
ctnZrmllyGpsYdKkSfgJkoXvn332WfLKRsILcxrf9+zZg6t4J1P+N4G8Y8uW
Lf5PSWvvBF6+fAnm6Gi9N2vWTM7itGbNGrBLpUzGjBlXr17tVvnu3bt9NhZ0
CYzbJ2vwKcnRo0cdk2Kjvd7sDP8OHjzYfmLBggX//PNPuSQINd8jKahXr97T
p089LiEXPnfunFuxhIQERz41cuRIDLTTp0/7ucUbNmzImzcvTg8JCUEnL168
+OTJk3fv3n348OH58+fXrVs3YMCAfPny8RKlSpXav3+/o7Rbt249nwjIHB8f
/+uvv4q7Nn/+fD/C+IEyRq5du/aVhVevmRMpeuO8hLNnzx46dGjhwoUNGzZk
Wxo0aKDknbf3gCOSqwc0NP4F0IRXIyBSW0k1NDTSFtwI77Fjx/LkyePIdlMM
JLxDhw5N7U5KBZDwbtq0yf8paY3wTpkyhcZ8hw4djhw58ujRI7Chr7/+GuTI
SPRUB6BdWbJkwZFGjRqB5ly/fv3AgQMRERE4kjVrVsdM06inRIkSPhs7b948
n8tkPiUBVS9TpgwOvvvuu+ApN27cAFcdO3Zs+vTpcXDJkiUel/j5558pSb9+
/fbu3YtzwRnZFtQmVm9fvnyJpuEg/gLXhiSggVFRUaGhoTgIyuxxCdZfunRp
fI4fP96t2OTJk0WxpC0gTpgwgee2a9fOgyA/efJk5syZ2bJlQ0l0r7IBhzX8
8ccf9hP//vtvaA7+rVOnThLEc8TrGyMB94ZAMTJkyIAy6HmfPaChoeEITXg1
AiK1lVRDQyNtwdFOO3HiBNdlwHYvXLiQWrKR8IIipXYnpQJIeGNjY/2fkqYI
L1hhwYIFDSeX1B9++AHHYfwzzl6vXr3ws2rVqvKa79OnT0EAcbx3797iIBhi
nz59atasKQhswMaeOnWKHNYPrfMpyaFDh8jdwEPl0yMjIw0rfqBb/eiHsmXL
ooyypHj+/HnywRUrVvBITEwMfmIMynnogOjoaBx/6623PBZ52dJRo0bhs2LF
im7FqlSpIoolgfDOnTuXa9/QOj8uxwkJCWFhYXx1cObMGUVaN7q3efNm/Js9
e/ZgxXNDKhJeYNy4cYaVakHe1KwJr4ZGsNCEVyMgUltJNTQ00hbsdho4Qv78
+bm6ZGe7HrvelL+4RIX6YZxPnDgRtjc4Ai5Uv359Zbcjvi9btgzlc+bMiTLh
4eGTJ0/GWSS84BGmi6V6+/btIUOGwJDOnDkzau7SpQu4gyKGx55E+a9vvvkG
3/FpWnSjbt26sEtz5MgB+jNr1iyFX5w8eRLXAqFj4Ljhw4c/evRIkfDJkyc/
/vgj6ilcuDDEK1269EcffYRrKewAJ44fP75y5cqhoaG4Ijrn559/FrL98ssv
LPbw4cNp06Y1b96cjcWl33vvvaioqDt37phO+wcpRhJu1qVLl7p37w4FYNNg
otMDc/v27Y0bN4aEuEGVKlXCpb0da3///XfWHx8fr/yFHqCr/M6dO0Etc+fO
je+LFy9Wii1cuBDH8a+gn+QL9ma6AbeAtK5fv34BaZ1/SRYtWsQFWaXYunXr
OGrcLnH48GGKAfan/NW1a1cch4bwZ7169YQ2ynjx4sXQoUMHDRrk4XTBSxw8
eJBM397/pjXGDSueEoopPeNnDy/O4nL2Tz/9pBzv0KFDgQIFcGloPn6a1sid
MmXK8ePHr127VqhQIXplK9K60T1HFgn9AfFH/SD+4MLvvPPOmDFjlJcPYjij
MAZO0aJF8RP6EHAPr/9Zy4+oCiAAPeHlftOEV0MjWGjCqxEQqa2kGhoaaQuK
nXb69GkuzDmyXTN4DhUbG1unTh18SZcuHaxTQVVECFmQiI8//tiwoXbt2rD/
8WXgwIGmE+HF5SiqDNiTK1aseBXCy3U6rqOJatu0aSNsXdBhOVg6Aasb5rGQ
8O7du2CFhhNkL9MrV64o2bQJNJmyrV+/3rRiLlWoUMGxtvDw8Hv37oFJobvA
T3EEJB3fQfGScLPmzp3LlX35TvXs2ROUn9/l2EQDBgzw0CtIblgrgC9fvrT/
yzXTpUuXgo4Z1g7Q27dvK2XQajo/Hzt2jEfAmI4lYuTIkQEJL4ghyjRv3vzk
yZMBCa9/SbZu3Yrv2bJlU0pSpPfff9/tEoyKXK1aNftfGzZsMKzgTlCzO3fu
0Pf17NmzZvAQBKp9+/aGy44AMET8hXFn15CAhBc3lJuLubmegNjjxo0jC65V
q1aDBg0yZ86cNWtWDH/WT59nrtgCR44cUaR1vBbfVHzyySfiyPPnzzt27Ggf
CNBb8mtCDGc0X5TxT3gDzlp2+CG8QKdOnVCsb9++9vuVhHutofHfCU14NQLi
f//3f/9HQ0NDIxE7d+6EuZU/f358P3/+PIPZ5sqV6+LFi47luTYEBPyLpiOY
GqgBqM3Dhw/xkAJlADfEcdjDoLooRgdXkkoIc/369e3btzdq1EgmVig2Z84c
WqqsHLYrtx+C865cufLq1asQeNGiRWCpMLNlMbhajZrtAst/kQKQV8KSB7fC
QQgjrOvdu3fjyIkTJxjUCFY9TFwQW5Cp0aNHwzDmdSnhZ599hu/ozFWrVt24
cePp06fHjx8nrwcpAJGhADyCc0eMGAEKAP67evVq7ugkQBtR7KuvvjIsH9p5
8+ahpei3v/76a+rUqaRFMMJZm9JFSbhZoaGh1atXRxtxp27evNmkSRMhSdOm
TRMSEnAcQtavX58NefTokZteQc5t27ax0xRAE+jBe+DAAb6dKFOmjGMlvMXo
Q/tf9sYq2LJlCxUb/e/RDwL+JQG5o1t17dq19+3b9/jxY/RJVFQUSDFu5S+/
/OJ2id69e+OsXr162f9CDZQQ0u7du5fKI/6lgfc//sB60GRIgi/FixdXzsVP
vmZZu3atvWc8xgvBbchFixbFGBQHv/32WxJ2sE4eOXPmDNgfNx1XrFhRXLpy
5co4AoVXpJXFg17hCN9XgG+CDIp/x48fz1G/fPlydBpGaExMTLFixQzrDRV+
shiH8/vvv29YPuqzZs1ibHBFbezN9zlr2SFPpB4Qgtnvl8/7q6GhAS6T2nRK
I60jtd/KaGhopC2IhQnQGdqNhNvu0WAXDQ1bbh3wKR4/dOjQgwcPuKL0+eef
y+6Cz58/b9GiBYv179/ftK3wTps2jcRc2eQIXkkaaCRphddIzIIkAKuefpgg
mPjZsmVLw4qig+NysR9//JGnU8IiRYrY+xCNYhwwOs0Kb9Lo6Gi5GCgPTwcY
HJiLxdOnT1fkJ63u2rUrfzouggd1syAeeK4oc+HCBZYBP5IdmEHYxR0MVt9w
l7lsV65cuRcvXsyYMcNwT6BTo0YN/OsYmtt7MyaID4nbxo0bTX/ZZ4KS5Nat
W61atVIWGdF7HmGlgdatW6PYsGHD7H9BnVgJuNWCBQsMayEYBydMmADylTFj
xhw5ctSqVQu8UlE8O8SKIW4ZXcfBoOUC9DZHhagqCSu8HAIYgOLIgQMH0qdP
nylTJrEWT5CcKmOKHhTt2rWTpXVD3rx5Ia049969e1myZAEFVkKZ4XbQ2UPs
sxbDuUOHDrKPgc8VXu9Zy7FbfK7w8uaWLVtWuV8BYWpoaCRCr/BqBISj5jzx
B9MK3+GnJJ4vMO38lEQxFPZTkuaWFlWLqkX1I6r/BwfttGzZstEhtnHjxlzL
KFCggMx9BILlUPYIq6A89BbGpdesWcOrg+UpxWA8sza6/ymWKpfYxo0bZxej
S5cuSSa8MKdhVCvFaOGjwOPHj+m0uXv3bqUM+lyOGywTWxn379+/c+cO7zvX
bcGk7BsDv//+ezYhJiYGP7dt2wbiZne1HTJkiCE5fL464ZU9LQneKcWTEwLT
t9l/tlYCfctERWBwJBTkRG6BnvjSA6TP/pcH4YV4zZo1MySnaz+ENyhJfvvt
t6pVqyqUJHPmzGLLsyOYmyYqKsrxX7rO7t+/HwUMaxEQnNdOfMLCwuSgT3YI
wovvPXv2tN9WevnyPUmwhBd3kB4O8iZiTBo48uWXXyqFSe4UksjW4RRZWg+8
9957x48fZ+Hly5cbLk7afOOEWYujSRDea9eueaiNG+H1nrUce8Yn4aWPd6FC
hZT7pQmvhoZ/aMKrERCOmuN/vhUvP72BmV88bryBYn7StYsnlBZVi6pF9SOq
/weH3CgY5OB08fHxtGnbtWtn52LBcqhBgwbZSwqjetKkSfjy4YcfOspGDt6n
Tx/TZqkyvhB4h/2sZcuWyWIERXjBYuzFGDsLBbjNE8TEMXZNjx49hIQk3SEh
IR999NGqVascXx00bdrUsOUoIcAm2ISVK1fa/wVfRsOnTJnCFKjJSHjtWxTd
0gH7CW0k49mzZxCPZ2XNmpWBuczE5DhuNLN58+b4d+LEifa/PAgvdxxXrlz5
SeJiqB/C61+SgwcP0iW7VatWO3bsAKVC/bNnz+b2Z3tUagHoueFOeFlnXFyc
iM2FYThw4MDff//9wYMH58+fnzdvHpeta9euLRIY2cFzSXi3b99uWPtbBQ2H
bMWLFzcSM14FS3jplgBeKY5cv349Xbp0OGjPFTtgwADD8s2WOwS82JDcEnh1
tFF5a3fr1i1wf764yJMnD5MUc5BigNvf8gl/CS7+smSxYsW81caN8HrPWo49
45PwMgCafYXX3gP2V6MaGhqEJrwaAeGoOalrmb9BJEKLqkV9U0T1/+AQjYqI
iBDJMshDDcu2VMq/OocyJdORK1D2tSGCKVB79epl/tNShTHMC9kXPYE9e/bI
YgRFeNu0aWMvJggvdy+CSTlKy22MlPDevXtMISoA8g5GvGHDBuFgySwtgvrJ
AJ3hOwcRzfXUqVOjRo2qV68e6AP5hUAyEl7U4NFFfo47Yvfu3eXKlePlGjdu
LDMjvp2oVauW44lcx1+6dKn9LzfCGx8fn9mCWBY0/RFen5KAu3FtF6qrlBEp
kOhHbQdficixngSeJLo0g6/RXd+wxUA2LY99KoYI320HzyXhhSKBnBpSQmcQ
asNyFWbE6WAJL4eAHHeLO4XfeustO82vW7euYYXIlg9yUM+ePdsurR0YLNyH
26VLFzMx4pM3GJWaw7lRo0beauNGeL1nLUdRfRJeCiZHNvPuAQ0NDTs04dUI
iNRWUg0NjbQF2mmwV+XUkLCTa9euzeNKAhQP7iCckPnTjUOZkunI7ZxuhJeh
q8gsZEv13LlzvBCT8iigSe+H8NLxWCa8cjxYAUF46aIZHh7uKK0cpZkAA5o6
dWrDhg3lQK/vvffelStX8G/FihXdCC/sfFA2I3F7L8xvbkzOmDEjuEb37t2/
++67X3/99euvv04y4fV5s16R8EKpREog8ERlX6RpeWsbVqgox9P5TmD79u32
v9wIL/MQRUVFyatjIkeSvOkgaZKArbMqZfM4QUqLG+RYCZPe8gWOAtRmWOHL
nj9/LsJnOVbCvcNjxoxx63OFQHGZlYTRTHSkF3tdgyW8XKCUhwAHhd01Asyd
Sivf9AsXLjDCuQhAHZDuMSVx0aJF8V2OouYGblh2G84+Ca/3rOUop0/C27lz
Z2XG04RXQyNYaMKrERCpraQaGhppC2522pkzZxh2OCIiQo764sGhuNYTFOHl
YpabS3OpUqXw72effWb+01K9d+8eL3T48GH7WT/99JMfwvvgwQMW8094mWon
R44cjj6rIDKGi5Ptixcvjhw5EhkZySBCrVu3xkEmXXJ0aQZZoGxLly5Fh3NJ
d9iwYcr+YkXmoAivz5v1KoQXvJJOvCEhIWCgjp1GCTNlynT//n3lLxwh6z91
6pT9RDfCKyeTcgNUOsmSHDhwwLD2ejs2h37RbvpMmR0XkZnqKH/+/Pi+a9cu
fAe5c6yEBFa4BNuhECj6+mbPnv3x48diwXfnzp1yq/0TXuYVyp07t2g+N6UW
KVJEKQl1Nazt+SKNMsA41SLdsOmD7lH+0NBQcTpzdXkjbRLeJ0+ecAZYtWqV
/x7Q0NBQoAmvRkA4ak5A80A8Ef7L3US1qFrUN0VU/w8ODzuNKTyMf8YHFiai
fVvZ6NGjRaNMf6YjKaRj0KqTJ0+S6HG9TLFUy5QpY/wzp60AYxcb/yS8wqVT
gNsbjWAIr8gdo4S9NS1Ky0VASvjtt99OmjTJXpXw/8T3gQMHGlZYYDt1Ej2/
ePFiJm+tUaOGvTZyHz+EN8k361UI7xdffGFYWzj379/vVkZErl6xYoXy18qV
Kw3L+dYxDFSyE16fkoiXLUqgYIK6FxkZ6dhYLjRDq7nEL6NPnz5G4psQqlnB
ggUdUxjT7WHEiBFuXUrxBIGCdjGnUkxMDAd7oUKFRM3BEl4RoFu8axLuFvIp
Yptz3bp1xUEoM9quBHNWpLUjOjraSNxHMHXqVMMliFlCQgIauGHDBv5Mm4RX
JG+Sx2PAHtDQ0FCgCa9GQDhqTupa5m8QidCialHfFFH9Pzg87DSYyvQhzJw5
M+gnD4p4Srt27ZILX79+XXANHvFjOt6/f5+GsZKWCPyRsZGNxMUsxVIlX8ud
O/fVq1flmiFnSEiILAYjX40dO1YuJvYGGsEQXjNxW2K9evUUt9j58+fLd598
3G7Erlq1yrAy8uD7jh07eIqSlujmzZtFixblXwsXLiThlYkDgYYzabJCeOWS
r36zkkx4IR6dV/ft2+etgVwZb9CggawA+M7NnmDNjmd5pyVS4GcPr39JmKyZ
jgfKVbiHl7G17UBVVAzFIfnWrVuMPyYW/qhm9mhdW7du5VugAwcOuLWCLZV1
j67UYNNs4MCBAz16JuCdZSJduRJycJy4fv36S5cuLViwAAOTGXjRIdC9ixcv
YgBScjmfkRmI7j179oyXY28fOnTIsNbBQW+VYlTgTz/9lEfSIOFdunQpfbyV
qGXePaChoWGHJrwaAeGoOY8ePWruhI8//jgyMnLNmjXJnj9l586dqP+nn356
s1K9JEHU/v37w25/I0T1xrVr12C3gE14FwN/Wb16New3N1Fh7cyZM0cWFbbQ
5s2bz58/71YnaoN1hzIwch4/fuxWrG/fvrAGRa/evXsXAv/666+///77vXv3
HE958ODBkSNH9u7dy0wxHkCZw4cPB+xVyBkbG5sWdNX/g8PbTrt8+TJ98KpW
rUrXRBjtjEYbFhaG9uInrrh9+/ZSpUoxhGxQhNdMXPUwrIBRjHmL4yTazH3T
uXNn02apghXSObNQoULgF1euXIEiLVq0KGfOnFynA9tiybZt2xqWS+SKFSs4
NKDGMNFROW3yoAjv7t27mZkIfBknQnNQG9g3jHlet2HDhijG5DvFixeHlQu9
RRdduHABTYB4OP7111+zJ5mnBucOHz4cCoZWYL6lIze3/YI77N+/n/0za9Ys
qhbaPm/ePPYh8O6773LBjl1UpEiRJ4nrR69+s5JMeKdMmUK92uoOLpKiZ8gT
P//889OnT0PIGzduMJpZ1qxZHRdSzeQgvEOHDm3WrBmmCHHEpyTbtm0jdwOF
hD6gzKlTp2bPnk3SWr9+fbF+2syCvAueQZ9CQkJmzJhx/fp1ysaIWFWqVBEn
oloK3KVLF0w+uER8fDw0kBorqDcOon7B8gg7gYKKGpa3NsfywYMHPXpGubPR
0dG4hEy9uQ0hc+bM586d4xHMsVRsgQYNGuAqHCkC6DQMduXW8C8ow/l/4tix
Y+gr6DavJQKdMW4ztHrJkiU4iCcO5nlcjkNeNO11E157t3AihQ7IrTh79uxv
v/22ePFijnTD8i5QImy79YAdflRdQ+O/AZrwagSEo+bACOSUm/ufEAsleBw/
fPgwGXWVyTcdHZP+ZcDzGg/9oE6B8QxrNrUF//+AEc40iwRYhlsMUjMxwIjb
mg7MOZwOc5E/YSZxrYSoVKmSHFjVtDjj4MGDaeMRFStWtMe9MRNjoTD5C0hx
//795bPARGbOnKms2sAgp3ELZMiQ4csvv3QMZWNaywcwY+wLOgpgfKJCOcHi
G4GACxNiS+yoUaN4hNkwCRABLuSB3G3ZsiUJhBfzT/v27Q0boHXcBkh73k5w
YEly9VYG6N7atWsNKXMKbFoRMwpzGjcmQz02b95sj9IckPCaVjhfViIDdiz3
b3bo0AFlwFAKFixoOAHtEpoGdi8PAYExY8aw9zgVoAeEogpmgSty8Zf2P2gs
BiZ/onWwxpPlZiWZ8JLye0NcDk8EBh82LH9v0knQHI9YxK9OeB2b7FOS6dOn
c1evgqpVq8r0lgeVxTuGGiPE3SxcuLDCaHAJx04Dy3706BHLOA5ex4syuTZQ
qlQpeSYMSHjt4wLTMr33q1evLgwDcOoWLVqgORh3gwYN4isXTB1lypRBf+bP
nx81xMXF2W9NQCXBLZg7d64ojyHDNV8FUGw5/tvrJrz2+v34/6C8HBvQZw8I
+FF1DY3/BmjCqxEQjppDwmvnZXgs7t+/v0SJEvj3q6++SkZd1YTXA4YVxzW1
Bf8/3Lp1CwzOsJY81q1bFxUVxVUMx9CyZ8+eZYZHN8ILqgtziKsYYCuwGGEL
wXLYsGHDiBEjSEaE6yzQrVs3w3rfAqN906ZN3377LZgLTrG7802aNKlp06b8
3q5dO5xVvnz577//HkYIPun5Ke+pZOTYKlWqzJ8/H1YZX787hpqBfcLtdd6E
986dO1yY+/cRXjOR8YFtCZN1x44dTZo0QWNxOzBFDBw48Pbt26dOnWJGGJbx
7xyIqSY6OhrlQTFweqVKlaZNm4Z5iVYl6LDpQnDu378/ZMgQGN6geLjLuK1g
mtycKycPgmZCl0qXLg1pcWlw0hMnTuB40aJFcTkG8PFPeIHTp0+jwrJly+L0
cuXKTZkyBdLSy7p///4sgw4ZNWoUGBCGDMQDR2jevLmclogAeRk/fjykRZkc
OXLUq1ePMXnYe3PmzDGtKRpqjKqg/9myZatRowb0Fp2G42hLlixZQK53796N
msE1eLmOHTuKS7zKzUoy4UVDAhrw8uXi4+PB6zE/gLngs3PnzrxHbnhNhNe/
JGfOnOnRo0e1atVwR6BImH9+/PFHx8U7u7cqbjHmnNy5c+OOQC0HDx7smGAL
z1/oHtgiioE5tmnTRl6PNoMhvHwbY9g2/yaB8JrWAjRfC0RERDjmmPYPN91A
51eoUAHqbd8vjyEzceJEUHhoPmYMTOOwT5Rg8mmH8GKIYdB17drVbbBowquh
ESw04dUICEfNcSO8BF2wYIImo65qwuuBNEV4YYkprztANtOlS1ekSBFht+NL
9+7dYYSL9KBuhBecUaRjqF+/vvHPNK8wF3GkZcuW/Hn9+nXDWoqSX4kvXbrU
kDZqCYSHhy9ZsgRfjhw5wrNA1cW/sIVgF4GvMf4qjRzYqKLM06dPIb/xzwSa
qBA0gU6A3oQX1ANkmXtR3zjC++8D98k2aNAgha/LGE3KZmENjX8lYBhwRyom
UjzQHeNraWhoaLwOaMKrERCOmuNNeBlYsnDhwvJBMIiePXu+8847OXPmLF++
/JAhQ7gdScbu3bvbtGlTokQJnNu8efP58+eLZ6IgvMeOHWvbti3K5MuXDwxI
9lZduXIlTr9y5cr69etr166NC6EeFJa9Xv/zn/+gjPJqF+VxUCwC4iqdO3cG
JZk1axZoe44cOUqWLNm7d+9r167JZ+FCPXr0qFChAi70wQcfcIsZ6mEWe9NK
YjJ58uSqVavmyZOnQIECdevWtQfz5Fadt99+u2LFiuBHZ86cUQgvunrGjBmo
H20Bk8LlBg0aJKLu/PTTT7giegZ/4cvs2bNxEBQM35WYM5AKB9FFSl8tXLgQ
3Zg3b15Q5m+//fbFixcnT55s3bo1CCB6uHHjxuCDcj2gnzjRY5mGwXOUCCGM
9iNEwm39MBF043QkvM+ePUO7+Bc6nwsTspkE1om7ExIScvfuXfzcuXMnyrRo
0UKu5NSpU1yZlQ+CwIaGhjJjyw8//GA4BbrhRk62dNy4cfg+cuRI5d4ZidtF
iWnTprFR6ExvwsuYMORZmvCmDIYOHYrhM3PmTPtfjMzjkbflVRAREYHr2sMO
i3hEGIOp3TcaGikBPAKE3z4GxTfffIMjeFhgKr58+TIsBzwiIyMj8fR/YgsS
rqGhoZFkaMKrERCOmuNNeLnu9vHHH4sjYIJghSAmzZo1+/zzzxlWAgzuzz//
FGVAFlAhuOEnn3zSvXt3BkgBo+S/JLzghiA4oGOgHvhMly4d6hRBJ+gfCD4I
LgMagjJcEwRxE+SaOSDkHAdmYrAUXII/QVhwFZQEvYIlPGzYMG6aq1atmjjl
6NGjlLBBgwYk8oaVBhGfW7ZsMaUgkPirT58+sKW58Ad6JSrBQcPa9tWqVSt0
F1hn7ty5YQ+IjkU/cxkRAqDfIAwvVL58ee7pA2/FiYa1mRpfWDl4umGl45Tb
yP136CK5r9DVuAsDBgzo378/Q7CCLWbPnh32xogRI+hhiGbKWSa9TXRYKfi3
bNmyynFGGXLcaEz5HQnvhg0bihUrxu979+51XKhlYF5YSqZFijNlyoRulN+l
8OZ269ZNPgvNB23n923btg0fPtzu80zloXZ16tQJ3/fs2SMXuHr1quGS/IW9
7UZ4mVgHimpaq/Oa8KYM+GajXLlyii2N+0jllzNdJiOo4cyUJGPTpk2Gtd9Q
iRqtofEvxs2bN7/++ms6t3hAiUOuoaGh8SrQhFcjIBw1RxDeY//Ejh07vvvu
O7BF8BSxxvfo0aOiRYvioLxWGBUVhRrq1KnDn6dOnQJ1BVG6fPkyj9y9exc/
UQbU0kwkvMDatWtFJePHj8cREFL+JIkD2+UpBLdn/vTTT/zpk/DiZ+nSpcWS
Ltgl7GQcPH36NI/UqlULP1evXs2ff//9NxNcCsLL7TkfffSRuArYPakrf5L1
4KeI5Hnjxo2qVavKbxJoEoNHyzFDwElxUF4wUlya/RNetJFro6bF+yg/Thdn
MdUFdywKsVHz2bNnHRWDKRfBlJXjoLqGLbMG4UF4O3bsOGTIEH5nXkt7tkqu
zYl9auixnDlzgkIOHTp06tSpuPsgFM2aNbtz5458Fmi7Wx4Qgqu35cuX5w47
cn+l1S9fvsSdUjwZ5N52JLxQA+67ZM2a8KYYwCu5nbxatWqxsbH4+ccffyxc
uJA7qTHbMKZ0smPr1q0cWe3bt4+Li8MwP3jw4MSJExkXK2BkMw2Nfx9u3bq1
ZMmSTz/9FHNsnjx58PTPnz//O++8g6cb5u34+Hh7pmkNDQ2NJEMTXo2AcNQc
EaXZEWFhYbL3Lxd87fkB6fZ54cIFM5GHKhwkOjoaZdatW2cmEt6IiAi5wIED
BwwrOBJ/KhFgCCa7FCTOP+FVCGPv3r0FL2MCiFatWskFwOtpTpPwMlBtly5d
5DK4rnB45gLi9u3b5QJcxxSEF/waYiixREaMGIEyGzZsEEeSTHjpAk3A2udK
sXwWPW9FzwTErl27UL5t27bKcUbBFev1MtwIL/ozW7Zs4t0F35DYtYi9AR3j
z9u3b9MVWSA0NFR+SQIcPnwYlNMe+lLUwJ2VuXLlQkkeZIhR8XJAAKZahgwZ
7JvR3Ajv/fv3YeCB4YoBoglvSmLTpk1yLG6Bt99+WwzM14ExY8Y4TpU1atSw
K5WGhoaGhoZGMkITXo2AcNQcEt506dJN+yfGjRvH9HblypUThhzpA/5a9U8w
cw3X5kh+PWw/El4moxRguCGF8CpEjzGLkkB45di/AHi04GX0jZSdk4nmzZsL
wgtGQ/5bqVIl0DQwWcWRMn/+/FmzZrW3FFzM7iv+4sWLEydOrFy5sm/fvnS/
TBbCK1fCet599135CPeu+ie86B9DiiIlwPXZnj172k9xI7w4BdxQaZQ9JyNj
ZDEJxfXr18FMwUBHjhyJ7rp69ermzZvpEz5+/HhxSmRkZKdOneySgAKjfiZy
jYiIOHPmjPgLkuCgPbgodxD7J7zt2rXLmDGj3FhNeFMYFy9exIwRHh6eJUsW
3D4o/DfffOMY8DZ5ERcX16pVK+gnve6hYFDa17SmrKGhoaGhoSGgCa9GQDhq
jvceXoZREonwmjZt6rEcTGfjfPnyObI/AccozY6EVyFxSSa8V65ckcvIhJck
y04DIYkgvEBCQkL37t1z587NlqKBbdu2JY8GgcWRMmXK2FsKbiU69u+//542
bRqMcyZ0gJ3cuHFjMri0SXgvXLiA8u+//75yfM6cOYZLNFo3wgt2IJdn6O8B
AwYoxXhDY2Nj8Z1e5Qopvn//fpEiRcCC6WOPLsVPlpcBaswMrTVr1ty0aZPy
L5MQnTp1Sj7IUYDa7I1yJLwMUQXOu1GCYeX85XeRK1NDQ0NDQ0NDQyNZoAmv
RkA4ao434V2wYIG83ZKUJD4+/rkTuFWnYsWKKONh8L9Wwku3WP+El+61zHcp
AxxNJrzEy5cvDx06NHPmTDAp/JszZ07uUy5QoED27NntLc2VK5foWG5SZo5R
sX2YJDRYwhsTE5MChJd+0XYOOGzYMByfP3++/RRHwnv37t3MmTPLMc3279+P
Yq1bt1ZOb9SokZG40Zsbq5WbC3Tv3l04zO/Zsyd37txQPLnAihUr0OdvvfWW
0mkCDC8GUiwfPHfunBFM0Crmc/TA+fPnffazhoaGhoaGhoaGH2jCqxEQjprj
Jw+viIs7depUwymuL+z/kSNHMtowQ0vJOYZMa0UsR44cYJdmchNeJdUOGa5/
whsbG4vvHTt2lAuA6xUuXFgQ3l9++QXScoeyAIP9MpMs4yApRI8ZnUTHMlLW
jRs35DJDhgzxQ3iVDh8+fHgKEF7RLjluGADOni5dOjBEe3lHwrto0SJFkidP
nuTNmzd79uyyZ/i9e/cyZcpUsGBBuoZ+8sknqGrbtm3KJXhD4+Li8L1v375C
YYiLFy9mzJixZMmSSrIqGdHR0aihX79+8sGZM2catlxFhCPhxYW22MAVXn53
21asoaGhoaGhoaGRNGjCqxEQjprjTXgZf7hx48b8ee3aNfDWQoUKyflwwQdR
pn79+vzJDKpVq1YV0XRBhKtVqyZ4SnIR3oEDB+LnjBkzRAGGUw6K8EK2sLAw
NF8OX8zMO4K2c3FWBBkmGE9px44d+L569WoSTMFn79+/z6jIomOZhEiEcQbQ
h0yHpBBedJ3SZDkRT0JCAnf+vjrhXbx48bRp0+RbqYCvO1q1aiV2tnJx2b6x
l3AkvFCeqVOnKiWHDh3KzeDKEeHDzIbXqFFDzqO0ceNGcG2QYty1Fy9e5MuX
j/0vwNXnqKiov5zAFzIg1Oj2nDlzikXnmzdvli5dOiQkRMQVl+Gdlkjp8zdu
Dy+HzNtvv+1W4MCBA9wKXapUKfEa4ffff89sgZpZp04dfK9UqVLyysaXHtRz
Lql/8MEHqd1hrqCEGPWv7xJMjoYLOf6LEfHpp59y4vruu+9Ssu1//PEHr5s2
4/HKt0aImtpCvWFI+wPwXwxYRxjRDRo0KFmyZGhoaLZs2fClUaNGMKLsTlCp
Au+pSUMjeaEJr0ZAOGqON+E9fPgw7WERhGrhwoUZMmTAlNumTZsRI0a0bt2a
KXfl+MN9+vShN2zv3r0HDx7MfK9KHt5XJ7y7du0C/cmYMWOvXr2mT58OSoLv
5KH+Ca9ppRqBuQ6+065dO9AuPFbApBh4mRldYeejgTSZvrbAvbcoKfxp0Q84
UqBAAYjxxRdfFC9eHF2EYqJjubkYxAr0GQSwY8eOmTJlqlKlimHlKhLCkEdM
nDiRm08vXbpEuoF2oY0DBgwA2+Ua+qsTXu88vKZlQrMf8DiDSN27d4fMkMft
IWsnvNevX0fH2tdbcbxYsWKGleJ58uTJdCCHPHLKIXSRYeUOhuagzxkYDQLs
3r3btDbqgl0qMaZYxg1CsCVLluAniHNkZCR0mHGbR40a5dio/2bCe+jQIb5d
URbNOVqNxGTKjFPnuI39VUDCy2X3tG9vU0L7nvdkhIdViYFAX/2UZ7umxCKZ
nyutQb41KU94Me3giWlX3WfPns2YMaNOnTp5LeALfsqhz3i7vYHxy8JMHO+I
2rVrizpxgxYsWNC8eXNMeqBOGLN4cjkmknPswxQegGPGjMEVPZ5QqYvXLd7f
f/+9ceNG6K23DkRERPCZmIrQhFcjJaEJr0ZAOGoOLCXQTFBUt3/79euHAuvX
rxcHYQaDSIIvgG8WLlwYfMS+Y3H58uV4zoIccelnzpw5whb6/fffUSFmcrk8
zGkcFBnqQd/wU0kvEhcXh4PiEW9aS6vvvPMOeC54JfjdunXrjh8/jjK4BAt8
//33+KmEjF65ciUOyk65J06cgA2QK1cuWCYwPE6fPk2PZWHko9r27duzyVmy
ZKlYsSJo2oMHD0QNeDbBXKlWrRraC3kaNmx49OhRNEd0LApERUWVKlUKooJQ
wz5Bc8DESYp79+7NYhMmTABTxqXFiSgG1pk1a1byZfB9NAfyC4br2Fc4oti9
sbGxcs+YFlPGEW9r59GjR8OGDaODNxresmVLJbOSjHnz5ikd++OPP7qteaHt
3bp1y5kzp2FlUMKJ9sjJuFN43ONfdBG6DoxbpISG1tnDXsEC+dwdsmC//PIL
eh5kHDXjbnoYLSdPnsS5bjuClT5X3ADSPjwIL1gtRoSd7QJnzpxpbGHSpEn4
+dVXX+F7smehJeEdPny4ae3XxlXkvNJpDWQEtWrVen2XcLMqMUtjOND6lWOY
pxgEi0yboarlW3Pt2rWvLKTMpTFXlyhRwk4V79+/Hx4ebicvOCh8WoIivMxA
7U14oSfMPmDHiBEj/PRhChNezgDffPNNSl40jYgHzWH9fO7jKbxr166LFy8+
efIEOvzbb7/B3gDVZQGYJVBpujClCjTh1UhJaMKrERDJrnUB3+eD5dnzvCQ7
XlpI2rkgrbt37xberaJFYEN4iNifIEqIJMc+8fbrs3ea/YjjVQJe+rXi9Zmy
fmp+TStHuFNpc00qxeBGeI8dO0avBu8N0a8VtPeGDh2a2p3kC2QEjnHPkguO
ViV0mInFU4vtmhLhVfK1pRGkwK1xg3AyV6gig+9h3C1evPiShSVLluAnDuIv
ljl06NBWF3DTTYUKFdjhmEIzZMhgWO469sIHDx5khUxkj+daZGQkHnmPHz8+
fvw4JZG5s0cfasKbMuJBH/gGAyqxYMECj0c/7qCgvS1btkytAagJr0ZKQhNe
jYBIbSVNi8BDP2vWrCVKlJBXgTds2GBIO5c1NP6tcCS8J06cyJcvH9muEqst
JUF7UknYnWZBRlC9evXXdwm7VQm2++WXX9LctSe2TjEIwps2Y7WlwK1xBPfg
2Anvy5cvs2fPbiSmYBNgNIwcOXJ4v78FqSlXrlxISAgYMY+AvZLJevOdQoUK
2d8gQYVatGiB4507dw7Yh5rwpoB4t2/frlChgmGFrwTzDVged3DixIlUM+Eq
lsLQhFcjJaEJr0ZApLaSplEwsWzu3Lk/++yzgQMHch9osWLFPHx3NTT+HbAT
3lOnTjGWWokSJexs12MLpPIXTSDU//TpU9hjFStWzJIlCy5Uv379X3/9VfaC
wPdly5ahfM6cOVEmPDx88uTJOIv2JHOiOdrbsAyHDBkSFhaWOXNm1NylS5fz
58/bJUT90dHRdevWfeutt0A03nnnnTFjxly/fl2uClarsF1jYmJQOFeuXKAe
VatWnTVrluLpsW/fvjZt2uCKmTJlQi/179//2rVrlLBatWqiGNjf+PHj0fDQ
0FAUrlOnzoIFCxRKInrpwYMHvXr1wkXlIO0KFKsS7WK6aje262GQy39RB9i3
4FBoGhQAXVq+fHnUrwSWv3jxImMUoO1o1Mcff3z48GHR5w8fPvTf52YwlGH/
/v3scwhWtmzZnj17Mg26goC3xlE9Nm3a1Lx589KlS6PywoULQ+xFixa9ok/L
2bNn0fCMGTNCVEV1ExISKIMckc+0ItXzuPdbJobmQ3+KIxhQHLAeZ928eZOV
i6R4AoxpgHvkcbo8ADds2BAREYEnJroL1BtKgk6WC6Nd48aNQ4XZsmXDiEYZ
jGKljHe3czzKUHQVpy9evBj3FPVDx/DUZr4GjCP0D+ssWLDgRx99ZI84cfDg
wR49etSsWRNNgIRlypTp0KGDsg02aeIRYKl9+vSBCQElxGfLli23bt2q+H0J
Jfzzzz+bNm2KKUJsh+H7B8w8YjSZ1luOqKioKlWqoL2FChUaMWLE8+fPjx49
OmXKlLlz55qJoTXtK/XQjQ8//DBv3rwcEdBG4c8mgnw6gveagSuzZs1qf5d1
9erV9OnTG1boTjE13bp1C/qAC+FyuCj6355qwbQCsLRt2xbzDAZIvnz5mjVr
tnr1armL5Elp8+bN0KUMGTJwH5xH12F2wncoJ+4X7hqmqYYNG/70009+vONO
nDjRtWtXnAiRMIFgGlFSjfhUbDGlQw26d++ONqIrSpYsiRMpxvbt26GumOpR
Q6VKlXBbU9EX/Q2FJrwaAZHaSpp2ERcXB7Zbq1YtGNvt2rWbNGmSRx5hDY1/
DRTCC2MYVqIb2zWDJ7yxsbEgelx+4qoWMXPmTBaDAclYZwpq164NYwlfBg4c
aDoRXlyOosoAZV6xYoUsBmwMRj9TACtLuHqaEuGFAcMCjNZFwPgRxtj06dPt
taEDBw0aZEiR4mAFMSO5ApjoMu9jL8GiY1B3459ZyRTIhBfyfP311zxFjnYu
I1jCC+MWthm+w5zD/WLlsvcLSAFj6MkICQkRxjYZnM8+N30T3tmzZwt5BGAA
K9nA/dwaRUvRjSLYl4ImTZokeb8DtJqR3MBH7KoLIsN+Vixq/DSsuHweT59D
hw6h4WBDMh9nw4VL0suXL+3bag4cOJDHgt26BiMwrI2iHi0Ska6F1jHLPL+D
1t2+fZslz5w5w23LClB+7969Prt9wYIFmAG4q6JIkSL4jiOyrvJVD7oCrIEn
gpRBP8uXL4/v4CzgOzwOZZY3ZaAhdl0iwGdfUTzTeuUiTx0CoNgy7eLB8+fP
8+2ikZgGgu8uwMTlSJvo0rJlyxpWCEdwQ9wpfO/Vqxcd5jt16sSbDjEMKYeC
7P4hA52DkU5RCzmB7vHUWOgqe1KJimkm5kxE83FpTk2jR49mLEoF8ssZMzHM
ph1oiOgicaNxXcoDyITX3nXQcMeeN6xtAt4bzTAEMI/ZT8TUIU70o9hm4iw9
d+5ceknJT72ePXuy0wzLkUMct0cj0fCGJrwaAZHaSqqhoZG2IBPes2fPMjoZ
nuBua0zBEt4KFSrA4FyyZAmoECyHo0ePMj8XjCiudX7//fc8C6QSwoAnwuxv
2LChYgworAGMgFZfgQIFwHBhHEJg2JwweBjeTYjB3Y6gxtHR0ZcuXUL9q1at
olWGwuLlPAkvPQmHDRt29epV0yKtHTp0YG1MWxYfH09rGWR27dq1ly9fBoNj
1HeCy2RoKZtQo0aNbdu2gQucPn166tSpNM5r1qwpfFbZSwzE2rp163nz5imZ
tmQIwov6R4wYwStyBdwRQRFe9Am67sMPPzx16hTqf/z48eTJk2V7FfcLxq1h
vVWAOYcW/fnnnzNnzgwNDRXNJzX22efAxIkTYcCLWIWO2LVrFxXmu+++g2y4
hFhRAhjN3v+tUbSUi5ugALg7CQkJaCMUCe1lGcFiggXvTkREBG60o3MCaSO6
CNTjlgV84QucwYMHu1ULqlW5cmXDlvqtb9++NKejoqIqVaqEvgIXa9CgwezZ
s/1wdq5Bt23b1qMMW4GOIn0AhYSSYBgKJaEugU0zGBfsfCgJWAmGEppGb2rM
M3QY8NntdgWmrkLlQE+mTZsGOoYeXr16NQUzLHq7ePFiVIiGL1++nFxJbIuA
VpC+Qc+hHg8ePIA6YWjXqlXLsGgm2U2SxcN95EZs8OXffvsNk96RI0fEFnvZ
mZxHMPAxJ4CWQuYTJ07g6pyCMCuKkhgv7L3PPvuMcyaazPdybAvZq5mYHhFN
5gsTMbVCo44dOwZhMJSqV69uWPEn7e4WxPr16zmO1q1bxyPMoWCPSchZi33L
8UjOiBn70KFDGPhr1qwpV64cZWDCCwBTAY989NFHe/bsQf+jo0QXiXd3vNGg
+bgpaP7YsWNxNzl1OHYdjlPxwsLCfv3115s3b6IT0GqxRR2PHjfdxj2i5NAK
iISOQoWdO3fmidx34FOxRVdARatVqwYBcE/R1XL+iCZNmpw7dw7H0UXMgpE+
fXo5AqpGQGjCqxEQqa2kGhoaaQuC8MKuk1/OK7sLBYIlvIZtGQu2BI/DKMJT
nvbh559/Lr+Bf/78Of36AHAW00Z4YeuSmCupk48fPy6WA0zLRxRGEUwUOf+1
admlJBdiy5vwUWQWJAFYmDRpmEsa7Azfq1SpotgnwuwHHzETl+pg8CiudHv3
7uWiGEi60kt+tr8Jwit7VMJWdyM1QRFeoE6dOsruUWZAa968uZmYWA39KVwi
if3794slM1B7/33uE7Sr5TQBpmXzN23alCYxNcfnrVG0lGatfZ94y5YtDSl+
VFAAH0eHgHJSOR0JL+QfPXq0stQI1cUd8djAC6plOKVBb9SokeGCmjVrOlIb
0AHQB9AQUCdm94uLi/NoFFth/DMpvNyHVJLo6Gg2RE4HYFrur2AuQuV8drsb
4TVsi4aC1ygvT2TZzEQHXcw5ys4C6CpPZ76JJIuH2cNIdEqRwT22mTJlEi8S
eTkwVtA9UYzp3qA58vI9A2t36tRJVgzwL77ZQw1C4fGF1WKORQO5AK0EssMw
5MrjjBkz7Hc5Pj6eSSLkqN3cio6z5HlG9BhvtJjHMEvIFYpo5BEREaal9kwC
iIlF0XO+I8LV6SUibjQoM2SWSzp2HcrI8ghgcmD4L49EDJw6FI8O8dKydevW
pm/FFl2BzpezTuC+U7zy5cvLLhZnz54VT0NTwzc04dUICEfNeeIPpjXH+imJ
eQxmnp+SKIbCfkpyitCialG1qH5E9f/goF0BM6NkyZKG5RXJFdgCBQrYs0SZ
wRNecCilGAwJOp7h0kzJjasrG0VNK0w0a+vbt69pYw0w4w0XV94uXboIMZYv
X264xHn+8ccf2UzSJVJIMDXwNaUkrVwUAJtjzWJVUZ5FyYsrVKhgWgmqHIsB
XDLGp9xLOMvb404uTAMS9p7YwOuWeDdYwmvfbccXC+x2XtexM8mLAdxH/33u
B+CMhkuAZUZqAvDF/61RtLRNmzaOxPbx48d37txJwrILDG+6SYiM546EF2RT
JJ2RAaplHwtCJNQMcmrflMrBmz59+lGjRh0+fBhiHz16dNiwYVy36tixo702
elwT6B/7dkUFgvDaY7bLSkL1xhi01zB27Fgj0bHcZ7d7EF6llyiDWKJ1lM20
eMfGjRsVv3oqCatl4I4kiwc2hz63qw2YFLUCQ4BH5MlNgLuze/ToIY7s37+f
g90evYruFoLLE3SgxVlopmG9ErQLA4GrVq1qj+gOneQ7TxA9mfqhyVSkXbt2
KR0L+sYO59RUtGhRu8M8Q7EBeKBwzEJRlZdmpvVykjkK+WpL3OiYmBilpGPX
oZloMoa/fW6hqru9UXz06BHfO9nzM0ISdBSUwfSt2KIrFPEAPvXEXh4C0tK3
2TtGuoYCTXg1AsJRcwx/MP2lBeTItYd0cASKeYdNEOADS4uqRdWi+hHV/4ND
bhTsHFh08fHx3GAIFmM3HoIlvIMGDbKX5KouLj1p0iTDciRzlI1mPBNSK6yB
L9XlN/wCy5YtE2Kwx3DE/loARi+LcSGSJWHe2CsUZu2BAwcMixQ78jWuMZUr
V060HdTAft2pU6fir1KlSsm91LVrVz83S6gKbhCX4LlVNmPGjIzY4ya5919C
B5QYSnK3o8n0x7aTBTPRBRSAzey/z/2Asn3++ef22qCrtJCXLl3q/9YoWso1
U8OK4Tx79uzz58/7J+N24FxypV69etn7UByB5U9Xz8qVK69evfovC/hCd+VK
lSqJ/bAyuFRtN7lx0f79+8PAtpNWsZ9dOJQKyITXsN50eQdpZCtAjd3+YgOr
VauG78uXL7cX492H2Q+BfXa7G+HF8HeUwZ4F2zu4NC5Kx9TWrVtTHnZC0sRj
cqiyZcs6vodkRALhGMz6lWVHzISGRIoBbsK1zw8goaxB3sYu4pJB4BkzZhiW
27DpD5CQrhQgrfZXLvTIlVeuqT+CNXNq6tmzp73mly9f0vU6Li6OO5TDwsIc
ZeBKK6i0KU1KXHOX4dh1dty9e3fbtm2RkZF0qnEjvEePHjWsHbXetflUbNEV
CrE1E596W7ZscTyuCW9Q0IRXIyAcNcefYa5JhBZVi/rGiOr/wSEaFRERIeJw
kocaFm1RygdLeO3PfVN6xHPzIIw6R9mYX5LcQTZchfeaIy/Ys2ePEKNTp04B
uwsE30wkvHyZr0CYtfRqAx9xlJYbV8uUKYPvXM3xgLDY2UtuS7QKWBhsF3Yj
j6AH6CdcsWLFJ7aUNEERXjuJkLudK62A4l6o9Dnog/8+9wOmjvUGdMz/rbEH
rRo7dqy8DTlfvnygP6A8SVjenTdvnmF5WctRp+ycC8SB0iq3DAOQgc5E1FmB
J4keqkG5PqJ1VatWdRuGz58/v3jx4oYNG6hXsPkTEhLcqnJjlEoDc+XKZVgr
jPZigo7hi89udyO89rzhbsTWfhy0FNNax44dK1euLPb7C5DwJk28M2fOBNRV
McPwp7KqCJXAwV9++UUcIc8iB5Sxfft2w4oEKO+I3717N0UFxyRTdpta7XrC
l0KYWxzfaM2dO9ew4teR04GEUv5z586xgPc8xkhi6HbScLeEj/369cO/+BQ3
GkzZ7uHv2HWiW7744guQ8bx58yo970Z46eXuNnUI+FRs0z1Dkxux1YQ3CdCE
VyMgUltJNTQ00hZoV7z11lty1okXL14w4CeOKx6MHoRXOCHzp0dmRvGIp4Xj
ZpVxZyJXDWTDFVYWL3Tnzh37WXFxcUKMJk2aBDRBGWCThBcWrL1CYdZ6m0Yw
9ozExQsRIdYNGTNmDNhLdjhalZs2bWKd9sV0D8LLhUiZ8NpJhNztwqhzJLww
PvkveLH/PvcDkWDUA+PHj/d/axwVGKwBXObjjz8uUKCAqLZQoUKyD2dAXLly
JUuWLCEhIegNeWkPZNOwfPvFjgM6jjqG6qJ/QsmSJZXjgtEHuwBN73rHpTcB
SEVe7OiPoWiC919cc3fkBXfv3mXHivjDAbs92QkvrkhSaVgRw1q0aBEZGQk2
J9zj5WXuYMUTM48HGjZsyML2ywFUDOEMDxQtWtRwipDMKE/vv/++fLBXr15G
4nIw3yXadxM7gtvzDSu2sGMBdAX9fhn6iW9E5bcf3oSXrgtolxJOXAH3aEBj
Tc9JybHrMKwYs9qwXt00aNCgb9++uBxUkWkC3OZYjizhkOwG/4qtCW8KQBNe
jYCAkqS2nmpoaKQhuNkVZ86c4fIHI82K4x6EV+zV4k8/hJcbwdxcmhlshE6A
suEq0pUePnzYfhZzrFAMmoVKvCNH+CG8uJzh7jcLOY1EX2XmELF7CNuRBMJr
L9ynTx/DWu5RIjx7EF6uHPknvGKvmeMCEMPaGJavsv8+9wM65Qa02/3fGg8F
Nq2lroSEhKioKIbWsUc38gAjDgXEuHHjuHTo2JN0j0RDlOP16tUznFb6AoIB
nHFTcJcXLlzoRuG5D9FtJJq+CS/1CmPQXuy3334zrA379nvk1u3JTni5ExNX
sb9ycaRRQYkHVuiHOnlcjqEJ5OV4BlVWooXfvn2b+wsmTJggDv71118MVc2N
HuSkji4rjx8/vnr1qvBbBpsmmfXO3cO8aYwVVqVKFeOfoaS9XZop7bFjx/iM
oK+FHQxUyPCAwRJexgfAyFq2bJkSxcJ7juVuCEf/lhcvXly1gCb4V2xNeFMA
//M//5PadEojrcNRc/w8ow3tJqpF1aK+OaL6f3B42BVz5sxhhdOnTxcHBV+w
EwGRXZE//RBe0CLDJWjVyZMnhRlm2gxXmEyGLQApQXZDMbhhVjYLBWDBxsTE
iKUTP4RXEO3NmzcrZZ4+fcq1mBIlSpiJgVUdlwPAaHBdERE3WQjvgwcP+HIA
MoicuUJye/woMHG+zfBPePEdlrxh5WyyF2vfvj175sKFC/773A8OHTpkuCwJ
PXr0KMYCmuP/1iiEF+YxOkH2CyXAKRiox3FztCP8E14upy5dutReCV8dwLqW
D3L9EfI4xlsG7yhWrJic60oGOdSsWbOYjNgx/JeZuLjGgLSO8El4qXKOe9K5
zg6u5L/bk53wcu+/PbKZ0B/SqKSJB76DqUzxlhGIjY2Frp49e5Y/5csJMDq0
vPGWIfj4xolHcJfFUub27dt58M6dO2Rk+ItHmKIof/789ol6yJAh+KtVq1am
5ZbDsMwY3Y5iC9AbGbeP2pghQwZ7PnHHoFUYkob1Og4DlqMvffr0Z86cUYph
FPPuMB1SsISXLiuOsfJIz93mWBHvzp63iIG/IBX63Kdim5rwpgj0Cq9GQDhq
Tupa5m8QidCialHfFFH9Pzg87AqYWHRPzZw5M+gnD/7111+8irJUBOOHUSiN
YAgvjByaW0paohcvXjA2spFoYyiGK8k1TBEmzBWAnLRIKQbpEqw+ZXPis2fP
KJ6wD/0QXjNxoc2e+4Ysz7Cy2YqfDRo0UGxIkcNi3rx5AXvJDo/Ce/bsYWwW
2STjvjyIoSzcDB8+XFYVn4RXBLJWIqyCwov0OufPn/ff534g9q7aSQpbUaRI
EUaU9XlrFMJLL1B7l+JOsT/trCdY2LkYV10rVqyoqAd+Mg2rEuJ1woQJhjtX
FaHA5PhFxNq1aw3Lfx7Dll7f4Cn2lWU0ljvBubjmsxWOfzF8Ga6i0Aeh+aNG
jfLf7Rx6GOyiQLIQXsETBbjL20ikUUkWj2+6hg0bpoy4LVu2sH4xduTLCZCl
Yr4VWrd3716W7NGjB0hiXFwcLgoZuJiLwX758mX0CTldiRIlxI4D8Dg6Eih5
gkCNGbR82rRpmLSLFy9uWMGcxW5cN4jEOpDEsDkDiKeYokIiLRGjSYM58tUc
WuGWloiv7JJGeOV7QezYsYOJ6jzmWL4UatGihSwS7iDvJrOA+VRsUxPeFIEm
vBoB4ag5qZs/5Q1K9aJF1aK+KaL6f3B42BWmlRSGwTqqVq3K1JAwA5jGMSws
7MCBA/iJK8KAhBkDjhMs4TUlUxMWC4wTWHo4TqJNH9rOnTubNsP15s2b3FgH
4y0mJubKlSsXL15ctGhRzpw5yY/EJllG/oTMsFhAx2CAgaqDA7KMMP59El6c
S2lBTNatW4f+OXz4MGMQUVrwL9OyKskgqlWrFhsbe+PGDQi8atUqxp1GGeHt
nFyE10xcuAFgNvPI7NmzeQTGJGkgOop5V3kLgiK8aALPQifPnTv3tIXvv/8+
a9asbDvABSyffW5aW3RR2HE3qwA3GMLUHD9+PKzNR48enThxgl7chpRO1Oet
UQgv7Vg0AZWfOnUKlBMaCJ7I4FHVq1f3P5TcYOdiuAQHUeXKlSHqpUuXGKWZ
20vxl8Ky69evj+ODBw92rB9jkNF9Q0JCRo4cefLkSbAetB03nbSIIbAwfsk1
cBN/+OEHMC9oKXoDtxJEybDSRcnuAQFb4fgXZgN2Hfp8wYIFCQkJaAtGKEkW
Lk1fDp/dzqEnk6NXJLyMNoxRSeKJPvn999/JlQguLyZZvP3795MRY9bas2cP
Bh3ubFRUFLmnvIDuyNrQexxicpRvkWKYyJQp088//8zw7DLKlCmjkFbxghQK
cOzYMQizb9++WrVqsQMhGMMyYzbYuHGjH03mIjKhjFlOTWzmoEGDoH4YgOgx
RiPH4BXbT5i2jEQS8ty7d++3337jGwYAjwPvG+3WdXwphKfV1q1b/7YAho6G
M+MAMGDAAJaE5JhzMPOIc7dt28YyOA6RMF9BPdjt6Bw+p3wqtqkJb4pAE16N
gEhtJdXQ0Ehb8Ca8prQlVrzBFhYLbUIa1cWLFxerGCzmk/CCnguHWBkwTZmV
kguCdoMWZhL5owyQGq5qwXpnMZglDJmiAGLDbhS1+SS8wKxZs+y1FS1alEay
yNsSFxfHOCcK8ufPDxNaVJ6MhBcmGRlT3rx5yZjADbm8Qogl+HHjxtmjNAck
vKa13iS4rUDmzJlF4CxQYP99bnruMhZ48eKF8OFUAD4rL6X5uTUK4QVVIQmy
A7pkzzmbBDhyMfS5HApJVg8lG/LDhw85xMjFHHH79m0SGTu6du0q3oDFx8dz
6NkRFhYG6hdsKxz/Allg8CUFuXPnFk7+PrtdvMOB1nH/wisSXvSACCiH4cCO
zZYt25w5c5h/HHQV/DfJ4vGKwuFBRp06dXArhWA8aN8yvHDhQsPiWatWrRJ9
BTaHoQ06Wbt27Z07d5rW26ePP/4YM0yWLFkwxkHf7A7JoPOOuZ4xaW/evFk4
LIGNFnJC27ZtlQpFBDlcVPGj4NQEusptzjJQPwagKIkBy8VcO7p06SJ0NVjC
i74Vl8YtFvG3v/zyS8GmoZYo5jjVM7KcHYKA+1RsUxPeFIEmvBoBkdpKqqGh
kbYQkPCaiawEdovYebpjx44mTZrAKMqUKVOJEiXAO2Byg8dltsAyPgmvaZlA
0dHRKA8TFKfDtJs2bRosH1omoMOmi0F7//592JzVq1eHKVi4cOF+/frduHGD
CTtAuEQx8D6YajBoYafhElWqVPnqq68ULuOf8JrWOg6sYrQCBjOY/oABA27d
usWeBGERxS5dugRzC6wcvYTCNWvWnDp1qqOhmCyEFwBnoQ3fvHlzMsG7d++O
GjUKXYq2wzxu0KABk5506tQJXQ3mawZDeIGLFy9+8cUXaDUuhFNgdR87dsxM
tEIFl/fT56Y/wksNWbFiBYRHEyB22bJlcaI9t6yfW2MPWgVesGDBgvfffx8q
hDsFmxbt/f777723NPqHGxe7d+/eyJEj69atm9cCvoAI4KBSjKlLAfs+dxkv
XrwArcCoRNtDQkLy5cv30UcfxcbGKr61GKdjxoypVq0arHQ0FhyhadOm8+fP
D+gW4p/wsmm4CogYeAfuV5kyZSIjI5Vlaz/dDlrXokULEFLc91mzZpnJkZYI
KgrlgW7gorh0t27d6Hu/detWTGWYSdq1a5dk8QhoJioRStiwYcOYmBjFg9eN
8KIYPWlx0ZUrVyZV6f4P8sAhNf78888xL5n/zMDuCHtniljWHTt2VP4SU9Od
O3cw6IoWLcr5AbO344sUXJ3jFLqaJ08eKOGaNWtkXQ2W8JqWbuNJVK5cOagc
6mzWrBlfDmDKeu+993CwdOnSmJfcpnrcNcxmuCLHRevWre0zjB/F1oQ3BaAJ
r0ZApLaSamhoaLxerFq1yrA2rqa2IBoaGhpBA6SMWeEMK7jB5cuXU1ui/8PT
p08Zb1nOFKyhkfLQhFcjIFJbSTU0NDSSAUOHDq1QoYKcv0NATkapoaGh8cbh
8ePHTKBMB92OHTsuW7bs+PHjN27cuH379unTp3fs2DFt2rQOHTooGYteK7hb
JE+ePIznoKGRWtCEVyMgHDXn0aNH4zwh52WIj4/ft2/ftWvXbt68iS9KHsyt
W7eivAjOuWTJEvwUcyO+28NIemDjxo045RVfb+KKdNtLXqDOhQsXJnu1qQLF
x9IRHsFMCDx27Z5L8pYlR7x8+dLuwqcUmDBhguIyBGPA+yzTcvB74iOBJtQ4
oJCm5TrrmBBEI7Xwww8/wPQqV66ccpevXr3KnapiB5yGhobGmwiYQO+99563
43FYWJhH8tzkBX2t+/Tpk9odo/HfDk14NQLCUXNu3LjhPaOKDBoAQ5H85z//
YSibokWLylUxJKbYjMBM5SIeqeE7JzvxxRdf4BR7DoWgwNyR4icI+4YNGwLS
t4BAnXgS+S+PK+K6uPorXjcZcfv27a5duzKWbKFChbp3727vln379jVs2DB7
9uwog88mTZo43g5UlTFjRhEi8tSpU02bNmXEntKlS48ePZp5Q2SsXLkSt4YR
FPPkyQNJlCQmxI4dO95++22eDmrz3XffMdCoYcVj/OSTT+zp/LZt21azZs3Q
0NCQkJDw8HA5XIaCW7duQQB575UjQHULFy4sghFppAWA2ObNm9dIDIOMn3/8
8cfChQupHmXLltVrEBqvDjwc/wgG3ttsNTSCBchsXFwcnqF16tQpVqxY5syZ
s2XLhqfq+++/DwNpzZo1r27MBMS1a9fwEPzxxx/55PUObqahkQLQhFcjIBw1
h4QX9OS8CwRjBdq1awfOu2rVqo0bN+ILGJBclTfhxfw8efJk/yqdLIQXV0Q9
4ifdhOQ166QhWMKLK3I/ziteN7nw119/FS1a1LDi8ONhyoiUIAuywbZly5b0
6dODOfbo0WPChAlgxKCHYJFKAlZg3rx5Ikck/sUTGc/lTz/9dMSIEXzh0KhR
IzlkB26KYWXfGDBgwPjx45lxFcT24sWLSs3oMaakFKk3IHa/fv0mTZrUokUL
0nA5eMWcOXPSpUsHKtS7d29oI5MMfv31146dgDL415vwgmszBoUmvGkNmzZt
YhYMBVCkNPVmSePNhc/M1wJBpcDW0HgjIKIcG1Yg5dQWR0NDE16NwHDUHBLe
3Llzv7oSehPeYJEshFeBJrwEE8GMHDlSHAH3NP6Z/q98+fI4sm/fPnFk8+bN
XFNTaqtfv/706dNNi5YyNcDatWv517NnzyIiImQ/AehDhgwZoG9XrlwRNXz3
3XcoAwYqV/v8+XMU27NnD76vX78eBSpWrHjz5k1RgO+c69Spw5+oEAwoR44c
x48f55Fr166R88q+96tXrx48eDBbF5DwoluYY0IT3jSIixcvYkyFh4dnyZIF
9/3dd98F47h9+3Zqy6WhoaHxL8G0adPy5s1boECBoUOHMsu8hkbqQhNejYBw
1JygCC/Yx6BBg1q2bNmoUaOuXbuuWLFCdh30JrxTpkxZtGiRvTZU1aFDh9jY
WNPKHi6yDdoJ7+nTp1EA3EreuPfnn3+OHTu2TZs2H374YWRk5IkTJ+RLLFu2
DKeYVjx5fOGOmC+//BLfhZ/t9u3bQfQaN27cvHlzNEHOkkls3Lixf//+KACR
Vq5cCVpnJ7wePbNq1SpckafgumwR2ovvigtcXFwcDqJF/Ll79278vHPnzqFD
h8DRmjRpAgGYIx7NAUls165d06ZNR4wYcevWLbmeuXPn4kS3da67d+9mypQp
W7ZscoYFVIiD2bNn58FHjx5B4IIFCyrnogDoquyiDJoZEhLCrdboBJwlVntF
z8gH+bNFixZyGfS5nUqji4oUKcINSnzJbCen+fLlw9UhLb5DMVCGK8IC9oMN
GjR42wJdtT0IL/32x40bpwmvhoaGhoaGhkaqQxNejYBw1Bz/hJfLo6Ghoe++
+27VqlUZoB40U8RM8Ca84FPyHl6w1HTp0oE9VapUqUCBAig5dOhQfH788ccs
oBDe3377DewmR44czK1GzJs3D2KgkvLly4eFhaHC9OnTT5s2TRSoVasW9/CC
l5UsWRKn42fhwoXxne8q6dcK9le9evUKFSoYVur5LVu28PSXL1/27NmTS4Fl
ypTJnz8/voBcK4TXu2d69OiBKxpWenpcl9GuPvvsMxxhCkuBKVOm4OCaNWv4
c/To0fg5fvx4ULM6deqwLQCOQxiQQXBwilS5cmX5zQP+xUG3sFroUvzbunVr
5TioOo7zjQEkz5MnDzpWdjM+ffo0e08+a8aMGfXq1eN3Jj0EE5cLsCr0CX+e
PXsWZUT/E6SWLVu2lE/s1KlTZGQkv3/zzTdo7MmTJxWZ2bEMPMUu3bx5s1zg
3Llz8iqwvbfdCG98fDxkZj5TTXg1NDQ0NDQ0NFIdmvBqBISj5pDwglKtccJf
f/3FYvv27SOxEouJd+/erVatGg6KlUT/hBeMEn9VqVJF8KkFCxaAaboR3m3b
tkFCkDs5YAIoMBhuxYoVxZIojhQrVkyWQRBeQnFpPnToEH6C6orIDxs3bpTJ
LAg1PWlFcKSVK1dy56Ao46dn7C7N/glvzpw5RT3z588n5wUNf/78uWnFWKZ3
rrwUDsrZv3//uLg4xzuO+lF+wIABynGFMP7yyy/oc3DnRYsW7dq1C11RokQJ
CLNp0yb5rBo1asydO5ffhw8fjhqio6OVmsPDw3Fc+JpOnjwZN+6DDz74+eef
d+zYMWnSpBw5coSFhcm7cR8/foyrK2HAFUBnUC3q4U/uRFYW6NFLOAjJ7ad7
EN47d+6AkpcqVYqKoQmvhoaGhoaGhkaqQxNejYBw1BzvKM1Lly5lMbAncKjt
27fL55KRiSzk/gkvWJKd7n3yySeOhDcmJgbngn2IOMAEVyTFhk0C1FhevvQm
vMuWLbNTP/A70erChQuDmimX+Prrr2XC66dnXoXwfvvtt6LAw4cPcSRr1qyy
U/eQIUPkbbMBAYqnVCvXI68LM/mLDIXMnj9/PmPGjILpd+nSBWXodC2D23hF
Y//++282XyA0NFSJ/Yib/v/YOw+wKI7//x8gIKiIgtgLKlaMNZbYS2yJGms0
9hZjjLFGjUajiSX2ltgbttjLV9HYiL0rIIqooIIiioCiSC//d+7zY/7r3nG3
wMl58Hk9PDx3s7Mzs7N7d/PanQLXTusQnj9/Tv0B7O3tRbIk/tJBvoSdnZ21
tbVmImkJL4rXqlUrGxubc+fOUQgLryY65vNB1VWrVq13796yD2x25cWLF/jS
wHdO8eLFcaU5ODjUqlXr66+/Pnny5IfLlOZSW7hwobGPPoMUKlRI+mOhg44d
O1qruXHjxt69e+n1hg0bDFiYK1eu0KVLfXKUl41hGIbJYlh4Gb1ovXJIePPl
y/e3NjQnzo1QG8HNmzfRxqMZihCNwhUK78uXL2FJ0BNZshs3btQUXkgizRrU
pUsXWXyIDIRUNqc0GkW5cuUS3W51C++1a9dQKhTmm2++2b9/v2xJVqiT1smp
YFhpTVqVVs1kRnjFoGYCIbAJaQgNMhV76WXWrFmI/+uvv8rCx4wZg/D58+fT
25EjR9KT60WLFu3atQvhZJTSdY2nTZv2+eefi7fdunVDBNSkLGW6NUFPnKHq
0Em8bdmy5cqVK3fs2DF16lS0MHEipM7eoUMHHL5m4cPCwpYuXQqzUKlXuZLe
i6CO3JrLNECKcQnRA3HN2tYU3p9++gnhq1evltY5C68MJRPYQkzc3NyMXdIP
Cz7C9GHXyhdffPGB1g3JOcJLs7iD69evUw8csG7dOgMWRggvzU6QMeHFFzVO
ynfffZe1FckwDJOzYOFl9KL1ylE+htfd3R2aBtHLkyePSr18KnlHeoWXRnHC
emTpQ4g0hRd8/fXX5DKbNm0Ske/du6ejpQ1/p2i6hTdCPfMwLS4MLCwscHQw
wSdPnmDTyZMntYo2tsqEV2/NZEZ4RSKESmM54/QK7/r16xFfDI+VVQ5ZJ/U5
r1mzpnRo8LNnz6pUqaKSTN2MqpOK4YgRI7BV8+ELLU5EN0/gyHiNw5dG8Pb2
trOzy5s3Lz0sDgwMzJ07t7SHM3H8+PFPPvlEpR4C/Oeff8qW9yUFwNUlDYQg
w3adnJw060Gr8OLqRWD37t0fSEBI4cKF6bV0faWcDAlvmzZtZHecUP/4IC9a
tIg+Ag4ODtl4cVJcojQtAK7eMWPG4OJByMGDB+GhdKGCRo0afYhrJucIL43f
B76+vqdOnaLXhn38KoSXvu7Gjx8Pb4VfpysRmsFAjLBgGIZhPgQsvIxetF45
CoWXLAmtu27duq1btw6GEpGqWukVXnJVqKgsi/3792sKL9KMUJuOubk5RBL7
0lbq3AvhOqYNMXxVr/ASN27cQBMdZo2GKyK4uLjAamm+IzSuZJHv3LkjFV4l
NaNQeGXq+oGEF3pOTicLpycpHh4eEanqqtmcnjlzpip1PaNLly5BS6XLTtFW
WqJISrFixXD6yE+poa652lTXrl3F4+yVK1e6urpqXoG0LvCcOXM0H9eKFGgZ
I4Gfnx8Ca9SooRlfq/BSq1UHcDqF9Zy9IeHt3LlzWhGuXbtGs7ctX77c2IX9
IISEhNC9MrgtLjPZVkgufTBVkoEhBiTnCG8WIIRXOlQkvbDwMgzDZAEsvIxe
tF45CoWXHljIRrNS58/0Cm+EupcpkLUuSJfSmqWZJkRq166diF+8eHEnJyfZ
Yz6IMNQPgkxvdQsvDmffvn3SPofBwcGNGjWix5TU9RoNM1k5IWVS4VVSM2kJ
r2zlIFK2Dy28jx49gjai6qQPnl68eEHPWOl8TZo0CWnOmzdPti9J4owZM+gY
O3XqJN36zz//aD67hxerJEsOtWnTBm/FCRLgvCOchkIjhenTp0u3ogJhuy4u
LpqLRgkgwkgBpZIGwp1VGiv8So9FJrzIaJoGdEODXn+gHqomh17hjVD3S9fa
lyB7QHOm4ZtT3IWTER4eTt8/mr1ZMg8LrwERwitdqS29sPAyDMNkASy8jF60
XjkKhReuYWZmRn19icDAwMqVK2dMePv27YtNMA6RGjyCJlhOS3hhZDTZr1jM
lwaZ/vLLL9Jy0kBUuA+91S28JNEy5Rk6dKg4qK+//hqvYX9iK4y4Ro0aUuFV
UjOawjtkyBCErF+/XoR4eXlZW1sbRHj//fffI0eOpNUOj0jVbWnf4z///FOl
XqGY3lLP3ipVqkhbgDhGHKzQ1bJly27evFmWMs6RpaWldDVkOo8QT3pLmtmt
WzfpXtevX4drQ8NRdf7+/kjh1q1b0ghdunTBXjgoHZcoLiFbW9tSpUoJJ8U1
U69ePc3bEdKS6FiHV1rnPIZXhhLhheoiTq9evWThuNRxVTg7O+OCz58/f506
dWbNmiW7rUQCEqGeBb1ly5b29va07NfGjRsj1M9PlyxZgk8izjhSwMd8+/bt
slxu3749atSopk2bFitWDBnhwmjWrNm6deuk3QPoKPA/Qj1PGr6ykFG+fPmQ
Mi4M6cpZmtDj3ZkzZ+qIAwmiEj569Cgi9WOVFuRKbm5uKvXEdJry5efnR1PZ
Hzp0SAhvQEDA8OHDS5cujS9YBweHdu3aHThwQLMk7u7uHTt2dHJywofL0dGx
devW+PCKFeVE2agMe/furVatmoWFBU1AJ87FtWvXIO84EahY5ZWsFa3CO3Xq
VBpaQqNXaBpDOjsypJukJffw8OjQoQMOE4WpWLEiakbWox4FxrWHcqK6UAb8
3Jw+fVoIL03joLVsu3btwrEXLFiQrsNly5ah9qgYuMK1nsoIiUpHMAzDMIaA
hZfRi9YrR6HwQoVU6omG9uzZg+YWGqhQAOoADHe7e/duRHqEF5mi5YCtMF9o
17x58ypUqIAmFkK++eYbiiMT3gj10qhoraE5SoslIeUSJUogDhpyy5cvR0u4
R48e1M8Z3kS7yISX0oQUoxWNNjM8FAmiAYOSb1SDCLBXNMWp2MiIxuihXQRl
QxsYQgc1Q4tICK+SmqF5rlAwKBsNZcVRIwTpLF269OjRo2i4Fi5cmGog88Kr
ex1ecPny5Tx58tjY2ED6Dh48+Msvv6Ae0CyX9tclKUZSs2fPRiMcMdFKpIOK
UDcsUTOaPQDRikYcnBccF5rNgwYNwlu0PIU74EWtWrWoTbh48WLU+bhx45C1
uJWxaNGiTz/9VJZskSJFEAEN9ULaEE/5kRSiQaBQvVu3bkWrXoeUsfBmBiXC
2717d/q4SQN37txJC3vJwCdL2jGYAnHhQX/oCbuIuWLFCroBolKvpybCpZOe
nTx5kj6DmvTu3VuInhBecnOVejSuiAl1kiqhFHyuKY6O20qa4GunqDboGMmS
4Fx040v2wY9InV+9ePHi+O4i4cVXBN0nlCG9RxeR+k2iCb4whZkKbUS+VB5V
6ozr9BpfDrTqNyDhVVjJWtGUSurhA6MXE1KlV3hxteBXRqVeV52mOlSplyQT
d8Dw9Su9kIhcuXLhC5Be09e+rGw4EBrioXmM1C9lwIAB9erVK1OmDF2oeD10
6FDal4WXYRjGsLDwMnrReuWgMQCBatKkie4LDM0w0chUqeeigaNdvHjR1tZW
lfrADmaEpGgQKOjXrx/eBgcH01tYDNpXIkFvb2+avBegcdK/f38aWzp69GiK
MGPGDOwufVYI/vjjDwSK5wsBAQHImho5KvWjAfiytAkKa5PqIZxURKYHKPBE
6SSraG516tRJ6n14jaaUaD65uLgcP34cByKeWympGViemBoLRkw7jh8/XrT8
4Z4//fQTzBelhTVTBPgg3soeayJEWo0R6sV5pXtFqLuSIkSzwSwFbW96DE0g
vmxoM1rCaGCLJi6AdeLQyC7RAuzZs6fWlNFehbyLvdq0aePr6yu75H788Ueq
H6JKlSpiCSfUtkxCX7x4UbNmzeppI4QXTVM09YUE4VwPHjw4rW6Kq1atwr5K
1jdBtA/RK9Wk0Su8Dx48wGcBcf755x8RePPmTTrv5cuXxxlHnGvXruETQZ/K
pk2bCkuiM4gPCD5o+EQj/OzZs3TLhcAl9PDhQ4RDu4oVK6ZSL6gtMqLeIPho
w6/9/f3xLXThwgUYCu0rFpyio6hUqZJKLeZk3MiOBheAw4cPaz06eg6rZK4/
vWzfvp2+XsR87F988YVKY2I3UL9+fTrwiNQuzZA1lXphNXzr3rlzB99mFSpU
oJKLRZFo9nuVejwIvmHw6fv3338HDhxIgWLSddJGfL/hoODgP//889q1a+m7
lGIid3xNffvttytWrKCvZYWVrBWZVM6bN49+CERXkIh0Ci/EH5fW559/fvXq
VVwV+NTjF0Sq/yEhITSRWv78+ZcsWXL9+nVce/hBkd5+ITWWlY1WY6czcurU
qcDAQHx5Und9upipGFq7NPv4+LRWk/nrhGEYholg4WUUkPnLDC1MtKzoASuB
VgRC0jsRKwSQHg6igYGGGT0GpYeeojeycqBmEEy0tYRc6wANMzRXLl++LELQ
OoKRoRhoxclWJhI8efIETR0dA0j11gykDEaJpqZ0ECiSRTMe0aQ9orMSCAhq
Q/dETDg7qBzZtDxoLuo46WFhYTgjx48f1/H8C3GQL45dNir2/PnzaZ0FhaCt
i6rG+eLxth8OUsWOHTuGvA8+g97e3jAvusPTrVs36ZO+fv36qdSTbMtODU1Y
p1J31qUQetu4cWPp7lAtCkc60t1pOG2ePHnobUBAAEWTLe6MpJydnVWSzg9i
cSWah02AA4H0Ifz333/XevgkaGJkeobB1U5Tu48bN04Erlq1SqXuzyCdoOD2
7dvSgyLhVb0/MCRC3e+FPLRp06YR6k8Z3dDr1KmTbLJo6g6B3OmxpuhuDWUW
K2tLz4W1tTW+vkSg8krWilQqhVHK5jdLl/CCBg0ayI4RR0333CJSe3TA2eG5
0jj4mhL3M/E1LisbrgR6K+6yEsiIVmHTLbwMwzCMYWHhZfSi9coJUUZEqqXq
BS0BGKjuOHR7HLKDyBQCx2nSpIlKPT5UMz51iDVKUQlEE0XVDReVi2r0ombB
L46SdXgHDRokGwZLj/61zttMH3+alT0iVbKkK5FFpI6FV2nM9nb69GkKp7dP
njzZvXv3nj17NHvV1q5dWyWZ64mOAhIkBkEIaNJyrbYVkTqOQDqHXga4d+8e
dUhu1qyZ1G0fPXpEj27d3d1FIC2fXbFiRTooEt4SJUpoDjTesWMH1Ya/vz/k
TqXuuCKzvAj1VAM0lICGPwttlNW5OBc0lkGgvJK1IqRy5cqV5JuagwvSK7ya
g5ep0khC6T6A6EEkhbwY0E08qfDu3bsXr+3t7TWvEFQpDalm4WUYhskyWHgZ
vWi9cvS2WkVLUjxT0A3aCUoaw9TOpFmh9EKtCCMWFdF0TzjDReWifjxFzYJf
HCWFgc1JlY2WEgPUo0MGPYCDZkq/l2RiK1svVTM8rdI+fvwYNvTDDz+QociE
V+uqVTpsKyJ1SvDMPOENCQmhLsqQVs3OEi1atFBJ9D8i1SLFHH102ciedBNh
YWE0CvjEiRM7d+5UqXsday0DDXKnQRbi8tbs70Hhup/Y6qhkrZBUDho0iCKr
JJ2rlZwCrcIrXSKNEBIKK6dFsjQXRItInctdlToiWyq8f/zxB163bdtW61GU
LVtWxcLLMAyThbDwMnrReuUYsWXu4uKiOYWIVj4GiTAh3+Gi5vCiZsEvjo4x
vIGBgfBcEjR7e3vRe/ncuXMIgYtpnc6IRsVWrlxZ+r0Ek5XGSUtstYYfPHhw
8ODBKAYNJZYiE94OHTpolke38K5bt46OTm9FwbCOHz8us0jUAI11tbKy0qpg
S5YsUaknXKK6wu5Uck9PT4pAl83UqVO1ZlqxYkVsXb16NYm55mLiBM1ITzMs
0eWNsyPrFSzOxbFjxzRTUFLJWiGpBJaWlnQsyFocnd5ToCm8WsdTCwn19fWl
7GS9tYmjR4/SVhq4IRVempNw2LBhWo+iadOmKhZehmGYLISFl9GLsS9S7YRo
zPTLMMxHjt5Jq+AONKWPWLvq7NmzOoR369atKsmzyMwIb2hoKE0QrVLPmtuk
SZMhQ4bMnj0b4tmgQQNN4dV6FLqF9+bNm5S+1qfVApoDX9P+6HE2gNhq3fHe
vXvU0Zemfpo+fTpe161bV0TQLbw0gHrLli04ah3CO3z4cFXqcmmkjXA9zWha
z4XyStYKSWWuXLm2bdsGCSVfpsG2Sk4BDYqRCq/WkgsJ9ff31yG8cHnaStPr
SYW3Z8+eeP3dd99pPYqWLVuy8DIMw2QlLLyMXox9kTIMk01QsiwRLYIMCaK3
T548kT5Hk0Gr0gjlyYzwLl68WKWe4Xn16tWyEc1i+Vq9R6FbeAFNzZSWchI0
ER+QDqH9+++/SWZ1r91Dy7rRDMOffPIJXs+fP192IGl1aabuuxcuXKDxvOXL
l9eaRdu2bVWpE3OlV3iVV7JWSCqRCL2lacdUkqmqdZ+CmjVrpkt4Uc/Um0jr
83SaJQzQmnFS4aW19tIarE0LwLHwMgzDZBksvIxetF45SjpJqribKBeVi2o6
Rc2CXxwlwktzAUnXhCWV0DoalBYpGz58uPR7KWPCS4//tE5PROZoEOGl3sLQ
KG9vb60RIJ6k/EWKFBFiCwmlaZmrV6+e1oJZ0vRRYJp4ysLC4v79+2Krjkmr
aJ4lOHVwcDDVjLm5+Y0bN2TRgoKCChQooEp1zPQKr/JK1ops6R/UFa2ZXrJk
STHZPp0CzSxQcul6QEqEN0K9uJhKY1VoQqwrd+vWLVnZqO86KkpzgLCXlxct
WMzCyzAMk2Ww8DJ60XrlGLdlbkISwUXloppKUbPgF0eJ8JKwCIcFNHDV2dlZ
NuetWJZITLRLbzMjvBMmTJBFO3ToEBmKQYQXXlamTBmVuhv2zZs3ZVthcKNG
jaJSTZs2jQJhrLSUsL29vWy8qiaQL9q9b9+++P/5559Lt4rLRrZwkliWiJ6V
oxj0JBqHk9ayRDTIOmPCq6SStSIT3gh1j3eawEqs0ERXS5MmTWTPwceOHSu9
1BUKr5iRWzZh9alTp8SyRDTUWlo2VA6t6y1dNypCPQq7R48e0mJQXp999lkE
wzAM88Fg4WX0ovXK4aVeuKhc1GxW1Cz4xVEivN988w3i4L8IuX79OvW2rVCh
wq5du/z9/REya9YsKysrlXrpWKE2mRFeCCZJJTw6XA3kEfpJuUgdPDPCG6Ge
hosOx9ra+ttvv927d+/ly5c9PDyWL1/+6aefUl61atWiEx2SOi0z9Gr37t1K
Kpk67hJr1qyRbiLhzZ07N/6PGDHi9OnTvr6+W7duRcWq1I+DEUIx165dSym0
b9/+2LFjgYGB//7774ABAyhwypQpFC29wqu8krWiKbzgu+++U6mnsaIVz2mx
Y5JNWqn87t27P/zwAyqQdk+X8OJio73y58+/ZMmS62rmz59va2sr5k6kGxey
stGRAlQaqg4VeOLEiY4dO6rUT35VqVNnU17FixcPkcxK4ePj01qNktPNMAzD
6IWFl9GLsS9ShmGyCUqE98cffyTjkz6h2759Oy2aI6NatWq0KAyRGeF9+vRp
uXLlKAR5UfdXACcVoleyZElEy6TwRqifD8Jx0nra3rx5c7HkkOghABstqg04
lCzxX3/9lXaBVpPxCUh4oaviSAVIf+XKlSImKp8e5mrSs2dPcXskvcKrvJK1
1ptW4X38+LGTk5O49REcHExPqwk7Ozt6MXnyZM1ZmvUKL/jnn3801wVA4ffs
2UOvocCaZXv58iXN7iVj/PjxX375pSp1JPLu3bspPHfu3MJw9S6YxTAMw6QL
Fl5GL7EMwzCG4JdffkEzvnv37jri/P3339Ta37lzpzT87t27Q4cOLVOmjJWV
FQTk008/XbBgQWRkpDQO7ejt7S0NxFsKl2WkGR4SEjJq1KhKlSrBPgoWLNiu
XbuTJ08iPCAgANnBcWg6aB1HQVMQI4LeqsCP79KlSz///HPImqWlJdTP2dkZ
LgljiomJEdGOHz+u0knjxo1lKfv4+AgzlW1CZIQvX778+fPnI0eOhFoiaxSg
R48eV69e1Swkcv/qq68QIVeuXKiQNm3a7Nq1S7N4iKC5r9ZzobyStVYaiS0y
lYVv2rSJstu6dSvevnjxAnoL7UWt2tvbN2vWbP/+/Qjv1asX0v/11191l5zm
wpJWLMo2bNiw0qVLo7ogtt26dbtx44Y4xlu3bqVVtsOHD3fq1Klo0aJ58+Zt
0KABag+BjRo1Epd3dHT06NGjHRwcbGxsxPlK64plGIZhMkZcXJyxdYphGIZh
GMOAn3V6cgrbMnZZGC1UqVIFZ+fs2bPGLgjDMAzDMAzDMIyJceDAAfiUg4ND
fHy8scuSQwkKCqpatWr16tVjY2Nlm54+fUqzbD169MjYxWQYhmEYhmEYhjEx
aIjo8OHDjV2QnEtycjL1cHZzc5NtmjRpEsKrVKli7DIyDMMwDMMwDMOYDM+f
Pw8NDV29ejUN//Ty8jJ2iXI0U6dOpbmt8OL27ds4NadOnfr+++/p7GzZssXY
BWQYhmEYhmEYhjEZhg0bJmay6tevn7GLk9NJSEho3bq11nnGoL3JycnGLiDD
MAzDMAzDMIzJsGjRIkdHx6JFi06aNImno/wYSEpK2rZtW4sWLUqUKGFpaVms
WLHu3bsfP37c2OUyDeJTMXZBGIZhGIZhGIZhGMZghIaGmpmZ0QPxcePGvX79
2tglYhiGYRiGYRiGYRjDcPfu3R49epDzmpubJyQkGLtEDMMwDMMwDMMwDGMY
kpKSOnXqRM77448/Grs4DMMwDMMwDMMwDGMw4Lzly5eH8JYsWZLH8zIMwzAM
wzAMwzDZidOnT9ND3s2bN6drx+Dg4N69e9dS89dff/FMbgzDMAzDMAzDMMxH
RXJy8ieffEIjecPCwhTutWHDhjx58khXg7Kzs4uKijL20TAMwzAMwzAMwzDM
/2fZsmUkrf7+/nojv3371tXVFZHbtWv38uVLhLx584Z2nzJlirEPhfmwJCQk
nDhxYvbs2QUKFJg7d66Hh0diYqKxC8UwDMMwDMMwDJMmgYGBZKz379/XHTM6
OprG/LZo0UI6sfPnn39OKSQnJxv7aJgPQlJS0pQpU1xcXFTv4+rqGhsba+zS
MQzDMAzDMAzDaOfVq1dWVlaQl5EjR+qI9vbtW/KdNm3ayJ7riWfELLzZkpCQ
kLx589IpHjx48Pjx4/38/B49ejRs2DCEjB492tgFZBiGYRiGYRiGSZMqVarA
XFq3bp2WsUZFRdGz3fbt22su2tulSxdsmjZtmrGPgzE8T58+LViwIM6vo6Oj
t7e3bGvnzp3t7e15HWeGYRiGYRiGYT5a9u7dC6MpW7as1iGZ586dq1ChAiI0
b95cawR69rdw4UJjHwdjSOLi4gYMGEAnd+TIkTExMZpxevfuja28phXDMAzD
MAzDMB8t7969I695+PChNDwpKWnx4sUWFhYlS5Y8fPhwWrtnbGEj5mMGelu7
dm2c1ty5cx88eFDro/8rV65QZ/isF15WbIZhGIZhGIZhFJKYmFi5cmWYy5w5
c0QgbLdnz57m5uajRo3S4Rc055WZmRlN2sxkA+Li4mrWrEmLVb148UJrHE9P
z1y5ciFO3759s7h4ixYtKlKkyOPHj41dTwzDMAzDMAzDmAb9+/eHvFSqVIne
wnbbt29vZWXl6+ure8fjx49jx969exv7CBjDEBMTQ0sz16tXT+vSzMnJyefO
naPH+n/++WcWP2w9ePAgZb1y5UpjVxXDMAzDMAzDMKbBlStXIBEuLi4p6uVW
u3fvbmNjozlJkQzErF69OnZ8+vSpsY+AMQy//vor9WSOjIzU3JqUlESTM5cq
VerixYtZXLbExMSKFSsidysrK09PT2NXFcMwDMMwDMMwpsGdO3fowdmAAQNo
DRq9z3bBtGnT6LkwPMjYR8AYgMWLF9Nl4OPjo7n10KFDRYsWrVq16pkzZ4xy
xtetW0fFGzt2rLGrimEYhmEYhmEYkyE5OVmVSp48eW7fvq13l7t375qZmVlY
WGT9kz7mQ7B69WqcfVtbW80n+/Hx8R06dKhWrdr8+fO1TtecBaBU4hINDw83
dm0xDMMwDMMwDGNKCJv49ddf9UaGILdt2xaRT5w4YeyCMwYgODjYwcEBJ1Rr
P/bo6OiLFy8a8Tk+rrdmzZrR9Tls2DBj1hTDMAzDMAzDMCaIEF6tgzelwD6G
Dh2KmP3799e6YA1jWuCMm5mZ4YSuW7fO2GXRzpkzZ+jibNKkSUJCgrGLwzAM
wzAMwzCMKREdHa1wdCQM9/vvv6eezzx0NxuAE9qjRw+c0IoVK360ty+KFi2K
ElpbW0dFRRm7LAzDMAzDMAzDmBiLFi0i4Z01a5aOaBCi4cOHI5qjo+Pz58+N
XWrGALi7u9OpDw0NNXZZtHP9+nUq4bJly4xdFoZhGIZhGIZhTIyAgABbW1u9
wgvbHTx4MNtuduLx48cWFhYf87zHcXFxdnZ2NH+4scvCMAzDMAzDMIzp0apV
KzGANy3hFT2ZYR9su9kDnNPy5cvjnJqZmX20vdNXrVpFy/7qHVrOMAzDMAzD
MAwjY//+/fCdOXPmHDhwIC3hhRkNHDgQWwcPHszekW2gMw4OHz5s7LJoBxdb
kSJFUMJRo0YZuywMwzAMwzAMw5gYiYmJRYsWrVatWkJCQnx8fKlSpTSFF7b7
3XffQTp69uz50U5qxKSXt2/f5s2bF6e1SpUqH+28x9988w3NVfXRlpBhGIZh
GIZhmI8WNzc3CEVMTEyKerAk5FcmvGLcLoAiGbu8jMHYtGkTndbAwEBjl0U7
z58/pxLu27fP2GVhGIZhGIZhGMbEuHjxopWV1dKlS+nt69evZV2aIyIiyHYH
DBhw8+bNrClVYmIiP0f+0ERGRpJLLly40Nhl0Q4ug+bNm6OE1atXj4+PN3Zx
GIZhGIZhGIYxJWjhXUdHR3q8m5IqvOJpGqyzQYMGCHFwcEDkDGTx8OHDn9VM
mzZNR5fUV69eBQUF/fnnn4g5evRo5NimTRu8Dg8PN3YlZU9EH/UCBQpk7Mxm
AefOnSMlf/DggbHLwjAMwzAMwzCMiXHq1CnYxKJFi0TI5cuXERISEkJvk5KS
atasiZAFCxZkIP0DBw6Ym5uLyZ+bNm26V01UVFSMGrzA2ypVqlhZWYlo7dq1
K1asGL22tLSMi4szdj1lQ27dukU1PHfuXGOXRTtQcsg4Sti2bVt+3M8wDMMw
DMMwTLqAbxYsWLBu3brSzqJr1qyRCi84efIkQqDG6U3/3r17KmXAamfOnHn8
+PEoNdgXRSpevDg2de/eXWvijx49uqMmMTHR2BVpktSuXRvVW6dOnY/2fsI/
//xDl4e3t7exy8IwDMMwDMMwjInx+++/wyYuXLggDdQU3qCgIIRUrlw5XU/Z
ELl+/foKhff169eaKZQtWxab/Pz8ZOEPHz5s2rSpdPeIiIgPVEWPHz9etWrV
u3fvPlD6xuLp06eWau7cuWPssqRJ9+7dacXnDEzO3KJFi49c5xmGYRiGYRiG
+XDExMRYWFgULlxYprFFixYtV66cNAQRyCuvXLmiPH0fHx/aq0aNGseOHXv+
/Hm8GuTr6+sLhUTgiBEjrK2tEefly5ey3eEpBQsWLFCggKx4R48ehQFhlwoV
Kri6uhYqVAivJ06caJA60TR6mq2rUaNGH/hsZDXDhg3DcQ0dOtTYBUkTKDld
P3///XcGdhc3Q3AxZ9lMawzDMAzDMAzDfCT8+eef0IH58+dLAyGkCKxUqZIs
8g8//IDw7777Tnn6devWJeN49OiRjmg3btxAHDc3N1n49u3bEb5hwwZp4Pr1
6xHYpEkToTDu7u4IGTRoUFrpBwcHh4WF6S3tmzdvZsyY4ezsDA0XgQkJCWXK
lEH6Ygrr7EFERASdmmvXrhm7LGnSu3dvKqSYTi1dyLoQcKdohmEYhmEYhsk5
vHv3Lnfu3BABWWfdO3fuILBVq1ay+FAkGxsbbFLYq9nLywuRraysLl++rDdy
ly5d6tSpIw1BLs2aNcuXL59Y8xchBw8eRBm+/PJLaQdXEt7JkyfL0kT8lStX
li5dmgYIw2d1FABbSWxBrVq1RDhJNzh8+HBWnZmsYMeOHTgoe3v7j7m7b6VK
lVDIXr16ZWz3/v37Y/dJkybhamnRokXVqlWzeKw36jYoKOjQoUNnz56NU5OU
lJSVBWAYhmEYhmGYHMvs2bOhA3PmzJGFk/AePXpUc5d69eppCrJWXr58WbRo
UUQeMmSIksLMmzdPNg4XaiBdCzgmJmbatGkIgQXLtIUO5O7du9JA2O6gQYP0
jhEmoqKiypUrR9GGDRsmDhCiRFMEZ0B436jJ7En6YLi6uuKgli9fbuyCpElk
ZCTdYDlz5kzGUkD9lypVytnZec+ePe3bt0dSWbP0Ei7+q1evDh06VHOgeo0a
NRYuXBgYGJilVckwDMMwDMMwOQy0/PPnz48WeGxsrGzTihUrEH7//n3NvUh4
9Q6HfPHiRZ48eaiFj5a/kvLQZLxS4T1//rzYXTx+7dChg8x2IbYlSpTAJmng
8+fPyZVGjBgxf/58vcI7Y8YMiiPT/9WrV1etWjW9wosqhdfQ023xePqjAvVD
B/X06VNjlyVNcO6okJqXqHLevXv3xRdfCN/UHCduKHAd3r17d+PGjTSinGjV
qtUwCdWqVRObmjRpkoFpuBiGYRiGYRiGUcKSJUvQ6v7jjz9k4XFxcfRMkxYG
krF//35sQqteR8qwXScnJ9GwV9hjVvMJ79KlSxECKYCzkO22a9dO0xGePXuG
TV999ZUIcXNzg3RANi9dugQNoSHJIDw8XGvWvr6+efPmRYTp06dL62Hx4sUz
Z84U9qpQeLEj3RZQMnjZWAjhNXZB0oSe74N8+fJlMilckOJ0jBw50uCL+eKa
3LJlS6NGjSgLfHzKli27b9++169fy/LCQeHywHX4999/29raVq1aVettJYZh
GIZhGIZhMoOwCc11dWn+qI4dO2r1gtOnT2Nrw4YN07KG//3vfw4ODjS3FWWh
ZLaoFA3hRfr0OAwSWr58eZqEWesAzF27dokDgUrQzMM1a9YUMxSJg12zZo1s
X8js5s2baaurq6uYGQmO/Omnn3799dc04nLhwoUKhRcJImuhV5aWlq9evcqa
c5ouoGMq9Xo9Hyh91AM0MzMpvHv3jurwxIkTmSwJdS0eMmQITgfNxobLOPNj
aXGA58+fpxm8idy5c2/dulXhHZ6HDx8ivrm5ub+/fyZLwjAMwzAMwzCMlDNn
zqB93rRpU02FrFixIjYdPHhQ646kw1qflr59+3bmzJnY5OzsTP2QaYpdKIDe
8qAY+fPnr1+/vggJCQmRjnzUIZvjxo1DhFWrVrm5udEcXJ06dZJ1gh04cCA9
ehOFgVDjEEqWLCmyEMMqAwICPvvss4IFC4aGhlLI3bt3lQgvfBma7OjoiBqg
NIcPH541JzS9tGnTBsVbuXLlh0j89u3btHoynC7DiVy+fBkp2Nraau1poBA6
I0hn3bp1KerOADjkIkWKIKR06dJt27Y9duzYzZs34+PjFfovYt66dWvbtm2i
ozsoX778L7/84ufnl16Jhhp37NgxT548mstMMwzDMAzDMAyTMdAsp+a65oq6
CQkJEE9ra+u0mu4wU2rkb9myRQRCHj08PCwsLBBevXp18ZwUcoEQJycnvVPj
wiAQs3HjxiKExhETe/bsSWvH+/fvS70YfvTgwQPNaChhnz59KE6/fv1GjRol
OqAK9u3bB9VdunQpDqR9+/aQI7E7CS/cRMchQIU++eSTvHnzPn/+/MSJE5Tm
x7n2q1hS+fTp04ZNGZfN5MmTRZXKphFLFyNHjlRpmypcOZ6enjgjml4fGxu7
Y8cOXAPSs1+uXDmEwLIDtDF69Ghs7dq1q+ya6dy588mTJzMz8zP2bd68uY2N
jdbrlmEYhmEYhmGY9PLkyRNqrmtaLdQS4Wjb69h90qRJiAMpfvToUVRU1NOn
T2k2ZpXGlL8wC3perLnArhSoIg3RheSKQOpz6+zsrLvD55s3b2jVoQoVKuzf
v1/HIzZY3v/+97/KlStTUWvVqrV48eKgoCDoOfYVCuPi4nLu3DnZvjRMOH/+
/Frn+EXK2MXKyqpw4cLUj3fr1q2IX69evY9zDRohvIbtbo2DbdeunahJ1Gpm
Uvv888+RyNq1azOwb1xc3KBBg8zNzYsUKbJ9+3YdMYODg8+cOdO/f3/xUF4v
UGNIfWZcXgacF584CwsLA6bJMAzDMAzDMDmWZcuWod0+duxYWTga3hCEXLly
pTW5E+Hn52dmZiZVALTVv/76a8ijZuSbN28iQcTZsWNHWgmS28Kgpf2QIWUX
LlxQMo0t4kBaFT5lQ7QYNVIVhbbvTSWtDrRpPRKNjIyk0cq2traiC3T16tUR
0r17dwOcrQ8A6pb6fhtWeMWCxUj8yJEjmVzxtkWLFkjq0qVL6d1RrIclPSN6
wVX05s0bXAADBw4soqZy5criqnjy5ElMKh9oauUbN2588cUXH+cdEoZhGIZh
GIYxIchKvLy8ZOGbNm2inr16U7h3797PEnQvbTN+/HjKEelrbg0ICKCtmzdv
NnbF6GL06NFUzrNnz4apgUyJbrFt27aVztHUt29fCp80adLiVK5du5aZ5XUM
y5w5c1TapizLGNA0umuhUk+q/Pjx48wnSDcN0iW8r1+/FmdEPG1nGIZhGIZh
GCbn4O/vr7W7aXx8fPHixbEJMmvYHCEv/fr1Iw3p3r276BWMcD8/P1oPqFat
WsauGD3ExcXNnz+fJqCW0rJlS1SpbM7qxMTEwYMH11cjnd2oUKFC33zzzfnz
542+AGtISIilpWXmJ63CSTx58mS5cuXoAPPnz2+oZZh69uyJBBctWqQkckRE
xMSJE21tbbFLiRIl3NzcMvl8mWEYhmEYhmEYU+TQoUOQgipVqsjCaYHdBg0a
fIhMoUUwF3IieNZENWLk7G+//aZwJRejA1tfv349ag+Hc+bMGd19vwmaDprw
8fFp1qwZHfW0adPEvNBGYejQoSNGjMjw7jinJ06ckOo8GD16tKGKRyPNHRwc
pLOHycBlc+XKleHDh1Pu1tbWy5Yt0zrOmmEYhmEYhmGYnAD1tp01a5Y0EOYF
WXB2dv6gTx5jYmI8PDx6qMmbN2+pUqXw4uTJk8aukqwmMjKyadOm5Gjjx483
oqDNmTNn6dKl6XoYCn9/9erV7t27CxQogPIXL158w4YNXl5eNKmyYaca9vb2
zq3m33//lS6RjBoLCgrCxZMnTx6qRly6f//9Nz/VZRiGYRiGYZgcDgkvTEeE
wHYhL7ly5bp9+3aWFQP+AnMxdmUYDWjj3bt3GzRogHNRqVIlWrbYKMXo2bNn
lSpVfv/99zdv3uiO/PLlyy1btjRv3pwc08bG5ttvvxUncdeuXVZWVjrWzI2N
jfXx8blz5066Snjv3r3PPvuMOgb0UVOiRAnxQNnMzMzOzg7JGr2LOMMwDMMw
DMMwRgeC07BhQ5iCvb29v79/RETE//73P3Nzc4SsW7fO2KXLcUDT1qxZQ+6m
uRZS1oBLYvDgwVSGsWPHnjlzZsWKFdDSnTt3rlBDc1BLcXR03Lp1q+x+xfz5
8/Ply6c1C5hyly5dxO4bN25MbyEfPXqE9KXdp2vWrLls2bInT54YpdIYhmEY
hmEYhvk42b17t+a0S5mfVpfJMFu2bMFZsLKygkXKJr8itAYaEKS/fv16sZiy
VszNzatXr96sWTM/Pz+tPYcLFiyoKbyQYg8PDycnJ1q+dtiwYXSzJWMPZJOS
khJS4eV7GIZhGIZhGIbRyr179+arCQ4ODg0N5ZGPRufIkSNkhYMGDZLprZub
W8OGDbPA7yCnuBiWLVs2X8LatWtD1bx8+VL37prCCy2tX78++fLixYtxCLjS
KlasiLc5uTc7wzAMwzAMwzBMTiMsLIyesfbq1evSpUuxsbHe3t60Fq27u7ux
S6efmjVrmpmZBQUFpagfGXt6etISTl988QUFpqjnuEZI8+bNP/Qza4ZhGIZh
GIZhGOajIi4ubuDAgdBGaV/iiRMnGrtciqCu8iNGjPDy8mrTpg0Vfv78+dI4
Z8+eReCoUaOMXViGYRiGYRiGYRjGCLx48QLa+P333y9duvT+/fum0uE8Pj6+
cOHCwtMbN2586dIlaYSkpCR7e3sLCwu9vaMZhsmBHDlypJia2rVra26dO3cu
bR0yZIixS6qfr776ikprrBn4GYZhGIZhGIOTkJCwatWqTz/91N3dXXPQ8bFj
xyDCffr0MXYxGYb5GImJibGzs6M7Zjdu3JBtrVatGm3au3evsUuqH1pMLSun
39+xY8cnaqRrDjIMwzAMwzBZA/y3cuXKaP49ffrU2GVhGOYjRSyR9vPPP0vD
AwICKLxgwYJxcXHGLqZ+sl54ly9fTjl+//33xj56hmEYhmGYHMfRo0fREhs6
dKixC8IwzMcL9JCsrWLFitLwBQsWUPiIESNku7x+/Rp77du378aNG7KOJS9e
vPBU8+zZM7wNDg5GtOjo6MTERAq/detWirpryqlTp7y9vcWOCPH19UXkf//9
Nzw8XGtRk5OTHz9+jG82d3f3+/fvy7bKhBcxDxw4cP78eZmtIxcqCYX7+/tT
tKioKM0cdZcqXcKLCjlz5syuXbuOHz/u5+cn25quUjEMwzAMwzCgdu3aaImF
hoYauyAMw3zUODs7k7jduXNHBAp/vH79ugiMiIjo1auXdIq/MmXK7NixQ0SY
M2cOhU+YMGHp0qWWlpZ4/eTJk1evXlG4nZ0dXLV8+fJ4PXnyZNpr06ZN+fPn
F2laWVkNGTJE5nrQ2AoVKkiz/vTTTy9fvqxZ4G3bttG3H1G8eHGYpohWtmxZ
Cj948CAt2UYUKlQIjinNUXepSpUqZWFhIdZMx9YLFy5ord6wsLCuXbvKpkas
UaPGtWvXMlAqhmEYhmEYBpw6dQrtK7QqjV0QhmE+dqZPn0569fvvv1PI8+fP
SdBcXV1FtJiYmHLlylFMCFr16tUhevR29erVFEcIr9BPmfDmzZv3k08+odck
vDNnzqS3+fLlq1evnr29Pb2tW7euWD38xIkTIjVIKK2/Rq8fPHhAcUSOyEL1
Pk5OTm/evKFoQi01oyGEHkwrKVXDhg1pJXcqBmRccxA00bRpU5FFkSJFhCZD
Zt+9e5euUjEMwzAMwzDg7du3JUqUQLNKNmkzwzCMJg8fPiS3gsNSCASWQhYs
WCCi/fbbbxQ4duxYCrly5Uru3LlJyl68eJEiEV5yw0WLFq1btw7fSEJ4SQ8n
TpyIcOz++PFjSqF06dKUAhywVatWFHPx4sUp6unoxUPPNWvWpKj7Nk+ZMoVC
+vXrR4URwuvs7IyUExISTp8+nSdPHgo8e/YsRRNqCe/28vJKSkry9vYW091v
3749Rd0dWm+pUpR1aYaPU5yqVatSf5uYmBhRVPHoWUmpGIZhGIZhGGLGjBlo
Iw0bNszYBWEYxjRo2LAhuVVAQADetm7dGq8tLCyeP38u4tDjXTMzM9irCPzi
iy9ox40bN6ZIhLdy5cpQThFNKrweHh4iXIwUnjt3rgg8fPiwUGa8vXHjhpBB
ESc6Orpp06Ywx+7du1OItEuziNa1a1cKdHNzoxChlqdOnRLRfvjhBwqcNWuW
wlKlKBNeVOAhNT4+PnhLY5ldXFxox927dysvFcMwDMMwDAP8/PxsbGzQRqIH
EwzDMHpZu3YtudX8+fNfv36dK1cuvG7fvr2IEBcXRx2YIbxlJYi+vuPGjUuR
CK9sqishvFZWVtJ5roYMGULhhQsXFmmWKlWKAvPkyYM427dvp7e6lwPWOktz
v379pD6eIlFL0RcaTJ48mQKpU7eSUqWkZ9IqCC8qpH79+ra2ttLuyprCq6NU
DMMwDMMwDPj0009V6hlRkpOTjV0WhmFMg8jISGtra3x11KtXb9u2bTIdS1FP
Miw0zUob1KVEOmmVNH3ppFXS8A4dOlA4FFszTRQpISFBeKXoSq0VAwqvklKl
KBPexMTENm3aiKqrWLFinz596taty8LLMAzDMAyTAehRiKWlpZeXl7HLwjCM
KdGjRw/SqwYNGuB/gQIFpAv6JCcn09NJR0dHHYmkV3hHjx5N4Xv37k0rzSNH
jlCcrl27SsM9PDxOnDhx+vRpemtA4VVSqhRlwot8KU7z5s39/f0psFu3biy8
DMMwDMMw6SU+Pp5mDRUzpjIMwyhEeGVaEle/fn3a5OvrKwIhfd+qodWL0iu8
bm5uFP7jjz+KQC8vL0pz0aJFePvkyROaMtra2hqvKc7BgwdpxxYtWlCIAYVX
SalSJMKrY8IEpEBxxPRfb9++FdM7s/AyDMMwDMMoZ8WKFWgalShRIiIiwthl
YRjGxEhMTBTTAgPpKrHEyZMnaVPRokX/+uuvPXv2DBo0iEJKly4dGxubkn7h
jY+Pr1y5slDsAwcOzJ07t0iRIhQilqCFUVJIyZIlZ86c+ccff4g4YooqAwqv
wlKtW7eOQipVquTu7q71ixdFpTiOjo6TJk2aP39+1apVRSXv2rVLeakYhmEY
hmFyMnFxcQULFlTpG+bGMAyTFvj2IMOqUqWK1ggwL7GMrMDFxeXhw4cUIb3C
m6KehNnZ2VmWJnJZuXKldPeWLVuqNBgzZoyIY0DhVViq27dvi5WIZfkKXrx4
AdWVJlK8ePEmTZrQ6+HDh6erVAzDMAzDMDkWMc9MeHi4scvCMIxJEhQUtFbN
xYsX04rj6ek5evToVq1a1alTp3v37m5ubvHx8WKrt7c3pXD16lXpXnFxcRS+
efNmzTTfvXs3b968Hj161KxZs02bNpMmTQoMDNSMtmPHjiFDhjRo0KBx48Z4
ceXKFenWQ4cOURbSpZTOnDlDgffv36eQXbt2UUhkZKSIdv36dQrE0aWrVIcP
H27Xrl316tUR4d69e1prDM4LMYePt27devr06a9fv/b396fs1q1bR7MLKi8V
wzAMwzBMDgQNvNy5c6ven1WVYRiGYRiGYRiGYUwdGknn7OwsfdTCMAzDMAzD
MAzDMCZNYGAgdWYOCAgwdlkYhmEYhmEYhmEYxjAkJycXK1YMttu6dWtjl4Vh
GIZhGIZhGIZhDAYtnWlnZxccHGzssjAMwzAMwzDMx4uPi8tNW1vdf15OTgbJ
6+3Fi3rzwt/jb7/Vm1TQmDFKkrpduXJSdLRBCo9SKckx6v05KjWJf/FCSTrp
+8uXz7tYsdtVqtz97LP77dsHjhgRtmVLTOrslFlMtK/vzTx5FJY8dM0agxcA
p0BJ1o8GDTJUUkr+PPPn9y5Z8rar63/nqF27gJ49H3/33fMFC17/8098SEi6
DjAyMpLmquLHuwzDMAzDMAyjG4jSdZVK9x+a6wbJ6+25c3rzwt/Dfv30JhX4
/fdKksLfk/eXBcwwKJWS7N5euqQ7HdiNwpJn/s+zQIGH33zz9vx5g9SAQoLG
jFFeQt+6dQ1eAJwCRZfZN98YKqnM/92uXDlo1Ki3Fy4oOUCxSqN06UaGYRiG
YRiGYTTJ9sJ73cLinSEWszNF4RV/d6pVe7lhAy3890FJjo/3cnRMV9li7t41
bBlMUXil5hu6alVyQkJaRfL09CTbXbx48Yc+mwzDMAzDMAxj6mR/4VWpfGvX
Tk5MzGThTVp46e9eq1ZxT58a6MLRTsSePekt1ZOffjJsGUxaeOnPp2LFyGPH
NMuTkJDg5OQE2y1YsOC7d+8+6KlkGIZhGIZhmGxAThBe/D1ftCiThc8Gwos/
T3v7VwcPGuja0cL9Nm3SWySvIkUyfztCSjYQ3v+7FTB+vOxR77p16+jx7tMP
fOOCYZjsTUBAQA8N+vfv/8svv5zP2lEwhiI0NHTu3Lm9evWqoearr77atGlT
oiF+XIKDg1E5R44cMfYhMgzDMBkkhwgvDiH20aPMFD57CC/+blhaRp46ZbAL
SEJcUNB1M7MMFOn14cMGLEa2EV783W/bNikmhgrz7t27IkWKwHbXfICZvhiG
yVFcu3YNXyZOTk51JVSuXNnS0hLhgxTM6fdRcezYMTs7OzMzs2rVqvXp0we2
W6JECRxIrVq13r59m8nE7969y6NIGIZhTJocIrz/uUObNpkpfLYR3v9OaL58
77y8DHcR/R/BM2ZkrDz+XbsasBjZSXjxd69ly6TYWBSmf//+9Hg3Pj7e4OeO
YZgcBQnv999/LwsPDg6uWLEiNh0/ftzYZVTK7du3bW1tixQpcubMGRGYkJAw
c+ZMHMg3Cr7qdcPCyzAMY+rkHOHFX9jWrRkufHYSXvzdKls22aDelJycfKt0
6YwV5oalZUJYmKFKks2EF3+PBgwIDQ0l2925c6cBzxrDMDmTtIQXLF++HJtg
i9LA2NhYT0/PU6dOPXv2TBb/7du3dBcOmxAhKCiIwpOSkqCKx44de/jwoWYu
+E47f/48tPrOnTvS8MTERCSIffEam44cOYJ8dc+42Lp1axT4grZZ7hs0aJAr
V67w8HA6hLcaREVFiU2yXOLi4qgkUuHFMZ48efLBgwdaixQYGHjixAkUO+H9
0SioH3rQjNQuXbpEY1IQQtGePHly8eJFETkyMvL69etHjx69ceMG395kGIYx
CDlKeL0cHTMsVtlMePH34s8/DXghRZ44kanCLFtmqJJkP+HF34rx40l40QQy
4FljGCZnokN4V6xYgU2LUie+gNn99ddftra2qlQaN24cEBBAW1+9eoWQefPm
ffXVVyJC3759b9++XalSJREyevRokX5ISEiXLl1UEhDzbup0/RBGhBw+fLhZ
s2YiQrVq1YKDg7UeCGwRET7//HOtW2/durV79+7nz5/j9aBBg1QaFCxYUByy
u7u7dF8UwM7O7t27dyS8v//+e/v27aVlvnnzpjSj6tWri60FChTYtm2b2Ip9
ae6FsmXL4sXGjRtfvnyJFytXrhw5ciRe1FWv0AfvHjNmDAxdpFO4cOHDBh3y
wzAMkzPJUcL7X+J9+2as8FksvDdy5/apUEHvn3fJkp7582esKrycnBLVN7cN
QkCPHpkRujs1ahiqJFkvvDfz5dN7pm6VKXMzT56MVc5NO7s66vFoRP369enx
B8MwTMZIS3iDgoKqVKkCXxNPctesWYOYrVu3vn79OpQNspYvX75SpUrFqKcX
IOHNnTv3hAkTXr9+HR4eTlZoYWEBTYYtPn78mEzQ39+fEuzcubO5uTkcE+Z7
//79devWYfdWrVrRVhLeokWL/vTTT6GhodHR0XPnzkXIkCFDtB4IvBJbp02b
pveQHzx4cE7Cb7/9hh27qgfUREREWFpa9uzZU0SG0Yv6IeGFh3722WcXL158
9OjRqlWrbG1t7e3t6dlxWFgYXjs4OOzcuRNifunSJcTELocOHaLUSHirVq3a
r1+/AwcO4MBJeBFSsWLF9evXX716FdFmz56NwFGjRiELiPz+/ftRz1DyLFhS
kGEYJnuT04QXf5EZGpqUxcLr16SJ8rLBW99evPhs9mwfF5d0VUXo6tUGObMJ
4eE3rKwy+RDznbe3QQqT9cKrJCkiKTo61t8/dM2aB19+ecPGRmHNXHN1FbaL
NlWY4bp/MwyTMyHhdXR0rCWhbNmyENU6der4+vpStISEBMQpXbq0tG+tm5ub
6OJLwluvXj2x1cPDAyG9e/cWIatXr0bIsdSl1gYOHDhx4kRpYVq0aFGiRAl6
TcIr/JcoXrx4o0aNtB7IggULEB9FStfh37x5M2/evA0bNoxJnRUQGg7vfvPm
Db2dPHkykr1161ZKqvDiu1c6/9XmzZsROGXKFLwer+6BI53GGekUKFCgSpUq
9JaEt0+fPiICCS/iQGxF4KxZs3r06CG9nzlhwgREe/HixQe9GBiGYbI9OVB4
bzk7J6V/DdOPWXilQKbwQ66wKvw7dzbImX2+ZEkmbRd/QaNGGaQwH7PwSkl4
9Spw5MjrFhb6P4BlyhTNl++/1mmBAmgmGaSWGIbJyZDwli9fXros0Zdffunk
5GRtbb1y5UqKdv/+fUSbNGmSdF/IL7yYnoeS8I4YMUKW8pIlS0TI33//jZCj
R4/KypCYmAiXhA7DNIsVK0aBJLwLFy6UxoQ5fvbZZ1oPBBkh/ur03Lz19/fH
YSLNiIgIEXjgwAGks2nTJioYyiMsnoR32LBh0kSgpTY2Nm3Uk2E2btzY0dFR
lgv1oKYxwiS8UiMm4e3QoUNahQwMDNy+fbuzszOihYSEGPTkMwzD5DhyoPBe
V69wmt7Cm4rwpqg1TeHTw5t2drKVXjPGbVfXzAuvp4ODQebRMhXhJaJv3/ap
WFFvFlc/+WT0p5/6VKtGMzYzDMNkhrS6NEPQKlSoYGVlRc86jx8/TkNNZdFK
lixJw05JeH/88UdZysuXLxchMuGFRA8ePLhGjRowa6gu0ilatKhMeLds2SLN
Tofw7tu3D/HHjRundeu9e/emTZsmNU3IIyyyRIkS0kerKWqLd3BwaNmyJV67
u7vTSFvaRMI7Z84cWeKVKlWqXLky1UatWrVkW6nLtI+PT0qq8Pr5+YmtJLyj
3r/NGx4ePn78+AYNGuTLl8/c3NzV1ZXGQbPwMgzDZJKcKbzXzc3fSaabUIIJ
CS94sXy5wqp4K5kcMmNEXb2qNxcvR0clhYnYty+ThUkxNeFNUV8SPhUqKDxf
Bpzdi2GYHIuOSasgj9jkpV66ztPTk+ZrksWxsbFp3759SvqFNywsrGDBgoUK
FZo6dSpi0jTFSCrDwhsREWFhYeHi4pKg7ebtTz/9JO3wHBkZWb16dXt7e9nU
0MQPP/xgZmYWHBz81Vdf5c+fPzo6msJJeMeMGSOLjwOhybJgu6VKldJMTbgq
Ce+DBw/EVhLesWPHipDk5OQ6depYWlqOHDny5MmTlDtsnYWXYRgm8+RQ4VWp
7tSsmZyYqLzwpiW8SXFxXkWKKMkoXDKTZMZ4PHSo3lyCp0/3rVtXb7QHaffv
Uo7JCS+If/ZMyScRf1DjzFcRwzA5HB3CO2PGDGyCc+H1u3fvcuXK1bhxY2mE
8+fPIwJcMiX9wrtjxw7NIbcNGzbMsPCmqAcFY5cFCxbIwuGMpUuXhg7TBFyx
sbFNmza1trZG+XXUCXwfhwxdFeEkvK6urtLJoy5duiSeLPft2xemLH2Am5SU
VLlyZZoCOkWZ8Pr7+yNEmi8YNWoUCy/DMEzmybHCi7/nGr+POjAt4QWPBgxQ
VAmSkVYZIOndu5v58unNJdbf/8Wff+ovj4VFvHr9iMxgisILwnfsUHjdvjl9
OvPZMQyTk9EhvH/++Sc2bd68md6OHj0ab+fOnUtvHz9+XLVqVVtbW+oSnF7h
hUfj9c8//0ybEhISaBJmMQY2A8ILeaTlfnA4tOZvXFzc5cuXaWGj2bNnU7TO
nTtT9+yQ95E+Goal0vSA1BWZIOEFEyZMoBmloK6IaWNjQyvq3rp1y9zcvEGD
BqGhoSnqIcAwWVqtiVJQIrxUk23atElMvRW/b98+Wg0qMDDQ2NcLwzCMaZOT
hfeGjU2s+sdRCSYnvKFr1ijJ6GlqwyNjvNy4UW8Wdxs0QMyEsLDruXIZ9i6E
VkxUeMG95s2VZPeof3+DZMcwTI5Fh/BeuHABm2rUqEEzM0dGRnbs2JGWrIV4
wuwKFCiwd+9eipxe4YVdkocWK1asefPmTk5OjRs37tOnD0LwNjw8PAPCC4KD
g3v06EFamj9/fisrK1osCWZNiop8VWng6ekp0pkzZw5CGqh/swQkvL/88gtq
wM7OzsXFBW/z5csnKgGsXbsW/mtpaenq6oo4iDBgwAAxtbUS4U1JvbeA8qMq
nJ2dy5cvT12yq1evjlo19iXDMAxjwmRv4b1hba07wr00VqvXxOSE99XBg0oy
ejx0aGZyuduwod4sQlMnPHnQoYPeyLerVs3kgZuu8Cr8gHg5OibzOrwMw2SC
6OhoiB49oJQBTfNUkygZ9ePh4TFv3jz416ZNm55L+uEgjiwdSlk6nzykGCFi
xR/ssnPnzgkTJkAD//nnn+TkZESYP38+5PStGkSWzp8M/Pz8pLaYFjdv3ly/
fj1SnjZt2ubNm2VH55kGYqxuSho9rmNjY6n8SHDDhg3jx49ft26dbM6rFPWz
b4SPGzdu0aJFly9flm5CjSGFuLg4Wb3B02WJnDp1aurUqagKVBHyha1DpZGj
ksNnGIZh0iJ7C++zmTOvm5npjhOW2nFLNyYnvG88PJRklJnFgGL8/PTfc7Cy
SkhtukTs2aOkSFGZu5VtusKLht+tUqUMcpkxDMMw6aVhw4b29vZicV6GYRgm
e5C9hTfyxInAESN0x/F0cEhQsLapyQnvq/37Fd0TmDUrw1k8GT9eb/rSpX6T
YmM98+fXu0vg8OGZOXDTFd7/qnTCBEVnTWPSVIZhGCbDLFq0qG/fviqVasqU
KcYuC8MwDGNgsr3wJr554128uJ4ce/fWm6PJCW/oihVKMgpdsyZj6ScnJHg5
OelNH94t3UvJlM6e9vaZWW3WpIU36soVJTk+6NjRUDkyDMMw5cqVK1So0PDh
w2N5rXOGYZhsR7YXXkR+9b//6Y957JjuHE1OeAN69lSSkUxIlROxb59+dS1Y
MDl11o7/uwbOn1dSqvAdOzJ84CYtvEnR0Xo74ePPO3UJD4ZhGIZhGIZhdJAT
hBf4d+2qO+atMmWS3r3TkaNpCW/imzeeBQooySguo+sd3G/fXm/iWjsn33J2
1rvj/TZtMnzsJi28wMfFRUmmCe9P6sIwDMMwDMMwjCY5RHihmXpHjwa9v0CA
DNMS3qe//KIkF59y5TKWftzTp9fNzTNWG8FTp+ovm5lZnLbpQ5Vg6sLr36WL
kkzfSZbSYBiGYRiGYRhGKzlEeFOUrEtrbh51/XpaOZqQ8P43GbKCbrH4ezxs
WMay+G/6a702Xb681n1jHjxQUrZns2dnrGymLrwK5616dfCgATNlGIZhGIZh
mGxJzhHe5ORkv8aNdce/U6NGckKC1hxNQngTIyODRo9WaLv/SdOBAxnI5b/V
cxR0S372229ppXC3fn39vuzikqGrzOSF99msWUoyDV21yoCZMgzDMAzDMEy2
JOcIb4p63dgbVla6dwmZN09rjh+n8CZGRcU/exZ1/frLtWsf9u59w8ZGoer+
Z5QVKiQnJWXgPEaeOqUk/diHD9NKQeEM0m8vXMjIZWbiwvti2TIlmT5fuNCA
mTIMk6M4e/bs/PnzPTw8NDcFBQVh07XU9dB37dq1im+vvc/Dhw937ty5YsWK
48ePJ6RxkzwDhIeHv3nzRnecZ8+evUt7vhFfX1+cu6dpDwg6ffo0IkRHR2em
nMnJyU+ePElKu/3w6tUrnuyaYZiPihwlvODZb7/p3uVG7tyxAQGaOWax8GbB
X9jmzRk7jwG9eulN/G7DhjpSSAgPv2FpqTeRR4MHZ+QyM3Hhfblxo5JMeSle
hmEyzIQJE1QqVb58+R49eiTb9O+//2ITtIjetmjRopjxpoW/dOnS2rVrExMT
M5/Uxo0bz5w5k8lEoLeDBg0yNzc3MzOzsrJCRbm4uNy7dy/zxYNFli5d+ned
X+x///03ckSFpBVhy5YtiHDu3Lm0IowdOxYRXr58mZmiHjlyRGsiOIRly5aV
KlUKW1E/9erVu3z5cuZrhmEYJvPkNOFNjo+/XaWK7r3utWypmWM2E16f8uWT
M9SESIiIuGFtrTf90NWrdafzoFMn/Rde3ry6p87WfpmZuPD+NwRbQaZPf/7Z
gJkyDJOjIOEFDRs2lD2qkwkv7Gb79u3GKuePP/6IwsTExGQ+KfhpPwWtC93M
nTsX5Zk8eTKKBL/bv38/koXZZTLZ+Pj4X375BSnrEN5bt27Z2NhkUnivXLmC
3TPz+PXJkydVq1bVKrx0srp16wYxX716dYkSJfLly/fgwYNMVg7DMEzmyWnC
+18xLlzQu2OYm5tsr+wkvDcsLaMyet/1xfLl+tO3skp49Up3OkqW8b2eocfQ
pi68YVu2KMk0eMYMA2bKMEyOgoS3b9+++D9nzhzpJpnwpkVERITuB69Qwvj3
12GPjIyUhQggj+Hh4fgvC8+A8CIRuJhm2XQIL7LWTEFrX+V27do5OTlJQ3r0
6GFmZvb27VvNw9cM1OTevXvNmjUrUKAA3X9IS3hfvXpVrly5QoUKpUt4X79+
raTGcKQ4Xs3Kl7F06dKaNWuam5tTUWXC+/DhQ9TDgAEDRIinpyeijRo1SkkZ
GIZhPig5UHj/2334cN07ehYsGB8aKt0lOwlv6Jo1GT6Jd6pX15u+f9euetNJ
iotTslLwvebN032ZmbjwKhzgHKKvOcowDJMWJLx37tz57LPPcuXKdfPmTbFJ
JrzDhg1rIplTAuY1cOBAMi8LCwsI4O3bt8XWMWPGfPnllzCd2rVrYyscs02b
NtCuzZs3U09X6FLXrl2lo1AhSu3bt8+XLx+22tjYwElfvHhBm+rUqWNvb0/d
hr///nuEVNDGwtQJDSCPHTp0oJ7GyAgieevWLYS7u7sjGnXhxgvywebNm0+Z
MuX8+fOVKlVCUSmFs2fPokJy585NToejOPF+K6Ju3bpVqlQRbyGJCLG1tZXa
MayzcuXKJIawVN0joIOCgn5X8+2336YlvMgFVVS2bNmNGzcqEd5jx4716dMn
f/78eF2kSJFJkyaJ+wxLlixBDbxKvSPt4eFRr149KirqrWfPnqHvt3ykHDhw
gIpao0YNTeGlztKy3t33798PDAw03GXLMAyTQXKm8CZGRuo98IBevaS7ZBvh
DRwxIsNnMOr6dSVZKFwx5/GwYUpSi9UYYqbnMjNx4Q2ZO1fRXYsVKwyYKcMw
OQoS3rt378I38+bNC0ETT1FlwgvVEmN4o6KioF3QxlmzZh0+fHjBggUODg7Y
HeJMEXr06AHPcnZ2Xr9+/eXLl0eNGkXOBe/bvXv3hQsXYLsIwe4UH36E3UuW
LPnXX38dOnQIagbtKlOmDD2a3LlzZ+vWrRF/w4YNp0+fRsji94GQYusa9S3c
6OjoEiVKwMSnT58ONZs2bRrKiZDExMTHjx/DBOH1jRo1wotnz54hPgS8YcOG
iN+rVy96xo3fNzMzM/ism5sbjm727NkoGOQ3LCxM1JsQXojhwYMHYfdIFsUT
EZAvitSlSxcc7/bt21u0aIG3PysYgXLp0qW0hBdpohje3t779+9XIryFCxeu
VasWSrV161aqwK6pd6EnT54sXNXX19fa2hqHs3Dhwr179/7www/Y1KFDB71F
7devn6bwom6RL14EBwfjVEK6dbgzwzBMFpMzhRe82r9f7+6vjx4V8bOD8FpY
PF+yJDNn8PF33+nNxdPBITmNTmvy6+HiRSXFDp4+PX2XmYkL79PJk5VkGrFn
jwEzZRgmRyGEF68hp3g9cuRI2qRDeCFuUELpEFGoLhRVWBKEF/v+888/IgL2
xS7379+nt2/fvsXbbt260dt27dpBkKWzCu/ZswcpTJ06ld7q6NK8bds2bPru
u+/o7fnz5/F20aJFIsLq1avhm0FBQfRW1qWZnjivW7dOhCxZsgSl9fHxESHk
jydPnhQhQnhhnfQUeMSIEaLn8IMHDywtLfv06SPiJycnt2rVytzcXBQjLdIS
Xqg3wlESvFYovOXLlxc1hgLg7CAQ9ZPyvvDiePH67NmzYnd6QK/34tEqvGXL
lnV1dSVrJlAVyE5vT2mGYZgsIMcKL/Dv3Fn37rdKlUqMiqLIpi68Xo6OkadO
Zeb0JUVH37Sz05tRup4g+5QrpzfBW2XKpOsX09SF91H//koyjbp61YCZMgyT
o5AKL+jUqRPeHj9+PEWn8ML1atSoIUsKUpknTx56DeGF3En799aqVQsqJI1v
Z2fXsWNHvIiNjUVk6ahPomDBgg1T5/lPS3jh1Lly5erSpYuYcSsgIAAqDec6
cOCA1pHCmsJboEABHVX07NkzGuN8VHLrWwhvSEiIu7s7/NrBwaFcuXLUDXv5
8uWIf+XKFWk6u3fvRuDWrVt1nxGtwguDzp8/P3XnTlEsvEvev7N98eJFkbJU
eKlgbdu2PXfuXLp+ZLUKr62tLQJRObh+oqKi7t+//9VXX2kWhmEYxijkZOGN
Cw7Wa3BBo0dTZNMVXs8CBZ7Nnp2oYPYM3YRt3qxIxN7/rddN8PTpStJ88++/
6bjMTFx479SsqSTT+OfPDZgpwzA5CpnwhoaGOjk5FS1aNDw8PC3hhVpaWlpC
M+3eByHCSSG88EppRhBe6aDXFInw+vj4YEdra2tZgvDWChUqUGStwgujhF41
btxYNtvwhg0bIMuInzt3bijzb7/9FhwcLLZqCq/m7MonT5786aef2rVrV6JE
CaRDc0lpFV7BqVOnEGfKlCl4DTOlkcLSw8mTJw8CFy9erPuMaApvQkIC/L1+
/frC3xUKr7TAKeq5whDYv3//lPeFF5I7ceJEGvJsb28P84WwR6Xe5NeBVuEt
XLgwAv39/UUIzlqRIkXKlCmj5IJkGCYt8LXs5ubWrVu3mjVr4jOF72F8V9eu
XRvft/jIR0RE6E2Bhv8T0i4oSsAHmeZYoGkWpHPx/frrr6qMgn1lGdFPj17w
i4NvG3wxjhs3zsvLS/mB5GThBaErV+pJxNw86tq1FBMU3huWln5Nmz5fsCBR
30L2CvFr0kRvpricYh48UP4XeeyYokuib990XGamLLzJiYlKVn3y1PlggmEY
Rjcy4U1J7TqLNpWOJ7xwN4jkCW3QU910Ce+DBw+QEexJMzXRa1pTeP38/Bwc
HKpWrfpK21oAcEMPD4+pU6dCh7Fj3rx5vb29aZOm8Eon40pJXXKoUqVKkyZN
gvkifRJM3cKLA0ec7t27p6RO3LR7927NI3qkbzIKTeFFAXS0+lauXKmZCAnv
3r17pYEhISEIHDNmTMr7wkug+XrgwAGUnBYbKlu27Ct9iyxoFV40xTXXa27X
rh1iZmYVJIbJybx48WLw4MEWFha6BRBxxFx/Wnn9+rW1tTXFh72ma957+mkg
6ItOYBThlYEi6f3KIkh4G6XuOOX9dnXf1HDRoyYt8ONIMb95v/EvKgq/EbqF
d3NqXoXf9+s3b96I4xJzIGgV3qsqlW1qzH3vC2+dOnUofNeuXdLEk5OT7zZs
KE1EsyrufPJJckLCUPVvwX91myXCe9PWFvmm4696deitf7duqJngGTNeu7sn
KrhPq5yY+/ezxtO1y7uNjXJtN2nhjfHzU5LjvVatDHhyGYbJaWgKL6CJggcO
HJiW8MJe4YOypLZt27Zv3z56nS7hTUxMROSvv/5aujUuLm7VqlViYKlMeJ8+
fVqyZMkSJUpIh/0SEFvonnSCKWp+iLHJeoXX0dHR1dVVup7Rjh079AovBBxx
UJ8pqQN7aX4tgaenJ+RUWjCtaAovqmLt+9ATZBwFXsvOHUHCO378eGkgmj2q
1Km9pMLr4eGBcyddhXn69OnYulnfaoBahXfAgAFolsseEFerVk3TghmGUQI+
iTTXuhIQc9OmTTpSowkD/0+RUr+xlTBo0CCx4573Z4/5GIQX4HtGyRpwJLyF
U/dye79dXT81fPXq1brToaEuYO7cudLw2bNnU3ivXr10C++01LyaFS8uTYGG
n4CiRYuKQK3CezA1hdxq+RXCi98vWq5dpTFnPoj29b1haSkS0VoVIX/80bhY
MQqfnCXC6/f+D7HReTJxohGFF38v169XWFSTFt7nixYpyRGnw1hXAsMw2QCt
wgtbKV++PP3SaRVeSBM2TZdMJEgyNW3aNHqbLuEFw4cPhyVJG1E///wzEty/
fz+9JeEljYqIiEBSBQoU8PX11TwiNzc3aUkAxFOqkChY7969xVZN4S1UqFDN
mjXFaNbw8PDPPvsMKRw5ckTEkQkvikTzMJOh462Dg0P16tWfpw45gRW6uLig
9aJ7zeIUnbM0CxR2ac6TJw8sm0KCgoJwTlGqyMjIlPeFlyaYOnTokNh9wYIF
Ko0e0ZpoFV5vb28EDh48WBzphg0bVLwOL8NkCPowCvDVNGfOnCtXrgQHB8fG
xj558uTy5cszZ87Et4002rx589JKcO/evSKa7DajDhISEvDtQXvlzZs3Ojpa
ulUIb+fOnbekE9H3RiCEt1KlSmnttXnz5mXLlk2cOBE/ImZmZuKIvv32W73H
4l28uEdqfOx57v12tWPqJlSs7nQ++eQTiin7qoTnUvgff/yhW3h7pub1naur
NAW4NoW3bdtWBGoV3vmpKbimhpDwQnIp3NbWVuuPTvC0aRQ/raq4kTt3IfU4
F7Ap5wlvckKCV5EixhXeu6lzmOjFpIXXt3ZtJTm+lkyCyjAMk160Ci/Abz11
n9MqvElJSV26dKE76gMHDmzZsiVe16tXT6yrm17hhSEiAhKBWsKVaJkh+JSw
ThI0iCraOatWraLf8WLv065duxR1Z7CKFSsiQuPGjZFU/fr1LS0ty5QpI9yz
YMGCUFq0lPz8/FK0CS82YfcaNWqMGTOmf//+iE/TLjVt2vTChQsURwjv7t27
kRENbfvpp59EIvv27UMJsS8qqm/fvniBCvHw8NB7RgwovKiu3Llzf/HFF2iF
5s+f38bGRnRylgovrQmVK1cuxMTZdHVF00mFcxqvb50FrcKbkmrQFSpUwIHT
vYIGDRrIWsgMw+iFpr8jSpYsic9vWtPKIRzfRTTnAJHWNHExMTH47hU2pGS0
foq6H4hI+RuNtq4QXs3HtRlACC++cpXE9/LyojXBVep+3Xpnwr9dufKa1GMp
9X6j+qTE/t6q7w2mRVxcHH5ZKDKtcCeomtoTGCL8+vBhHW342qnZLZeILRgx
YgSFT5Q81dIqvN+mptDlfeGlqQjpd1lr+ZPi4m5XqoT4SqrinE4TyZbC++rg
QePaLv3FpC5soRvTFV6F/cZv2tom8ZAohmEywdWrV+FNYj0dKf/88w823bp1
i94eO3Zs+/bt0gj4SYVRQve6d++OmFI/Quto48aN0sgHDhyQDSmFup6QTK+R
kJCwYsUKNKWQYJ8+ff73v/9JI4eEhPz444+NGjWaOXMm9HytNpAFRYY+z549
u1OnTrCtrl27Lly4UHqA7u7uCGzWrNnNmzdT1N2VDx8+LM0LOr9p0yZILuKg
4UGTLU+bNg2tr507d1KcgwcP0uHgf9u2bVE2WQfmFPV80VBgbG3duvX48eMf
P36s5IyEhobiWMSTWa0gKcQhYdeKv78/IsTGxuKUQUtbtGgxduxYsUpyinqt
YYpAbx89eoQStmvXDjXcq1cv+LJe2wVnzpyRJiIF9YOqQwXiVOJKkPaXZhhG
CT4+PmK8bZ06dcLDw/XuEhYWRncOVeppAG/fvq01Gg1XIWQDPNNi5MiRYhfx
TSswrvCmqFf9plkBwapVq3RH9mvceHzqsbR8v129SmJ/CRq38qRQVxbg6Ogo
vQuB70Oav5FEOMzNLa02/DWVyi41u39//FGaeJMmTShc+purVXibp6Yw4X3h
pYXgdT/ypqfPSqpCt4xkS+F90KGD0W0Xf09//llJaU1XeB8PHaokuwepD0cY
hmEYhmGY7EFSUlLNmjX/r7eqq6vWe5JaefXqlXjCCPnVeq/pxIkTwl67du2q
pDDi2bGdnZ3mVFdGF94U9ewBtNegQYN0x/Tv3LlT6uEPf79dPS41vJVKFaWz
SzP1oqHOMNJwLy8vCi9UqBBEOHjq1LTa8EdS87KEGkvmHsRe9vb2tEl6l1Kr
8Ion+uveF17qlQT++usvHUfx+NtvlVRFThPe+GfPrltYGN128eddvHiygtvF
Jiq8UdeuXTczU5JdxPuTBjAMwzAMwzCmjru7u+ijq7u/hybXrl0T8zkfO3ZM
M0JCQgItH6ZSr932Rt9ksFeuXBGC3E/bAjofg/D+P/bOAyqKZOvjQ0aCiCKY
ATFgzgHTCivmnMMaUYxrdlVQn2vW1TVHzHnNgjmtAVdMICoYMYEJASMqgvDd
N/dRX9tpeoZBBvf+jsfTU32ruvp2013/rqpbbLJzixYt5C1B5ZVOP50/v21X
M/U3CETo9OkyhYwe/b+uUYx7z2BCuIE6qOytWrWk2vAL0o9VEtrznOFP0dHR
rI+eu5a9UPCeVf0/p78VvG5ubpgeHBwscxYpb96USR+YLeOKf5vgfT5zZpZL
XfbvrdifMI/sKHhTv3yJrFZNybGuOTmlKhhyRhAEQRAEQWQjQC6h3Bg+fLgO
2TGQO9CsWTNRAwwDiGzZskW+NAxrgIASFxoYguANDAzEXBjMQYaY2bPN008n
6NumNRPC81WqiIoVZQpp2LAhWvJiYo8ZMwbTR40alfT4sUxH4eD0Y7VQqRI5
kbvYt44qVapwSxYK3rXpJRTg6qPjx9+/f8+u11vZmcgpKSkW6YJXxhX/NsF7
w80ty3Uu+xelILJcthO8IGDvt26t0AMx/v5ZfUcQBEEQBEEQ+oT18RkZGd2/
f1+HEm7dusUkD4vXxyUkJIQZtJSdH5eamlqiRAm0tLe3T0pKEtoYguBdt24d
5vLx8RHuVWUALAEqo3MJK9Xtdl+d86sdC4J3ZQZKYM7MiCv+DYL33enTWS5y
uf+uWlgka1pgOnsJ3q+JicrVbmjOnMkKwhcQBEEQBEEQ2YgtW7agvvD09NS5
kDp16mAhvGiBCMjYokWLooG5ubnMHOGbN28yvSM1PdYQBC/rhp41a5Zwb0ZU
HpZAglf17xC8D375RUlt77dpE9WxYwb/RVSqpORYsZwp3qJkI8Ebv317eKFC
yvX+099/z+o7giAIgiAIgtAzAwYMQH3xewYae7j0mEowyZQxYcIEJmQ2bNgg
Vc6UKVOY2VGJ6YRZLnhTUlJKl/7vIFxjY2PRZYkyovI+qpcqIMGr+hcI3pQ3
b65aWmqsakT58no5XOK1a0o8E1mtmnw5hi94P9648XzWrMiqVbXq3b7u7Jyi
bN00giAIgiAIIhtRs2ZN1Bfchdu05cCBA1hIPQkdERERwYRM06ZNpcphS9w6
ODhwYyhxyVrBm5SUxFZN6t27t0b7Vq3+F5Bp2Leta+Gatv8bU2pmFjN+fFJM
DCth/vz5aMmbIs1qrnEpn63px7IyMkrmNOlllvflzeG9rFLZpheykZP+9vhx
ps15KwnKuGLOnDm3atbU6IofXvDGLlumpKov5s7V1xFvli6t5IgfOfG6hXx/
wXu9aNGHffrI/3vQrdsdb++IChWu5c2rlc79/5v5xImsviMIgiAIgiAI/VOs
WDGUG7pN4EXYNN5SpUpJ2TAxa2pqKrrO74MHD5go7t+/v1Q5TPBqi7Ozs7A0
JYIXpHd0dPSFCxcWL15cuHBhtPfw8BAumSTE1dUV7Zd927pma9qOFW1+GxtD
6/3ppEmv9+3rnr7oz/jhwz/du/fh8uW4jRufDB8+Pn9+TNe4lM/v6ceqUbIk
t25Sy/umCQTvgfQSjFWq85z0N8eO2dvb464IWZXEdcXx48c/3rwJ0l6RK35c
watojLGx8Zdvv0VkhGczZihxTvSoUTKFfH/B+x3+PR4yJKtvB4IgfhyioqKg
dfHo0SPhrtevX8Mu0eFhOgCHgNI+f/4sZQAvd2jD4KqRsJGSksLd+88//4Sn
x7G8ceOG/FILWgGl/f0toaGhrzXFiFACt87Xrl2Dn/qqM0EQPzBMsCQkJOhc
yMuXL7EQJycnKZs5c+Yw7bl69Wqhwbx585jBqVOnpMrJJMGrFYMGDXr//r1G
t7x9+5ZlOWltzW1gC9e0lfpXKt1y9rfpUmvaCv/9km45ePBgbvWklvdNEwje
+eklFP225Ftb/9d7bG5uLtUjL3RFbGwspMT4+2vrih9J8CaGhSmp592GDfV4
0P+G8lZw0P8uzSN9NX88wXvH0zNV9u4lCILQit9++w1bHcLFC7DV8ccff+jl
QFOnToXSoqOjpQyCgoJU6pF1YWFhsFG6dGnu3gIFCjRMf8u0bNkyd+7c+vIA
lCbafOrYsWN8xmIDcuvs5eUFP/VVZy6enp7z58/nJaakpKxcuRJOwd3dvVy5
cl27dg3nLHuBbNiwoUmTJm5ubuBz3rokUVFRjgKKFCnCDPbs2SM00Lj8JUEQ
SmCr6CZnoMmXlJSEhZiZmUnZPH78mD3xGoo142vXrs1UM+8jJJcsF7weHh4K
Pw4EBwdjloIFC75cupQ1sEXXtBX9dxG0ZLrl3m93SS3vK/xXPd0yICCAWz2p
5X3TBIJ3UHoJTb4tece0aZheqVIl5a7AlK+fP98oUUK5K34wwft48GAl9Yzb
vFm/x71dp46S474OCpIq4QcTvDfd3SkyM0EQ+gUFL9CjRw/eru8seM+ePVu+
fPkhQ4bcvn0bNtq2bcvdm9mC9+jRo2FqQkNDYbtz586Q2Lhx44yUzK3zggUL
xo4dq686M3bv3g31BN/y0lurR9xVqVIFDgouBXcZGRkFcV6X/fr1U6kn98EN
AG1F2B46dCjbi7P/oPI9OHAX+5g8eTIYgI7mGkyfPl3vJ0gQ/0L00sMLebEQ
KE3GrG7dumgGKvvVq1fcXc+fP4fnBu7ldUTyyKQ5vFqRP39+jSN4gWXLlqE9
Tr99PGQItrFF17QV/bcz3dJKpbrESb/EEcJBmgrJnW55+fJlbvWklvdNEwhe
7/QSeDOR/9OnD6b36tVLK1cg786cUe6KH0nwfv30KSxXLo2VDLW2/pqYqN9D
x65YocQ/99u0kSrhRxK8EeXLf1GPNyAIgtAjKHjxM/6uXbu4u76z4JUnswWv
sGKgFiE9Li5O55K5ddYvT58+HT16NItMwhO8INghsX379qxHBhqu+fLlY5PC
Tp48CQYg6nHv169f0QkX0tstf/75J/y8e/euVAW6dOlia2ubGadGEIRe5vDe
u3cPC5GZwwssX76cacYVK1Zwd8FPtuvs2bMyhWRJ0CpQ9PDIgiehsbEx2pcv
X150mWAuLAK2v79/mnoqzZPhw6GZ7Zd+pvU0NchnpFtW+DZ9d3q6tTqilEwJ
x9PDUpmYmHz8+JFbPXhQ467Q0FBezXmC1yX9cLyZyO08/zcBFx7jWrmCMT29
W1+jK34kwRu/ZYsizdi9u94PnRwff8XUVPPRTU2Tv/0kxfhhBO+9Vq00LjpM
EAShAyh4L1265OLiAiqSGxZSKHjh1Txp0qT69euDcZ06dRYvXsxG3EHGrl27
HjlyhFv4nDlzhg0bhts8wfvhw4chQ4b06dPnxYsXmAIbgwcPrlGjBjT2WrRo
wQsvKSV4b968CceFZuFff/0FVSpcuHD16tWXLFmi3ANSgrdNmzaQzp3CHB4e
3r1793LlypUoUaJTp04hISHcXVCNBw8eQDVq1649YcIEXp3nzp07JD0CQ1BQ
EBh/+fIFfFuxYkVnZ2dPT88g6dFKQiIjI1uqwd4ZnuDF9ShB1XITBw367wg4
yAjbvXv3hm3uIGdoN6rUk+Dwp6+vrym8W6WHU1auXLlq1arKK0wQhHL0EqX5
1KlTWIj8Yr6vXr2CP3ZRS9bbWLBgQYyuIEXWRmneu3cvE+aQV964Vq1aaLlz
587/d8Lq1R3TRaiPpjZ5n/Rjdfw2fVZ6ekXZ7OGFCu1fsAAty5Qpw61bbGws
E8LC6FtcwXteHavqfzfJt+W7Oztj+glNEW5FXQEM8PFR6IofSfDerl9fSSUz
KW7wvRYtlBz95cKFotl/AMEbZmf3UpuWG0EQhFag4L1161ZwcLCRkZG3tzeL
DMkTvHFxce7u7ubm5r169QLZ26BBA5U6sAbKIowIyptMCu0lNvGTK3ihqGrV
quXMmZM1TkC35smTJ0eOHD4+Pv7+/tje69u3LytKSvBCgxAsQX6CbJwyZcqC
BQsqVKgAKYsWLVLoAVHBC2LQxsYG5CRL2bZtm5mZWfHixcFjI0aMgBYgtEk2
p8/lOXz4MBQyZswYsKlfv/6aNWt4dW7atCmbwztz5kysM2hzEMLTp0/Pnz8/
OP/cuXPaXj4UqjzBCz6BC5H47bAr7A5++vRpmnpenoODA3cvXHQ4X7j6zLhk
yZJnz56FM+rfvz94lRe7DIy7dOkCzaShQ4f++uuvq1atevfuna73IEEQ3wB/
dKg4MrIO77T0uZz9+vWTt2zWrBlaGhsbP3/+HBMTEhKYEB4+fLh8CVkreOHx
xeYaCyuArx7d+EndFF+tc36Vyia9PW+cgULCwsLgRGoXKqRzCfhqzrgrflTB
+zkqSkkNwwsUSJX98qMzCTt2KKlARIUKotmzteANtbZ+MmxYcgZG0xEEQWiE
CV7YHjdunIojFXmCF1pN0P7hdmvi2xO7U5ULXpBOIKacnJyuXbvGLD09PaFw
fK2nqRsw3bt3B/vTp09jirzgzZcvH5vs9ubNGysrK6bdNIKCF1pWDdWAkK9Y
sSJqfzaeGTbs7e3r1KnDoky/ffu2VKlSoPvwuCh4QbBfvXqVlSwveOvVq8e6
UFG3jh8/XtvLJyp4hcA1gjNiQaWcnZ15PQtp6vUpWKAw8Cc0fUHRlytXrmzZ
srABLt2wYQPuBdWsUreN4XyrVq3q5uamUk+gozDUBKEXtqYH2pXvnJUHnmBY
CG+uipAtW7YwXcOGx2zcuJElavzTzlrBm5b+UAW6C0acGojgNUmfDa0DJHgz
mxg/PyU1jB4zJpMq8PXTp1BbWyV1SExvJnHJjoL3qpnZHU/P2BUrUuhrOUEQ
mQ9X8H758gW0nqWlJQ585QrelJQUc3Pzdu3acfNCIpOWCgXv0aNHCxYsCBvX
r19nZrh8Bq+hAtJYxVn5UV7w+vn5cfOCFK1Vq5ZCD/AEL+Dl5QWVhPMF5+BA
vtWr/9vk4Y0QW7duHSTu2bMnLV3wcuM+pWkSvHv37mWWHz9+FGZXgkbBe/v2
7bZt26rUUUzZWksgVIX+qVSpEno1MTHRycmpWrVq9+7dw11wcYsWLQoOwRsD
Duro6Ni6des3b96wqwBlwrVWsiwIQRDyxMTEoMowMjLSbRrvgwcPcGariYkJ
+zuVAv5s4UmOR2TDWlqnLzULf9e8BWGFZLng3bx5M2ZpIwjsk8WC18joUd++
iVevssjbOkCCN1NJTUkJL1BASQ0/3ryZedV42LOnkjo8/vVXYV5DF7zGxmH2
9tddXCIqVYrq1OnZjBlvDh9O+fAhSy43QRD/TriCF4iIiLCwsADZC+KXK3gx
/omzs7PXt4DMwYgoCgUvqGmMxzJgwABmdu7cOZVYhA3QX3AI3JYXvKA9uRlL
ly6treDlDWkGLY+TXrFWI0eOVKlDe3HPvXLlyqr0DnEUvKtWreIWIi94b9y4
wSw/ffqk0rfgTUhIACdDoxfE6eLFi7lLioCcL1euHM/ezc0NVK3Ugfbt2wcH
mjJlipSBv78/GBw6dEjbUyAIQgjOGQFYGAStGDFiBGYXLucqCsalV6klNsjt
Dx8+wLMdU0aPHq0xe5YL3hMnTmAW8JuMGRvm3alTJ246xqUHSpYsyRI/R0U9
nTTpjpdXqI0Na7qvSReAub9t0nOX8jmqUl3Ll+9+mzYvly5NEXxtSE5Ohpcs
WrI3L1K1alVM37Ztm7DySTExiWFh+M+zRg20XOjvzxLh37AePTCdfSvOiCs+
P3zILVzqn8aoxanJyUrK+ZT+ifU78zUpSUn1PnK+0mcGyXFxirwkFkwSLoGS
vEmPH2v2hrKiFHksIgJu2hT6DE4QhAHAE7xp6gV0IGXcuHFcwQvqDLa9vb1n
Cli2bFmahOCFthZP8Hbt2jUpKalJkyawfezYMdx15syZ/764BdEYnJycQGPi
trzg3bRpEzdjxgVvWnr8EGwuovidMGGC8PQxsjEKXl4rRV7wcn2ud8F7+fLl
vHnzWlpazp49mxcFFKhWrVr+/Pl5iXZ2dvWkP7A/e/YMDtStWzcpg8DAQDCA
m0fbUyAIQsjBgwdRd5iamgoD9soTFhZmlh6CiRe8Tgr8+2W9gbjeGcJbN0eU
LBe8LAt7ZYjSsWNHNJsxYwY3HX5iOhgIc6V+/ZoYHh67YsWjfv1+V8eIADws
LEKtrEJz5rzu4hJZufL2dK3qkDOnvKyIjIxEyxw5cnC/Q8I2PLFxF46lkcHR
0REteaPNWZwxfC/r3RUEQRAEkR0RCt7U1FRQeUZGRihRUfB+/vwZUnx9fXnZ
r1y58vDhwzQJwevq6ioatArUk729fcGCBXGQLYopXmSVV69eQWKfPn3w5/cX
vE+ePIH01q1bw/aiRYtU6ePKGKCIoSn4QT0sx6AEL5wLqNeyZcvyug8YfdQL
NUZFRbGUmzdvqtKjNIeEhEAN8bIywsPDwWDy5Mlp6pios2bN4gURXbPmv10f
Bw4c0PYUCIIQ8vXr10qVKqH0KFOmjMZhyQywhL99Jd2dXJKSktjivzVr1uzW
rRtuFy1aVON45jRDErxVqlSRMXN3d0ezgwcPctNZB7fGxcTZUj5jvp3OyZZw
0hg+Yvv27WhZrVo1bvrt27cxHWSvTIT8NPWKBqw7njeLhK1qdP78eflqZNwV
BEEQBJFdEAreNPUMsly5cmGITha0qnnz5jY2NtyBuBjVBMfxgj5SfTtQGVeD
FRW8aelRWX755Rf8Wb169Rw5cjx48IBlHzx4MBgEBgbiT50Fb1xc3Llz5yIi
IqQ8ICp43717h8sSrV27Fn6CNjQ3N2/RosWXL1/QABok9erVs7W1zQzBq7HO
DFHBiwOw79y5I5Xr4sWLvJGKv/76qyp9lPXZs2eFn/e7d+8OjatLly6lpa/S
y12v6vPnzxUqVICLwkKHEQSRQW7evMnGvoKOU7Im+KtXr3ABccDMzOzKlSvK
D+fr68t6ddmU3nHjxinJm+WCF84UsxQvXlzK5uPHj2zFXnjHcXfBKwPTNX6y
Y0v5sBD9CI4CUikYAe7n978lf7nLEAA7duzAdI0rvh07dgwtixUrxk1nqxoB
8mHz9eIKgiAIgsguiAreNM5XaKZr7t+/b29vDxIPdNmKFSv69+8PirhmzZo4
YjY1NdXV1dXExGTs2LG7du2aOHGik5MTyFgpwQu0b99elR67CZQUNLFAMY0f
P37x4sW4TAY3/IjOgnfnzp1gAHpTygMoeIsWLVoiHdjGAYG9evViZqhSoSkC
G4sWLYJTg5/Lly/HvfoVvBrrzBAVvNjizSkG+6QA4h27dLdu3dqvXz/Y7tKl
CysBtlXq4dwLFiyYNWsWLvnBIoPBFQd5C/q3W7duS5YsmTx5MrS74NLzFnMk
CCKDLF26lEmYwoUL7969W6q/FdLhD7AQJ64R76mokdOnT6sEhImFhBXCBC88
tDdpD3dN8DSdBG98fDxmAR2XKDGl9OrVq2iTJ08erhs/f/7MIkoJh/rwnAxv
QLTkfvsFcEl0JW7HZy8AbzpuOrw0Md3Hx0e+hHnz5qElL4zkyZMnMd3NzU2+
hIy7giAIgiCyEaA3fX19X7x4IdwFSgd2gaJkKc+fP+/duzdIwhw5cri7u8ML
+u3bt2zvnTt34FUOUtTR0bF58+bQhtmxYwdbaufQoUNQGgsUnKbujBgwYMCE
CRPwJwjqDh06gGqGFkWNGjVAVHJfxKCj2XpJIDNHjhyJ2yAbodiLFy9yaz5l
yhSm00NDQ0FZg4KW8gCU5vstAwcOBE0qXBX3wIEDnp6eDg4OcI7169cPCgpi
uyIiIiAjb7Ibt87QcIWfuH3kyBGez5OTkyEF3KWwzgwQsJCRFypq9OjRvhLE
xsaiDUjsSZMmVatWDb09ffp01nmdpp5NBm4BtQ6XMm/evKB8ecPe3r17B9nr
1KljZ2fn7OwMrVxek5UgCL0wf/58rgKtWLEiPJ0uXbr07NmzpKQk+B+efjNm
zIB0rpkOC/h+/foVQ+gz4FGvZDxzGkfw6gavX1gHwQv1zJUrF+bauHGjqA3G
1QdYLEQERD2mw4Nd/nxxIBNgbm7OfWBCLngS4q7rmkIbwQMTLc+ePctNb9Wq
FaZrXES+Z8+eaMmLIshulbZt28qXkHFXEARBEARhUIAe5PbVZguyY50JgsgM
Nm/ezPSURqytrdmS2doyevRoblETJ05UmDHLBW8aZ0i2g4MDW8CdC4tcDRvc
dHAXpmtc9Xj//v1oWalSJW7648ePRYWwkDdv3rCz5s3LdnV1xfQzZ87IV4NN
7ob6cNN79+6N6Ro/d2TcFQRBEARBGA43b96Ed/cFTQsFGhTZsc4EQWQesbGx
IOgwroIUZmZmffr00W3dXiQ0NJRb4E3Fq44aguDFpQQQZ2dnocHPP/+Me3kf
BEaNGiWq/oSwdWxBWnLTg4KCRIWwEFyDDwB5y01/9+4dqzx3HJQQ7qpGj78N
B82mb/OEcGa4giAIgiAIwwEaEu+z2zJw2bHOBEFkNgkJCRs3bmzfvj0IKycn
J9C/efLkcXd379ix48qVK58+fZrVFTRoBg8e3EnN3W9XMp0zZw6mc+fviLJ0
6VK03LdvHzf9wIEDmC5cXI8HaHm05C0G9ODBA0zXuH7uy5cv0bJ79+68Uce9
evXCXRrvhIy7giAIgiAIgiAIgiAIgiAIgiAIgiAIgiAIgiAIgiAIgiAIgiAI
giAIgiAIgiAIgiAIgiAIgiAIgiAIgiAI4kclJSXl4cOHwcHBt27d+vTpU1ZX
hyAIgiAIgiAIgiAySnR09IABA9jqfoCRkVHbtm1DQ0OzumoEQRAEQRAEQRAE
oSMXLlzImTMniNyuXbuuWbPm/PnzQUFBQ4cOtba2trS0PH36dFZXkCAIgiAI
giAIgiC0JiEhwcHBwcrK6siRI7xdYWFhdnZ2sDcpKSmrq0kQBEEQBEEQBEEQ
2vHbb7+pVKo5c+aI7p09e3aJEiVOnTrFTQwKCho9enT79u2HDx9+4cIF7q41
a9YcP378w4cPCxcu7NixI6Rcvnx5/vz5qampe/fuHTx4cM+ePVetWvX161cQ
0UuWLIGf3bt337RpE6SwQlJSUiBl6NChbdu29fHxWb16dWJiItt76NAh2AsF
btu27ZdffoGjTJs2LS4uDvcuX758x44d3CpBaVCZffv2ZbWnCYIgCIIgCIIg
iO9KkSJFrK2tv3z5osQYVGq7du1AIJctW7Zp06b58uWD7ZEjR3JL69GjR6NG
jUxNTV1cXCBl5syZYDNo0KDixYuDvIWM8LNLly7VqlWrVKkSpEAWSJkxYwaW
8O7duwoVKkBKzZo1mzVrVrhwYdiuXr16cnIyGoDCLVWqVLdu3VxdXUEse3l5
gUHRokUhI+wFjWxhYfH27VtWpcDAQDAAcZ3VniYIgiAIgiAIgiC+H2/evAEx
WLVqVYX206dPB/uAgAD8+enTp86dO0PKnj17MAXUq5mZGQhe1uWKgrdx48Y4
Lhp0q7u7O6T0798/NTU1TT2m2s7OrmLFimi/ePFi2LtmzRp20PHjx0PK5cuX
8ScIXvgJh2BxpCdMmAApIGxhe//+/bzsLVu2zJEjB5xpVjubIAiCIAiCIAiC
+H5ERUWBPGzdujU38cqVK8bf0qVLF9wFytTLy4tr/O7dO1NTU1YCCF74yVWX
KHj//vtvltKzZ09IiY6OZim1atWCjLh969atoKCgz58/s70rV64E+8OHD+NP
FLzh4eHM4Ny5c5Cybt062P7y5YuDg8NPP/2Eu54/f25iYtK7d++s9jRBEIQW
qDRhbm6eP3/+xo0bL1y48MOHDxoLhKeixjKlYA/wKVOmsEQzM7P79+8rP6Pg
4GBumf/884+8Pbye5s6d26hRozJlytjb21tYWLi4uHh4ePj6+sLrgPuOUOhJ
KEereBQso84uhTdm6dKlW7VqtXHjRu64I4UEBATofMkQNzc3boH/+c9/MB02
tKqJfEa4PXAve/MqRElGJadpZGSUO3fusmXL9u3b9+DBg9wZUkq4dOnSuHHj
6tSpU7BgQUs1BQoUqFat2tChQwMDA1NSUpT7RwooE66Fp6fnH3/88eTJE+3u
g2/BQWsM+KPAvgMp4uLioFHE7H18fJQfC0pu0KABywtPG/ljEQRBGCbx8fHY
DOAmvnjx4g8O8KDG2bggUVXq0cW/fQu80+FFg3lBt5YqVYpbGgpekLEspU+f
PpDChigD9erVY4I3Tf2MffDgATzVp0+f3rJlS2tra9W3ghc0ODf7hQsXVOmC
FxgyZAj8xHfK7NmzYTskJCSrPU0QBKEFWumafPnygZyUL1AvghdkZokSJVh6
u3btFJ4OPNVr1qypsNUdHh4O0kC+SvDemTNnjhIBy80F7xQdLoFeXAovssWL
F2ulxUjwpmn5h4BUqFAhMjJSSQUiIiLq1q0rXxooyu3btyv0j0IGDhyowwcQ
BIfVcdHYwlm/fj0zNjIyunbtmsJjHTlyhGW0sLC4d++ebnUmCILIcgoXLmxq
airVQYCKGAVvWFiYSq2O2wqApzfag24F9cotQVvBC4/i4sWLg0GePHmgNTVr
1iw/Pz/Vt4LX3Nycewie4L18+TL8hIywDW2z8uXLZ7WPCYIgtEPbRj48FeXb
vXoRvMCpU6e4u86ePavkdHbt2sWy2Nvbv3r1StQsJSVl5MiRxsbGCisGL4tL
ly4p96SlpaXyRjvLpUeXenl5KemOR0jwpukkeAFbW9ubN2/KH33fvn1wPygs
0NfXV6ZzU1vBC0DT6+7du1q5C4Cbx8rKilfU8OHD5XNBzbn36s8//6ykoxb+
GKH5xHJNmjRJ29oSBEEYDqNHj4ZH2ZgxY0T3gopUpQved+/eqb4NUSUk44K3
UqVKdnZ20KZiX8L37t2r0kbwAqVKlSpdujQOdV62bFlW+5ggCEI7WDtzkxir
Vq36/ffffXx8cAl1xNnZWWagL2vx+vn5bdKSFy9ecIvq3r07O2jVqlU19lp+
+fIFP2MiK1asEDWDyrdv356Zgext3Ljx6tWrr1+/HhcX9/Hjx6ioqBMnTgwb
NqxgwYLMzMbGhreOgJQntWrtp2kjeEVdCjWfPn06vO8wuiOjYcOGCsdjgzaX
uSgYDUP+gsLbk1tgtha8Mq5YuXIlyLGePXvieDAEmgEyo5EvX77MVbstWrTY
uXNnaGjomzdvYmNjL168uH37dhC53AInTJig0T9t2rQRVm/9+vV//PEH3LfQ
LOFp3kePHmnlsa1btwq1c4ECBTT+DUZGRpqZmbEsQUFBGo/F7Rd2dXWFP0Ct
qkoQBGFQwLPd0dHRxMRk9+7dvF3w8MfWFApeoHLlytDSSEhIYDbnz59XcWIs
Z1zw5siRw9vbm1vCuHHjtBW8eFBoiVlZWek8cIggCCKr0Ki2kNevXw8aNIgZ
gxCWsmTqjNtdqxsvX760t7fnKhF5+yVLljDjatWqicoQEKG4BABSq1YtmYGX
IBinTZsGLws0trCwkOndFgqEDRs26OUSKHQpiBEQU7jiAAIvtQxeAuVH55Kt
Ba+SAl+8eMEd8btt2zZRM+4A++LFi0NTR6rAmJgYNroemkncloxujr169Src
26yGHh4eWo1yB2HOzcu2z5w5ozEvhvdESpYsKb82B8jbQoUKaSWQCYIgDBwQ
jLlz51apQx/PnTsXnmwBAQE9e/bEcFXwOmCCNzg42MjIqESJEtDCuXLlyurV
q/PmzQsSGFQzGmRc8MKLz9LScsWKFXfv3oU2TL9+/aAxA/azZ8/G6VpKBC+8
pKCeKi3jMxAEQRgIytv50Hpv2rQpGsOGlJkeBW/at6NtoWHMXSqdx9u3b+E1
gZbwWGbx9nnA24QV2LdvXyWRguAdhG8uAN5KUnVgxeKrRKWeLyM1plqrS6CV
SxMSEqpWrYr2ZmZmd+7cyeAlIMErCjQtqlWrhllA/IraYJtBpR75/PjxY/kC
P3z4wEb2Qusl444FhQsNG3Ze3KaLPHALsV7a6tWr7969mxXCppXJABrWzc2N
ZVm8eLGMMbbckJYtWyqsIUEQhIETHR0NbQw7Ozv2iKtQocLWrVvT1KsCDR48
mFmC5i1Xrhwza9KkCffF3bx5c3iSc0tev3595cqVueN2pk6dCinc9gxkgYy4
ff/+/Ro1arD2CbxfoG4FChRQpU8hgfp4eHhwD3Hjxg0okPcFEr/KapzeRRAE
YYBo1c7fs2cPGufPn1/KRr+CFxrt3I4qeKpLWfr7+zOzAQMGiNrAQ56NHe3Z
s6fyPq/w8HDWzztixAh5T06bNo1t9+jRI+OXQFuXgmBhvWZdu3bN4CUgwSsF
G4tbtGhRUYOJEyeiwahRo5QUyGI35cuXT3Q8vLaOhTuc9dXCLaHk807at1+Z
5s+fn5iYyObzOjg4cDsRpDh69CgrIU+ePK9fvxY1e/XqFZsrYWlp+eDBA+XO
JwiCMHzggQlPNtCPbBVdKd69excZGak8+Ia2vHz5EnQ0ewtAxW7fvi3TicAD
MhYuXJit7UsQBJG90KqdD89t1nUoZaNfwQtcv37d1NQUywS5+uzZM6FNTEwM
E6TQJo+PjxctasyYMWjj6uoKLxetqrFgwQLMC41/7nQboSeTkpK4kyhPnDiR
wUugg0t37NjBdEQGp9uQ4JXiypUrmMXW1lbUgA175s1xlgJaIEwAcldUzIhj
Hz16xP40jh8/riSLl5cX2hsZGeGfG3cWAIhZJYVwh3xL6f1hw4Yp+ZZFEARB
ZC04Om7lypVZXRGCIAhd0Kqdj+H0AUdHRykbvQte4LfffmP1FJ0/AonMYO3a
taKFvH//ng0u2rdvn7Z1+Pr1a9myZTH7H3/8Ie9J7lrAxYoVk4/DkxmCNzU1
lQ0rlXKIQkjwSoEBNgFQlKIG3t7eaLBnzx6FZVasWBGzXL16VV+OZX8dSsYb
gMJl0ctB+WLitm3bmH+khlsLy2HiXXQpbUhhA6fhb0T5gtcEQRDEdwPeX9ic
KFWqlJIlGgmCIAwQrdr5bKmgypUrS9lkhuD98OGDs7Mz63XihZm6ceMGa6LL
BOfZvHkz2ri6uioc28ljxYoVWELp0qU1erJ///4sxc/PLyOXQDeXTpo0CXP1
6tUrI84nwSvFw4cPMQtvVSYGCzMuE3iZB+jEh2o+ffqkL8eyP1sXFxeNxmwk
AxAQEICJIO3ZzPRcuXIpFKdLly5lRQmX0u7UqRPbe+TIEeWnQxAEQXw3bt26
NWTIkGXLlkmNnSMIgjB8tGrnYyh7wN/fX8omMwQvEBQUxKrKW/GHhdIC2RsW
FiZVAgvg8/vvv+tWh/fv37NmvzAaFc+Tr1+/ZusEmZqagirX+RLo5tKzZ89i
rgyuEU+CV4rDhw9jlsaNG4saTJ48GQ2sra1v376tVZ316NgvX76Ym5tjRo0t
FhbbxMzMjDt0nxu3OTAwUMlxU1JSWFwv1bdLaV+8eFFGCxMEQRAEQRCEvlDe
zof2Kso9+di/mSR4gbZt27LasuCBrPcKGDp0qEx2tp6skqVVpGARtPbv36/R
k3/99RdLlOl6ziTB++bNG8xlYmKSkfGiJHilGDBgAGbBwJtCQkJCWLG2trZL
ly4V7bfVl39kqFSpEmY8efKkjFlUVBSrMC9m8oYNG9gu5ZHQQkND2egLtpR2
ampqvXr1MNHKyurJkycZ8QlBEARBEARByCDfzv/48eODBw9Onz79yy+/sIbr
nDlzZArMPMEbHR1tY2ODheP6ntB+rlKlCqY4OTlJBYMFQGiwzlb5GbXyjB49
GsvBYP7ynuQu5ASA3tHhEmTEpfnz58eMopG+FEKCVwhc2c2bN+NfhLu7u8z3
BJCNKg52dnY+Pj6HDh1SHhtTL47t0qWLvDZHpk+fzqq6fft27q6EhAQWOw7+
DJXXf8SIEaxMXEo7MDCQpcyaNUsHPxAEQRAEQRCEQlTaAC382bNniy6YwmD6
SFt69uypsbbz589n9osXL4bWO68tLUVMTAyaFSpUKCPuWr58OZYjXJBUVDE9
fPiQLemSM2fOp0+fylwCjS7VVvCWKlUKM3JXqNeWjAhenTFAwQu3/atXr0JD
Q0EJ1qxZE40dHByioqJkDh0dHc1dYJFhYWHRqFEjuJ/h0sj/QYk6VlvBC7cr
ZoQbWMaMhWWztrYWSlqoMKv/zp07FR763bt3BQsWZH998JPdlu7u7hQChSAI
giAIgshUtJIh0AyeOnWq/II+mSp4k5OT2eDMPHnysEhW9erVk1cN4eHhaJnB
Ca1slHKnTp2kPMlLnzdvHtslOl1Ro9TSWfCy+Zj//POPzqf8bxO8yqlfv76S
pWPfvn3buXNnNkBCCNzGAwYMOHXqlEblq7PgHTt2LGacMWOGlM2NGzdYlUQH
LXPX59Vq4i1bvxtgQzJUmsZXEwRBEARBEETG0aGd7+DgcODAAakCM1XwApcu
XTIyMuJmNDExkQkJhZw7dw6Na9eunRF3HT16FMvx9vaW8iQvnSvSVcom/0q5
VFvByzoiL1y4oPMpk+AVJU+ePBEREcrr8OTJk0mTJnEXaBZSrly59evXy8he
nQUvCzc3c+ZMKRs/Pz9WE9E/8NjYWCbbLS0tla9kDWfUvHlz3sl27txZq1Mg
CIIgCIIgCB3QqLbS1FFeb9++DUqNhY0yNTWVGtOYeXN4GYMHD+a2nEeNGqUx
i756eFlfVZs2bZR78sqVK0wp4KhOhRkz6NIsH9KcHefwKsfCwmLbtm3a+hOU
b0BAQLt27diq0Dx69+4Nf3H6dazGIc2gSV1dXdEmd+7cUiONPT09WT03b96s
vAKPHj1iY/tV6hBeosP7CYIgCIIgCEK/KBG8XFhYG2tr67i4OKHBdxC8b968
YSv+FChQQElPk77m8LJRnQrn8DKGDx/ODHjRpDNP8LKgVc+fP9f5lP9tglem
nI8fP4aHhy9ZsoRpVfgruH//vm6OTU5ODg4OnjhxorDbt3379vp1LAtaJaXQ
L1y4wI7u6+srVQ53ad3mzZtrVYc5c+awvH/++aduTiMIgiAIgiAIrdBW8Kak
pFStWhWzQFtdaPAdBG8aZ/glbCix11eU5kmTJmE5wsV85T35/v37woULo4GR
kdGlS5cUZtTZpW/fvmWnnJHQQCR4hTx+/JgFDNf2HIWkpqZeuXKlR48eXM0r
Or9VZ8dWrlwZM546dUrUYOjQoSot4S3Uq5EvX76wvFJd2ARBEARBEAShX7QV
vMDOnTsxS61atYR7v4/g1aHlX7JkScySkXV4GzRogIVs2bJFW09yV2OpUKEC
a/NnkuBl05bhWBlxNQleUfz9/XWrjAxHjx61traW+ePSzbFwp+EK2oCoRE1J
SWFDJrRizZo1Wp2gDk8bgiAIgiAIgsgIOjRB79y5g1ny588v3GuwgtfX1xez
CDtnFfL582fUI0ZGRrGxsTp4sl27dsyMLWecSYKXdUb37t07I64mwSsKGwNc
uHBhUYPHjx/fUvPhwwflVV2/fj0Wa25unpycrBfHnjp1CnO5urqKGpw4cUIH
tasSC90mDwlegiAIgiAI4jujQxOUjZWFNrlwr8EK3i1btmAWFxeXlJQUHQ66
YcMGLKFatWq6efLp06c5c+ZEsxw5cuCiNpkheFNTU93c3DDXunXrMuJqwxG8
TGNqG2r72LFjmPHnn3+WstH2D4HNCre3txc1aNOmDRps3bpVeVW/fv3KBkvf
vXtXL4718fHBXFKB0JmBSsECu69fvzYzM0NjY2Pjly9fKq8JCV6CIP4N5MmT
h/ugE65eYWRk5Ozs3KpVq5s3b0oVsmjRIjTu1auXcC/7kHvo0CHR7Gggv4Qc
K4SLtbV1uXLlJkyYEB8fL8yi8UNoVvueIAhCBB2eUf/88w9myV49vO/fv2ex
hvbu3avtEUFCsomQU6dO1dmTy5YtY5aNGjWCYjND8O7YsYPJ6rdv32bE1YYj
eKOionBviRIltCp248aNmLFbt25SNtr+IaSkpKC9qampqAGbFTt58mStasvm
yHMneuvs2IcPH8I9gLlOnDghNPj8+XOuXLnQALR2YmKixjKbNWvG3LV06VLl
p0YtIoIg/g2ICl5HR8eC6djb27M3yOnTp0ULqVWrFtpA0wUe1Ly9TKuCcBYd
R6Rc8FpaWrKKOTk5sQc1VPjy5cu8LKjWC0rDNf7y5csff/xRpkwZeA3B/1Om
TBEN4ABNsrp168ILCM6ld+/ewhF0ojx//rxfv37ly5e3srJycXFp0aLFxYsX
eTYvXrwYPnx4hQoVQMUXKlTI29t7//79wrX/goODO3bsCAZQ//bt2/Mmvmlc
bZO1juAF+vvvv8OFs7W1rVmz5sSJE7mXRvTzAhc2CA3aq/CWL1u2LFTbwcGh
Tp06GzZskFmyEBg9erTydtqTJ08GDBgAVwTuw4YNG65Zs0a+8KCgINGGB9yW
0B6uUaMG3KJwt8BF3LJli7AouKC//vpr4cKF4XTAWPhd/evXr2vXroXsUB+w
gcY2uE6+NSJVpeTk5Llz59auXRsuAbiuQ4cOkZGRXAPlX2yUeEn+ihMGhQ5N
ULi9MYtof5nBCl5gzJgxmMvV1VX5KqIIE6rwdy3/2VO+HPi79vDwYMZbt27V
u+CF6sFDW6PEU4jhCN5Pnz7BexlbCFqFS4J3IhYrE+JMhz8ElkU49hiAtzzu
bdCggfIy4XHKrh28qTPoWLjZ2AK48K6Bn0IbePuzE1F4t7ChDkC9evV08Jjy
LARBENkOUcF748YNrk1cXByIO0h3c3MTNqQfPXqkUi9+h2+EwMBAngFXPYku
zqhc8PJsXr9+ferUqUaNGqnUQ5h4S8ip1MvQK3FCUlKSl5cX1hDOEYcGwSuJ
d7KgEdhLClSDSr2ahsZXPKgY/FQL6rt06dJMp2/cuJHZRERE4Jg6kNvu7u4F
ChRAm759+3LrsGfPHlw40l6NSj14CRJ5l0+GCxcupKmbKKx1BwIcN0AEQbrw
kokCPscbA2qLKc5qcLtt27ZSsvTQoUPK22n37t3LmzevSj1Kk7U3hg8fLmUf
HR2N9zOv4QHnVaFCBXa+bFShj48P1wzuZDwK3Mxs9UNoIDEDaJl07NgR08H/
pUqVMjExwXtGtLEtU6WPHz/iJYBWIgjV3Llz49UXjRMrClRSuZc0XnHCoNC2
CXrnzh0UHSrOLFQuhix44W+EBQXq3r27aPtflOvXr7NVRKdNm5ZBT0Jp8MeI
xvgHJZ9RK5fCq6pKlSpoD3+nwmGx2mI4ghdo0qQJGixYsEBhmbGxsaxnPzg4
WMpM2z8Ebpb3798L97Jx1CqJrlVR4LHMHp7CV5tWjoXbG17rrA6gUkXNOnfu
zGyCgoKUVBLuMbi1MAs0NmJiYrT1mHInEwRBZDuUCN40dQcoiDvY9eTJE94u
XMcNNM7IkSNVYl8jUT2B1oPmBAiE0NBQUQMdBC8Cb5AOHTpgY4mbrlIseLFz
pFatWvjx9vHjx6jj/vrrL2aD0TWhIXT16lV45SUmJrZv314ltvIjF7D8+eef
waxfv35v3rzBlLVr16rUXRLwhkKzSpUqQcpvv/3GOt2uXLmC62WwDwhv377F
ZtiSJUtSUlKSk5MXLlyoUvdua+wWCQkJAWncsmVLfFnPmjULrwh+IoA3I56v
aFOZdzrNmzeHi4g91PjihoYctLfZgYoUKQKJq1atEmaHw7GWpJJ2WuPGjcHy
l19+AbfAoeESYPtW2D+eph7MxhqBvIYHXt8aNWrg7Lw0dQMG73xuNfBKDR06
FHtsz5w5AyICdCUIYTTYvHkz3lTHjx/HZjm4Dj+VdO3aVasqjRs3DhI9PT1x
LU44u2XLlkErRcmX+blz56o4ayYq8ZLOV5zIErRqgkZGRrLvTnDps2od3rQM
SKo1a9awU/bx8VEymReekPgnrFJ/bRNVN9p6cvz48cIvS1LGCl0KD4pdu3ax
xY8Af3//jLvaoAQv6xDPmTNnRESExgLh5QUvI8zi5uYmc7l10GJssi3vAzg7
NLsWZcqUYa9gGaB6devWxSzw3M6IY6HxwIbDAXXq1BH9MgxPcvYlJ1euXMqX
r2IdxyptFtUlwUsQxL8BhYIXaNiwoajWQLG2Y8eO4OBglXq+CW9FRaZVsTkB
+og31iiDghe4f/8+CDpzc3NuY0+h4IUGiYuLi7W1NTfv0aNHeYfr2bMnpEA6
S4F3JQgiBwcHmS6J2NhYbAbwThmn2+CifnBclXo4H+/dh5EhQX/hz3Xr1gk9
gCE4wFLmBOFylCxZEnQxBrKAo2BX7PXr15lNeHi41OdrLijVMZ4qqELsVOIN
xMXYkkLhBs0G0IampqbFixdX0k4DcQpmBQoU4PZCosYXnSo+efJkbMMIGx4g
9CCRN+gdx7axRUtxJhq0RrhXE+/YxYsX40/86wBlyi0nPj4erq+ZmZlwML9U
lcAV0J6BW443Om7AgAG86yIE2pOgwcGTWE8lXsrIFSeyBNYE3SQN3JbDhw+H
xzKO+kBmzZolWiDTR35+fpu0RziMUxSdJRXchGzsBP4ZhoWFSRnDH9r06dPZ
FEj465OJL6FVYx4elWz4h3LBK+pSkPAzZ84E8c5bWaZx48bCB4UOGJTghWcR
NgPwnbthwwaZFV1jYmLwGx0iP3FbBy1Wrlw5zMJ9WXNhcdIAqDb7WisKvJ07
derEtKfoJCbmH3gdC+8EeDvPmzdvxIgR+CJgFClSRNh9gHBH1POGIcnDpkUD
1atXV5iLBC9BEP8GFApeaKJDm9nExITXfXD79m1VelAFeOvhy507yDaNo1VZ
c4L37THjghdo27at6ttghgoFL64O0KVLF24ivK+nTp26aNEi/Pnu3TuQJwUL
FuRpWxCAYCbzlfjs2bMqsfCV2Bu+evXqNHWHskrdScGTHqgu2fuua9eu8HPb
tm1cG3x3i3YvMqBVrOIMi7p79y78BAnMM0MdKjPWDuppa2tbo0YNFO+gc8E+
d+7cvGrDXnNzc7DkZZ82bRrYz549GxcB0dhOW7VqFZj179+fm4hBOEHf8YxP
nz4Nzf6mTZui1uM2zKA+oEbh1uUN38X1N3/55Rf8icuFrFy5kmtz//59uL77
9+/Hn46OjqKCFDt5r169qrBKeAmE3wQOHz6skh6cmaa+LatWrQrtLtZSUuIl
na84kVWodAL+sqQ+vmmc7CCPQlWls6RKU88rwYE6CPztNGrUKCAgAP7c4KUD
f7wPHz48efIkCAc2bh+AP+3jx48r8aTCanCHvMpn1MGlDRo0UBJ9SAkGJXjT
1C0BnJeBgJqDRz080CAd3vvwAoVnKbyde/bsycbeq9Sfc+U/uGl7+YDWrVtj
lj59+ogawBExjgQCrwZ4gW7evBmehAkJCfCMffbsGTzM9+3bx6ut1PBj5h/l
gH/u3bsndQotWrRglvK3N483b96wUc0AG9Ekjw5OJgiCyHYoEbzwtho8eLBK
PS6Xl/33339XcYYxDxw4EH526tSJa8PVqvD0VqmjK7Nhoml6Erw4bHX8+PEs
RaVM8E6fPl2laa328+fPqwRDppUQHx9/+fJleNfz0nH0LDSu0tTvXxwxNWTI
ENTOkAJKGWfyss/UoI/gJ29iDggfSKxfv75UBc6cOaPiyLq0dIHft29fniU0
DyBdKi4Zjs2GtsGtW7cwBd7Xw4YNAzXHs4RTwBc6NzE4OBjyent7Q4NcoeBF
BQrtEF560aJFoTHMHQX36tUraAPnz58/NjZ28eLFvIYZNGDgEgg7jPCGYfFS
oG7wMyoqSqo+UPPhaoSxUCpWrMhrXchX6dq1ayoxwYuXBm4DqTpgnfE7iXIv
6XbFiSxE2/Yz/HGNHDlSZmio4QveNPVn1VGjRnE7rOWBm1wYMlfKk8qrAU9L
7lH04lJ45cFzQPn0ZI0YmuAF4DGL81kUAnesRofocPlY96iRkRH4XFRQQ+KI
ESOUVxWKmj9/vkb/KASaSTIxukF0swWGHB0dRUNvycDGigMzZ85UkkUHJxME
QWQ7RAWvi4tLyXQKFy6Mj19QtbyxyvDWKFWqFOw6cOAApqCetbKyEob8ZVoV
ZCP8bNasGXsT6UXw4gBg7vgflbqboKQ0aAaqDSwPHjy4dOlSOB1LS8ty5cqB
ruG+kvbu3atSz7E9ceJE7dq14QRdXV1B12vVO4Yzf+/cuYNHhGOxd9n79+/x
oy40XMHhGM0D2khr165l2bE/jjccDq6ISqzzDoEGZPny5S0sLB4/fswSsVNY
OBdp7NixKkEPMmPXrl2wd9CgQRpPE2enDhgwgKWA6oeTgnc3zldVKHgxhueR
I0d46TVq1IB0LCotfVoxNEhwfLhQXfIuATgwJiZm+fLlcKHhOrIriFGtQKhC
Q6hAgQI2NjYeHh4g5zU2yaCGeDWZpcYqQR3gQtva2vJCXWEbTOomj46OhjqX
LVuWq2uUeEm3K05kIUqazfBwc3BwqFy5MjyXbt++LV9gthC8yPXr1/F7oAy5
c+eePHmykpV9dGjMx8bGcjsrdXZpzpw53d3d4cEO7yYM4KBHDFDwpqnFGjz5
ub2iolSrVk1hwCgdLl9SUlL+/PlZxocPH0pZBgcH47dKeeBFEBISosQ/UmAU
RLhkc+bM4b6LRQkICGAZBw8erNWVSksPNIHASy2TnEwQBJHt0LgOL7eNwRvw
iR1VkM6CKnz58gWbCtxwTzytypoTzEYvgheHg3I7lzW+yNCsS5cusI0dfCDt
WYRkZ2dnNnMNThxSvLy8QMWo1INFMTwvKCYUNUpA4YOAaua++MLDw4Weh9bs
2bNnmQ3oXzicsNgcOXKAQBY9Ik77hfYwNxHnrgqjFc2ePRvSRb9jw/UtVqwY
aED5qXxw9SdMmKBSh/ZiY25B/eEYMybKFApenOYs7MHBiKCsxxYqrOJ01MoL
3hs3bjD3FixYkOteaCNBs6ROnToq9RB9Fg+nadOmMpp3586doFtBenDXmFZS
JbzrGjZsiJoUPLxgwQLs24JbUfRYOIuct5i1Ei/pcMUJImt58ODBvHnzGjVq
VLp0aXt7e3gy58uXDxrwvr6+O3bsoBW1DBl4xS9fvhwecaD34S2GH/fgfQov
0EmTJoF4NJy4AVCT0NDQyZMn169fv2TJkrly5YLawv1WtGjRli1bTpkyRWZ6
OEEQBJGNUDKkGVoXZ86cwc7cFStWsHTsy+ONc+7Vq5dKHbSZpQi1KvbGQgMG
R/DqRfDiInTccZsqZUOaUerCa27RokWo3J8+fYoRutjcWBz2rFJPC8JeuY8f
P+LykfBm5HV8S7Fp0yaQjbgAB6jUgIAATD9//jwkwqt24cKFDx8+fP/+PegX
DAENiWwMM4Y5EhYLRVlaWgrTExMTQZhDCbyFkzCqNne1HQTlj2jQG5yFCq0C
qVODZsOBAwcwVGyhQoW4gbhR7oGvWIpCwQtKUyWINJWWLuXwk/uVK1egJezh
4cFipMgL3jt37pQoUYJ130DjmYlZHMYA9yQIc0iEM4KrgIsTiUachoYQhl4B
53PndimsEuhcNvwPLhMbRKGSmJEN0tXIyAhaZby2ohIv6XDFCYIgCIIgCOLH
QHmU5sjISGNjYycnJ9QI0PDGBT0dHR2544Rx3RlQAWytHKFWhbyenp6oONL0
OoeXu+KDQsGL0a54CwS/evXKxsYGVDAOIQYtrFIPxOJ29sFZ4BIDyjt5MdfO
nTtB4IB+uXfvHvzEqJK8IV6Q3qpVK67MRPHFW6Hg06dPKnWEZ+GBUGcNGzaM
l45fBlj/IwM/XwjjcoBwAxloamqKQZ6FPHv2DMdjw+3Rr18/bgiv8PBwc3Nz
8Bu32goFLy79jNOcudSsWRPSHz9+/OHDh2LFitnZ2XEHrckLXgZIcvQnGzSO
Kpi34iEG665bty7P5+Ar7I2F25hNak5TfxpSXqU3b94MHTq0bNmyFhYW8Iez
ZcuWgwcPqiQWGkanCSOaavSSDlecIAiCIAiCIH4YlAteAJrlqvTl7UJCQuQH
DEMDHnOJatW7d+9COx/Sz507pxfBi4pg9+7dLEWh4B00aJCo/sJAUteuXYPt
HTt2iGqWiRMnQvqCBQu0dTsofZV6gZvnz59LKVYQX7ALZC/+9PDwgJ+gLrk2
cC1U6lU8eHlBL+MiCMKQwiji8FMDF5wNKpROeO7cLnsuhw8ftre3x6G/whUY
ly9fDrucnJy4n0RwncTChQvDtsySlLgk0NatW3npOJcZFDQoTdiwtbXlFo6B
lOG6w7bU2GAEY5t07NgRf+I60bzvCfDTxMQkV65cLAWULA51gP/h3Hn9rRms
Eq5GKow0AlcZqgHlCBf70OglHa44QRAEQRAEQfwwaCV4UUPhrEOMvCSqQHEB
nZYtW+JPKa2K69SAcMCwPxkRvFFRUcbGxqCguVGAFApe7BoWrtlXu3ZtSMcA
y6DKVd+GgEZAr6m+jZrLAzRylSpV2Lo2DBA1OK3y1atXKomoU3jK7du353qV
t+QTCHzVt0GYEVwOSXQlPlykpnz58rx07GgWrpWAa+7wpo4i58+fz5EjB+hE
kPyi07JQ8Mogs8ggLrjDliFGYmNjjYyMChUqlJauLmVwc3NLUy8/BJdg0qRJ
vPIvXLiAOh1//vzzz3AL8RYN+fTpEyhNPBzw8uXLYsWKQa6ePXuKLi+isEp4
FcCY5zSc2Ct09ZQpU1SCudgKvaTDFScIgiAIgiCIHwblghdEJTT+cd3VlJQU
DIS4a9cuoeW+fftgl7m5OYamlNKqSUlJpUuXxnGhGRG8X79+xQUcQYZw0xUK
Xgy9xVvJ9NmzZyDlbGxscAzz58+fHR0dy5Yty+1iAydUrlxZdAYlAyf/9u7d
m5eOa9kfPHgwTb2CDGxfuXKFZ+Pn56firMp64MAB4TmKBjJKS59JLRWPqGrV
qqpvw1fCtqhAxnS46MIVT+A2AIeIfiuQR+GQ5ri4OLiFwDncQ4uG4eIiHD+M
S0qBUOWt74BinE0uxnnKvJDFeCc3a9YMfw4ZMgSHzWsVdEV0SDN+RggPD+ee
r7W1tZ2dnTAWOs4dEK6spNxLyq84QRAEQRAEQfxIKBG80OSOiIhAcTd27Ni0
dPlpa2srGq/p06dPsAsM1q9fnyarVYODg1nnlw6CFwQ1pGN8HhBlvOG+CgVv
mnr0spGREVuDJjo6GqP1cgfc4ujlHj164NxkOHFcdBgsZaL43r9/39jYGApf
tWoVShJw5tq1a1XqUMYYTgo76fLnz79z5042P3rz5s0gZKysrNjKsKDXwAaK
YotAgRzDjjyeGoVCnJyc2HhsIcuWLcOa4wxluF44GZkXhZtZtm7dWlgI9nqD
cFPiYS4KBS/QsWNHFG4oMMEVDg4OkCKzCItQXYJzcLpu//792TomISEhONIY
zgJT4F4CvQnls8nUoJQxZDcO+k1MTIS7OkeOHOAurc5XVPBiooeHR2xsbJq6
TxZHFAgjg0VGRkK6vb291G2mxEvKrzhBEARBEARB/EiICl7QAgU5oHrFUZEo
90A7oPqTKhYX2wUpmqZpNPKAAQOUC15LS0tWq3z58jGxDBUW9pCq1OvFF5QF
LS9evIhLB8KZFitWDNceAkXAlfPx8fE4L9LMzKxEiRI4ARkEETdmkSi4KAwW
XqpUKQyOZGpqygIQgU4ZOXIkHhT0lLu7O67Da2JiwhssvWfPHjSrVKkS9q6C
mg4MDOQdMTQ0FHZBIcJuWQRUDwY1Apv69evj9QU1xJvBmpa+iv2ff/4pLAQS
5YfvSjlEueAF7YbuKlKkCOhBcJp8926ahLo8e/YsXl9zc3O4iIUKFcIacmNH
p3HWjYJbC+4N3B4xYgTXqzJInZFolZKTk1FyQsWgSnhZGzRoIJyli35mEwR0
85LyK04QBEEQBEEQPxJK1uEFcQcKa+zYsdi3BW1yzHX48GGpYjHgErS9QSfK
C97Xr1/j6GglgpeHlZVVmTJl/P39uVN3GSoFMOMbN260bdsWhIONjQ0okblz
5/JGwKaph4/++uuvIJfAIaD9YZu34o8Ux48fb9WqlZOTEwguENQdO3aMjIzk
2YSFhXXr1g2KhZNycXFp06aN6BBW8IOnpydUEjSLl5fXmTNnhDYzZsyAU2ve
vLlMlT58+ACaCCQS6HdnZ+dx48YJJ6WCGsIAU8KPCWnp43szVfCmqZfj7Ny5
M9xv6POAgAD54cRSIZHv3r3bt29fOFMop0CBAiAtcTw5j/3794MMhLN2dHRs
2LAhN2jzrl279Ch409RdxvA3VaJECdC8pUqV+uOPP4S3HIArZMENmUEvKbni
BEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQBEEQ
BEEQBEEQBEEQBEFkI5TE3MuVK1epUqV8fX1PnDghE8yNhSJUGClOlP/85z9K
qiSKMGKbKIGBgdxcLi4uWi14jaSkpOzfv3/gwIEVK1Z0dHQ0NTW1tbV1dnb2
8vKaMGGCzJrpoh7TAYVOVniInDlzFi1atEOHDgEBAaKLAGbqZWKxIqG2wmNx
87q5uWl7scC+WLFi3EJ08JKJiUnevHlr1qzp5+cXHR2t0DkKb0jlGUWDagqB
u9HJyQlqO2rUKKlFA6UwzBtb3jPy908a5xbSyhUEQRAEQRDED4C2zVFPT8/n
z5+LFpVdBG/nzp15GUNCQrSqJCgCkMnylfHw8AgNDZUvx3AELxdQdvv27fue
l0m54FVJBPOXQbjQWwa9ZG5uvmzZMiXOySrBy6NDhw6vX79WUgGDvbFJ8BIE
QRAEQRC6oUOLtEiRIrGxscKisoXg/fDhg5WVFS/j8OHDlddw/PjxCutjZma2
bt06maIMU/Ai69ev/26XSSvBy1vWXCPjxo3jlaAXLy1YsECjcwxE8ALlypV7
//69/NEN+cYmwUsQBEEQBEHoBmsKbpJg0aJFv/76a7169biN0pYtWwqL0q/g
bdOmzSYtCQ8P11j+1q1bhW3sAgUKfP36VUn1lixZwnJZWFgMGTLk4MGDt27d
SkxMfPLkyenTp9euXduiRQsjIyO0MTExOXLkiFRpzGN+fn7anuyLFy+UVFjJ
IaDO06dPHzhwoLOzMzs7c3PzBw8efJ/LpJXghUoqH9UMlm5ubrwStPUS+Gfm
zJlDhw4tWrQoKwSu7M2bN+Wdk3mC193dXcq9GzduhL/ZsWPHwh8puw8BX19f
mUMb+I1NgpcgCIIgCILQDeVNQWhVli5dmtmHhYXxDPQreLUVCwqBRjs7BQ8P
D7Z95swZjXlfvnxpa2uL9lDOs2fPpCwvXLhQuHBhtHR1df38+bOomV48Jo9W
h4B6grJjPunfv7+UpX4vk1aCFwD3Kiz56tWrwuw6eyk5OXnlypWmpqZo3LVr
V/06R7nglVJ2PK5du1axYkXMAtUG6SpqZvg3NglegiAIgiAIQje0ago+fPiQ
NYxHjx7N22v4gjchIcHMzAzLr169+u7du9npDxw4UGN2JgarVq365csXeeM7
d+7kyJED7Tdu3ChqY2iCFxkxYgRmyZcvn1RfapYIXrhkuKF8CDobz8zyZkTw
InPmzEHjnDlzit4GhiN4gadPn1pbW2OuFStWiNoY/o1NgpcgCIIgCILQDW2b
gnPnzkX7mjVr8nYZvuANCAhg5zt//vzExEQ2n9fBwSE5OVk+e926ddE4KChI
yeGY2urUqZOogWEK3kePHjEvSfUJZongnTdvHm4ULFhQyRB0UOtsEDK7bzMu
eOPj41lRoP706JzMELxAr169MFefPn1EDQz/xibBSxAEQRAEQeiGtk3BkJAQ
1v3H22X4gtfLywsLNzIywnGb7dq1Yx44evSofHY4ZbRUGPP28uXLaO/m5iZq
YJiCF3Qi68e/evWqqE2WCF5Q32z77NmzGou9cuUKs+eq+Ix7qUiRImh//vx5
PTonkwQvE/stWrQQNTD8G5sEL0EQBEEQBKEb2jYF3759i/ZmZma8XQYueEHh
GhsbY+GgfDFx27ZtzANS/V8MNhw6ISFByRHfvHmD9qAfRQ0MU/AClStXxlwX
L14UNcgSwQvbtWrVwu3BgwdrLHbs2LFojKMR9Ch4y5Urh/aRkZF6dE4mCV62
8HSTJk1EDQz/xibBSxAEQRAEQeiGtk3B27dvo721tTVvl4EL3gULFrCTDQgI
wMR3795ZWFhgYq5cuaSC8CAsXM+JEyeUHDE1NfVhOqIGBit4Wbjm6OhoUYOs
ErwLFy7EbUdHR/kh6OB8V1dXNP7zzz/T9Cd44SZhcatA+unROZkkeNetW4e5
fHx8RA0M/8YmwUsQBEEQBEHohrZNwb/++gvtQRPxdhm44K1RowaWbGZmxu3J
4sZtDgwMlCmhfv36aFa+fPnExMSMV8kwBS+cGmaxsbGREpVZJXifPn3KVsaR
V2fc8cw4E1lfgvfIkSNoXLt2bf06J5MEL+vpnjVrlqiB4d/YJHgJgiAIgiAI
3dCqKfjly5cqVaqgfceOHXl7DVnwRkVFsTPlLSK8YcMGtktqoRkE9AKzLFas
GAgfhav3SmGYgnf79u2YRWbl1qwSvNwz6tevn0yZv/32G5rVqlVLtBzdvPTs
2TO2sO/69ev165zMELwpKSm4mpixsbFUCDLDv7FJ8BIEQRAEQRC6obwp+Pnz
58GDBzN7kEU8A0MWvNOnT5eqeUJCAhuhamNjI9PD9eHDBycnJxUHFxcXPz+/
kJAQkBU61MoABe+1a9fy5s0L9lZWVqITVJEsFLzLli3Dn3ny5JFaQyc1NRUu
DZotWLBAtBzlXoKjxMTEXL582d/fP2fOnGjZtGlTva/ZpHfBm5SU9Ouvv2KW
3r17S5kZ/o1NgpcgCIIgCILQDY1NwdevX1+6dGnVqlVshReVeuijsCWsX8Gr
LcIh1lzKli2LZtbW1kJJ26hRI1bOzp07ZcqBU8uVK5fw6Llz5+7SpcuGDRue
P3+u/GSZx7SlZ8+e2h5C5qK8ffs2IiLi0KFDnTt3xgHD8P++ffu+22XSSvC+
fPmSBR87fPiwaPVYGGEAtKpoORm5EJ06dXr//r1G52SJ4E1OTo6Ojr5w4cLi
xYvZ5FwPD49Pnz7JHNrAb2wSvARBEARBEIRu6NAotbe3v3v3rrAogxW8N27c
YGaig5a56/O2a9dOvoaRkZHVq1eXqUnlypX9/Pxu376t8WS/p+BVjouLy6lT
p77nZdJK8AINGjTAlF69eolWb8yYMWhQp04dmXJ09lKfPn0ePXqk0TmZJ3i1
YtCgQTLynGHINzZbWWnevHnCvWy+ttS6SzY2NirpmNIEQRAEQRDED4y2LdIS
JUpIjXQ1WMELrXRmduDAAaFBbGws6zS0tLR89+6dxnpCG9vX1zd//vwyVWrS
pIn8crGGKXi3bdv2nS+TtoJ31apVmGJnZycMrM0dz7xo0SKZcjLiJTMzs6lT
p4qOajYowevh4aFwsSHEMG/sjRs3osGmTZuEe9kCzVJhqHF0itSqwQRBEARB
EMQPjJJWqJGRUe7cuevXr79s2TKZhXsMcw4vd3kaOIukpCRRM09PT3a+mzdv
Vl74tWvXZs+eDdnZYqZcTExMVq5cmakek0c36TFs2DD5YrNwDi8QFxfHpl0L
A2tfunSJ3bdPnz6VKUerC/H169fHjx8fO3Zs1KhR5ubmaD98+HCh5jUowQuA
eo2IiNCqJoZ2Y7PI2EePHhXu/fTpE+4dP368aPaaNWuq1NpfL5UhCIIgCIIg
shEyKkBbDFPwXrhwgZ2jTNjhpUuXMrPmzZvrcKD379+D+Bo0aJCjoyNPHSxZ
siTzPCaPkkMkJyffu3dv9+7d7u7urM5//fWXTLFZK3iBxo0bY6JwjPro0aNx
V926dTWWo9xLXE6fPg2KT0qCZXnQqoSEBLjtwQ9s3EL58uWlPvVoxBBu7NDQ
UCwwLCxM1ACDic2fP190b8uWLWFvq1at9FIZgiAIgiAIIhvxwwveoUOHatsj
xluoV1tAPx48eLBWrVqsQDs7u7i4uEzymDxaHeLjx49stWJ5SZXlgnfdunWY
aGNjA9Vm6ampqc7Ozrhr8eLFGsvRwUvIyJEjRWV1Rpyj9yjNe/fuZWed8Xss
C2/smJgYLJDbZc+lWLFisHfLli2ie/v27avStI4VQRAEQRAE8UPyYwvelJSU
fPnyaSt4gTVr1mT80NzlTf38/DLJY/Joe4jjx4+jvYWFhUxc3ywXvK9fv2ZD
bXft2sXSL168iIlGRkbPnj3TWI5uXgJevXrFCuSN8zccwQvyv3bt2nq8UmlZ
dGMnJSVhgVILUeFpnjhxQnSvv78/7J0wYYJeKkMQBEEQBEFkI35swQsNYB3U
LuDt7c0r6lY6UquvitKrVy8s0MvLK5M8Jo+2h4CzA6mLWaKioqTMslzwAi1a
tMD0Dh06sEQ2nllYlH4FL8AiO925c0cvztG74AVmzpyJWbp37y5qkF1ubHt7
+9y5c0vtbdOmDRzu+vXronsXLlyo+jaCGUEQBEEQBPEv4ccWvD4+PuwE5RfY
Tfu209DY2Pjly5fcvdDexl28fkN52IKwBQoUyCSPyaPDIXB0KBAeHi5lYwiC
d/PmzZieI0cOXHaHO5556dKlCsvRzUtApUqVMNc///zDTWca09/fXys/sHDi
U6dO1cFRojAvgSQUNcguN3bJkiXd3d2l9vbv3x8O9+LFC9G927Ztg73bt2/X
V2UIgiAIgiCI7MIPLHg/f/6cK1cuLM3GxiYxMVFjlmbNmjGH8BRT+fLlMf30
6dPK6/DhwwfMZWVllUkek0eHQ9SpUwezBAcHS9kYguB99+4d64zGpZTYeGZj
Y+Pnz58rLEc3L6WkpIDQFu3hXbNmDabLBEkTpU+fPpgxICBAB0eJwgY5NGjQ
QNQgu9zYdevWrVevntTeiRMnGhkZJScni+49efIkVEbj6tIEQRAEQRDEj8cP
LHj379/Pzq5bt25KsmzYsIFl4bWumRaeNm2a8jrcu3cPc4l2Thmm4GVZjh8/
LmVjCII3LX0gK9C6dWv4OWrUKPzp6empVTk6eOncuXNM8fHm8IJyxF1VqlRR
7oTU1NTixYtjxmPHjungKPkstWvXFjXILjd2fHy8TCi59+/fS3XvpqmnAD9/
/lxq/i9BEIQOJBMEQRDZBKYCMl4UKEQs6sSJEzoXMnHiRCwENjJYn06dOrGz
27dvn5Isr169YkusGhkZPXr0iO0aN24cptvZ2UHjWWEdWHifHj16ZJLH5NHh
ECyLjNP0eJkA1gsJhxbulblFt2zZgrssLCzi4uKKFCmCP5cuXapVOdp6CeRV
qVKlMEuTJk14ez9+/Ghra4t7r1y5otAJhw8fxizW1tZQvg6Oks9SuXJlUYNs
emMTRKaSkpKS1XKKMHRCQ0OvEARBENkBpgIyXhS0qLGolStX6lyIr68vFgIb
GanMuXPnLC0tsShQHxcuXFCYsW7duswnI0eOZOm7du0CCYzpTZs2vXTpksai
jh49isuDqtRL5GSSx+TR4RDMA9OmTZOy0ddlQqBuTJQJ98rcotyr3LFjR9ww
NjY+duyYVuVo5aW///67fv36rDTRK9u2bVvWAXrmzBmNZcKtUrBgQczSsmVL
3RwlyqZNmzBLkSJFRA2yxY29d+/eRWpgQ7j31KlTuHfDhg2i2Relo5fKEP8G
ZCIYEASCgjcsLOwaQRAEYdiwdnvGi6pSpQoW1bdv3+mKOXnyJLeQAQMGYCFe
Xl7KC2Hs2LEDy2GBg1TqcD3KzwJUHstYtmxZ7i6mYoBmzZqdPXtWppx9+/ax
6E+VKlUSfSfq5jEp18lflNWrVyv0QJcuXTCLj4+PlI2+LhMCdcPSoLbCY8nf
og0bNlR9S40aNUQtZcpRciEmTZoEDvH29ra2tmZF1alTR/TKguJm84tB865Z
s0amUbRx40bWNw36HfJKWco7ShSQ2+w7QEhIiKhN1t7YU6dOnTJlCvzdydzY
7H6DDR3cosenHPHDA7c0CV5CCSh4X7x4kUAQBEEYNqwpmPGi2IqfWhEYGMgt
ZOzYsToUwoDsWE7jxo1Z4t69e5WfxaNHj9ioZgAaP2zX06dPa9WqxXblzJlz
4MCB27dvv379+pMnT54/fw5tpKNHj65YsYLbA2hjY3P+/Hk9ekzKdfKHUGKM
zJgxA7OArpF6levrMiFQN0yH2gqPxXKJ1oQ77RqZP3++qKVMObpdCPDPnTt3
pNy4bt061nOqUmuxBQsWwJnCTQJeffDgQXBw8KJFi7i3CmjS9evXy1waeUeJ
Eh8fb2dnh7mWL18uamP4Nza733h3jkK3yN9CBMHl2bNnJHgJJZDgJQiCyC7o
sSloOIIX1ARbYChv3ryxsbFanUiTJk1YgZMmTeLuevz4sVanaWtre/DgQf16
TEYXyBxCueC9ceOGiYkJ5urcuTOoIaGN4QheaJ1yu1yh5nfv3hW1lClHhwvh
5eV17949eU8uXbqUjbjWCJxFQECAfIE6CF6gZ8+emCtPnjxBQUGiNgZ+Y5Pg
Jb4bJHgJhZDgJQiCyC7osSloOIJ34cKFLKVv377angibKalSj2rm7Y2Li1uy
ZAnoaPmagPJq27ZtRESE3j0mowtkDqFc8AItW7ZkR4GTFRoYjuAFOnTowGx+
+uknKTOZchReiJw5cxYrVqx79+779u1T6MkLFy40aNBAvlhjY+PmzZtfvXpV
Y2m6Cd7z58+zYxUuXFjKzJBvbBK8xHeDBC+hEBK8BEEQxI8NvOP27t3r6+tb
tWpVZ2dnKysrMzMzBweHkiVLtm/fftasWbdv387qOhKGwsWLFydNmuTt7e3i
4mJnZwea0d7evmjRoqBzp02bdu3atayu4P/z/W/sW7duQaPxwYMHWX3qBPFf
SPASCiHBSxAEQRAEQWiEBC9hUJDgJRRCgpcgCIIgCILQCAlewqAgwUsohAQv
QRAEQRAEoRESvIRBQYKXUAgJXoIg9M7NmzenCJg/f/7OnTtjYmK+Z03g+YZH
/+effzK15OvXr+PPM2fOfM8TJAiC+G6Q4J09e/YUWcA/mXToJ0+e4CG0Wrvt
x4YEL6EQErwEQeidQ4cOSYX0dHBwkF+8Ur9s2rQJjysavVaPJe/Zswd/QnPo
u50dQRDE94QEr62trXzYang1KCknPj7eT83atWsVHvrGjRt4CB8fn6x2g6FA
gpdQCAlegiD0DhO8efLkqaXGw8MDtjHR3Nxc7/2tUmSe4IVzxFPbuXNnAgle
giD+BZDg9fb2rpVO7ty58bFfrlw5lgivBiXlxMbGYt4mTZooPDQJXiEkeAmF
kOAlCELvMMHbunVrbvrMmTOl1me8fv36gQMHLl++HB8fLyzw0aNHf//9NxjA
IysuLk5o8Pz58+Dg4CNHjvCW4eAJ3jt37hw8eBCaDVyb+/fvX1Pz6tUrKPzE
iRN3795lex8/fnz06NFTp049efKEmysmJgZzYTpP8ML799ixY/Au5p0FZuE+
cqEykMIWyuRWBn5evXr18OHD3PowoKpwyiEhIQnqthPmgtpm5YUnCOKHhgQv
lxYtWuBjH94RogbwlIZnuPClkyAreMEY3mXwGoX3HS+dBC8PEryEQkjwEgSh
d6QEL7z3MX3MmDEscfPmzU5OTmw8WPHixXfs2MH2goLr1KmTiYkJM3BxcVm9
ejUziI6O7tevH9fgp59+unTpEu5lgnfWrFleXl7MplWrVi9fvkSbnj17YiJI
VHd3dzYmDUSot7c3y2JlZTVw4ECWS2pI86hRoypVqoTbpqamUDeWxc/PD9NP
njzJ6p8/f35IKVOmDK8ye/fuLVKkCG4bGRn17duX68ktW7bY29szj+3bt4/6
lwmCyGxI8HKREbzw2J84cSK8NdgbJG/evEuXLsW9GzZsYEOj4eUF28HBwZB+
+vTpKlWqcAdIlyhRIjAwEHOR4BVCgpdQCAlegiD0DhO8VatWXa0mICBgxIgR
zs7OKNAiIyPRcu3atWhZunTpdu3aofI1NjZmmrdly5ZoUL58eVCy2EgAAbh7
92408PT0ZA0DDw8PyAvbcKCHDx8mcGSphZqiRYsyaezv748lMI0JJbBJWKCj
CxQoANtwxLZt21arVg13NWvWDHNJCV6kWLFi1tbWuA3ZMYtWgtfS0tLOzg4q
DCeLKStWrECbnTt3YgqcLDjTzMyMtZ1I8BIEkXmQ4OUiI3jbt2+PuxwcHGrW
rGljY4M/QQUnqL/9NmjQgAlhb2/vsLCwR48eOTo6ogSGF2LlypVNTU3xHYTj
iEjwCiHBSyiEBC9BEHpHJmhVrly5mNqFJw+Kyho1auBA5aioKHzjg45LUH8k
Nzc3h5/Vq1fHLCBjwQAaANjjuXXrVizW19cXDebOnYsp8+fPT+DIUlCUODD4
wIEDmAJKGbMwjQnqEgT433//Dc250aNHo7JmUZf79euHZkFBQQnSgheaKPv3
78eqQosFE8+ePZugpeCFDewa3rJlC6Z069YtQR3qpGTJkvATBPXp06cT1KPB
XVxcSPASBJHZkODlIiV42ZCbn376CRcmgLeem5sbfnrF4c3CIc2bN2/GFDaE
ady4cZiC84JJ8AohwUsohAQvQRB6hwleEGUu6aCSBeC9j2/8c+fOYUr//v0P
pcMGHj969AhUMPswXrNmzYkTJx4/fhwntyIDBw7EvdeuXcMUeJrNmDFj+vTp
0ORI4MhSrhK0s7ODlLJly+JPpjFRqCJVq1aFlEKFCrGKzZs3D80mT56cIC14
27dvzwrZu3cvJk6aNClBS8HL1raA88VO3oYNG8LPsLAwNOjTpw8rZOXKlSR4
CYLIbEjwcpESvMOGDcN07ip1y5Yt4+pZoeCNj4+PVXP//v2goCB40RQrVgxt
MDQiCV4hJHgJhZDgJQhC70jN4YVWgYWFBaQ3aNAAfq5bt04lzbFjxxLUY56x
F5hha2vbrVu3e/fuwd5GjRrhADDRUFcJElGapTQm63oG2AxZIV26dEmQFrwo
hxFot3CzaCV4oWHJbHCctre3N2zv2LEDDf78809mcPnyZRK8BEFkNiR4uUgJ
3mbNmmE6qFeWCOIXE3/77bcEiaBV8L4rXbo0e9fgkGYSvDKQ4CUUQoKXIAi9
IyV4gQoVKqjUE1Rh+6+//kKzX375ZZ4AFtby5cuXoC579OhRsGBB1hKoU6cO
7Grbti3+5MVDZmgleLkaE1W2m5ubsGLY9pASvCNGjGCFwAMWEwcPHpygJ8Eb
GBiIBtOmTWMGf//9NwlegiAyGxK8XKQEL7zRMD0qKoolBgUFcR/d/8fee4fX
lL39/wchiRBBiN5FjxItwpDobXRj9F5GG70NH4w++mD03nsZvYxOuFxy6e0Z
YfCRQZRHvrrzez/nvrJ+a9beZ599kpgc3K8/zrXP2muvvfaq93uvsrWCd9Om
TeQSEBAwdepUCORff/2VBa8xLHgZk7DgZRgm3rEneI8ePerp6Sn0nZidSzN+
iZMnT26wgY7s7Nmzs2yIsVfYALR3sbu7O/4OGTKEQli9erW4PH369OnSpaMw
Yy14aS+srFmzirHjO3fuUMQQqyj7gtff319MukYcyJH2mxo5ciT9hdInDzdu
3CAxa17wIinIQ1BQkPDQs2dPFrwMw3xqWPDK2BO8Y8eO1c7D6dixIzlu2bIl
Sk/wtm/fnlyoi4mS1uyw4LUHC17GJCx4GYaJd4Tg9fb2LhRDjhw5xIbDM2bM
IJ+VK1cmb/Pnzz9z5gzEIyniMmXK4Oz+/fvJP+Tn8uXLDx8+PG/ePF9fX7gE
BgZG2fZrou8+QOH+9ttvMCTEdsqHDh2KioPgFfuHtG7d+vjx4zt27AgODrbY
trE6duxYlOEuzaGhoYsXLx4wYADtCA2F/t///hd+8AhCFM+ZMweJIGavmRe8
QHwsqUmTJkuXLu3atau4NQtehmE+HSx4ZewJXqQP7Vnh4eExevRodExCuqLn
oh0a8UsdYt68eWGKR0ZGdunShfy0aNFi69atuJBWALHgNYAFL2MSFrwMw8Q7
Brs0p0yZctSoUcLn+fPnxb4cggIFCly6dIk8tGrVShsIRPGBAwfIA5QjjArF
w3/+8x86G2vBGyVtyyxwc3OD4tYNWQjewoULy5f4+Pj8/vvvdAlaWtpgWVC6
dGlaLOyU4D179qw8u5uMKBa8DMN8aljwyhh8lgg9Ar2blfH39w8LCxN+AgIC
xKkjR4788ccfYtEuvVwVH92jrSFY8GphwcuYhAUvwzDxzrVr12ZoWLhwIYTw
nTt3FM/osMaOHduoUaOgoKDGjRvPnTuXPscj2LlzJ/r3atWqlSpVqnbt2gMG
DLh8+bLsAe3Yjz/+WKNGjW+++aZ9+/YwG8Qp9IN0dzFJDCxYsAAuy5cvp7+7
d+8mP/fv31fitm3bto4dO1aoUKF69er9+vUTy4q1ISNK9PfkyZPQwk2bNq1Y
sSJideHCBTnA27dvI5zQ0FDEFqocz24mMjNnzoTLxo0bhQsMzoEDB1auXBkJ
MmXKFBhRZAhNnjw5oTOfYZgvFha8Mlu2bKHmmr55p4BUGjFiRMOGDdG1tWjR
YurUqUrXdu7cuebNm5cpU6ZmzZrUuZw4caJly5bBwcFt27bds2cPegHRe+Ls
vXv36K9WX3+1sOBlTMKCl2EY5jMCJtAIG2JaeJRNEZPg3blzZ0JHkGGYLxYW
vIxLwYKXMQkLXoZhmM+LYsWKkbxt1KjR5MmTu3XrRgufS5QowY05wzCfDha8
jEvBgpcxCQtehmGYz4sbN260adNG7GcCkidP3r59e91pdQzDMPEFC17GpWDB
y5iEBS/DMMznCNrt8PDwgwcPXrx4UXwIiWEY5tPBgpdxKVjwMiZhwcswDMMw
DMM4hAUv41Kw4GVMwoKXYRiGYRiGcQgLXsalYMHLmIQFL8MwDMMwDOMQFryM
S8GClzEJC16GYRiGYRjGISx4GZeCBS9jEhK8ERER9xiGYRiGYRjGDpcuXYLR
eP369YSOCMP8H7dv32bBy5iBBC/DMAzDMAzDMMznBQtexiEkeK9evXqdYRiG
YRiGYewQHh4Oo/HixYsJHRGG+T+uXLnCgpcxAwne//f//l9CR4RhGIZhGIZx
Xf7nf/4HRuN///vfhI4Iw/wf//u//8uClzEDC16GYRiGYRjGISx4GZeCBS9j
Eha8DMMwDMMwjENY8DIuBQtexiQseBmGYRiGYRiHsOBlXAoWvIxJWPAyDMMw
DMMwDmHBy7gULHgZk7DgZRiGYRiGYRzCgpdxKVjwMiZhwcswDMMwDMM4hAUv
41Kw4GVMYix47927N3r06JCQkHz58hUqVKhWrVozZsx48eKF7KdLly4tWrR4
8+aN9vJbt241bdp08uTJOB4zZkxT+xw+fNheDB88eDBkyJCqVavmz5+/dOnS
8Lxp06aPHz8mdMr9SyBlkLzfffddQkfkHxw7dgwZce3atYSOiCvy5MmTdu3a
yXUKxRVpdejQIZzSvSQqKurEiRN//PEHSruuhzNnzqAmir9v375FzcUl0dHR
uv7v37+P2508efLp06e6HtauXbtq1SrxF7ENCwtDBHChvYdCgNevXzeoelev
Xj19+rRx4qBXMqjsToFnP378ONIBqSG746m32OH27duyzwkTJiAEk8/4/v37
K1euHDhwwMDS69y5s5yDSMz9+/efO3dON5sclgpi9+7dkZGRBh4Qzo4dOyIi
IsTfH374AW1vvCQywzCMzJckeGHNGtilMHfJGxk8e/fu1YagnEKDrw2nY8eO
Y8eOvXHjhvmIPXv2DB0Wfo29OeyVXr16hS4Sfa7DoD5fWPAyJjEQvL/++muy
ZMkSJUpUoECBZs2affvttzly5LBYLGnSpIENJrzBuILjxo0btSH89NNPOLV0
6VIc9+jRo7QeSZIkgZ8VK1boRg/11N3d3cPDo0mTJgMHDoQ9WbBgQfgPDQ0V
Vi6sSrjDVo9LOqxfvx6BvHv3LqEz5B/cu3cPWZAlS5auXbuSS/fu3Sk9Exbk
F3IBTX1CR8QVadSo0aBBg8RfaECqOESLFi1evnwpzqLIoWokTZpUeGjQoMGj
R4+UMDt06DBp0iQ6XrNmjbe3N3lG9YEQ/vDhg/AJcVSvXj0RGkLu3bs3ukUl
wKJFi0Jq4eDhw4c1a9ZENReXoKaj4AmfMAmaN28uzubMmRPqW/fBy5cvj2sN
Ugb6LmXKlCVKlIhjCuN5R44cSU0HQGqsW7dOnK1WrZrFDr/99pvwBhGKC//+
+28zz7h58+ZMmTIJD0WKFNF2r2hIc+XKRcdbt25FtRX+U6VKRe/9TJYKwaVL
l3BWbm+1DB8+HH4WLFggXGbNmhUUFKTNdIZhmDjyJQledLXUg+hap8OGDSNv
ZPDAJNaGoJxCF0M9iBxOnjx54Jg4cWK0zGZi9fHjx9q1a+OS8+fPG3gz7pUQ
yNSpU728vISHKlWqoLtP6CSPf1jwMiaxJ3hnzpyJCuLv7x8WFia7QxhC8MLU
FAIzPDwcPmvVqqUNHLU+RYoUuoYcMW3aNFwbHBysO0AMs9bX19fPz08Zlxk1
ahSuGjNmDP29ePGivbbIPL169UIgr169+pfS3RwwdBErCBzhAv3bunXrhI4X
C167/P7779B0YhbE9evX3d3ds2XLtm/fvlu3bkGcIt0gMIX/vn37wuWHH364
cePGnTt30ENBe1auXFkO8+3bt6h0OIvjTZs2wX+FChWgmKCGIJTwF5JHeP7m
m2/QsU6fPh3+cfcuXbrAgyzArTbhmSFDBpLJUEbwMGTIkCtXrvz555/jx4/H
5aVKlRIvlNBLwgPcYeegQKKH9fDwwLEcILrRfv36kVi2lzLolfLnzw8/cRe8
gwcPRjjt2rW7fPnyyZMn6RG2b99OZ69evXpKA9IcafjXX3+JQNauXVu1alUz
z7h//36cLVu2LO4FM2/Dhg1IPbRLSrOJFEAyWm2NKlrIjBkzbtmy5cGDB8ip
kJAQhDBv3jyTpcJqa/0Q7YCAAGPBi6cmY0YWvJC62bNnnzNnThzTmWEYRuHL
E7zVqlUz9uas4F2yZIniDSkGw8DNzc14ug4xcuRIatUNBK/DXmnKlCnw0LRp
U1jId+/eRQw9PT1hOSR0ksc/LHgZk+gKXhpYhH2oHWkCZ8+ehU2eK1cuMR4a
GBgII1mZjYlqiOrWvn17e7fesWMHwoEo1r0LuHDhAkLo3Lmz4g5T0MvLq2LF
ijiGUj5z5gy8oXaj2MveUMcP2RCT/QhYg/BJ1j4kA2xmSPJu3bohkMePHyua
F4HAKEUSKYO/0dHRr1+/ttpmnsBDXLIAIUPs7N27F/qRxpsIhI9GDLHCL2II
b4g28qV58+Y4oOEb89FAM3vw4EGIGnk0EPn+vxooBXBKOw8Tp+j1hRC8Hz9+
vHnz5oEDB3SnwiKS0FZomaGklGmiCIpKHeKPPIJC1OaL8IxkOX78OB5QdjTg
+fPniBtyjRJHAUoQUUJQSp5C4lERQkzCw8NxR/GuBtHD36NHjyplTAvElxiO
BxBlSCh5om+rVq3ggrjRX3RS+fLlk0No0qQJPMjdIkR0uXLl6LhIkSIo/GJ6
EqIKl+TJk1NUUXNxLUqIuBbJjqqaJUsW+RboT3v16oWDsLAw+EeU5LOkwY8c
OWKNqcUdOnQQZ5EIcIGOpr+ogL6+vvLosL2UadiwYdasWeM+wovMhVpEIKIk
o9pCn6IVsncJKheamp07d8qO9erVI7PE4TMiZB8fH3niMRIHHuTX9UhnJDJM
Cxy3bdsWZxGsOIvcSZcuHfS+yVKBiOEZRaraE7yoet7e3oULF1YELxg7diw0
r6tNWWEY5nOHBa/BKXuCF7Ru3Rqn9uzZY3wvdPforahVNxC8xr0SjBn0icWL
F5ftvRkzZsCDvIrny4AFL2MSXcFL75dmz55t7yqy6FAx6e+8efPwd8KECbIf
kpD2KhcKJ+x2WGsGEoaGbmHZapXXw4cPqb0l41xA2hlqpXTp0rJ75cqVhUag
YVMIotDQUBpcExNEZYsdMaThFSJTpkzytO1s2bJByy9atMjNzQ1iP9bpD9UP
u1TcJUmSJJ06daI2qmnTpsIdOnfNmjXyE5ENbCYaSKsaNWqICyFPxFiY/IAC
avxhkysvMSBt0qRJU6ZMGWtMI4/fAgUKyBNmZP/QFxkzZhRn8+TJI0sAyB/c
/dSpU6lSpaKGXZsv8IZchk85elANV69etZee0NHdu3eX023y5MlCa1+4cKFo
0aLibOrUqeV1rOPHj4fjiRMn0qdPTx7QZUAroS9D8pJL2rRpEWd7d0dVgh/Z
AySemOZKIEAaTKS/qAXo2mQPLVu2hAd5DSYELPWnEP44BUUs+4e0gSMkvNU2
dItjVE/ZA1IMiSy7QGJTJNEvw/+yZcvks4sXL4YjChWOafCRJj/rPhTK6m4b
yG4DwYvGAXlx9uxZpG0cBe+uXbtwIzHBm6hfvz4co6KitP6RaH5+fv369ZMd
0RpAelObYPyMsByQ+6hBSrAwNr755hvxF+W2YMGCdIzGB9mqzCguVapU0qRJ
qSg6LBURERGUqtSK6gpeiOhChQohDvRaTBG89Opj8+bNcUlqhmEYBRa8BqcM
BC+95zx69KjBjdDvo7Pu1avX0KFDDQSvw16JJl4OHjxYPnvnzh040rvuLwkW
vIxJdAVvpUqVUC8MltiT+Orfvz/9ffHiRfLkyf39/YUH1EdIg7x58+pejqYy
S5YsEHe6mwAIYByWL1/eYlsB17NnzwMHDmiVL6xZmtQ3bNgw6CAYmbgKMhDS
DFoSZ1HxSb+Luk/CCrYiHnPdunXXr1/Hk9IIC6oMrV7EL0xW6II9e/ZAMB4+
fBhWOjyIUVTcAmdhvU+dOjXWI7x3796FCoDegfpAwwupRWJn06ZNVtvaZGo8
8YtIIpHxgLCZ69WrhwMa0XMYDSQInhS2PZplqFHkNRQryTqcRXN6TOL7778X
Ly7wyDRuLoJav369aMmpkUeTi3SDioTOGjJkCFwCAwPJpD99+jT+QgJARyC7
oYag6/GwYnY6ZKyfDVyIs3gcbb7AW4MGDaC758yZg0CQTQsXLoQIhbK2l6RI
QPiHBsSN4J+eaObMmVbbOCC6AxRLBI60RZqXK1cOZ1FO6FoSvIgnStq7d++Q
RCgDiRIlgmA8d+4cXCgFlPnGMiNGjEBFEMNqEIMo5Mgv2Q9yQch5MG7cOItt
RjGK2dOnT/GASFVZ0qJuovzT0htEwyJN5ieo/IseFgmLQoK/UHNItAEDBuDs
xIkThX9keo4cOUTxePXqlfwSGNSsWVN0tR07dqSZD4oHd3d35dnx1PYEL8Q4
MoUUWdwFL71eU96T0zpWGmBVQGJCYCpNHNJH5IvxMyJxkKdBQUHKw+KsLFqR
oSJf3tiQ/aM0oiDRyyIzpUIAO8qe4G3atGmmTJkiIyO3bNmiFbwgd+7cMLHi
ktQMwzAKX57grVix4l96CIMz7oL3zJkzMMOKFi1qsLUCbgdrMDg4GP2LseB1
2CvRq+9u3brJHmgICRZCQqd6PMOClzGJruCFdIU2MaiYKFqoOFATwoVeXokh
PIgI/IUxr70W9ypVqhTOmllihhYAFR+yjsbXoAVgNMK4lce/lDW8UVFRsLoh
HORwvL2969evT8ckrIoVKybPd1XW8LZt2xYpIC9UhHaG7kBbRH8pSjTtM9ag
DURU5U1rb968iWCh1+RkFIrMqlnD6zAaSAdLzL5hBB4KLr1791Z8rl69Wp7G
Cd0K6Yf2WXioVq0aUoCKCjXyIjWInj17wnHr1q1W2zsTRFVeMkmvHEXkadxW
FtS6+YJypaw/DQ0NVSboCtA7IITu3bsLF3QB6dKlo3j2798fZ3ft2iXOvnjx
InXq1GJgjgSvnFY0u1iepYDoCbWoBTeSR/1olE2Z1f/27Vs4ynqHVqQK6tSp
I0//hsoWEhtpa/nnzkvWmBm5Qm3hWmXXppEjR8r+IYGVJBWg46B5BSLO1atX
h1JTFDG9HVIUoj3BGxERkTZtWhFg3AXvsGHDcKOzZ8/KjrTngHa22KFDh+Au
b2lFVK1ade3atSafsUaNGvAgr1ind2geHh70F00lipm9jZFPnz4NZQpThEIw
WSoIe4J38uTJaAypvbUneFu0aAGlH5ekZhiGUfjyBK89xGaqzgpe2E4lYihe
vDjaYTg2atTI3vI9olmzZn5+fjRNzljwWh31SujO0OnAvBE2GDpoRMBiW/ab
0Kkez7DgZUyiK3gLFy6MqmTwcV5aNisv/Tt16hRcOnbsSH9hNiMEea9XAtZ4
48aN4bNHjx5OxRNt7JIlSyB/YDyT8hWS1mDTKkgnPB2N/ghTnISV/JEXq0bw
5syZE9Lm5j+BlkmaNCl5gNLMmDGjQYSvXLkifw9F+XKKFogv+gIRovHzzz+T
oxnBaxwNeE6cOLEy3vTy5UtlcevevXuRpPXr15fNflIWly5dstomwyBDhZak
Rl55q0AZQRsbJk+eXDvfJiAgQCxjJMErT4HWzRcBNMXVq1fnzZuH9hwtua4f
UgfKl3HEYuQKFSr4+voql0B34BIaLifBS88rn5XTCmUAaW4vtTNnzow+S/yl
dwvykl6rrSeSt6Wi+bRIq0WLFq1cubJt27bILwQihokbNGhAs4sBhJuYbCyA
9LPEbEuFq1C/EAJivmrVKvgkNSfmytL8B23XgBIybdo0qDYUAwhwUQwqVaoE
F91EU5bG6wpeVCj0+IGBgSINjQUvyoNca+Ql7QJ6caE8ApkZyl7xeIpChQpp
+3d6eSXe3jt8RuRjmjRpUPeRL3379g0KCsJfpBV+yfO+fftKliypjSokMC6h
nQrEWykzpUKgK3ih4uUNP+0J3gEDBiBMXsbLMEw88uUJXlgma/QQfZyzgrdU
qVLyZ4mqVasGiwi2q7JwRmbq1KnohoSAdSh4zfRKOOvj49OhQ4eePXvmy5fP
398fPUJoaGhCp3o8w4KXMYmu4IXVirqGU/auolV+o0aNkh1p6izMSGg3qBJY
2toLqRbDvI/1JzNgQuPuKVKkgPQjQa0VvLAtmzRpggoOsxCWbUhIiLu7uyJ4
IS7kYGXBi7jJX2lREHOJlfFNBQiZ5BL2PoKGaNSqVYsGajNkyECTyZ0SvMbR
KFeunLEittpeX3h5eZUvX17ZsOvGjRtCSdHO2GLKKDXytG5UgKyn1yC01FS7
21jdunURfzqG4BUDZAb5gjiguS5WrBh9nap06dJ4HHuClzLR3qdss2bNqpVa
pDfpuUjwyguESfXIksFY8KJ/kScRoVppl9w+fvxYvCwirap8ZHnSpElwnD9/
vtW2QRPqlPiWLm2mpCxf3bNnj5i2Tb2t8gUcGqem6nzixIkCBQoo0T548CC6
QlSW5s2bK99Wpjnhyqe36bNHylsUXcELzYVOfNOmTWdjQHecP39+HOgu3kdR
l2uN7rfGYBhol9yOGTPG8s99oqwxSlCM5Apmz54tv5cw84wo0n369EFdQxHq
1KnT3bt3s2fPXqRIETrbtm1bea6C1faqbdiwYSjtfn5+06ZNk2uWw1IhoxW8
CNnX1xfmjUhSZDe9aMKx/IqACtKXYZcyDOMifHmC919Yw4tE8/T0FF2GAnrD
JEmSwN4QrTrNmVy1ahWOdT/jbnXUK1ltE5sRJs7CD/riv/76S7eX+dxhwcuY
RFfwwthGvejZs6e9qypWrKh9+zR9+nSaBLJ06VIcrF+/Xrlq+fLltEgTZryZ
uCEC6dOnl7ehE9AsUNp8SRG8p06dQtMBoxqGMeo7zQ5FOIrglb/1Y9WM8MIs
r1mz5lM9KECoHnnyauyYO3curR+BhKddjqlFckrwGkejTp06EA4GHpBEadOm
RaYIVSVTtmzZLFmyvH//HjeSF4xQI7969WrZ8+3bt2k5KrQPskC7VAShCa2K
s0rEtPkCFUAvLYcPH45mn4RnrVq17AleUuVXrlzRPYtmX6tVe/ToIURB3AUv
lIjSm/j4+NDKTQHNu6bv19BnuWgSuADdlsX2YVYcL1u2rG7duuIUDQ7Kc7bB
ggULLDHbE9HHZJWZFTgFR1RPel5lDH3lypWQuigAui+TaThVHvWmlESmKD51
Ba+88ZpCQECANVbQMLfyNerOnTvDEUknO6JmQW9qJ1eUL19e7Nvm1DMK0GAm
TZoUlctqGxxPnTq1nOZoRmhWOVJb11YxLhUyWsGLemowB0+e7k4zNFztU2sM
w3zWfIWCl/pQeSsMAVlxQuEabFqF/kg7lYigbwzZQ1m/Yw+5V9KFNtX86aef
EiSpPx0seBmT6Ape2EiQOTCDdfdYpgqu/fAulCnkWEhISJUqVWABKpNmjx07
hsoIG1L5qK4BEyZM0M6bJWhzp5s3b1o1gpe+ByqPH0GvQVs5JXihazJmzCiP
YUHn/vjjj2LsLF4ELxrAlClTynoKVnf8Ct5BgwYhBPljynhGb29v+nINrHSE
gLyWF9vKUOtNrxfkvXxJ8CpfBCbjnAbUChQooHyoNDIy0tPTU3z51IzgRVAW
zR7CwcHB9gTvxo0bLZrdxaHTaTs1SNFEiRLJI5gfPnxAPMUUoLgL3mLFiikT
G2hGqzzuRmORtFUjfVRXiTCtDiDtg9DktwoohHgWZRFxvXr1PDw86L0Q5ZTy
7WzKF3TZqAjIFHkzuvv376NWoi7rfr/Jahv8tfxzA3bYObpviXUFb0RExPl/
gtRGmuNAGUo2DxITtaBRo0ayI8qwWItN0K4dffr0US5HUUfrJFdth88IO6dJ
kyayckSZtNi+F2a1LaxWPm5IWUxndTEuFdq8kwUvMlFJUhryHj58OI7lhdWd
OnUSZZthGCZe+AoFLzoyXaPXGrM4S7wvNRC8kKI4pTvZD5JNadU7dOhA1hSO
dVcXGvdKoGvXrsqgFSxY9Du0HeiXBAtexiS6gtdqs7qhR9zc3EaNGkUSFeoA
WqBNmzaoUzC5dSUSDDmclRd7EhBWtPZ23Lhxf+ihXe1rtW0/haugkiZNmiQG
hVG2aQqfWO9GglfM8ySZTBsdW23fH6E4iyWlBoJXfNaEvhLSoEEDmsAMY56k
hBhAiRfBC6M9SZIkYq8bNKq0K7V4BacreOXJkNpoPHz4EGK2b9++IuWRjxBi
lMKwlulJ0ZAiSQsVKoTkhcH/XwnaEFhkAe4I/z4+PnLTSoI3ceLEYgYyMhE6
AnKM5CG1vUh5UlK4FzoLeSaqGcF74MABedgLIaORt9i+rCT8wKrH89I42tu3
b/Pnz58+fXrxRpQ+u0OfpLlw4QIiDP1LQgNJQd+0EiUn7oK3R48eyrAg7SjV
tGlTmhiAvgZFWmwFhuTNmDEjLhER/vPPP0uUKAERGh4ejr7Y29tbfAuYoN2Z
RJx37tyJIiS+IYvqjGsDAwPv3LlDLqdPn0ZyZcqU6enTp0hPZVI36SyUN+3y
JREChCRCoA3c0AjQGnzxxViBwS7NMnHftMpqe3ch7/FOO13PnTtX9kMTepVv
71pt2z1pPw5u/Iw0ho7SQgsxkMjIsjx58tBK5++++07ZRixz5swZMmTQJqlo
lIxLhYzBLs0Ce2t4UQzk6QEMwzBx58sTvCVLlvzDDsInffkOElIYSDjo3bs3
CWGxz6SB4CVD1N4MNAXtGl7YbDB1hDVo3CtZbR8OkKdCofeBbQCbNqGTPP5h
wcuYxJ7gtdoEAn3CxmL7MBCUEWkcVFtdfWqN2RMVnDt3TnY3nrBhb3GE1SZm
ixQpQn5odiutrq1SpYqYgotmB7HC2apVq0LeQs7Qnnj58uWDfoRkgHmMA/qG
jtWO4CWZHBAQMGLECHKB/HGzgQjAGLbYFqWKZi1eBC9kDlIVkS9VqhSs0xQp
UkB6+Pn5QV3SBtdawZs9e3Z3d3eIfRrF00aD9nmWP5iyefNmBIgHKVy4MAK3
xKyupZFELcr3fOkFpvKqkAQvbRWLMCnBc+bMKdZ904A4HL28vJCAiDMaW3lG
kBnBCw1Fi5qh10JCQqCVKlSoQIP7+EtjmvQNZVEY0EHkzp0bLnnz5kV8cICs
F8UbfQQSHDFBUtCFbdu2FVNe4y546RGUN6jUc0HYlitXLlmyZHgKuWVGLtCH
mPGLOCPxkVk0qouuE5pIuQViSy+K/f39ixcvjuoAoSSP6yFr8GjQgyj/Il+o
tOBxfvnlFzk0iDV7VVJkBEop5BhiHhwcTOVHzECQ+TcFb2RkJCQqnh2GCmU3
JKqyLQByComArlC5FndX1p47fEYUZkooRB41i5KUXum/fPkSqS3vvYkmyF6S
wqfJUiGIteDFg6MsKS8BGIZh4siXJ3gNED5fvHhBu2EAdBYwOOkYXY88aGsg
eGfMmEGjAGYiphW8AwcOtEjfajfolUSE6WOaOXLkQEeDg6CgIN0Vgp87LHgZ
kxgIXgJnoWsgXoYPH75y5Ur5Sz1aUAfDw8O1BU87YUPBYLf2Dx8+HD16FNW8
d+/eaARgwmm/tgnVMGzYsCFDhtCD4Hbz5s3r27fvlClTzpw5Y7U10VCyZO2j
HcAdlSWrr169glLAY8qCC8oFt+vTp8+kSZOULbwuX75ME6rjyP379xFJ3GLO
nDk01Hv69Gm0bDQx+Pnz54iqvOT5xo0b0Ob9+/enjNBG482bN7hEeYv44MED
tMD9+vXDtWIT4+joaN28QA7K12qniFttQ5PwCYkBd9jkiDDSTbs0G35wFhmB
ZFRk4O3bty9cuCC76OYLbrFu3TqEDwGyZ88eFDB4QD4ir0nLIBCKibgEGgSp
Bw+jRo3SDvBFREQsXLgQDzV16lRlP2fIKAQlT+69e/eusrIVqa272xIB0Qfd
qtWDiOSsWbMGDRq0YcMG7Vpp3HH9+vUon/CwdOlSMc1g2bJlyuRkwZEjRyZO
nIhLdu3apWweZbWtfUZ2I7SRI0fijsLD2LFjaam4AEXOXpWU44leEjFEgLNn
zzZ4fFz1559/Wg1BjxwvU6qQaMhcNEqom7orL9BKaKOK9gFlSXfHPIfPeODA
ASQ4Ss7q1atFg4n6SIujBVQBdVEKvHGpINAw4kJlQy0FmFvwo1gyKEgpUqSw
FyzDMEzs+JIEr3aFiILiH5bVggULBg8ejHYbB9rhWnS+2taYoIbaoAOVQfIq
k5lhxcEFVorsTbdXkp+OOjWYQzAVlE/vfTGw4GVM4lDwMl8zEI9p06Y13gia
kYGEyZYt25faszCfC0FBQQMGDEjoWDAM86XxJQle5guABS9jEha8jC6PHj2a
OHFiaGioRbONMGPAmzdvihQpsnjx4oSOCPP1sn///kyZMompAgzDMPEFC17G
pWDBy5iEBS+jy+3bt318fHLlyqV89ZVxCBregIAArlNMgvDx48dKlSqJHb0Y
hmHiERa8jEvBgpcxCQtehmEYhmEYxiEseBmXggUvYxIWvAzDMAzDMIxDWPAy
LgULXsYkLHgZhmEYhmEYh7DgZVwKFryMSVjwMgzDMAzDMA5hwcu4FCx4GZOw
4GUYhmEYhmEcwoKXcSlY8DImYcGbgFgkEjoujAMKFSokMuvXX381c8kff/wh
LqlYsWJCP4EpPn78OGLEiMyZM3t4eJw4cSKho6PPf/7zHyTpzJkzEzoidqGs
b9iwYUJHxAjEME2aNAkdCyNQaxDJCxcuJHREvhYePXok90oXL15M6BgxLgcL
XsalYMHLmIQFbwJCRsV3NrRn9+3bp2ty/PjjjxY9ateube9G5cqVa9SokcP4
fPjwYfHixRUqVEidOrWXl1eJEiWGDx8eHR2teENP16lTp4CAgOTJk+fIkaNu
3bphYWHa0MLDw3FTX19fGNU1atTAX4Nbk2VrABSEw/jbe0yIuHXr1oWEhGTK
lCllypSBgYGjRo1SnqtYsWK69/3ll1/IQ79+/ZBNJHudErzp0qXDhbgjOaJx
hl4rXLgwUhiJU758+WXLliGGZgJUwCMgWDw1Hqps2bLIrJcvXyp+Xr9+/fPP
P5cpUyZVqlTp06dH5q5atcrgditXrkSckyVLVqVKlUuXLomsbNasmb+/v6en
J35xrM1NhLl06VJkNApPwYIFUUIiIiJi8VBmIME7Y8YM3bO6xeDZs2f2itbZ
s2fjPYaU9Q0aNNA9O3To0LRp02rdHRbC+AUhI7N0T8Vj4xMXqFnQtWSeP3/u
7u6urYlbt27VjSGqm/n79u/f37jNsXd3q+kad/z48aZNm2bJkiVz5syNGzc+
cuRI3JMr7rfGc1F/hFYrFoL31atX48aNQ+OGrqFAgQKop9rug/ncYcHLuBQs
eBmTsOBNQAzGdmGlNGzYUNfkqFOnjlM2J9oBnHUoeKF2YQVRUDCDYa4kSZIE
x7lz537y5InwduXKFR8fH7gnSpQIusbPz48uWb58uRzazp07YRDSEFKGDBlw
kDRpUoMRQ4eC99SpU8bxN3jMLl26UCCIDIwxqDkc40AUe6R2ihQpzGgNklpO
CV55bPfx48f58+enkLPboGPktbOaF7ZlUFAQXZ4jRw46gOyFu+ynaNGiwg+y
ko47dOhgL9j27dvDw6xZs4QLcpauQr4jxyn3tTnep08fcochTSkMOX/z5k2n
HsoklAvTp0/XnrJXDNDK/fuCt379+tpT6J2zZs2qFbzmC2F8QXmqdY/HxieO
ULOg+65s5syZujVx8uTJcRS8u3btoksMBK+9u5uscZs3b06cODG1tAAH+AvH
uKRV/N6aUt4pwYsepFatWrgKfQckc7Zs2ahgxO5tHuOysOBlXAoWvIxJWPAm
ILqCF+YBZEL37t3prNbkIMX0/Plzh+FHR0dv2rQpZ86cZgQvDe3BDt+/fz9M
F7jcu3cvNDQUjs2bNxdxq1y5Mlw6der07Nkzclm8eDFcUqVK9fTpU/KG9gd/
oYhXrFjx/v17+IHFToaQs8bP6dOnYY99++23BhcaP+axY8cstmHWo0eP0nPd
v38fwhCO0E3k5+HDh/hbokQJh/GJo+Dt2LEjXAIDA69fvy4ekCzD+fPnO5Uy
EyZMwFVQoHgcyiwqGJMmTRJ+fv75Z7iUKVPmzz//JJczZ84giw2MeSSgfBYp
4+7unjRp0tWrV1Pq4RfHcPHw8IiMjCRvp06dIk1x4sQJ5BQKwPfffw8XGMBO
PZRJKBemTZsmOxoXg7Vr18K9b9++nyI+Wijr69WrJzu+e/fu5MmTVKe0gtd8
IYwvqNrKLvHY+MQLJLvOnz8vOz569GjGjBkofro1sWvXrnDfvn177O6I2kSD
m/bqiPHdzdQ4pB7dYtasWWgeUSoQIP6mT5/+xYsXsU6r+L11LATvnj17cEnV
qlURMv7CqAgICIALmrhYPxTjgrDgZVwKFryMSVjwJiBawQtRljJlSnlgQjE5
YEskS5YsY8aMDgOHsQ3JKcJxKHjJwpkzZ47s+OTJE29vb6ib169f4+/ff/8N
P3CBpSR7q127NtwPHjxIf5csWYK/Q4YMER5gSNNwpFMWFIplvnz5YIwJYRWL
x/zhhx+0Y2Rnz56FY4UKFejv8ePH8RcazWGU4iJ4ocjITr5y5Yrs7cCBA3D8
5ptvzKcM0pNGh+XljTS4mSNHDvFyAHJYO4JJLx+GDx+uG7IieCEh8bddu3aK
t7Zt28JdDAy1adNGSRbkHUopHG/fvm3+uUxCuTB16lTh4rAYjBkzBu7z5s2L
98joQln/7bffCpdJkybRwDehFbzmC2F8QXVZ/I3Hxie+oEYJnRT9RStE00UE
2ppYpUoVuIsXSk6BBwwNDXVzc8ubN69W8Jq5u5kaR82jUkQbNGgAx6VLl8Y6
reL31rEQvKiPuAS6W7jQrI/FixfH+qEYF4QFL+NSsOBlTMKCNwHRCl4YGB1i
IONKMTkiIiIs5nZAGjt2LIVD08wcCl7oSove/jA0IHXu3DmrzSTGcXBwsOKn
b9++cF+4cCH9hXbT2pyQw7CFjFfyKtCCwR07dsTlMSn++/fvlx1fvHhhsU2+
pb8w9uQBXwPiInihcy22adXKaPW7d++gI6A1ZMeTJ0/CEM2fP7+7u7ufn1+Z
MmVmzpxJrx3AjRs3EFS+fPmUO5KhjrMUbNKkSZMkSSJPcgbbt2+Hn5YtWwoX
GgayaiaWI/7Lli3DAfSscqPWrVvDfcWKFfQ3U6ZM+EtjzYJOnTopI9fiRoLH
jx/369cvT548SAEEUrt27Z07dyr3evToEYJCUnh6epYrV+7QoUOUC1OmTDFf
DEihO1wJruh98Pbt2xkzZpQoUSJ58uTIu6CgoLlz54qMEDk4evTo0qVLI4bI
lDlz5iCSCKdu3brCz8aNG0XV1hW8Jgshyp7WG+pI1apVfXx8EMlChQpB4Gjf
Ea1duxZiMFWqVFCsqFnR0dEIRy518dX44Cqtt0uXLjVv3hzBIqNz5crVrl07
bVODzghlHsUAkcTB7du3qUBS40N5IWJYvHhx3ZqYI0cOKFb4NI6ktihaY96K
TJw4UVsMzNzdZI1DOuDvmjVrZD+rVq2S59JY9Yoiwp8wYQJaV29vbxSz77//
/vDhw5/i1tZYCV56Y4MKQiO8z549o+ZIdzUKqgMqO1o2ZDeqCUQxTSBhXB8W
vIxLwYKXMQkL3gREd0qzQNfkoNFAWFyLFi2CnQA7vEWLFtAUZGPoQrLLWPDC
2PjRhjJ0a43ZSIemyT158uTs2bO3bt1S/NA853379lltg4+wabNmzRrHxDly
5Iiiy4yx95hIQMRZKeE0zxnqif7+9NNP+AshM3LkSDxL2bJlu3TpsnfvXu1d
4iJ4b9682bt3b+1WS0+fPoW3bNmyCReY3FQ2kIwlS5YUS32FUUp6qmPHjkpQ
tAKXzGDY53hwZTqoNWbq49ChQ4WLMP7xXLT0D8mIqCLC0E1QeTCkFy5cSGUD
vziGC6zuv//+m1wSJUoE0arciBb/Ikm1NyJQkLJkyQIXyLSAgAAxlbRnz57i
nQDiQFO+EydOjLjhF7em8qa7stVeMShfvjzcYZN369YNNjlC6Nu377Vr1xRv
isqAfAgJCYELbgrFLdZKV6hQISoqivxA/JIfi21dNp4FB9WrV7fYX9mqK3hN
FkKt4EVWitJSsGBByD0cQ0fIL5eGDRtGfnx9fSmdKYb2VrbGpfHRCl7ILhrd
RlkqWrQobmqxbYwGqSX8bNu2jeY/eHp6UoHHI9AecbqLrHVrIvICJcTf3x9V
oFmzZoGBgfXq1Rs9erRYbWGvKFpteg25XLVqVTSGuoLX4d1N1jh6H3jv3j3Z
z927d+FYqVIle0URj4BSR0URyULTJ8Rrxvi9tTW2a3hr1KiBq3r16nXixAmq
LJ06dVK8oWrDA0U+V65cJIpB69atzd+LSUBY8DIuBQtexiQseBOQWAhe2MMW
2wZQln8CG97evF8zgtcetCyrQIEC2tfvsFuio6OvX78OZUR+SBCRfCtdujS6
RdzUx8cHNjbMSF39aA+Y0FBA7u7ud+7cMXmJmceEWfj48eNdu3aRhhL2Nmxj
3VSFtaY8eBzX8OoyePBgeOvatSv9ResNLYDI7Ny5U+g+yH+kBnQlme40KIML
laAGDRqkHcGhzIIWgKH722+/QVZAlNEoMAFlumDBAjrWmvrwCQUBR1wIJUKq
BNasWJp3//59i22/LOWmu3fvhjtUm+6NAI3Gjho1igZMEUlkDc00WLJkCflp
3Lgx/kIAIuOsthFhMQwtr1Z2WAzEzmly/uJZ5PiA/fv3w+XBgwf0F7ew2DZb
fvjwIblcuXIFZVse9Z41axa9r6AO982bN2L/LntLmHUFr8lCeOnSJcRQDHoi
Fyy2pdxC7Dx58oRmmCPXaLzvwoULKDl42LVr1360Qauw6VWDbgzj0vggAojh
77//Tn9fvHiBPPX29t64cSOVZzQUU6dOhTJFOb969arV9mIhc+bMCGrgwIFI
QKttY3ByAWfOnNHGULcmXrt2TTeGCEoZZ1SKIuKcNWtWxJPM+NgJXhmDGkcS
T5kkgC7Y8s85G0pRRMrAQ5UqVWgLQYQ/f/58i20VtrL8Nu63tsZK8Fpta14o
11DeELGZM2dq916gPcHQgAgDNSwsjLbCO3r0qFO3YxIEFryMS8GClzEJC94E
JBaCl76XARsG1g7E4KNHj7Zs2ZIrVy7tnDRBrAXvhg0bUqZMCbsUJor2LI00
EcHBwUKZQgLDRQzY4ZfGvMD48eNN3prWmsHGMx9bM49JwzrAzc1NXs5ZsmRJ
i20/ajwpJFVERMSMGTNoy1xlL6n4FbwQ4DSuh1S6e/cuOd6+fbt27dryCmhC
XgRNS/O0io+GhpXdnKwxg27C+DcwLLWmPgoY7QQlU6JECTFORAuiteIOdqxF
s3GTgEbwtUtW6R0LLHOrbQjYYpt2K4/QQQKQosHDmiwG6BAp2jVq1IBChECA
bKStmVASxNeXFJ4/fw6jHZVLaR4hfuEuRsro5YlYwG61KQ7arqdmzZq6IesK
XvOFUCYkJATigmSj4P3796iS4pUOzT9XVm3TKJunp6dusPHV+IBRo0ZZ9FZP
03seGgGkje/Emnpi8+bNlGu6Xz3TrYlQ2XTJgAEDkK3IQbFLGBLWXjeH/Kpf
vz78oOyRS9wFr0GN8/Ly0n3PgLxQ9hATQEi6u7ujMIh5BQSNqB46dCjebx0L
wfvmzRtUSRq+N0gcNB04e+DAAdmRtuAbMWKE+dsxCQULXsalYMHLmIQFbwIS
C8G7d+9eGBLK8jdoJRKV2ima1lgJXtiKZEp5eHgsW7ZM18+KFSvy5MlD5g3s
JTFccuLECXqusmXLkh3+4cMHGN4w2AzEhUx0dHSmTJl8fHwU684YM49ZpkwZ
Wm1Kw1Kw2Mkd9jZSlcYQBWRvZ8iQQR6kiC/BizBhnNOet1myZBHb8thLEOQ7
DYJQeaCRR+2cXhK8sB4V9+vXr/v7+6dJk4aevXPnzvZWzCmmPn1+JV++fEiN
yMhIGh+nWe5ITArkzJkzFr3puyR4UZB0bzR69GjdwWiE6e3tjVPQlfRNVe0K
YtokTfuY9ooB9DKybMmSJcrkWxJ9zZo1040hrViXR6gFdevWxam1a9fSfIbs
2bMrI1n0RsLes+sKXvOFUEArN7VLucGUKVMsMdMGKL+U3cPoNQUquG4M46vx
scYsoteax+fOnYM7qoA1ZrW+GNYnkFm0iZbuNr+6NRHNC1x2796thENLbufO
nasbQ3p3B40sXOIueA1qHJJLdyY5WlF72bF//36L3qTfJ0+eIFth78X7rZ0V
vMjfwMBAXFKyZEmUZBRLtPb0AgHWRdGiRWn9xevXrxMlSpQtWzalPKOJw4OI
BplxZVjwMi4FC17GJCx4E5BYCF570J48sMC1p5wSvK9evRo8eDB9qDEkJEQZ
OdICu2XDhg0wb2DG0EdXYQ9bbGsDlQ5xyJAhFvubA8uQ/dm7d2+nEtP8Yz54
8KBmzZoWR6vG8Gi0DE1MZ7XGk+BFBEgxIZ07deqkXWAIAxVG+9ixY7///vsi
RYrQqkyCygPtJSWvwyVo1MzeOwqrrb7TcK29rVNlU//evXvu7u6+vr5KViLC
NKxJi4Xv3LljkRZEC2isVrvDM9GyZUuLIei/6Juq8r6vRM+ePe1NGHCqtNMu
TKS5tCxcuNA4hjNmzKDP+1auXFm5lna3rl69um7IuoJXF91CKKARcAMaNGgA
bylSpEANVcQ+tBI8IH917xtfjQ+gZdr2SJ06tTXm877Hjh1TrkXht9jZ9cip
mkgbgolVAzIoZsmSJStVqhRNpSbiLngF2hpHf+XbWW0NLxxxSjeQ2bNnW/65
HN4Mcbm1UwUA7RWN2/bp04cCX7FiBfUCYWFh9EKMEv/y5csWzXph5vOCBS/j
UrDgZUzCgjcBiUfBO27cOIuTqxq13L59u0CBAhbbglwILvPfzO3cubMl5pNG
9Okirco7ePAg3OvXr28cFG5KO9VoN3E1ximlA8lpsX190thbtWrVLP9cQhh3
wYuEhZFvsc0BhvmnvSoqKoo+E+zt7Q3FNGTIkA0bNsDGoA1nqDzs3buXxm6U
a2ljZNo9zB6rV6+Gn6ZNm+qelU39NWvW2FOs/fr1s8TMnX79+rXFtmJU8UML
jbWqnKAFvFBD+eyAponGl7WClwYEUebtpbnJYoDCBsVnbx0rDaOnSZPGXgzn
zp1Lr3e0gpfGplF+dEM2L3iteoVQQFLCw8PDXgzbt28Pb3gEreB99uyZxbZz
lO5N46vxsdpGFal46MawcOHC8NOwYUNdwUtj0ydPntQG61RNRAgWO0uqf/vt
N5zy8/OTY0UzybNmzYrjYcOGxfHuSo2jtQlicS5BC+G1b40IGq8fO3asmdvF
y62dKgDUtkPGyl0GlQpfX1+q6Vu2bLHGDOtXrVrV2QdhXAcWvIxLwYKXMQkL
3gTEWcGLer1ixYpNmzZpPdPOUTCztadMSoDIyMg8efJYbDNIo6Ojdf3AzAsM
DNy2bZviPn78eGHxfvjwwc3NDZaV4odm5TncdZnmkZYuXdrZxNR9TNhyiLB2
tq2sdG7duoVUPX78uDbMokWLIkx5BDaOgvfEiROenp5In+nTp9t7n0BD4c2a
NVNmKsqClz5LFBAQoFxLI2I01L59+3Y8u3ZZ3KlTpyz291OSBS+EtsXOnF5K
h1mzZtHfTJkyJUqUSJmRSOOw4mNVClRidQuzYMeOHRa9Kc00Pj5mzBh7aa4U
AyQ7spiSRYYmJENV6d4dJrrFtmW0QQxpdbB2SjMplCpVquhepRW8ThVCQVRU
FE4h062G0FxTZUozSQ8URd1L4qvxEfGnrZbsQe9PlCnNaElorbRusujWxM2b
NyOSyiZO1pis/PHHH7XhkOA1oEOHDibvbrLG0beBxDesCZoSYK95pIqg3ZX9
8uXLSLQLFy7E+62dEryLFi2i4V3ZETUCTQelIcoATaum78Fpd3RH8cCDGL+p
Y1wEFryMS8GClzEJC94ExFnB+/79e1rIqVTtV69e5c6dG4pDd09jk4K3R48e
8DZs2DCDgd2xY8fqDvl99913cBdfUG3QoAHkpGJg06ic7qdkZGh6pHbbJYfo
Pua7d+9oV+GIiAjZ/erVq3AsVaqUNcbyz5gxo/IJyytXrkAOIGFlx7gIXiRs
4cKF4WK8YTWtnlaM/NevX9P2p6I80B5HciLjWH5XQIupYVsqn5oiC19esSgj
C176XknWrFkVtYUHoT2RRCRpOyNZsKCs5sqVC8XAntIhIxnZrbiHh4cjxcj8
Rq6hVKdMmVJezf3w4UMEqzvya68YkPxs2LCh4nnBggX2FI01ZsJw3rx5lY+6
vnz5EgqiUqVKJPDpQ07KplU0NKkd+SW0gtepQiiD3IEHrZZHdUMy0tZA9OVf
ZTUB1cckSZLoBhtfjQ9o1aoVrlq6dKniDhfcZfLkydaYGbDKplU0Sq478mu1
UxPpTcjMmTMVzy1atLBIn412SOymNJuscbSzlvIahzbW1t0e0GpbNYAUTpMm
jaLlmzRpgqugduP91k4JXqp0JUqUUGYRINo0Vl6+fHlxiuoLIiz7pDnbffv2
NZlBTALCgpdxKVjwMiZhwZuAxGJKMw2m5MuXT+z+BPsfAhOOP/zwg244BoIX
Bv/y5cuttj1DICs8PT0Ve1sBEiBx4sQwvcTHN2Hb0w6r6dKlE6qEZrgFBgai
ZyQ/UDcwrVOnTi0vRRR3F3z48MHPzw/Xyp8QlYEuwFW6O1/Ze0wy5yDQ6FPC
4K+//iK9RlMEcVOSJ0hG+rCs1VYvaGb1+vXr5dBkQ/fBgweIzP79++0llyJ4
6eO/oaGhxqWiW7duFtsnh8SbByQ7fTXVIq1nnDNnDlmS9JERZFy5cuUs0na4
yCBastelS5fnz5+T4+nTp+m7P7KIsPdZIkSAhoTKli0rvoWKG9F4XJEiRcRi
QFqahzJALxZwIflRNmGWb0RCCX4glkX7c/78eZpmIEZv6WM9UI4knPELpUlJ
MXr0aJPF4N69ezSxFpeITyBt2LAhVapUKPPySwPlWzC00LhKlSrCBWYeLTgV
o7f0sZ5s2bLRJHyoY3p2g7zWCl7zhVD5LBEtNEZGnzlzhgoMEhPaFo7QpzRJ
ALmDOuvu7r5u3Tr6LNHatWvpw7iozroxjEvjo3yWiDQ70h96kxoNPCyeiPa7
o3cmKEi0KnzgwIH0egHWi1j8q7upuK7kpJFc3Gvbtm2UGshu2iY6ICBAfnGh
fJZIIXaC12SNgybNmDEjckQkEaQ9/uJ5ZcGoFEV6a1G7dm1qZvF0tJAfufz0
6dP4vbVSAAxaXQIy3NfXl95f0csxJPvmzZvJkfbGFwsQ6OVG3rx5xYIOhE9+
aE8AxsVhwcu4FCx4GZOw4E1AYiF4YVqQrrHYPmUIIwfmCq3A0p30aDUUvMLw
RjEwntcnbD/aftZi+1hMgQIFaC9QGLS0RIuAMUYWI8iVKxcNDJG9rXt3AUUD
MkSxvgQGA6z2HjMyMpJMQdodFHoK0ptSTBjAML1IaCdNmtTf35+OQffu3ZXx
bjkCDofOFcE7depU40Qmb8hxGpWGsoB9W7RoUSRvmTJlIPrIUKQtaGBS0lJf
JBc0IO1nC/0r70gDpUBBQd3gQqEglOFdsjbpWDH1X758Kb57mzp16vz589Po
KvJdaC6CPj6LBKxQoQJthQ39q4zyyzey2r5MRC54wMKFC5P+tdgWeousgXFF
uzZBmsED8g5PREuVIWTMFwNIPMp3KreUXAhKeeWiPD6MOpolbrF91waRpA3E
kJhCiSDBIX7JT/bs2UlZkzYMCQnRLRgWvTW8JgshbemGckh/IR7pnYDFtia9
ePHi9GgQ8khecRVJYIttTSWJoBYtWiATUSl0YxiXxoc+iyPP5J8xYwYlPkQu
YigejYZ3iR07diDOFHPKcZR/es8jP4hAtylAQtFEekoNhEBfsNJuhK4URYVY
b1plssZBDFLSITVo1geK9/bt242LIn3riioLhYxANmzYEO+3VgqAmWktCIGy
GNHD3amVwDGuunbtGqKEY1qHLpdY9A5oUig+vXr1sjKfAyx4GZeCBS9jEha8
CUgsBK/VZmDDioDY8fb2hgaB2Jk2bZo9hWg1J3g3btxoUvBabUMP9erVg9UK
Mwb6sWnTpleuXFFCfvfuHazZggULwvKBVaPrR2v20z4nderUsfcssRC8Vtv+
PMOGDStUqFCKFCkgD4OCgpBiyty/R48eDRo0CNYXjEbYioiDmKFtLwLOCl6a
NO5Q8Fptn4ypVasWLHYfHx+Rv+fPn4clCTkgVupBjQ4cOBAqHlY9pNbgwYO1
i69v3LjRsWNHnEVGQIdCmmmfy0DwWm0iAkYypDfdHUZyly5dIiMjlUDgbe7c
uZCHtLEz9JR2jqtWZTx8+LBr166wvREyohcaGgplqhRmZA0ULlQq/AQHB58+
fZpEn+6mtQaZcunSpTZt2iBzUW6R0YihdhNy7eOjuo0ZM6Z8+fLICyjEkiVL
/vLLL2IQjUBZGj16dOnSpRFDiKxly5aR6LO3G63FzqZVZgqhIngp5desWVOj
Ro3MmTNDUaKcQzsoc/itNsmP3MdTZMiQAXd5+/atgeiLS+OjFbxW2yhe48aN
IeTxaLlz527SpIl2Kyp0Rg0aNMBTIHB4gEVN2aE78GevKUBqQDujuKIQIjuQ
X3369NG+DPxEgtdqrsZZbQU1JCQELVLKlClR7LWiXhuHV69e/fTTT0h8XIVa
/+233yovneLr1lbnBa/V9sYGuYbMxd1z5syJuoYmSyQX5DAKNk05QB4tWbIE
0fO1gcq1fv1683skMgkLC17GpWDBy5iEBW8CYix4GRdEsf127drVvHlze54N
vsPLMAzjsihvPAYOHDh//vyEjhTjErDgZVwKFryMSVjwJiAseD87ZMH74cOH
ESNGyGNtCix4GYb5HJEF75s3b0JDQw3Gu5mvCha8jEvBgpcxCQveBIQF72eH
LHgPHz4cGBiofNRShgUvwzCfI7LgHTt27HfffUffFWIYFryMS8GClzEJC94E
RHf9JuOa0H65hFOfJSJY9jIM4+I8evRI7pVMfpaI+apgwcu4FCx4GZOw4E1A
8kkkdFwYB9SpU0dklskPeoaFhYlLWrVqldBPwDAMY0RUVJTcK12/fj2hY8S4
HCx4GZeCBS9jEhK8Dx8+jGIYhmEYhmEYO1y9ehVGI2RvQkeEYf6PBw8esOBl
zECCl2EYhmEYhmEY5vOCBS/jEBK8t27dimAYhmEYhmEYO1y8eBFG45UrVxI6
Igzzf9y8eZMFL2MGXsPLMAzDMAzDOITX8DIuBa/hZUzCgpdhGIZhGIZxCAte
xqVgwcuYhAUvwzAMwzAM4xAWvIxLwYKXMQkLXoZhGIZhGMYhLHgZl4IFL2MS
FrwMwzAMwzCMQ1jwMi4FC17GJCx4GYZhGIZhGIew4GVcCha8jElY8MaRd+/e
vX//PqFj8dXx8uXLhI4CwzAMw3xdsOBlXAoWvIxJ7AneqlWr+kvky5cvKCio
devWp0+fTugoG3Hnzh3E9rfffvvUN0I6NGvWrECBAm42cuTI0bt37wcPHsQx
2JCQkA4dOsQ9epcuXfI3pF69evAGqa49VahQoerVq48cOfLJkycU2okTJ1AA
KlSo8OrVK+295syZg6sGDBiA43HjxuE4f/78f//9t9bnmzdvihcvDg99+vQh
l5MnTxpEcv78+fLl0dHRkydPLlmyZNKkSS0WC5K9RIkSEydORHMne9u+fTuu
XblypTYC8qmGDRsaJ1F4eHjcM2LZsmVHjhzRTYqDBw9OnTp13bp19+/fNxNU
WFjYrFmzFi9efO3aNe3ZZ8+e4emQPjt27Hj+/LnuHT9+/Kh1P3PmzMyZMw3u
+/TpU2Ro2bJlFXekPFJp0KBBinudOnXgfuvWrbhXRhQAhHDv3r3YXf7ixQtc
jnjGOgI//PBDmTJlYn15HB9w7dq12mKJ8t+4ceNNmzbp5qYuVCtRAD7dgzAM
85XwBQhek4YHtZy6loByatiwYUogMJnKlSsHm/nUqVOxiKFTFsKBAwdGaNi9
e7fsx6GF8PnCgpcxiT3BmytXLsiKzjF06tSpZs2aJDTmzp2b0LH+/0HbW7p0
6Q0bNtDfmzdvIoY///zzJ73pr7/+mihRotSpU7dq1WrKlCmjRo2CQsR906dP
DyM/LiFny5atWrVqcY8hotFZomDBgohegwYNhMuYMWOstuFpuPv5+cme8VBF
ixaFe+bMmYVuhSNc+vfvr9zo9u3byZMnT5s2bWRkJP726tXLYmP69OnaWMFK
p7NNmzYll/379+MvbtdZjz179ohrr1y5kjt3bnguVqxYjx49ED5+IXjhgkS7
cOGC8LlixQo4Io+0EZBPocMSN2rSpAnc0UPJd//zzz/jmAsPHz50d3fXlkaI
QTwF7pgyZUr8IgGXL19uEA66qvr168Onp6dnkiRJcDB48OAPHz4ID4cPH86Q
IQPcvb29KeNOnDghzl68eDE4ODhx4sReXl7t27eXO7u3b99CzDrUpAEBAQj2
+vXrsmOhQoWo8MjKC+oYVYMc414Zx48fjxBQxmJ3OSKDy/v27RvrCHz77bdp
0qSJ9eVxfEDkC85WrFhRLpZQu2h54A4xbvIuVCt131aZZNq0aWhmhWRWWl2G
Yb4evgDBa9LwoJZTV7Eqp9Cx4i8MCRFIx44d69SpkyxZMrgvXrzYqeg5ayG0
aNHCogExFB6MLYTPHRa8jEkMBC+qhuII0ZEiRQoPDw/XmQINY96euvlEoKmE
SR8YGHj37l3ZfceOHdAUlSpVikvg8SV4FWAbI5XOnj2ruJPgLVeunPaS7t27
49TQoUPpL1QS4oYHDAsLk70htvAmTF/qBTJlyoTmWhtmvXr1cEoreAcOHGgc
/0ePHmXJkiVp0qQzZ85UBrbmzJkDUZkxY0ZS3FbTgleGShH6rHhJbUhRmATr
1q0rUqSIVvEhzQsWLIg47969G8/y4MEDlCV7vSrRvHlzeocAffrixQvq3fDg
dPb+/fuolejCLl++jL/h4eHp06eHJkKi4e+TJ0/Q06HnPXny5NatW7Nnz45O
WYQ8efLk4sWLy9pZF2SQ8qYLGo3UrhLz7du3w6VVq1bxkpIseHF2yZIlijty
FtltPmXiLniVEP79VpdhGBfhixG8Dg0PZwUvGkbFGwxsNzc3pzqRWFgIJUuW
hMX16p8gHDprbCF8AbDgZUzilOAFjRo1EtIJiu/YsWNWW4WCbSZG2VDX9u3b
N23atIULFyJw+fJnz57hEhjtf//9N1TS1KlTDx48SBLm2rVrixYtggWunQL6
+PHjbdu2/fLLL6tWrbpx44Zwh723fPlyxOfHH39EsKjgb968wYEsRRH48ePH
oQ5mzZr1xx9/iEbAapvQC89oT+AIuTphwgQ8BRpz4xRDw5IkSRI5GoLatWsj
MhEREcLFIClE+s+1gQOrnuC9c+cOpNPEiRPx7Eg9+RSijfibmWQeC8ELzzgF
g1+4IF+g9AsUKPD69WtyIf343XffCT/UC5A+kkddrTblBcU6YMCAWAje3r17
w9uIESN0z44ZM0Ye8EpwwYtMkV+0KoJ3586dcBwyZIhwQcmX00QB5RPJXrVq
VeEC2YveKnfu3PR31KhRuHzz5s3Cw8qVK+GC+mK1TYtF1ykqOLyh9EZHR+MY
FgvquJk3vag4SgxnzpwJF7rR4MGDhTvUJVxQVq22SVlKZbQalmeAZmHjxo1o
BHbt2oVeTKsH8SAoM2g3Zs+erRQwbXMkBC/K+aFDh1AN4X7z5k3lpqiwSCUk
FxJHseK0ghdtEUT9pEmTUKP/+usv+RTykWoxDmbMmIEA9+zZo7yfcfiAMvYE
L+jcuTNOodUSLjRjbaqNrVu3ikpqleQqnn3ZsmWIGzJUu/MAzCFUEEQJzZE8
iw+GVuPGjREC2uorV65oW12H5YdhmC8GFrxW04IX0Dw088nlrIUA0I83a9bM
3lljC+ELgAUvYxJnBW/lypVRUy5duoRjWPI4PnPmTPLkyYVhdu7cOX9/f/z1
8fGh6RwNGjSIioqiy6mdgeWZPn36fPnypU2bFn/btm0LC9DT07NgwYIpUqRQ
GqJNmzbB5oRjunTpEidODOO/f//+ZK0NGjSIZlnDhse9YIvCBJUlBsRCaGgo
zQWlySFofMTMTLKHIZfKlCmD2BYqVAihISjd5Z8EbEKDlgeaDial2E/JOCmQ
5jRPGE+UKlUqHHTp0iVTpkyy4IUGpyghuWhmixy3R48ewdHMy8NYCF7KqW7d
usmO/fr1E00x7o7s8/PzE0t9rTG9AB7cw8NDGVmDQqGS46zgRV5D3yH37Q1R
wbbPkCEDiiuVigQXvBCk/7VBPZcieIcOHQpH5e0HSn6WLFl0Q9uyZYt2HUHr
1q3hSIPaKDBIbTlxXrx4gTJTv359utzNzU3kEaQKiiKpoZYtW5ocisUToWKi
EAqXKlWqZMyYEWoub968BQoUEO70LppmwiuV0eqoPKOmU0XALypFnjx56DGF
HkQBxu3g4uvrSxW/SZMmJN6tes0RVXA0L5UqVUIRypkzJ/6iDZFvCn1HQVGU
vLy8oGTFWUXwbtiwgaYTo9gjhgjqp59+EmdRqpGP0JtIYaQJIgmfSCghCR0+
oIKB4MW9cIr0NYDCxe0QJjKFHgctya1bt+gs1cqZM2ci5ZGPKA/4GxwcLNYO
o+K0adOGcoRG7QFc6CxSBk8KFzwXlK+21TVVKxiG+SJgwWt1RvDClkYHLb+B
NMZZC+Hhw4fwP3LkSHSFEH3oTZS3rMYWwhcAC17GJOYF75s3b6ZPn05LJklZ
kIUJAwkCNiIiAh4QDs5CBx08eNBqs5Nh/slSgtoZ2HtUnVEHK1SoABfYorRk
EpY5jlE9aZol9COMK0hR2qgHBbtdu3bwL1YdKpPrFBu7Zs2asO5gwSLCaAS2
b98Oe0/M4SR7GFoYJpy4nTx2pmXx4sW4ZNy4cQ4T1mFSULPWsWNHWlN5+vRp
mqYoBC+9hevatSuZ9OhlSpUqBZtWTCqGsu7cubOZGZtOCV60zLhFQEAATH1l
IBtZXKRIETSVkLQ0zxZJKnugXgDJ+N1336FgyKNIZcqUCQoKQo5rBW+jRo12
6IFm2WqbSA8/8hCnllq1asEPtXgJLngF6A21gpc0jjK4WbduXaSq7tRixBb+
Dxw4IDuOHj1a6B10hdoSC+GD0mK17fSVL1++EiVKrFq1CvUXxbt79+5wP378
OCq4eaMF0g93pDlRyBfUShRda8w7EBo2RUmGMsK96BKlMhqXZ6gzhIm6Ty0D
0ocKmNCDCJzektHALori8OHD6TURha9tjqiC08x8SluUEJRqBEKXbN68GWfr
1KlDqg0CsHz58qSaxVMLwYtr8XQoh5RoaKlo3FMIZJRqNFyFCxemOR6o8vQI
lHcOH1CLruCNiopasGCBbK6gFiMrUQZoAwE8OPQvLuzRowd5oFqJpg+1Fc0g
6iBaMLjUrl2bPFC9QEuCOFttw9CovyK7rTylmWGYGL4YwWtseFjjJnjR0t6/
f79///5wHzt2rPm4OWshHDlyBP5hX9GbXoBeftasWUL2GlsIXwAseBmTGAhe
GiYgUDvoJT/sSfHqiSxMeerF3Llz4aJsrgvDDGYtjSZQOyMPi8A6hcuyZcuE
C6kzMkE7dOggD2RYbdYdjEbEh/4aCF7EE8edOnWSI4OWR8g0sodh/crNSJMm
Tdzd3e0l16RJk8SMTWOMkwIJjrtAPMq3JvNbCN6sWbNCdcoeYNDCA9pDZ3PZ
WPDSsJeAXLJnz647uxutSrJkyWgprhgDEgjBu3v3bhzs3LmT3CGcaZhSV/Da
g7oPas9JptmjT58+8IPQrC4veCtXroyeS/FJ3aWuCTFo0CCcOn/+vOxIUohm
tKZKlap06dLKVSg5yCM6fvDgAXIKxQkd3/jx4yFqUKiKFSs2ZcoU889Cd0Q3
iuONGzfieNu2bdaY+dsUlDIXSxG8xuWZ5uhChouzEG5ZsmQRepA0vnYJOVQk
KWhtc0QVvFChQvIb74YNG3p5edFx0aJFfXx85F28EGcECOuC/sqCF44pU6ZE
mMIzCjMSGQ9Ff2nU9dChQ8IDjuGydOlSMw9oL81pKFmpngiNxKnV9ipgxIgR
+/btExcikSGBaSd2a0ytnDBhghx4gwYNxFydgwcPIgQx+cQa83ZC2byFBS/D
MF+M4DU2PKzOC165oUa7TaHNnj3bqbg5ayHAyKRxKNil4eHh6JehZOEyefJk
8uDQQvjcYcHLmMRA8ELX9JUYNmzY8uXL5e+fkoUpG3gkrB4+fCgHRaOiZI9R
OyPvOEdG3cmTJ4ULLQOkBfWop5kzZ1bi1q1bN3gg88xA8C5ZsgTHv//+u3zt
hQsXxBAt2cOKaoP5jQen44kTJ4o93mlfJhj8NDnQYcIaJwXqJg5GjRoln4UF
i3aSBC9NV65Zs+aGf5I2bVpY6c7msrHgRVM5XgLKgvYErlixou4CPVL9yBft
GkwheN+/f58hQwaxP9Lw4cORqkhwXcHbsWPHq3rQrrDnzp2Dn8aNGxs8IE0O
p+XMn07wkrIQ0IpRA3QFb5UqVZDLyqQjmlCq+3mawYMHK+98rDHlcOvWrTiG
ZNO+qoXK8/PzsxexOXPmFChQgDIX6TxgwIB27drNmzdPaCgttEtVo0aNrLY6
4u7uTjIT2srX17dChQo4pgXaYg2+XBkdlueyZcuiwCg3RcEQehDaEzdVLieN
Sa/gtM0RVXDlO1/NmzdPnjy51TaPF9pWqEIBEjNnzpx0LAtemAdINCUCgYGB
MGwoNyky8swxKgA0ROvwAbVQ24g0l6vnwIED/f39cdNFixYp/tGMo44vXLgQ
D2WRFuBTrURGy57XrFkDx7Vr18qODx482Lt3L1KSXniKD1uw4GUYhvhiBK+x
4WF1XvD27t1bbqvhBx2cl5eXvf2mdC0KZy2Ea9eubdmyRV5agq45e/bs6C5p
HnUsLITPCxa8jEmcXcMrQxamvAkMCSVl3sWuXbvgSOYZtTPQHeIsGXVygyAL
3ixZsogZkgIa66HibSB4aTBXUXl///03zau0xtjD8ubt1n8K3lq1apWLgXZM
2rNnj8FoI2Q7jEyyb42TAlaldvwXpEuXjgQvqTy0VNk0kLhwilis4UUSWWzb
1GhP0edmIBy0p4TgxXH//v1J5KLpzpEjB2klXcFrvJTmxYsXbm5u+fPnN/BT
vHhx9BG0UvXTCV4UnnISBmu9CYMpzfJAodX27VrjKc00eC2gbShI6BUsWBC1
VbkK2gpaTDdW6BlTp05N82z37dsH0ffNN99A8KJrDg4ONtiDCDoLfqAToXBr
1Kgh3NEXI/ERLHrVFClSCNUsV0aH5RklBJmo3JEmLZMepM3isulBr8u0zZHu
Ls1C8EZGRtJQqXLTunXrIk3oWAhePLXFtsRVNwL0GhClWjQdcgGgBsHhA2qx
t4YXNQKxQoDCZc6cOXnz5oUKRvojN/v06YMDRfAqRe7o0aPi3R3NYaatEmAp
oaqSeGfByzCMwhcjeP+FNbw0tGHvdb2uReGshWAQc3S7VucthM8OFryMSeJX
8Pbs2RMuymeyFyxYICx2ZwVvUFCQdliEJgdSg2AgeGkrUZp4KTh//jwcx48f
bzUheLUgoby8vGDw6365myJGu+EZJ8X169eVqd1W2+JZmKwkeEmYy/Mz40Is
BO+6devEawoFk4KX9qdC/tKsV5pGHgvBCyCvtIP1Aqhyi213IPpLbxVGjx6t
9UmL0NesWaO4/5tTmpHpYjBakC9fvqxZs+oGggIs5hIL6MtEtDcUEgclVuzd
ZLWtD0Xn2KBBA90AUUobNmxIx4UKFRIDoHfu3PHw8DCYrk+ZS3P15WlatK0W
Yoibytt6y5XRYXmuVKkSqpXiSFYE6UHo0HTp0hmktrOC9+PHj+7u7jAklHBK
lCghzAN5hDdjxow1a9Y0iICx4HX4gFoMNq2SRwFoxW6tWrUOHTok3lekT59e
Ebw0e1lAk5Zp0UH16tXd3NwmTZokvj1NecqCl2EYha9H8NLYCiwK7SnqgkV3
Y7BplY+PT8mSJc3HzVkLAbYoFJ/iiK5WtPnOWgifHSx4GZPEr+BdtmyZxbYJ
s+wtNDQU1hRN7nVW8Pbo0QPH8txRRBUSWIxuGAheElyKLqMv5uzdu9caK8Fr
jWmOOnXqpHzX48GDB7CNkWg00dc4KejLMkhkeRIpXaKs4ZXvAnM0MDBQfIDV
PLEQvKSz6M2AgknBa7UNvJYpUwZpBVOfTPHYCd6wsDC0z9mzZxcbzwoiIiLy
5MmTKFEisdEQaatSpUopE3SRksHBwbr64t8UvDSpXn5k+uhAnz59dANBP5Uq
VSqUHOFChUcM9NM8efEpZGuMllm9erU2tHPnznl5edHuRgDHtMKU8Pf3V2Ir
Q+uyaTdjEQLFEEqZ3OXCqbuG1155ps09ZNPi5cuXtNGxvIZXMQPatWsHsUa6
z1nBa7VNM0YKyJ8jRF5ASIoX8soaXtRueU9yFGbI2N69e9NfY8Hr8AG1GAhe
6HTRSNICdnnF/YsXLxATRfAOGzZMDgGSOWnSpGi1cOzp6SneFxH02SkWvAzD
KHw9gpe6PNqeUQYNr5+fX9q0aYWLgeCFvZotWzbzcXPWQkAvliJFCnl9GTpE
mm1Fva1TFsLnCAtexiTxK3ghagoUKICKtmrVKpjBkZGRZIyJquqs4L1//z4s
Uiidw4cPw86H3qlZs6ZcVUnVisWwio3drFkzSCH8hZkKIxCmNU3gpLOxE7xv
3ryhnaXxu3nzZgiu8PDwuXPnIpJwXLduncmkoE2bYUXfuHED6Y+goGIQPSF4
caHFtpPq1atXP3z4gLsUK1YMpqn8WaWCBQtCxDnM5VgIXtryi+Z+K5gXvDNm
zLDY9sHu2bMnuegKXqi5aXrIc4bnz58PJQKpMmbMmKNHj6K3PXbsGPQ4fcdK
2ReCxAWC3bNnz71791AqcEBf1FKym/g3Ba/VNtiHMvb777/TRo4lSpRwc3MT
g2t3795FtspzhulxJk+ejCrw/Plz2t2XFvBSkqZLly5jxoz0Ohc1Gn+zZMmi
XZCL2wUFBclj39BEKFRIIpxCt4jKIq+mV6Cd1nDrwoULK6dIfymyS6mMxuUZ
FYS+fLR9+3bcCI5Vq1alz9+IXZphY0AhIt3gAYWfkkV8nTkWgpfmBqD8X758
GXXhzJkzSPkkSZKI3YllwQs7BCWwSJEi8AbPkPy0c7XYqNxY8Dp8QC0GgrdL
ly5ixhp98Av1gt7znz9/HrkMF9HQoczjoZB3aKaQjMgXahB+/PFH8oAMRcKi
yqMYoH1DXaNqJeZC0IewxXwVpdVlGObr4YsRvA4NDwjGKlWqWGzftkPPiDYc
JihaRXQTih1rIHgDAwPRzhvsj6HF2ELYt28fIiBab1KvISEh6FgRYeQOLfgV
RpF5C+EzhQUvY5L4FbxW29c3YEBabJuLkg0MsSPCd1bwWm1rzXLkyCEChIUM
GSU8P3v2DPG02L7SC1Wr2NiweMW3P4hatWrRoIY1toLXatO848aNQ0zkkHPm
zLl+/XrzSYGmaejQoeKUxbZ3PaInf4d35syZdBfanRVtlNg31fqJv8OLZ0Qb
i6QQ+lpgXvAihvTRT7Gzt1O7NIv9b4kjR46ULl1a8VOxYkXt5lFIW2QQrUkU
pE6dGimsjMsT/7LghcCkj9HTt6FRgDdt2qQkr7zo5vXr1w0bNrTY1pDSDpBQ
N8qNaN9sCjB79uzKrs7EsmXLUErlDwLCaClbtixVKwii6dOnGz8RCic8Dx48
WHFfuHAh3JVvH2i/w2tcno8fP541a1aRXyVLlly0aJGsB9GjoUiICoWihQol
ljXFQvCCpUuXUgNCYWbIkEGeOa98h3fHjh3wIOKPC+URbWPBa+YBFQwEL+3M
ScOyyFD62jgSBAXAy8tr6tSptAiXVg2jVmbLlg25T5WR6Nq1qxixPXz4MH1f
GE+ER8NVO3fu9PDwwOPQMC6txUDe0YeblVbXyjDMV8MXI3jNGB5RUVEwn9AS
yh7QOys7eBgI3k6dOul2mgYYWwgbNmyAo1iXZLWt1UKzL6KH4ylTpsjbXpm0
ED5TWPAyJrEneOMCTNDLly+vW7cOVpOyiDV2wKJDJNHCHDp0SP52BvH48eON
GzdCbNp7YQV7ctu2bfCj1W5x4eXLl+fOnVuzZs2WLVsuXLige3eHSQH1DQMb
IQgZrgCj/Y8//li+fDnkntg88GsmIiICyQUVcPDgQUgqA5/R0dHQ+Ej8tWvX
4kBew+IKoDSi8Jw4cULe19cAlJ/Nmzfv27dPuzm21fbuAnV59erV4eHhuqIe
7N27lz5iK4NuET0FgpVn9n46jMszkuL06dOrVq1Cd6z7FHBEbPGY27dvj5e2
xWobOz527NiKFStwa4ctITzAG+JvLyOMcfiAsSYsLAyPgEpBmxvABkA1EXOS
CYjTPXv2oBTdvXtXmwhoo+jDFhSxGzduoMkVLxBgy0EyiynlDltdhmG+SL4A
wessaDmPHz+O9pCMPYOtHeMRpywE+IGRgxiiY421hfCZwoKXMcmnELwMwzAM
wzDMF8ZXKHgZV4YFL2MSFrwMwzAMwzCMQ1jwMi4FC17GJCx4GYZhGIZhGIew
4GVcCha8jElY8DIMwzAMwzAOYcHLuBQseBmTsOBlGIZhGIZhHMKCl3EpWPAy
JmHByzAMwzAMwziEBS/jUrDgZUzCgpdhGIZhGIZxCAtexqVgwcuYhAUvwzAM
wzAM4xAWvIxLwYKXMQkLXoZhGIZhGMYhLHgZl4IFL2MSFryMMb1797YYsmDB
AnirWLGi4u7p6Vm0aNHZs2e/f/9ehPaf//wHp9asWYPjP/74wyBYBEiXKO5J
kybNmzfvoEGDoqKiyMOHDx/Kli2LU/Pnz9fG/9atW8mSJUubNu3jx4/JJTIy
csiQIYULF/by8kqRIkWRIkUGDx788OFD+SqKW5cuXZTQ0MvLcSM+fvy4ffv2
evXq+fn5IXoZMmTA8bZt2+Aue6Mk0toJuAvcccenT58aJ3XmzJnNZJn5yD94
8KBNmzbdunXDca9evXDsMLZxJF++fAg2fsN0FrkQJiD2sunfB9FAvnyKkCmp
8fsvPxEVdVCtWjVdD6dOnSIPrpD+5hFtBUpvgiQsw7DgZVwKFryMSVjwMsZs
3ry5twSsLB8fH9nl5MmT1hh91LFjR3KEemrZsiVkJhyHDh0qQtMKXgjP3nr8
+uuvdIl8RwTbuHHjrFmzwjF79uwRERHk58KFC25ubmnSpBGqVvDtt9/C8+LF
i+nv/v37U6VKRZcjqEaNGmXLlg1/vb299+7dK64yrxlRdxAOHD08PMqVK9eu
XbugoCAcw6Vhw4bR0dHCp0PBi6DkFChTpgzca9SoIVxGjBhhJsvMR/7q1atw
QYLgGGpdlqJfoeAtWrSokmjIEd03D48ePYp7NOxlEzJaKz/plY7Chg0b4iVB
dAXvli1btAVg8ODB2mh0797dOKk/kS6bNm1a5cqVw8PDtaeE4E2SJElkZKTW
g3iPx4KXYZyCBS/jUrDgZUzCgpdxCnuDQbr66O7du15eXkmTJhUFTCt4HRqc
2ju+e/eO7NUGDRoIRzLFO3XqJPvcvXs3HMuXL//hwwf8vXjxoqenp7u7+9y5
c8XwKw7wF45QqfBAjuY1Y6tWregWf/31l3DEcXBwMNxx1jiJrJIRq7jHeiDS
fOSfP38O0bR161Ycb9++XRZQX5vgXbdunTbRLl26BMdSpUp990+QbnGPhm42
Xb9+PVWqVNoq5uvrmz17diUap06dipcE0Vax6OjowMBAbQFo3LgxapASjUWL
Fhkn9SfSZfYqjjWmqKdPnx6/s2bNUs6iNciUKROd/bwE76tXr2DdvX//ngUv
k1Cw4GVcCha8jElY8DJO4ZTgBXXr1oW7GIWJF8FrtalUGgA9f/48ucBEz5Ur
V6JEicLCwsjlzZs3uDBJkiRCxlapUgWX6NrnCxcuxKnq1avTX5Oa8fjx4/ib
O3fu169fKz5xd8QHZ4UqcUHBa8BXInjv3bs3cOBAMSFfSbStW7fCcefOnZ8i
Gko2jRo1qmHDhu7u7toCT3PdBwwY8IkSRL7jqlWr2rZtmy5dOkoQpQAUK1YM
8t/ZpE4owYtsLVy4cHBwsHL2yJEjNDD92QleAQteJqFgwcu4FCx4GZOw4GWc
wlnB27JlS1mWxpfgBStXrlTmS+/btw8ugYGBtGp4ypQp+Nu/f386e/v2bfwt
WLCgvKZY8O7du/z588PD3bt3raY1Y5s2bQw0KbQDznbo0ME4iZwVvA51q8nI
62pPkdoU21u3brVv3z5LliwZM2asV6/e1atXhU86BVEPjQYPzZs3v3nzpjj7
5MmTbt26IbVTpEhRtmzZ6dOn05A63fT169d9+vQpVKiQp6env7//mDFjkP50
IbwtX768QoUKqVKl8vX1rVu3rsNxTONL7ty506JFizx58uBsSEjIkiVLRowY
IRL2woULlW2UKFFCm2iTJ0+G4/Xr1+3dWsm7sLCw2rVrZ8qUiZ4aRVRMJIiO
jh40aFDRokW9vLxKliw5fPjwXbt2yXesWrUqxURb4NFEw3HevHn2oqHIn/v3
70O0ImE9PDxQqkePHv3q1SuRVvPnz4cG9Pb2hgfk4F9//SXfEfWFouHj46MU
V1yL5/r++++tpjEjeA1ia7WNaSKtihcvjqKCYta5c+d79+5ZNZsGKNVHFHUU
LRyItQ8ESiYeZOfOnSL9RbFEHqGoo0jDZcKECaKtMChjIvE3bdqETE+ZMmVQ
UBCy/sOHDyhpCCd58uRolOQVE6g7jRs3zpYtGxL5m2++Wb9+vThlHBN7U5pf
vnyJsg3Pu3fvNp87DBMLWPAyLgULXsYkLHgZp3BK8MLkg6hJly6dGACNR8F7
8eJFnFLMb0gbOM6ZM+fhw4cw6WEhozGkU7BXcapnz572bkQjPqtXr7aa1ow0
hgtxpxvgo0ePcBaWvEESWWMleGHZQh/Ze5B4FLzFihVD/CFO69evj78w3dFc
WG0iJUOGDEmTJq1ZsyYs82rVqiVKlCh79uyU2pAkmTNnhkuTJk2GDRsGkx7X
QtSIm5a38csvvyA7aGbpyJEjKQI//PAD/kISIlioG+gLNzc34zFWg0vQvqEY
0OZFAwYMqFPn/2PvvIOjuNK1PyABkpCEhBAggRDB5GwRjJYokMhgchZG5Jwx
0RgDBmMwySaaaJPBOJAzGBE/CgokbBFMNoux54barbt7697L9+w8pVPH3TM9
LZEEvM8fUz2nT58+sfv99UktcFy0aFFzxrrNtAEDBmTPnv2f//znv//7vwOc
zZ9KUGdQFsePH8cxag48o8oNGzZs1KhRQGwEiOQ/cb2Ry5Yti7+VKlVCZvbo
0QPYy2iYi8lc4Tdv3gzHQ4cOgf5u3bql8yC1ZcsWRGP69Ok4/vnnn0NDQ4GH
vXr1mjBhAhgN16II+EmBI/BBUsgo5BuYi9EwNzFzdUWbgsvkyZMR1N27d5En
T7zJK/BaxxbPDaAuXACYyElAInK4QIECuPupU6eaNGmCUx9//PEPP/xgmLyv
qjrQEgcARnUKIeOJhAeFXuKslh07dgSrzpo1C2lkHzfo22sdI3vWqFEDRYzI
jB49mt30SEW5cuU++eSTvn37su38+uuv8H/p0iXgNtpOYmIiKgPXEACY663S
U0zcAu/f//53oV3RC5MAryhLSYBXZFMCvKIMyRp4T5w48ZNLV69ePXnyZO/e
vWHm6WaYGXhh2v3kTuAL6zvC3sapmjVr6o6PHj2C/RwSEtKmTRuc/eabb9Qp
WJ5uJ/QpLVy4EB7mzp37xDYzwlDPly+fpwD/7//+DzGBcatn0Qsb0mzOWJRO
RoEXuKG+GKxcuRIu9evXx/GyZcvIGupCEEFYWBgK/Ul6t/769etVPrA4wCm8
adu2bRU8nj9/nv3yT9KHiAMEOOf6iYudQdaAMsOS10oWl6jlu7mQOMWBATaB
t1GjRihioAcvyZkzJ5A5JSXFHI1/+7d/Q00A8qjsAqzhclA/7ENQEiOpOrLR
QFAxbAIvuykBUD4+PjhAmCiXXbt2uc2Q+Ph4fTY68o092mvXruWUdkC3wkM0
Is7VtQO8zGr45zcECHS/YMGC//7v//ZUFb0Cr0Vs8XfmzJmGOQgHDhxA8vnx
xM6QZhxXr169cuXK6tTBgwdx6vvvvzcDL2qpqpbJyck2qyXZMyIiAnWAZ7me
QKFChf7zP/+TLqz/uCmTjOPvvvuOpx4/foxsRDVjz7V1TMzAC9qNi4sT2hW9
MAnwirKUBHhFNiXAK8qQrIHXrMGDB+sdUpnblsgCeAEjBneYxwyhWbNmOiV5
Bd4vvvgCHuDtyTMCXig8PBx+9Cx6YcDrNWPtAO/mzZvVKVj77LXE+2XFihU4
gKWtL9VF/fOf/wSXIRA981NTU+fPn6+AF48dPVh10zFjxhjOQqRFWFluE2tx
yY8//uhwLTmlxwTHNWrUsAm8IBqgxMKFCwEjgMQNGzYA6kNCQn755RdDNICf
uPyzzz7THQmYqJDFihUDLBtGAowbN84m8ILv4NivX7+0tDQw1LFjx0Bwhu85
FIoG7q1atTI4Zs+evUePHr169XKYpiRzZLUd4AWEwuUvf/nLuXPnECbAv0OH
DnAZPny4p6poDbzWscVxtWrV8uTJY/jWUbNmzaioqCe2gReFguOrV6/yVO/e
vVGC//jHP8zAq9ci8KbNakn21Jeq5keVIUOGKJfJkyezyv3tb3/DQcWKFfVE
ffTRR3Bcs2aN15gYgHfs2LFogziYNm3aE5HohUiAV5SlJMArsikBXlGG5LA9
pPk//uM/yJjdu3dXjs9wSDNX0O3atavBHZZk+fLlcUp1G1FehzTjFDzAWH3y
jIY0A5FwFpDoKYuol7VolR3g1SftPnEt0ktr/O9//zs7qrJlywYAGTVqFG5K
Gx5kAXegkNu48aaGQbnqphxy7FZqLTKDLC5ZsGCBgTsoDk+1A7x//etfVbcd
xdHFhsXAn6TP9nWrGTNmIJcqVKhguGTr1q02gdfpdBr21rlz5w43pDZcy9m+
btW0aVOu82YY/fvbb7/ZBF7AGv6qTuonruHBSBe8sXfSLGvgtY4tPLAT3Cx+
RNIbDm+kNHr0aFXVETfkP5DzietrTGhoKMDfUOJPUy3N60eZXVRbhlWGg86d
O+s32rFjh8M1VtxrTAzAizqQN29e8HtkZOQzWTlcJPIqAV5RlpIAr8imBHhF
GZJ94H3iYs+oqChYZcpIfobAyyWhaCXaiYz1olVwJCY/ePAAf9k5mJSUZPAG
0IC7mj/LRav0blBdhKN+/frxL9cj4qJYutjvlpycbHB/8cALM9saeNmjR0cU
7vnz56dNm9aoUaOcOXPCHVyAbLx48aLDNLdayZqyAQI4PnjwoHmIu76jsS6L
S9h3aQZeuNgEXrPAng5Xr7HBnWO8Z86caY4GapSPj48ZeLdv324TeN2qUqVK
8AkI1R1//vlnOHJ5MfMcAc6QNQAvP8vYAV63GjZsmMPzQtbWwGsdW3goWLBg
RESE2ykPT/4MvI8fP9bPpqam6lUdByVKlECN5UJVXD/KDLyeCsK6Wj498HIx
8Pfff99rTAzAC9pFc1u+fDmOURBe64xI9PQS4BVlKQnwimxKgFeUIWUIeCFu
RwtzlH+f+bZEly9fth8Zbkv05Zdfmi/htkRNmjThX643FRsba/D2ww8/wH3k
yJH8Sy52uy0RXAzbEnFRrAMHDhh8chKloSfxyYsCXjUtESKrWgxpLlmyJBdx
ArYj7eq58ejRo2rVqsH/4cOHgQAO06DNCxcudOrUCVBvbc9PmTIFx4bZiICU
xYsXe5rDa3EJ1x82D2lmzfEKvNeuXfv000/VjlrUL7/8Am/t27c3RAMJV8yi
hFfw/Pnzf/3117feeitXrlyGkQAcE+sVeP/rv/4L0UDFM3grUqRIvnz5DNmC
okEBGSa2476Ixrlz5/r06WOGU467tjmkecmSJQZviYmJ8OZ2XvMTb8BrHVsc
g9Bz5sypr46F9ILvOJbb5pDmJ+mfIxBmjx49kGn8/mYfeK2rZYaA1+2QZs7R
Xr16tdeYGIAXEXviapi1atVCTnJBOZHouUqAV5SlJMArsikBXlGGlFHgrV+/
PtzVhjXPBHhhr44YMcItd1hHBnTs7+8P9IDNrAxOHCxduhSOAQEBut1ODuUI
ZwpYx261Q4cOKUcuewvLXB/VCdQi6XN1HYqwDDBUbEvrnZebU/G8gZfr36qh
wjCbOWLZsGiV6kPkvF2OVV6zZo3jzxvlEHy4aFWzZs1wrDZbQTI7duzocE14
tLbnU1NTYbcji9T4zBs3bgQHB6sPEWZZXIL7coHozC1ahQIljqnHI7KIK+6S
TXQBS6Ojo0NDQ9VAelzFKajcWMdhWrQqKCjIZg9vmTJlEI4+i/mrr75igOYM
6dKlC05t2LBBZT6/tJw5c4ZUnulFqwYMGOD488Thn376KXfu3MWKFdPHOevy
umiVRWzxl60DWaRa67Zt2xzpqy6T/pAoc7CGqv748WNfX9+BAweiYiAV5hJ/
mmqZIeB9kj7SgwtYPXENKS9UqJCfnx/HfmQIeNUt8GRDAtWObCLR85MAryhL
SYBXZFMCvKIMKaPAm5SU5HAtH8S/ZuCtUKHCcHdavHixumNISIhyB3BFRUU5
XJvLqJWcbUbmiWuNVq4xi8s7uAROwd/w8HB9o8wnrjnCRJIaNWr06dOnbdu2
gA69e5dC22nXrh3cYbICcpFe/OLY4Von2dDz27t3byYH94VPskZYWBjsZ3NU
n/e2RFwOt0CBArjRJ598Urt27caNGxuAF0Y+aGvUqFHclghR5beLX3/9NW/e
vDly5OjateukSZPYdV6lShWmF35wFozQqVOnyZMnN2jQwCZZPEnv9yxRogTK
esiQIUDIwMBAt/34ShaXXLp0iaWWkJAwbty4Vq1a+fv7k4LtDGmeOHGiwzUL
e5RL/ETQunVrxV/6tkTfffcdMgSF26tXr/Hjx5cqVcqRvhLR3/72Nw6Y57ZE
PXv2RAyZ23aAd/fu3cAZhNyvXz+E3LRpU1Zg1WWsb0t069YtlCkyH0WGomHm
v/fee4wzx89zWyJEHpVfL3TrRoTmhpB9fHy421T37t39XDKPxjfU4Zo1a5ob
ODtMrWMLjuaHo1q1aiHhqGzIBzwxuPoxAnG41qb74osvDIunmfeqRqbhLnA8
duyYucSfplpmFHgvXryYO3duVBUkE5WK2xKpBc8zB7wqhgsXLsQxKiTqg76O
lkj0rCTAK8pSEuAV2ZQAryhDyijwcuGgNm3a8G/mVmnWBUMRZifgxTwG2Gtk
qL/+9a8wDsuVKxcQEACCg0UN9HO75AtCGDRoUMWKFeGzcOHCgKY9e/aYvcE4
B+y0bNkyf/78OXPmRP6AjpVdbfC5fft2WPWRkZEwekGIwB9Pa15ZAK/BmDfI
JvD+z//8D8xscBlsY0DHiBEjOBpZB95Dhw7Bwi9UqFBUVBToVZ+ADLsd6IeE
IMnFixcHBegLK4GIYc+XLFkSgAnWmzdv3j//+c8nNsjiiasTtk6dOsHBweCy
du3aeRouq8viEsQZaIaY4GzDhg2ROW4z1m2mobw2bNgApEIywZuxsbErV67U
B4EbRtWeP38enhEHUHbt2rX1wcN4xgLZUOIo9+rVqy9ZssRTMbltYmfOnOnc
uTMKC1WxcuXKCEptefPERFio4WBqJBmegYeAILVzEFL05ZdfIm6IIUJD4f7j
H/+wCbxPXEMXUNBvv/02Qkb4yFjzgtW6DGtJ6bIT2yeuYc9TpkypWrUqKhKq
GSKs5kekpqYiJqh+wE81ccBtVX+SvmYdikb1gWYIeC3qWEaB94nrixAeEUBd
lALCxDNB+cw08KLxFi1aNCgo6P79+zYHz4hEmZAAryhLSYBXZFMCvCKRSCQS
vU7as2ePxYr0IlGmJcArylIS4BXZlACvSCQSiUSvjf73f//3gw8+WLBgwcuO
iOg1lACvKEtJgFdkUwK8IpFIJBK9Njp27FjNmjUN+0+JRM9EAryiLCUBXpFN
CfCKRCKRSCQSibxKgFeUpSTAK7IpAV6RSCQSiUQikVcJ8IqylAR4RTYlwCsS
iUQikUgk8ioBXlGWkgCvyKYEeEUikUgkEolEXiXAK8pSEuAV2RSB9+7duw9F
IpFIJBKJRCIPSk1NhdF47dq1lx0Rkehfun37tgCvyI4IvCJRpvX22287HI79
+/e/rAhER0cjAm5PtW3bFqeWL1/+8ccf46Bfv37PLwJt2rRxexan4OH8+fN1
69bF8YgRIwwevv/+e39//zx58uzbtw9/EUnHnxUcHBwbG7t48WJz4KdOnRo3
blyVKlXgJ0eOHJGRka1atdq4caM5erlz54ZntyHgFCNpONWoUSNPFzKSyFWU
OyM5Y8YMc+DIeZxCKTzD3HYb1WcixlYXsvStt97q27cvc6BLly4OS02ePPn/
pbcIXbly5SpVqtT7779/7ty55xFzURYRmwMqwHO9i96sLJ5+IpFI9IZIgFfk
VQTetLS06yJRplSjRg1YXCCClxWBYsWKIQJuT3Xu3Bmnvv766/nz5+Ng6NCh
zy8C0KpVq8xn4Q4POEAWgWr9/PyOHDmizl67du0vf/kL/IBn6YJI4i/ouKdL
gCzYzyAvOA4bNkwP+dixYyVLloQ7gq1Tp867774Lqsrm0ujRoxGyIXpffPGF
OXpLlizhWUZS6eLFi8A0TxcykshVJIp+EAdzHUDO4xRK4Rnmtjmqz0qMLfKw
Z7ratGlToEABOCJ7kZ/Ih56a+C1Cd9m6dev19BbRsWNHOiYmJrZu3TokJASO
AwcOtBkZlos5S3ELVJjw8PDAwMAKFSp89NFHP/30E0+tXr3azOCoIW7DZyTd
Cvng9pJly5bhqqCgoNy5c5crV27atGk///yzOnv58mWkDrmHGl6oUKEWLVoc
OHBAv3zz5s21a9fGtWFhYU2bNtVbgYXKlCljqD9XrlxxG+1z587ZzEM7Ak7G
xsba8fnVV1/B55w5c6672jjuiFzKxB3tS29WFk+/zMl+wkVvpkAWMBpTUlJe
dkREon8JryEBXpEdEXj/+te/OkWiTIm8hmfOy4rAW2+9hQi4PfXee+/h1Pff
f//o0aN79+49p3rOCMDOj4iIuHXrluEsTsEDj1euXIm/9erV++OPP+gCziUc
Kf/vv/8+XL788ks9kKNHj0ZGRsL9+PHjdEFySLu9evV6+PCh8rlnzx5EgwSt
Rw+I1KpVK3PkYd/ilB5JirAQHx+PX/Ca4SoVSZQ7047fxo0bq3RRyHm4oxSe
YW6bo/qs5Da2d+/erVixItx37txpMyZuWwQwLSAgIEeOHL/++qvXmDx48KBK
lSrmQHbt2pUtWzYAY7du3YYNG8aS7d27N8+CufA3ISGhjabBgwe7vcX48ePb
mBQdHe3r63v+/Hmz/4ULFyJw3nrIkCElSpRgJyNLHL+o1XABK40YMaJ9+/bZ
s2cH2164cIGXb9y4ES758+dPSkrq0qUL7oJaeu3aNet8IMIbSoRQWbVqVUPk
79y5YycPbcriqWIQWgF8okXg+Pfff0fDtFPETyO9ot6/fx93fIaB20+46M3U
Tz/9BKPxl19+edkREYn+JTxvBXhFdiTAK3pKvRLA+wIiwFHTnTt3NpzVsQhc
0LJlS0WjsBzy5MkDy183HtwCL7Rt2za4t2jRgn8nTZqEv506dTLH59y5cz4+
PqGhoTCGVfT69u2bK1cuAxTAAyisT58+ZnZr0KABHM+cOQNIwYXgPv2sAXiB
Oc2bN9cpm3oNgNeZ/lFi6tSpNmPiqUU0adIE7idOnLCIw4oVK7p27ZovXz72
WhoCqV69OioMntj8+/DhQ4InaBp/Bw4ciGMWeiYEgyEwMHDy5MnmU7hRuEt4
X9AFr4xatWrhdtu3b8ffHTt2cMqA4UtO9+7dnS4MLF68OC7HLfSzhESzUlNT
gfPMRnOJsH9zy5YtmctDm8oc8L4YPY9mlYmEi95MCfCKspQEeEU2JcAr8ioY
satWrQLUFCxYEOxTpEiR3r17X79+nWdpl164cKFbt26RkZEFChRo1qzZ2bNn
9RAOHTqUkJCAy3Pnzl2tWrXly5fTMCYuIYSUlJSYmJiQkBBPcbh69SqMWJj3
iEDJkiUnTJigujUNFhrs4Rw5csTFxcGDAl7dKH306BFosWrVqogMbjp//nyD
AYkLx44dW6lSJT8/P6SoZ8+esMAt8ocRgFWPLMLBhg0b9LMGLEpLSwsLCwO2
IO2gV5z95ptvdP+egBc5huRny5YN0cMxSgHJvHz5stsoJSYmIpBly5ap6O3d
uxe/S5Ys0b2xB23Pnj3mSGbPnr18+fLO9I8GDMocSVWCuCRv3rxBQUGEL8qO
ZY6a06pVq8KFCyNPkIFr1qzRk7xgwYKaNWsiWKQdFQz1xPABYenSpSCv4OBg
5CqI8sCBAzylSvzbb7+NiopCnfRazz3FduPGjXAfNGiQwT2jwNuxY0e9j96t
hgwZUs8l5IYhkMePH6PyN2rUSPc/YMAAeNu8eTOOGzdujNbnNZluhdpbu3Zt
5CTuYj578uRJ3KVHjx66I54JcBw9ejSOgck4RjNXZ2/dusV+WGf6txr6pPDG
mTdvHqPt9nbMhMqVK5tLZPr06XB02w3tNQ8NunPnDmpI6dKl/f39UX/q1q2L
2sKS1QWXw4cPN23atGjRojlz5kQmN2/enB8u2BCUBg8ezObA8H/77bepU6e+
/fbbeNSUKVOmX79+nnpjPT0hna6u6uHDh1eoUCEgIAD5iUfT1q1bVbboTz9U
4Pj4eD6lixcvjqsMH7hUgHwA4nmLMBExRBIVwG3CRSKDBHhFWUoCvCKbEuAV
eRVMfRg/gYGBffr0wXG5cuXwVxneNO8rVqwIJBk4cCB7+mBAHjlyhB5WrlwJ
egI59u/fH5fDElPWL3EJBh5swujoaLdjbp2uLkvYZsBPIM/IkSPZtQQ4gj3p
/LPJB9hUtOvUengV/oB2OXsRdxw2bBgCBEyxN5MGJC4E6uIv6AmRRJQQ+fDw
cJ3jDFIRQGuCAQnPN27cUGfNWLR27VpOrmTHqyE0T8ALsXcYpj6nMaIgPEWJ
twCqOzUeB1Q2bNjQECDKBacMkZw9ezZcYBU702kFhrTbSCrgdabjc/369ZWt
7hV4QQ2w8FFknTt3RuVBDNV9oU6dOuEv+AIJ6d27N84C8/WowpFUBdsefoC9
vr6+7PtjiSME1BwU6MSJE73Wc0+xRTWAO9Db4J4h4EUmgyzy5cunjz+3kDkQ
XIhEgbzMVYJtDTXqnXfeQeZfu3YNRqlheLm1Zs2aBZRTHbgGocohh/fu3as7
Tps2DbeeMGGC08WDiJs+lJeMDAbH8ahRozI30MJtifTq1QtNEu+s27dvX758
2S2hWxSEEvKHHvAoAKi2adMGjzhUxWPHjm3atInzAja5hKcKjrNly9auXTuk
hYO38+bNe//+feQM57PjFHzysxKbAyJGnygUPLUQPqJdqlQp8KYhJhZPSAAy
LsHf8uXLo4GgPuMJw1ZgAN6dO3dyXEfbtm2RHD7EzE9UPDO5qBrgfcSIEYmJ
iZyl/uGHH+KsIeEZLS/RmyABXlGWkgCvyKYEeEVeBdPO4VrrmH9RW+AC85h/
aTTCvlKdF5zuV7t2baeroycsLAw2mzoLux12IKxH1D3iEgS7i10MbgWGypUr
V3JyMv/CUh03bpzDtZiSUzP5Nm7cqNOu0x3wsnsIoKRuh2iwJ4gGJPuq9KG5
33zzDWLbtWtXT9HTiXvu3LkO14rN6qxbLCKnREVFma1fC+DlmFUQ6KFDh9xa
s0o//vijwg0VPVjmMInVxMk7d+4gV9lxaYhktWrVVCcaMhMgAJDUKd4t8ELv
vvsu/s6bN49/vQIvSlbvE79+/TrMfj8/v9TUVII27Hx1XwAOZ2UyqoQLkLIq
SlyVP39+4ABqCEscWrp0qfcq7iG2qL2oY4gPwsTdDf6tgXf37t1nXTpz5gyi
2r17d39/fyTKZmSsYe3UqVNfffUVv0QBgpBe4BWaJCiGNAQFBQUBoNRIDAuh
SsDzkCFDbMbN6Wo1uBGqk6GnFZUK2fj555+DvoODg0niaDsO11pY8fHxeBqE
h4c3atTo4MGDmSgRCE8PlEj16tWZTKQa9RwZktE8PHfunOH7zIoVK/BkI/rp
jZqtVe/g5uj0/fv3O/88pFlvDosWLeKgblU/OevBUCGtn5DDhw9nJefHPQjV
icuqG4CXK9IzSk4XbleuXBnNwfByx1OU+ZaSkkKXo0eP4m+DBg34V4Y0i6wl
wCvKUhLgFdmUAK/Iq7gUnrK4YB6DgJRRRKty1apVyj+n7MERJtzmzZtxMHPm
TD1AsgygkvYhTFaLbi8EAj9NmzY1OGbPnp0zWGmhbdq0CbQLU1AfNGgGXhiW
5qms7IGiAVm1alUY6obesZiYmEKFCnmKoW4iqtV71NBcMxYhhgATJlxRvJJX
4N2xY4dX4D19+rTqhVfRO3bsGA6A5PSzbNky/GWPoR7JCxcusMtehQZ+d7jW
ZDZH0gC8qCfAmYCAAPYVWgPv/fv32U+t5/aECRPgCGLq1q2beaomB3MyqgA0
HCNRugcCAu7OElcRsyPG1qzY2FjDEH1PJUupyacG9enTx2b3rtMbrFWoUIFh
vv322/SD1z3+RkREbNy4EbbolStXkJOAJtRnrzdFxEJDQ21asCis1atXg9EQ
uGHKNgQMZ8TQPBcuXEjHhg0bOlz7W02aNAmcC/ItX748a7KdEjHUH4A2mvCs
WbNSU1Nv3LhBSs2TJ8/FixczlIdAdYdrMTdUIXNvuN6ob9++jYqt+q8fPXrE
QSbss/YEvJzgADpQYeKxgyehYlLK+gkZHR2Np8TNmzf1s8OGDTMDb/v27Tmm
2jDd3iBEHmnRP15t375dbykCvCJrCfCKspQEeEU2JcArsiNUEvBOUlIS0M/H
x0ef4UWr0kAEYDHCCHtU3erDDz+kfVi2bFmLWx85csRTCDrQgXa5Q8eMGTPU
tQbgHTNmjK+vr3kkMAcA04Bk74lZfn5+nmJoMBEvX74cGBgIIkhLS3O6w6Je
vXo5XDvUICcrVapkaH0WwMtctTOked26dapPSkUPVj2O33nnHfpp3LgxzGma
+nokJ06cSDo7m64PPvjAkd5lb4ikAXid6WsKweX333+3Bl52Q7dt29Ycc5QU
ahoOdMvc6frYoqKK+HuqGIcOHWKJm0eMW4ixfffdd89qssAHh+0hzSAd1HbH
n5fjtpbXteAQJtIIGkK1B9ICZODZMGCANQ1I6PQ8PROciHpoWHPJMDVVnT16
9CgHxKLeGsBN6fHjx6ii3MR50aJFcGnatKmB6cCqiHnp0qUt7uX0ALxoVoa1
0DmbODExMaN5OGLECIA5/HCGOJ4DimoNjRrIiWwcOnRovXr11CPCGniB0vny
5fNa0BZPyEmTJmXLls38eFyzZo0ZeFFX+QD09/dv0KABrj1z5oynm6Ls8Jzs
1KkTJ1YI8Frot99+sxg2/wZKgFeUpSTAK7IpAV6RV4FBgHsBAQEdOnRYtmwZ
6gzXhuVZt8DbunVrOn722Wc4mDx58lmTuIGaw1s3HEceciEsg7hkEy00wN39
+/eLFi2KeKr5tgbgHTVqFAxIMyeuX79eGZD58+cvUKDAWXfyFEOzichFaFu0
aAGcNGAR17PlzkQjR47E8dixY/VrrRet4uxFHEdFRVksWkXSWblypSF6DBxX
wVzB5YgA3VUkETLnDJqFrLt69aohkm5LkHNvZ82alQngJS8PHz6cnWgG4MVf
FVWO4dy5c6e5pMB9mVg7N6OL39oHXmZsoUKFkOdqpIS1zIH8/vvvuNYw8p+j
hc1bJlGs2MA0pwuI3FZmZDVK1lCR0DYNTRXxR0VF9UMlxAPBEI3fXNJd2ONc
s2ZNZ3ozREPWPXCzJ7RZ870yWiKozI70BbK8FoRB4P3Zs2e3bNkyNDTU4dri
mZVcbzUgRzQ3pB3Nds6cOceOHevevbtX4A0ODrazhpjFExIx8fHxMQMvPwqZ
F63Ck2Hbtm0DBw7kyH8U6wcffGC+IycdFyxYED43bNjA2dYCvAbt3bsXL52I
iAhko6+vb/HixZs2beppmTVPWrBgwVsuWa/NroRm+JY3Pb8NEfAY4S3w3LDw
9joBL5qwRVarcf4zZsygy8aNG91ePm7cOLqgTZnD4eoKOOV1IzYKBTHOJTU5
KHP+b926NWXKlHfffRcJwd0tbJhXWgK8IpsS4BV5VYUKFQC8+nuWXQk8djuk
WaHZt99+S37RAwTpzJw5E+9NO8CLQBBUTEyM7njz5k2EwOG4alEmZ/rwPLUk
r3lIM+wWpMUwpJkzgmlAgrNy5sypT9iEqT9//nwLG8BsIuIS9nAtX75cxyK8
gGBB+fv7c8Qvt5WBTauvRGS9LZEaxsxtidz2GOK9hjDz5cvH3kk9evx6MG3a
NCI5CoLuKpIc9ly3bl1DmP369dM76ayBF7YQzGnkM+w9RwaHNDNdiF6PHj0c
piHNzARGFfzlcM1o1j3A/yeffKLm8GYd4IVAf3C3M6nWbSAcLWwYRdy/f3+H
a6FvNLSPPvrIMPaVpQxG83QX1MCwsDDDys9uxTbSq1cv86xzp+sRYRjzTwit
UaMGjhExh2sxcHWWX2yCgoIsZu67LZHz588jNAM+AFod7kb4WwMvHgKIkjqL
rOjZs6f6AKW3Gi6Frdu6doDXPEQBhlnbtm3VSG/K+gmJ51WuXLkMxcpx+wbg
TU5O1lfJxl88Z0BqhgHtiA8HuqsPFFz5XIBXF5ehcCv1kdCOODbGoc2tthaM
MYc3WSyfqAtP8sIu4XloM7ZqPsLnn39u4e11At5NmzZZZHXRokXpjZMIHKbd
CtTlXB/Smb6KhSdFR0d73TU7LS2NH98criUsvCbBk/+DBw+Gh4frd8eTZPXq
1S87y5+9BHhFNiXAK/KqPHnywCpWw7rwIOU4QHKKWrRKbQBKzGndurXTZUbC
sg0JCVGTVfF04jxZnLIDvFC7du0c6SMznS5rmVvHct0bg4XGjr+vv/7a6Q54
ueIu8E1Z2pcuXUL0lAEJtuWxojAOeDZvw6rk1kRMTU3N45KORZ07d3a4duxV
3nbv3g2XUqVKqbGUboEX1guAAu4nT56kC96bHI6YlJSk27Sw4bnOKlf0Mkev
kksNGjTA5SqNjj9PjFXXKnHWsOpEswZepws84a6vBuZWnO+sUOLatWuIPN7L
MOoIAhaLVp0+fRr1EFFSny8uXLgAhuJK1FkQeGvXrg13tYuutcyBwM708fEB
QipU4ZAGLkTGYb3gX+UfNQQcmiNHDkPXqi4abAYEMwu3RjjdunXz5IHtcevW
rcpl3rx5cAEqOl0mGTdUevToEc+ydFq2bJnREkGz4ucv1V7QkLkJl3lCsTXw
ouE7XKsrKxd+H+Ai4fpnNK48r5oeKiSeaXD57rvvVFqIyXpz4CrWvXv3Vq2M
K9oZ4mn9hORXHcOiVVxCwQC8Xbp0cWjd6PAP69rPz0/lOXXixAlDznNMdWxs
LP/qCX8zheeMr68vMiF//vxgwKtXr168eBEMyNdEtmzZ1HdCr8oo8N69e3eZ
Ji4X6XBtJ6ccbW60jTvyWjsL1FNvMvDWqVNnmUm0IpyZAt4xY8aocGbNmsUN
CByWnx8pjo5DNbMJvG794xnCdVTAvHjggHO5xRuew2qY1msjAV6RTQnwiryK
+4fijQATDlYW3sIFCxaEy/jx42H70aqEhQaAGjRoEI1D+FGGPbcKAvvAYB4x
YgSHQ/OVahN4YZriuQ1DF4GDWBETXNW1a1dakgagQ5iwFYGHMPjNwAsbkgv+
VKtWbfjw4T169IAZwzgPHjzY6TIU2RNXvXp1xLZ9+/YwfsqWLWsxl9NTnwhX
hVJYRHMC9zXMCOPeOgMHDuRfsiSobYBLvXr1Qnxy5sxpNl2QLaVLl2Zuwz+s
Yrzv8OJDbnOlWbfR42RSeNNhkJGElcsOaHNiOaBa8ZpX4HWm94JZI+Tx48cD
AgIQYZQmKg+tgilTpvAs163itkRAKnBBXFycjpns6ipWrBgyqm/fvijK3Llz
E0yyIPAyOXpHp4XcBsJtXnFT1BZkFwdasFag3nIQOH5Rb5OSkthIDashGURQ
tdjTluKwW7SINiYRlmFsIPPRUuAyatQoWH2oYOAFNYQPUXK4evOHDBnCs6i0
Xvuq3JYIl5iDOTfIJe6/06xZM/PCU27zENnFng7Udu5QVq9ePYSJmKPmBwUF
sYbzKYF69emnn3K9ZWQ7nngjR45EhWRbwCXAT7brUqVKzZ49m9952BzwVuX3
GbAkwu/QoQP3tubnKa48z7hZPCFBN2XKlHGkb0sEqkUNZyswAC8HtyBXUfRD
hw7l5nF4thhSjVgVLVoU+d+pUyegbtOmTZGTiBiembyjnnBDPN8Q8VOb+XmL
/KE7l+9D0YxyCRVA+fnhhx/oyLqtA+/mzZtRgiiRFStW2LS4FCW5nQdx8+ZN
xKR///54eOJGOlPjGYinKK9FLV23bp06tXPnTuAb3ul4Pk+YMEH/GvYmA68i
VrfKBPAanvNq1wDr9wuLAE8zFr1X4PXkH/WQt1ND7/jR0uGaPfGyc/0ZS4BX
ZFMCvCKvun37Nu1nmGTx8fF4ReIFCkMLxmFycjKtSrxGYSMBl0CaeMMaTNnD
hw/jQhiKMKveeecdNU7VJvA6XZ1EMPZgCsIoBX7OmjVL9VyYeZO9SzCGzcDr
dHWpjBs3DgYhTEfQAYxAvjWA87wczWHs2LEwpP38/GAcIl3Ww1A9AS8scKI0
PMDyB7PjjXP69GmDtzt37iDTYILiJeU0reHDftIGDRrAoDXfAmmBmQ27HRmL
nEGcExMTDbupmtfUYrD6jB5Gkm9JTwsrwdpXRqAd4EW6+Ba2fsXj+dOyZUv4
RBJQHLpthgwEa6DC4BSKHgWB9Bowc/ny5bgKVRG1C+Go7WmyIPByV5oWLVrY
CdzTZr5z585FKaOsUStQ7mvWrFGg9+DBAxgzwCucQmsFFrFGWQjIDCz1umMv
+/3dSmUXyrF9+/as5GAo1EN9geLHjx8j+SipwMBAnIWxzSXdMlEiiC2QAc8T
PpGQCYButz2SbvNQH0GBOAD5o6OjwXSoPygaNVh67dq1RYoUQVqQItxx5syZ
iDayvVq1arBy8QzEQUBAwIIFC+7duweDE6fwl21ENQd20bK8cBfAjnqSGOLm
6QnpdJlzoOCKFSsi/KpVq6IC6Nmit+7169cjN0JDQ/HgAiaDZ9WbXU81It+4
ceOQkBA8rlFMaKeIJJLJAZx6wp325kG/ZlKwgCLWF/5CHb7lEj9ZoCjpDZVZ
+eGKf6pLVwEvZ7goxcTE2OloswBelHVYWJihMXbo0IEjH7hhmVL27NmdrqcH
30cGqQEeArye9PTAyxE4kJrtaxaqFp4AaJhobnaA18I/P1EaPmayz7dOnTov
O9efsQR4RTYlwCt6owTwTElJMfSxEpDN43hFIpFI9EaJMwUUDxYrVqxbt24z
Z87cu3evDp4ZAl4oLi5uxowZ3HncYbmpnJIn4L1w4YKfn5/Dtdf25MmT+VWQ
PjnF+NSpUxzJ43AN2udG5ytXrqRLs2bNALkff/wx534CnBnsmwy8ERERdU3a
vXs3vWUCeJH/m9K1ePFiwibg1GJYC4cAceqWHeC18K+KUm39hlrN5eVLlSr1
snP9GUuAV2RTAryiN0pcf8bw9ZVGiM3JlSKRSCR6jQWibNy4MedF6gJgvv/+
+xxclCHgBe1yHAV+OZcfwl2so+EJeNVskW+++YYu8MDpLb6+vpyQYp7DCzLq
3Llzly5d1Pz3hIQE+uGqaG8y8LrVmjVr6O2ZLFpVo0YNi3WSuX2DWm/TK/Ba
+7969WquXLkcrlkkhw8fRnmpiHHkxuskAV6RTQnwit4onTp1KiAgoESJEjt3
7rx3796ZM2e4g4/FgjwikUgketN069atDRs2gHCBFXhrKHLhAmUZAl59dVy1
toPiKU/yBLycGx4ZGak7qkm7XPPf7aJVQHUwMlLUokULzvGnONL+TQbemJiY
D0xSfJoJ4A0JCQl3KSwsjF9OfHx89LU1dMEU4cp1au6ANfDa8a/qgxIRuEyZ
Mi8715+xBHhFNiXAK3rTdODAgb/85S98B+G3aNGi48ePt7k7qkgkEoneND14
8GDx4sXcniA6OtqZQeDlgt4U++YgrxsGeQJersNfqVIl3ZFrjENcRMsMvCAC
9gKzqzo2NpZ7YQvwOrzN4eXqiBbAq9YZcDuHNzU1tUCBAnDMmTOnW0tj9erV
DtdiHeXTxXXCgag41nctzJD/L7/8kut7vPXWW4sWLeJCdnFxcS8715+xBHhF
NiXAK3oz9fDhw0uXLqnBXSKRSCQSzZs37y2X9G22KO4Ex0mvCni7du2qPHAJ
cTPwfvbZZ8rP7Nmz6eh2HUJdnoCXK4mBd3R31QvJhfvMwMsN+9izzFUsOAlU
gNcr8M6ZM4feDF20am0otfSxp0WrmjZtSne349jVGs5uxf2+n8a/02XwcDsz
tR/EayMBXpFNCfCKRCKRSCQSOdP3Rne45j/qSwzt2LHDx8cH7vHx8U7XYv7s
8C1TpgzB8/bt26VKlXILvMBnzpNNS0vjiligD7pYyBPwcjd5COHTRe0mDxin
ZwW8Y8aMoR928AUFBfEzL2IbGRkpwMskt2jR4rA7cddjlZnIMbVf9rlz57gU
FbRt2zY6egLexo0b093tJs7I/z1/Vv78+R2uBdNwjJJyupYf6d2797Bhw+z4
h2HPAdXDhw/nLT766CNGQO0n/tpIgFdkUwK8IpFIJBKJRE7XulIKW0C4lSpV
qlevHrd/gvz9/dWQ0bfffpuORYoUqV+/PpBTrXNlXqU5X758cXFxefPmNbCq
hTwB771799SpmjVrtmrVChjLv2qy8OnTp+nCOTtwadmyJV1Kly7drl07joum
uEfSmwy8nqTKukuXLnpREjAVLKsAPQFv69at6b5r1y47ETPPyc2ZMydcQkND
bfrnBuUsbnWMmvyys/zZS4BXZFMCvCKv8rTP7EvUo0eP+vTpEx4enitXrr17
977s6LwIqT2FX3ZEnqUcHrayFT0/vcjmbF2+b+Aer6JXQg8fPhw5cmSePHkM
+FOnTh39dXP06FHVScqzgwcPdgu8Y8aM4aYwDtfCEePGjXO7c7RBFvvwXrx4
sWHDhnrcChQowH2WqcePH1erVo2nuA/v2bNnixUrpvw3adJEzTieMmWKU4DX
EnhhJM+YMUN9r6C4LRR7gSlPwDt16lS6q3WVrfX0wHvlyhW1WRUVFxd348aN
l53lz14CvCKbEuAVedXTW8jr1q2LjY3F26FMmTJDhw6FOeHJ5/bt22vVqhUc
HFyoUKGOHTt62rSOc2oqVqw4c+ZMvH8NZ2/evNmjRw+83PF2qF+/vgUR//HH
H0uWLKlatSriBnyuV6+e2ujBLPvBZkgbNmyA5Y8kBwYGVqpUae7cuW7XtcgQ
8OIVABMrOjo6V65cyPP58+fbsa9evF4K8L7//vuezBucMvtPTk5u1apVvnz5
kJklS5aETasbe16rEOpw586dcTnKF3VbX77GkwYMGGDOFmW+6lq7dq3BW1pa
mq+vr276GiTAKxLZEUAGvIOX19KlS9FsL1++bPZz7969HTt2LF++/OTJk9bP
2OvXr2/duhVQ+Qwr/KVLl7Zs2bJy5cpjx46Z36p4j2zbtu2LL75Qm7HCz86d
O/FwOHPmTKZv+joBb0aFF+uJEyfWrFmzevXqo0eP6qibNXX8+PHlLnFm92sp
AV6RTQnwirwKT3W81jN9+bRp0ziwqn///nXr1sUxTHduZWgQrHd+qR40aBBo
N3v27CCIa9eumX1yLyG8682n4D8qKipbtmwtW7ZMSkoCaMD+X79+vdu4TZo0
iTY5EKNPnz78pK9vIZG5YO1r4cKFDtfEq27dug0ZMqREiRL427ZtW27aqAu2
CkqBi41YCz75aRdUPnTo0LJly6pv+FlNLwV4Uc3amBQTE+O2awMGg7+/f44c
OVDuI0eOJKOhmO7cuUMP1lXo4sWLHIfQrl27gQMHoqB9fHx2795tEb3z589z
XU2DO65FDTRE+8CBA7ofVJvevXsjAhbA+5TNOUMS4BWJXjO9ycAryoIS4BXZ
lACv6LkqLS0tZ86chQoV4rIYMMi7du3q+POqlUqAYqCB+pDO1SxHjx5t9mnR
3QnuwClQNv+ePn0awBIREWFGxVu3buF2IJ0HDx7Q5ezZs0CbYsWKPU2w9gUy
5coSaIZ0QUusVauWw8YCnhbiPo8jRozgX7wOAB1+fn4qmVlHWWRI86NHj6pU
qdKgQQNzH02zZs0Qyc2bN/MvKjAyVmWv1yrUvXt3h7akCWDW19e3du3abqMx
fvx4YDV3SzRkC24Ex6FDh3pKwv79+/v27ctVZK2B90VKgFckes0kwCvKUhLg
FdmUAK/Iq9QYSIWZixcvhmlNku3Vqxdh1q3mz59vGCnKxTTq1q1r8Hn37l24
gzuUC+gALgkJCQaftJOVDNhboEABA9xxvQhzt9q+ffscpo0GKlSoAEdzF5j9
YKHDhw83bdoU/I4swoXNmzc/ceKE2dvJkycRQo8ePXTHVatWucV8lfkrVqxg
lq5cuRLZlSdPnjp16ujDaMFfgCbVBcmUzps3Ly0tLUNR5d4HuNG3334bFRUV
FxeHv8j8Y8eO1a9fPygoqGrVqh9//LHqjMYBIh8bG1uwYEFEoEiRIr1797ao
G850IEJBx8fHh4SElChRAtUJcOe2oFVx//DDDziYMGGCCqdMmTIObZPE3377
LTAwsGLFik57Qhrz5s3LlVsMCg0NLV68uO6CbHS41orxWoVu3ryJfKBPpbVr
1y5YsMDcgw8hV+u5ZObEI0eOwBGtyVMSkHZeGx0dbQ28mW7OqPyTJk1CoaOk
AgICkOdTp05VnwiQIqQLiUXFQDl269YtJSVFTwhaSsOGDfPnz49qhiqHrFPA
a6hphmlu1vVKpWLmzJm4dceOHa1bh3UqRCKRtQR4RVlKArwimxLgFXmVwUJ+
9913YZSOGTNm2rRp5cuXd0uvStwcUGdSmK/h4eGwWg0+ASmcBalq4/bt2808
6HR1ZnG9jilTpmzatElfhwHWLKFM9z937lw4fvHFF4ZwLl++DEsbz0nlArs3
LCwM0TD022Yo2A0bNnBlknbt2o0aNYr8Ap4yz/cB6A0fPtwwF5gjwHWao5Rh
v3TpUhy88847yCs4giwAd7gdY/Lw4UNzVD3JOqrEkE6dOgENKlWqNGTIEI7m
jYyMbNOmTf/+/VGIcOnevTtDGzRokMO13UafPn1wzF0wGjVqZBEBDucGyCDC
gwcP5qqnoG9+cNi8efPCdAGmgHKAMmTao0ePUEYqjWpDTBWTgwcPehobYBZY
0sfHZ/ny5eZTqAYoIGS47nj48GFV562rEDjL07xga5mBl59Bdu7cyf2jLWbB
c4ayfeC12ZzRPFXpjBgxIjExEdyqwz7qCecj9OzZE0BauHBhVg8mBCWIasah
3Sho8CaKkiudKuBVNU3tHGqnXjEVqI0IsFatWgMHDrRoHV5TIRKJrCXAK8pS
EuAV2ZQAr8irDBYyTFn1srtz505oaCgc9f5EXe3bt8fZ06dP645lypSBdWru
5Pr6668DAgI4MxEsVqxYsSpVqqSkpJiD9TSkmZ3CrVu31h05NVhtDW8W2AQQ
DaZo0qQJbGMY508TLHd/0DkdwTrS1+20FtojMAH8hTt6SvLnn3/ucO2Oofwk
JycDJWDhA1Tx2GdUP/jgg7Jly8IbfgFBbsczW0dV7W5P4gNn8e/KlSvp+dat
W+xa5VKWXMFSkSOeKnBBQVuklwEiaawMoEVykxkSOVVWjYRv1aoVQmai1q1b
h1NIphpIzMVR7WQ47luzZk3wl80+PuRwfHw8Al+8eLHXKgTIgs+pU6cih1Gs
IK+YmBjkj9vuXUO2GICXyY+NjeVOoLgFwFANtNaVUeC12ZxRx1hYqj0ePXoU
fxs0aIDjbdu2OVxrhKqvT7dv30bjZULS0tKCgoJQFdXgAeQ2uJgBKuBVNc0g
63rFVCBvuSqLdeuwToVIJPIqAV5RlpIAr8imBHhFXmWwkGfOnKmf5fpInibi
1a9fH2cNiy3XqFEDjuY3JqiBHTQUzNRDhw65DdYT8HKIabdu3XRHdrT179/f
UwI5QZICm5ibQ4aChal//fp1PIT599GjR5yWa73AMiBo9erVYWFhYBkDTBmS
vGjRIhz06tVLP4u4wXHHjh3s3AQWVa9efdOmTfg7ZswY/AUrmacbW0eVGKI6
Ui9cuIC/JUuW1HmN3c0jR450unpaIbXE9LVr14AhDssFgRXyKBdUFbiAQHVv
HMUNFla3RhYxvU7X9OqoqKiPPvpI1TTwC5jIzvRqfrWwuTciuJ4bGnbt2tUA
yG6rELeiQOajdH744QfkKjjdTtezGXg58x2QCI67e/cuQuPAafOyaRkFXpvN
GXUDhauPpuAADFYPVj/DInJbt25lQpYsWeIwTUBG8+dGGwp4PQ1LsK5XTIX6
QmLdOqxTIRKJvEqAV5SlJMArsikBXpFXGSxktQIPZb3yTNu2bXHWsAlC2bJl
s2fPbt58h3bpoEGDUlJSwGJr1qwpWLDgsWPHzMF6At5z585xlKbuyB5A65Gl
IKm0tDSuR9SxY8enDPbmzZtgNFj49erVU9svWgDv0aNHOdISPOWpX1IlmdOi
582bp5/lPk2ffvopsgsHyDd9GnLfvn3hiPzMUFSJIbiWPtnN3aZNG/3yU6dO
6X3feJggeklJSTExMeyL9Aq84eHhBkcOCVZ/QaMgI9QZfUw4jC5cO2zYMBxX
rFixc+fO7KoDgONp5u/vby5EswCtJUqUsAM7qN4cq4DYAt/cdtGaqxBYEsdN
mzZVfsDg5cuXz5Ytm/VKTWbghXlpmIJ9+fLlHDlyIP6GazMKvJ6as2HzJtZz
VM4ZM2Z06tRJrY7F3OMa14ZNHkGmTMjw4cNxgPZiiEnp0qV14FU1zSyLesVU
qMCtWwf/ekqFSCTyKgFeUZaSAK/IpgR4RV5lXuVGP2sNvJx/Z+hBy58/P4jM
4PPixYvwWb16dZ0mgAxgGXOwnoCXK1/VqVNHd/zss8/guGDBAoNn0AegW78d
jqOjo8EjhjmSGQoWdB8VFQWiB0LC0gaBcqlet8CLO44dOxaeQS4w2i0G1qok
c+6wwaSnI7ILBeFwbWykn/36668VHtqPqlpKSHk2Ay8ducoQ4u/n5xcQENCh
Q4dly5bh2cJdlpye5RZ48+XLpxzPnj0bEhISGBhoHuNduXLlqlWr3rp1i33i
KM08efJ069Ztz549+rhrC3EgrtvZu7rWr1+PkIODg6dPn24YGW5dhZiBhgXJ
OYZh69at1tliZ/FqTrk1zA3PKPB6as7Xr18/qwl/hw4dym8pSMKGDRu45BpR
kQMDDMCLv0wIarhb4OWGWfqiVW4jbF2vDKmwbh04tkiFSCTyKgFeUZaSAK/I
pgi8eIKliUQeVKxYMdiEOAB74uCrr77Sz3J8cnJysttrZ82a5XDt4aJcOOYW
FqbB586dO+HeokUL3XHRokVxcXHmYN3GhIqMjPT39798+bJy4TjSzZs3G3wm
JibC/dChQ7pj6dKlAYB4eD5lsEuXLlUu7Bx0G9vBgwfjVJcuXS5dumRdCirJ
U6ZM4SX6WS5OC8q7evVq7ty5ASDmUpgwYUKGokqiHzJkCE/t2rXL4Vq0CoSi
/BMl+vTpg+MyZcoATPSawGWLLBLF/jX9kuPHj8MlJiYGx6dOnSpcuLDDNWHW
fO2gQYNQUuy8Q6WCS6NGjcDvw4cPh/u5c+fSvAlVCxirl6lZq1at8vHxqVat
2tGjR81nravQjh07cBbx0c+2adPG4Vp+yjpb0OjUX8Rw3LhxYD2DN9TJ0NBQ
vTggri2GsvMUeOaaM5gXFF+xYkVUML2k4B/HQFEcr1ixQr+EGIvb6ZVE6fz5
8xzSjHsZappB1vXKkArr1mGdCpFI5FV4VcFovHLlysuOiEj0L+FhLsArsiMC
r0hkIW50ggOOT16+fLl+lmNx9+/f7/baH3/8MTAwEAbqiRMn6MJxy+AUg0/Q
DQzgvHnzHjlyhC6nT5+GIdqvXz9zsG5jQrFPeeLEifwLTEMEuPeNwecnn3wC
n2AW5bJlyxagSqlSpZ4mWE5bBgjz7+HDhyMiIhyuTXMMPvft2+fr6wtwtlMK
KsmjR4/GARAA0MRTW7duRdaFhIQcO3aMOQyrHuY9z548eRIIBpeNGzdmKKof
f/wxjlX+43Ly6cyZM+mC27GvbfXq1fgbFBSEOIA0eXbt2rXITJw1Z5ESA0TS
6AfXct/b999/H9HmNNUePXq4vRY3xVlUrfDwcF7OnkS4VKlSxWt+AmARvaZN
m1r4QbAo4qJFi6JyuvVgXYVwOWAN0Ttw4ADPosj8/f3DwsJQty3uizDR6HQX
xAH17bvvvlMunLPcvHlzw7UoL7ij7DwFnrnmzNKPi4tTLhy8Df845lTukiVL
ogqpusEOXNzu0KFDqBuosaoGoqB5d97LUNMMsq5XhlRYtw7rVIhEIpHoVZQA
r8irCLy//PLLXZHIgwg1OFBL0+hnucrNhQsXPF0+fvx4eKhYsSIO2L0FHlFV
bsyYMTBHlyxZgmPuyFO4cOH+/fv37NmzUKFCBQoUuHLligoKPkEQ5pjogVy6
dKlgwYI5cuR47733Ro0axc6gL7/80hwI4lC1alWc5W4m3bt3B1PAloaF/DTB
ss8RmQZvgwcPzp8/f/HixeHSsmVLsLweLDteY2JiWpoEkvKUZPZhIZdgwyPO
Xbp04Ro+8+bN4yVnz54NDQ0FSoMF+vbtC1bCWSQwo1HlgrcjR47kVRwqjEJB
yK1bt05KSoqKiuJ8VXogesTGxk6cOBGxRRy45wsCx8vIbd0g8lSqVAlFgEJn
ceAvigbpwjFgB3z9iSY8r3jtrVu3kAOcQUwXgBUDRE3zWqsB9fA5e/Zs86lt
27Yhi1ADOS8YyGYuoD59+tipQqCzbNmy5cuXj1vkIDk+Pj5r1qwx3MicLSgU
3QXhINuDg4O7du06aNCgBg0asA5cvnzZcC3KC6dQdm5TlOnmfPPmTdR5pAWl
PHny5Pj4eNQrpBQpYsVjLyqqEGLIxstdrpiQuXPn4lrEAYWFgq5cuTIiz8qG
exlqmiHC1vXKkArr1uE1FSKRyFp4I/8/17DAlx0RkehfwlNdgFdkRzKHV+RV
TzOH1+ma1Th//vzatWvDqixXrhy4AKiizupTDuFz3bp11apVg8/IyEiY0Kmp
qXpQam6jISaGeYuAU1jdMKdhGzdq1Miwe4s+QfLOnTtDhw6F0QvrGjzbuHFj
gJ7buNkPFqkAo8Gbv78/0rJp06Zz587hICAggBN+VbAcfepWSKCnJPOzwIoV
KxAOTgGCUARcr1gJd+zQoQPShZysWbPm6tWr9XmmNqNqmFnJ/WcRDZQRKC93
7tzAFlyu5h3fvn0bFIxszJMnD1ACQcEnboQ4JCcnu60bTGxaWlrz5s1xVenS
pZEnXDWa9cosvfpxALaaJMstnuFy8uRJr7Was5URSfMp3IIpRRF7KiCbVcjp
mimM3EDEAIMJCQmAaPONzNlinsN78OBBYBr4EYVVoUKFESNG4F1vjrzbObz6
jTLdnJFXSB1AMiIiIjExEQkfO3Ys0oW0M/MXLVoEXkaFRCQHDBjALaFVQvbu
3duwYUOwKvKhVatWKSkp6l7mObx6hK3rlSEVXluHdSpEIpG1ZA6vKEtJ5vCK
bEqAVyR6tcRNZi1WJXpOOnDggFs6E4myjl5W6xCJ3hAJ8IqylAR4RTYlwCsS
vVqaNGnSSzHp9+7dK8AryuJ6Wa1DJHpDJMArylIS4BXZlACvSPRqacKECS/F
pN+9e7cAryiL62W1DpHoDZEAryhLSYBXZFMCvCLRq6UVK1YkJCQYtjZ+ATp5
8iTuO2fOnJedASKRR72s1iESvSES4BVlKQnwimxKgFckEolEIpFI5FUCvKIs
JQFekU0J8IpEIpFIJBJlTf3222/cgcVsqj1+/JinHj58aDgFzzzFde91wcV6
qxcLm/B1Al6Ve251//59Q06iIKwzHwfmcO7du/eyE/o6S4BXZFMCvCKRSCQS
iV4b3b59e/DgwRUrVsyTJ89bb73VunXr48eP6x4AJqNGjapWrRo8lCxZcsyY
MYpu3Mqr/2vXrr333nvlypULDg6uXLny3Llz1X5tTpdNvnTpUoSwcOFCfVc+
6NGjR+3bt1+yZInF3c+fP8/d0OrWrWs49cknn/DU9OnTDae4ETYUGRmpRwZC
OA5LIaqeIvM6Ae+mTZssMkFtVTZs2DC6LFu2zO3lPXv2pMu7777rNih/f/9a
tWodPHjQIjIZrZNXrlzp1q1b6dKlUeVQ1WfNmmUoZes6+dpIgFdkUwK8Iq9y
uyuoTZl32DTrzJkzeG6XLVs2ICAgb968VapUGTBgwOXLlw3e8DqYM2fOO++8
ExISkjNnziJFiuCqEydOuA3z8ePH+fPnx63j4uJedv49lSz2KhVRkkUikUjp
zp07eDuYoWP16tX0cOPGDbxlDGfh4okvvPpPTk4GVBo8tGvXjmcBJsWKFVPu
4eHhOn0DVMEjYBPrRIGDcK2Pjw8io7vXqVOH7oa9sy9duqRHxrBRuwAv9cKA
l0JBp6SkuI1JRuskLJ/AwECD/2bNmimkta6Tr5MEeEU2JcAr8qrnCrzr16/P
li0bALZly5bDhw/v379/7dq1cUmOHDm+//575Q1PszJlysA9NDQUDNupUycA
cjaXpkyZ8scffxiC3blzJ5/wsAS82hLPSmlpab6+vs92hdjnR3PfffddvXr1
rHsWnpOe7a2zVBZt2LAB8YFhA2ukUqVKc+fO1UfBPX78eOLEiRUrVsydOzcs
2IULF5qrLvTVV18xRZ7usmfPnuzZsxtSevPmzR49esC0RhupX7/+3r179bPn
zp1DEytQoADOIlH79u0zhLlu3brY2NigoCA0tKFDhxpGSMJo79y5c758+ZCu
WrVqIWfs31ppwIABmX6SiEQ2NXLkSD78J0yYADrbtWsXP36ibrNWJyUl0cOc
OXNSU1O5sjf06aefug3Qq//q1auzF2/z5s1oKR06dKAHtjJgCI7btm27bdu2
vn374hhPAF6I6KFBzZo1y2ui5s2bxzAXLVqkHNHu8IKDY0JCgsH/2LFjddLB
3fWziOSZdA0cOJB+Ro8erRyvX7/uKSavJfACVM+YBPOY3jIBvCtWrFDhoBqw
hkBTp051G5OM1skKFSrw4wnMJED0uHHj6H/lypX0YF0nXycJ8IpsSoBX5FVP
A7yPHj26d++epwp2//59PJDx0EYl1N3xDAcC582blxcihJIlSyIavXr10u1w
mP0RERFwX7x4sSHkbt26wT0+Pt7ilfFsBXLp3bu341lviaJozjonM6GX2B/6
bG+ddbIIAAv/YWFhqH5DhgwpUaIETU1SLX4bN24Mlxo1asDILFWqFI4HDx5s
COTBgwf81O8JeGFqFi5c2BCxa9euRUVFZcuWDVQL2wlk6uvru379ep7Fcx6I
nStXLmBp//79Q0JC4POHH35Ql0+bNo09GjjL3h/wOPKTZy9evIhGisvbtWuH
mCOBMLN3795t59ZK58+fDw4OFuAVPW+x07NIkSLKReEDx5SGhoayhisP0dHR
cKlatarbAK39gyYYuNqy7fbt22gOcEFz4+V4nT1+/Fi/9u7duzgGhpQtW1ad
shBaPQLBhY0aNVKOn3/+OW+9du1a3fPvv//O3j28N2NiYnCAxotYuQ35gw8+
YCCffPKJnex9LYFXEatbZQJ4YZzoPjds2ED3xMREt7fIUJ1EETA0PLeVY8WK
FeGCyu+0USdfJwnwimxKgFfkVU8DvNaCyY3A+/btaz4F0xqnjhw5guNJkybh
uFOnTmZv586dg+2Nl4U+8gdQHBQUVKBAgdOnT+PCd95557nmz/79+5EEIvnz
A95nHu3XD3hfbjxR68JdUv0CeK7WqlULIWzfvt2Z3m+bkJDAUWdgc45SOHPm
DP2vWLGia9euAEZWJLcpAjUrm0qP2IABA3T7BzXf398/IiKCtjS//yir+Mcf
f8TfmjVr8m9aWhps6UKFCrFbB7dANODhs88+o4fu3bvj77Zt2/gX6AqkrV27
tp1bQ+PHjwcLw+R+fk8SkUhp4MCBaCN665g+fTqbDN44sPxVp57y0KpVK7j4
+fmZQ/Pqf9euXfQAclQeOIaZ/MLvV8uXL0eL+Oabb3LkyIE2Dve9e/cySjbT
xZvicoWuTZo04agngwmHpsooTZ48ec6cOTxWzdkgAd4XALyqg37GjBnm8DNa
J2Fy0L8apQ+1bt0aLoGBgU4bdfJ1kgCvyKYEeEVeRTMVVm58fHxISEiJEiV6
9eqlr7wBC3np0qWw7YODg8PCwvAWPnDgAE9ZIwMHHsNyNn/ihhGenJyMFwEC
L1KkCN7y5lm9VGJiouFNtG7dOrj0798fx4g5jj1dq0RvYJbhw4eDlGGcw2Xq
1KkqYt9//z2SX7BgQZwqXrw4vN25c4encOt6LvGTrDXw4hZjx46tVKkSXmSR
kZF4Uaampqqzu3fvbtiwYf78+RGHpk2b7tu3z+14XdwaB6VLlwZZIMPr1q37
7bffur3d4cOHEU7RokVBNAizefPmnPWMy/UBb16ZDhGAN0QmJSUlJiYG1QCO
d+/eRSYjGgEBAZUrV54wYYLqE3S6ehlmzZr19ttv586dG3UG0ESe8nrrVzSL
Tp48af5+vmrVKodrrKAz/RuOPlD/008/dbgGXvLvkCFDWJHy5MnjCXgXL16c
PXt2jiXQo4SYI7sePHigXGj/sB+WJre+WChqMkqNx/PnzzeExi9FXCHn5s2b
qPOKjimw84IFC9hzbX1rqH79+kyXAK/oxQs1k9Nh8HrCY+HcuXNs0eBi5Yef
dAxthPLqH9DBY7wElQe2OCCG0/WaQ5t1uMaX0ueSJUvweKxQoUKbNm3sJ2Tj
xo28fMWKFU7XFzN+ROrTp4/BJ1mJL74bN274+vriGM9tt8EK8PIzQpBJGzZs
oLdMAG/Xrl3HpSspKQmhwRH10G0/e0brJF/HEOwQuvz22280P2zWyddJArwi
mxLgFXmVwzVKExYyyGLw4MFAGIdr9KN6DtP8rlq1Kh6/ePLDrsAbdsuWLU5v
wAtTJCoqyuEafga6xGPfPKWRg3PKlSvnKXqwvQ1faFu2bAkXTiRElAwjf9yK
wIu3VfXq1WEAjBkzhh1thBFYLOxHbtu2LXIALIZTMCoMgRCRLIAXKMdrmzRp
AghCCDCEwsPDkUana0BstmzZOHAUd0F+AsE4+0ynOWQREQ8FAW8wmQIDA/G+
PnbsmOF2HEaFMBHgqFGjSBx58+a9f//++fPnhw4d6nCtYoG3Nv5a5w/fsNWq
VcNN8WJFzFF2zLS4uDhkMmsF0EaVYOfOnVlwsBZatGiBY5DRtWvXrG/96mYR
PCAfDNNXOVSYtQiRQS3Sp/SeOXOGppEhKE991rgFKBXZYmhWKAt+jtA9z507
F45ffPEFjhMSEnD8448/8hSMLuRb8eLF+ZfmnE7iyEDkOQeFfvPNN9ZN2PrW
ugR4RS9YZ8+eLVu2LNv4qlWr4LJv3z6ygP5S6N+/Px35nNHl1T8/Wzn+vDBU
bGwsXPhhEDp69CieQiBcPAk5/x1XoS1zCaPk5OTly5fjLWPeWkgXHh14ESNY
BOJMf/E50sdBKeEZi2ed3iqbNm1Kn6dPnzYHK8DrSWvWrKG3Z7JoFaqEp1Hl
Ga2TEEeq4zE+ceJE1AROlqHw4rBTJ18bCfCKbEqAV+RVfHK+9957ZJnff/+9
U6dOygbmuCzQjVoeMDU1FQwCaxn+vQ4KvXTpUrNmzfgJGsKF4AuYymqI8qFD
h9zSpRLHZ+KBz794pwCIIiIiGJ8DBw7gLBjKOo1kNxgSqkuX76AqVargGJyL
4/379/MU/FSuXBlRNTQcr8A7efJkx59nHIMmYIkBedLS0oKCgvz9/dW604g/
XqPqFaZykl+DdbRcsWIFGO3DDz803I7gr/c5cggcE5Kh8brqk3JiYiIzlmkZ
OHAgowFjjO9cTt5krQAgKxNu6tSpjvRud4tbv7pZZBaermgFgFzCcsGCBTmU
Uen69euMp+FCt8CLyobaCMZ/9OiRIWLctaR169a6f9rDyE+ny+wH3sLehv2z
Z8+euLg4xGTXrl302b59e7MxXKZMGVhTyEA0RodrrRXkEpITGBgIWwv2OfPW
6611CfCKXqRWrlyZO3duGvmqt44jMaBJkyYpn2pJH8OeQXb8L126lMebN29W
HtinXLhwYbcRQ8PPkycPSBNtWUekYsWK4XYWKSIE4RmI9yObLW5k8DNjxgyG
ppa3Umg8ZMgQc5gCvA7XTJNvTMIbh94yAbzVq1ePd6lhw4b8qg+hyNxGI6N1
0ulapRlvNB2o8X5xuFbpxGsxE3Xy1ZUAr8imBHhFXqWAQrmw15XLKeAdimND
3xn7VVG7bCIDHukwSEBPXHjB4epT5pdwr8DL4ZdqKQ+wkkMbGoSHP3sAAUEW
ESDw6qkA1Sr7nKbF4MGDudKIJ3kFXuRYcHCwoRcb+FCoUKElS5bg2qFDh+qn
1EIlOs0RMcLDwxFbt2v8KoH9YVnhdcC/MK44pZR9eZkAXkRGASzSAhd9Mc/d
u3fDpUuXLjhm3+i6devUWUQjICAAr37rW7+6WaQLN129ejXqMFBdwXuOHDnU
Phfqdgi/fPnyhsvdAi8SDkOX7GyIGD/OdOvWTffPnll+YXBqRi+lLwwL4jb3
I9SoUQOOyF5+qYAdhfB/+OEH5AwHTHKctp1bKwnwil6M8KDmPHQILVqf0qK+
3YFilCO3BsiVK5c5KK/+1YRZ/cnPWQme5kv26NGjePHisLu4ljJIBJTKiQAl
S5a0SNfRo0fVvfCcxMFHH31k8FO6dGmHB+FVqI8woQR4Hd7m8Kp1vw0r9qul
qJKSkujidg4v8pwGRvbs2d1uM5TROqmuQsQA1M2aNUNM+Fk+MjLSmak6+epK
gFdkUwK8Iq8iOxgcYcwHBQXhQB9LYxBYNRPIcOrUKU7LzZs3L3jE65BmzthV
nXQclYoX09l0cTytdRzUHF5DwmmfIxAu+ADiaNCgwaRJk9RCQ7q8Ai+7G8zy
8/PjJwKdEClaL4YJqiNGjOCksBIlSoA1wDIK2Qy6efPmihUrwErIFnX3TANv
2bJllUtISAjMJ8O9HOlLhDHPDR8ZUIiINjLZ4tavbhYpwSjlAO9KlSqpUQEQ
ssvQjm7cuOEwjQd2ugNeznZfuHAh/xoixh5tfcETZ3q7oB/20nbo0OEnl/gB
Z/78+fRJS8lQpVHWyECYajNnzsTZpk2bqlOPHz8GpIPlEUOvt9YlwCt6AUJL
5+caaPz48WroEYXay2YOUlCOfP7jWWEOzat/NQETzxye5Th/h2nkA3XkyBG0
na1bt+K4cuXK8AZbnac4TlWteudWqp+On6HQnPWzajkjTwLiGQIU4PUKvIsW
LaI3AKbu/uGHH9JdLUXladEqbk3l8PDhPaN18o8//rjikj5GmpsCtGzZ0pnx
OvlKS4BXZFMCvCKvcgu8+fLloyOtZRjkZ03CM9YaGWAYJyQkqNVfdbVp08bh
moGCZ3tUVJTFolW9evVypG8/h3cx1943C68Pi84+vlzMCVf2OdoI4jlw4ECu
/IC76OsfUl6Bl0stnXUnfuo30xwnoJk3mb148eLs2bPxduN2BuDxq1evGq4F
wiDrgC1AuTlz5hw7dozrYGQaeHU0MwMvl5rk0ihugZfd93g9Wdz61c0ip8sO
QSQRGmwPxNNgacO49fX11ddno1liHudmAF5QJ/KkWrVqiC2zgqvO9unTB8fX
r1+/e/euI31DCqXPPvsMjgsWLMAx0ujn56eQHw0zV65camzboEGD4FONcFYF
UbBgQZUJhiVeuXcnjHavt9YlwCt6AVIEV7p06Xl/Fpe/69Kli8M1XuWbb75B
I+XnIIc2CL9WrVp4jsXFxfGvV//cFBXtBe0RbwqOb4G4kIUuPCLQkNUEHNxC
QejNmze5yx4OLFLHZQGo+Ph4w1m10tH8+fMPa1JjXDn/1212vcnA+84778xz
p2vXrjldrwnudxwQEIDSB2mmpKTA5GCfqcP1bZ8BegJe1S9w/PhxtzHJUJ1E
LeJs7pIlS+I1gXeKGsfODynOjNTJV10CvCKbEuAVeRWfk3p/E572jvS+PGKI
AVrxUMXb0+sc3hUrVuAs3tHmU9xI5ejRo870bYk6duxo9oaHOd5EoG8ONmZv
lFr2VqlcuXIO07hrXdbAm5ycrN5o/Ovv7w94MfQIewVevLPwRtO/yiKLYJms
X79++fLlDtN43Vu3bnEdTp3m7ty5g5epKg7EgfNYURCG23G/mI0bNyqXZwi8
HNJ848YN5aJmczs9DGnOnTs3Icvi1q9uFkHjxo1zuHaL1pcsVqJJo69qxY4D
81xXA/Ai/hZdNowekBbGmF4h0V5wdt++fTjmLl36LfCXIzSc6bt56tPHLly4
4EifXAxrGccTJ040p4UNyvrWugR4RS9AFmN62a5//PFHtWAynx4O11hQBXGc
JREaGsq/Xv2vWbNG3YLXOlzbfpk/sS5evBghqD7cHTt28Ast8MTPz89hmh1g
1tWrVzl2xaGtqkThJciOwvz58xs2PkBMChUq5HAtR6w/tJ0CvJbC048+9e8M
Bundvp6Al0v0my0lpYzWSRpFlLqwevXq6iur/Tr5qkuAV2RTArwir+KjUi1a
hTcpDdpPP/3U6ZpCi/cv8Edt0wNrGbY0B+dYIwO4JiQkBJfD5Nafw8ePH8eL
W004unfvHne5TUpK0u1qvFP4SVytB0sKu3jxouFGHHpkYCVd1sBL8171V3IL
ANgn+i48ThvAy/1fVE4602dWTp06lcuY2FmR6dKlSw7X0sEqWE5b1oGFat68
OdzVKiiwc7h6BidHM0AzA7qVGXhBQHAZNGiQypP4+HgFuSgavn9VedGs4p7L
Frd+dbMIdiCMSQt7ldNdESsmDU/dmJgYXGJejdnrzsLmZsXFvtQo5cuXLwcH
B5crV473qlu3rk6gZFi1ke79+/fhuUSJEmqKOvt8WZQIoXLlygULFlRLuOCV
AcJVi7ZZ31qXAK/oBQiPncoepBY0PnjwIMcPEwcSEhLYl6eHwG257Ph3ukYr
cdoLhNcfnmDmJZfxvsuXLx8nvyuBgPDawnMAT57x48fbMcZ69OiB6AFeDJ63
b9/OZE6ZMsV81fTp03n2q6++0t3x9qS7vqmrhV4n4MV7qrKl9KX8du3ahSez
gkdfX99q1apxj3UlwC8vVC8patWqVXR3+3mfymidnDFjBgcv0X/nzp0Ny1vZ
qZOvgQR4RTYlwCvyKj4w8VKGhTxkyBA+k7laLD1wciUerQMGDADRgGGBq4QI
r31kmzZt4hukbNmybdq0SUxMrFevHhAYbxO1j6fTtZgzv9vnzZsXKI1nO2cR
wk5QS+9yqaLY2FjzXa5cuQLPhQoVMowyVbIGXrzUeGsQN6iZ/cW9e/c2+HcL
vHhL5sqVi1slggphpZAER4wY0b59eyQTCSdoAMrUnjvIZ+RwkSJFODFHpzkk
gTPUkFGjRo1CpoEB8TpDQ+YdEQKnPLMDEUmAHYUXcYECBRgaLjlz5gzMHhyX
KlVq9uzZeNXq8TTLDLwPHjxgaI0aNUJaOGs1Li5OYQ6/iqCYUD04whnQxEWu
LG796mYRx/Ei2m1M4txb5AyqrsM1qhCVlqtjqS8GujIBvMjYiIgINCU0QKSl
aNGi8PD111/zLAgX2QhK7dWrFzwgK9DE9PnF/BxRpUoVHHB1UBSoWt9my5Yt
yPbw8HBcC6sJPOvj46MmA1rf2m2DEomygtLS0kA0hu+WT+P/8uXLeMh46kTD
QwxPFbfm1ivU7/Y6AW8mhJcLrBFYzoY+9GelDNVJVBtEJjk52bxXr5J1nXwN
JMArsikBXpFXEXjxHG7evHmePHkAnmANwxJAy5cvhwHPkZMtW7Y8deoU3e0M
CkUNhB1evHhxPz+/wMBAkAj+KjZRevjwIbgDIAN7G/xSqVIl0LG+vgd5U+3F
YFCdOnXMA42UvM7hXb9+PW4dGhqKSJYpU2b69OnmVuMWeL///nt2WfIvV+ZE
5BEO0GDAgAH6Qsd79+4FEyEP8+fP36pVq5SUFMU+ek6iLIBd0dHR4C94BkDp
35NVtPGOmzlzJjIW2VWtWjUQyrlz53AA8FmwYAFekc2aNcMp/IU3QzwNMgOv
02W/9evXDzzI4pg0aZK+BCgMAwQLJkX4oMgePXqooXTWt35Fs4jLlbuVuuT+
/fvsAkA9B9cjTLdWUyaA1+n6KNS1a1ekBbW0UaNG+oYUTteoiYSEBEBrSEhI
vXr1wO/6WY4br127NpowGuDAgQMNnQXbtm2Lj4/H5ch2hMO5BjZv7bZBiUSi
V1FvOPCKspoEeEU2JcArEolEIpFIJPIqAV5RlpIAr8imBHhFIpFIJBKJRF4l
wCvKUhLgFdmUAK9IJBKJRCKRyKsEeEVZSgK8IpsS4BWJRCKRSCQSeZUAryhL
SYBXZFMCvCKRSCQSiUQirxLgFWUpCfCKbEqAVyQSiUQikUjkVQK8oiwlAV6R
TQnwikQikUgkEom8SoBXlKUkwCuyKQLvlStXUkWiF6iUlJSVK1fWr1+/SJEi
OXPmLFCgQJUqVcaNG3f+/HmDzx9//LFv374lS5bkdqilSpXq06fPiRMn3AbL
nVKhkSNHPvM4d+zYESGvXbv2OeXJp59+ivAHDRpk/xJEBpcgYs8pSlCxYsVw
i+cX/ouXZJpIJBJlThcvXoTReOnSpZcdEZHoX7p8+bIAr8iOCLwi0QtW165d
QQR58uRp2bJlUlJS27ZtixcvDheQ7/79+5W3JUuWBAYGwj0iIqJhw4ZxcXEF
CxbE39y5c3/++efmYBEUgReA/MzjjEgi5OXLlz/DMEeNGlWjRo2NGzfi+OOP
P0b4/fr1s385IoNLELFnnlil6Oho3OL5hZ9RLVu2DDk2bdq0TIcgmZYhlSpV
yiKvzp07V6tWLXNi58yZ8/bbb6Odol0nJiaeOnWK7qjeDg9SNX/Pnj3NmjUr
VKhQrly5ePmRI0ee/tYUHinVq1cPDg6OjIxMSEjYtGmT/VRv2bIFT6HQ0NCc
OXMWLVq0e/fubiMmEolEohcpAV6RVxF47969+1AkelHasWMHzNSaNWvevHlT
Of7666+TJk2Ce+PGjely9OhRPz8/2JawYHFWecNfOMIYhgc9WJwqUqRIQEAA
QkY4x48ff7bRvn379o0bN+7fv/8Mw+zRoweiigzB8dKlS3E8evTojOYkAnm2
KdWFMkKqn1/4GVUmcskgyTT74scBi7wCRBNXdccpU6bABdTfp0+f2rVr4zgm
JoZvmZUrV7Y2CXwKPwsWLICHn376KSwsLEeOHGDe4cOH/+Uvf8Gp8uXL37lz
5ylvDc2aNYtfzwDX3bp18/f3BxefOHHCTqoPHToE/4zYsGHDyNpg6mvXrr3s
4hWJXpxSU1NhNEq1F2URwTAT4BXZkczhFb14vf/++7AV161bZ3D/448/ChQo
EBgY+Pvvv+NvvXr14G3x4sXmEBYtWoRTcXFxuuP+/fvZczdv3jwcjBkz5mUn
1Lvee+89RPX777/H8ZdffoljZI79yzmEG4G87HS8OGUilwySTPMq2LRgOsKm
RV4dO3YsZ86c9KMc09LS4FioUKHr1687XY2awzk+++wzt4E8evSoSpUqDRo0
YKsfOXKk/nDA5Z07d4bLsmXLnvLWSJSfn1/hwoVv3rxJ/0Bd+O/SpYudVINz
4bh582YVsREjRsAFvy+5dEWiFyiZwyvKUpI5vCKbEuAVeRVMu1WrVsXGxhYs
WDBXrlxFihTp3bs3TUqnhmwg05IlS9Lg7NWrl/JgFlAUl4wdO9Z8ChUyOTn5
t99+u3TpEvyULl368ePHZm/wgHvBw5UrV5Rj37594bJ+/fqrV6/ioFixYoi5
RbroDfYtjOf69esHBQVVrVr1448/Vle99dZb8ACDvEOHDkhXq1atFJzqevDg
waRJk3BtSEhIQEBAmTJlpk6dSutdBWK4BC5wV6Y1hQwhlezatQuwHxoaGhYW
Fh8fj+ipGw0fPrxChQq4C24H/1u3blWWOW/08OFD+ClQoABKCi6IicpAxByh
sRCLFy8Ob3fu3DFE7Oeff2aepKSkxMTEIEUq/omJiTj47rvvRo8ejToQERHR
smXLCxcu6JcfOnQoISEBt8idO3e1atWWL1/utgi8RhVXLV26tFatWsHBwciE
Jk2aHDhwwJn+qUTJDsFJpmUi006ePFnPpcqVK3sC3vv376MNAlRLlCih1/D5
8+cb7nL69Gm41K1b1+294DNv3rxojPyLloiSUs0H+uqrr3D5kCFDnvLWeIjh
ePLkyfrd27Rpg6bNMrVONdojKoDuAr7mSBWv+SkSvTYS4BVlKQnwimxKgFfk
VYMGDYJdFxgY2KdPHxyXK1cOfxs1asSzBN533303KioKJDtt2rTy5ctb2LdO
l2Hp4+MDPzDvv/jiC/CC2Q8HYfbr189TIIgMPKxcuZJ/gcD58uUDMuDph7/g
Dpw9fPiwRboAy/ADmzkyMhJ2b//+/YEkcOnevTs9EDEGDhwIhIEZ3L59ezPw
4r4ckFm0aNERI0YAcAAj+Pvhhx/qgRhuTeDdv39/w4YNcTxlypRNmzYtWLAA
xwRn3PSjjz5iHzcs7Rs3bty7d69UqVIc3omznTp1Ahcwwjq7oSCqV6/+wQcf
oCyQIXCZMGECzu7cuRN5jqDatm07ePDgSpUq4RQQ3hAxshvKBYmKjo6GBxX/
bt264aB27drIMUSgefPm+BsUFJScnMxrURbZs2dHZiInUU84KRugZ85566hC
vXv3ZlYA7nr27AmC8/X13bJly/nz54cOHYpT7dq1Q47hr3XVlUzLRKbpsugN
xy0AqrB+DTV82LBhhmYCEg8PD0e2mwM5cuQIchiMr1wQYdWLSs2ePRsBTp8+
/SlvjQaFswsXLtQDR6HAURWHp1Q/fvwYuYqHku4NjxfrB51I9PpJgFeUpSTA
K7IpAV6RV8G25GJN/IvaApecOXPyL4G3cOHC6g14584dMAIczX1hSt999x0s
c9XrVLJkyaSkpG3btqnuKgAj3OfMmeMpBE7HU2bw9u3b8RdMyr8gArKqRbrY
iaxT861bt8qUKaNImeZ0xYoV79696/zz8GMlmMoMJCUlhS5Hjx7F3wYNGvCv
BfA63Q1pBv4gBHqDuZ6QkABHcArsbRx07twZiM2zZ86cAeAb2K1FixYqD/ft
2weXKlWq4JgrbgGxeQp+KleunD9/fkPbJ7tBIHf2sqn4d+nSBQeAPlAkPYMd
OOeaWRcWFga6VGcfPnwIYM+WLRseMobkW0d17969/5+9L4+v6VrfPySIzIMx
JCGuGIOYEqm5xoipKCKhiCHUPBQxTzXHUFpaQ4K0ZmouQYgQqtwS35puDNFW
ce5tb3t7b29783t++/1kfZa9z9lnZ0Do+/xxPvusvfZa73rXu9Z+n70mKqkY
5ktPT4eooC1QSI5m57LScqE0GdYIb3x8PMK3bNmitXD6LnTu3Dk5PpoVegzV
yDX+BgcHox+Qx3MF0KDQIcybN8/FxaV69erQVR6zpi4iKipK3EK+0B4Cd+/e
baTUMjIzM1u3bm1tzQWD8bqCCS+jQIEJL8MgmPAybOKWAkEZbt68STsn01+i
bPBL5UdCQkIQaHHoVsbXX3+9Zs2aPn36+Pj4EGUANUCg2QDhpUN8xEBqz549
hRsMpKWl4W+ZMmUs+tKES5cuEdeW/XAaWR4zZow5250WDNci4X306BGUc/v2
bRFCfvUbb7xBf3NKeNu3by/HpHnOuOXn5we/XSw/JNCQlszdxPxns0LQREbE
BYYPH07k3RqIuyEjMC+V/HQq0/r160Vk6Nbf3x/sDJE/++wzrRmAsFhkBPqi
vvvuu6q75mzqiv4qR9yNlZYLpcmwSP2uXr3q7u7er18/VWEJzZs3V601ABo2
bIhAlZNM50MdOHDAYtZDhw6lPsHLy+v48eN5zxrqQr9kZ2e3dOlS/L1y5Upk
ZCRlkZCQYLPUMpKSkmi4PyIiQqeHYTBePzDhZRQoMOFlGAQTXoYRwEji4uIG
DBhQr149mo2sIrzw0uX4tDrVJuEVAOXctWtXkyZN8FSzZs3MBqY00/kmNO78
8OFDJycnMI7k5OS0bJQtWxYR9u/fby2FixcvIkLXrl3lwNTUVAR27tzZnO1O
CzJrkfASjh49OnfuXJBuWlmcF8ILkiLHpAWYa9asAUWqVq2aKp2NGzeaNMtR
LWYEhdDhsMWLF2/RokVsbOz58+e1BSHuJmck5O/WrRsukI4cn9Y1nzt3bs6c
OSYrEB8lVGlaE7Vt27bWkgLxMc7dYBWstJwqTQWLk3th25UqVcrMzFQVlkDD
4ipFQTmFCxcWH83MCvFHIqKZWAQKe/jwYVRBsWLFzp49m/es0ZZBlh0cHBDN
3t4eFUEfymixs06p5bqmzyAlS5ZEq9TfJYDBeP3AhJdRoMCEl2EQTHgZNhEf
Hw8X0dHRsUePHh999BFsRt4rxiIN1Ce8cLzbtGmTnp6uCocdent7wztFD6a/
aRUCae4x7XWzYcMGa96+zjANHGMt4aXAsLAws8adtkZ4aYFkmTJlYmJitm7d
mpKSok944cbrEF4VKyHCC7Xb2dlpuRtN75S5myqCyIjUu2PHDghJ0zhBBqdP
n66KL/ZfEiEi2S5dumi5GwUmJycvW7bMpOwIlKaBdvsyfVGJtuzZs0ebFDis
ce6G8rLScqo0FbTUj2ZWwCBF+rQmmq7N2Uv+VeO2pUqVQgORQ2ggW169a1Y+
fIGZqpr86tWrTcq65vzKGlz76tWr9OmAvkjQrBKdUhMSEhLc3NxcXV3nzJkD
reZUmYxXCDDCo0ePLl++fN68eRs3bkRrza+U8YKAgel8ibUJmOvnCu7evfvi
NfM6Ed7bt29/bh3iOxh8HgpRuTTi8QsXLlBIamqqNh3UNcJV3yqtAR0gsjNe
szbjo6e6dOkS7W3yWoIJL8MgmPAybKJmzZogvHJXT8NedJ0Lwktb16rOGSH4
+fnBnySPl7ZsWrlypTYaHUv05ptv0t/27dvj78GDB+U4N27cAN/x9PR89OiR
RTFo+W1AQIA8TLNu3ToEjhw50myM8OKVBxIUFBQkRq+uXbumJbzyvEf4Tjkl
vLjl7+9frFgx1excmrNqhLuhsGJeKP0tXry4vb296i2sw906duxoenZ2LvRG
nz4yMzP37t2rHZ4+c+YM3EU4SCqp9EWlWdyqOQPbtm1buHBhTpejstJyoTQZ
WupH2rMGRPjggw9wERsbKx6htQPNmzeXU27Xrp27u7tKkxkZGYjZs2dPORA0
E4Fjx47NY9b3799HBJkOo58pW7ast7e3PPRstkJ4d+7ciapv1KgRPKucqpHx
amHVqlWwCpWB4T2YmJiYo3TQ9HYokNca0NLvwoUL51o82qHCJG0v8CLxOhHe
Tz/9VKdLqVChAkWjVTBap0U8LhZZ0MdMi0B3t2bNGh1hrl692rJlS5p/AqcC
7o1qP/+cxk9KSqpTpw5NycN7MCIi4vWoNRWY8DIMggkvwybc3Ny8vLzEsMux
Y8fwskYXSjwxF4QXzJSGRFUzCeFmmLKnE5uVL+HozNFRx8XFCU6Ki6VLlyIQ
1CM1NRUhoDNFihTx9fXVLqZr1aoVEoTbb1GM06dP05tIbFp19+7datWqIeTI
kSNmY4SXEgGvESE0TzU0NJT+0lo/wZsgJM1olQkviI/ZFuElRqPaf4kWUxvh
brR7kvgQjUT8/PygXtXXAB3uRjsMozhiQinVF23PBebi4+ODd7rY8BavoaCg
IFdXV+2XbX1Rz507BwPDs2LTM7zHXVxc6PsGacnimVZasNJyoTQZRrZvUgmG
kkJ+kHqx8JkGXuVzt0Fs4Yb16NFDm1rVqlWhEDH9A+2dBq83b96cx6zRg5Us
WRLdjtj/ig7s1s4e15YaYlSvXr1y5coGh2kYry6GDBkiSIqjo2OVKlXQjugv
aIV4WRgBegx6UN6ZgQlvwYFgrOiOHDVAk6douSC8NCmOIMwJucBhsChJWloa
vCyKRgc90IX2y6fB+Nu3b6eTymFptJ+/SdnDX/Vx7zUAE16GQTDhZdgEbbzT
pEmTWbNmwQn09PSE04iQSZMm3b59OxeEFxg7dix1xcHBwREREWAWRAy9vb1v
3Lghou3Zs4ecDfDZzgpoeyt04Lt27aI4dJrPxIkTtbnQcC3ktygDbadcvnx5
8OVu3boNHToUdAYhffr0oQg6hHfKlCkg3Rs2bEDbqVChAhyhnj17gurCsfH3
90e54Hh/8MEHiAnBTMqKP1BXuNYhISEtW7YUPIV25oELtFiBDuGFM0+zuOmE
HWjMycmJkjLC3WgrLdTdgAEDRowYQWdLDRw4kKKJ4uhwt3bt2lFFIAQ8gsYu
QR5TUlIo5tatW6FJNzc3KHD06NE0jklKAA4cOIAsoqOjbYpqzh5GrFixIvQz
aNAgMCAUljKiU1kDAgIWLFhw7NgxOVktWGm5UJqMXBBec7ZDXqdOHVyA1eK6
bt26sqNF21XFxcVpU4NCaDQEPiQUQtvfNWvWzOLeUDnNmg7qRQtFbaIu0Gyh
E+1sQG2pL1y4QLrtqoH+VvCMVwtr164lagA2AVMkq3v69Cl4Lr2J0HByNN3U
JuF9/PixtTlIZqUH0zIUFeGFkDopmJXT2WyKqi+GjNeS8ArGahG5ILyHDh0S
0cDIqC+y5qiYs+cCgaLSKMCOHTvQO5GXlbv4NA0PrhqdH0G7gAKw6pet9XwG
E16GQTDhZdgE3u9w+NFzwi3Hyxq+X3x8PFxNOk40d4QX2Lt3b6dOnZAsHH4Q
2KCgoNjYWO1rFPwXnnyVKlWKFy8O6gGCjFeGfOBR48aNkRfMWJsFvAVHR0dx
OK8KdIwm5EdxkDui1a5de968ecK11iG8goeaFWe4bdu2cNHLli3bt29fyDZh
wgQwXJoQBUdi2rRpIDLwlBAI9/jhw4fywBwyxWsLj4NA6RBes9KxgwIEBgai
UBB4yZIlsmdukxAlJCQ0bNjQw8PDwcEBNBD0XDR8kYsOdyM/LS0tDdS+tILw
8HCV2qFSRMMt8H1QFXlsPUeimhXPs1GjRrAxpIaXO43mmxXnLSwsDMYAJaCy
bDIyVloulGZRAGvQCgaCAGqJhkknCsHmxaAqgbZHFkPnKuzZswcMF70NdF6j
Ro2pU6daG1fNada4CxXVrFkTjRGtdciQIRb9dm2paT9ti5D1z3jVgU6bqlW7
V8OaNWsqKADNMSszizwUDB06VMSZO3cuBZ44cQIp0DaMRJ+bNm1KM04F4b16
9WqLFi3QJHFdv379Y8eOiXTQcvFyFCPLtEGEeOsJwgtJ2rRpgzcX7Bldh0yy
zMqujHgx0TggkurWrZvc87Rs2RJy4sWKaOi70DlADDQNmm6kAya8Oo9bJLxm
qQOx2JeiX6KZyei4RCBNNoPnkIv4dEqFSTqZEe9BOFomaQbdawMmvAyDYMLL
+NPiiy++MOj2M8yKg2TzIwZDBVYag/GqQByqDvppM/KtW7cocmRkpAikj5Y0
9rply5aSJUvS36JFi+KaPkAR4QXoHAGBEiVK0IkAIMJitiqYLC0gAjp06EC5
CMIrGDHB3t5eHMwHAcBhEQg6DBJEw3/u7u5ibkm9evVMysxb0F45EcRX7eGm
wmtJeN96660vNRAj43knvJMnT6bw1atXa8VAvdNdeTYaLeVAneYi/p49eyjC
3LlzRYSAgABT9rntrxOY8DIMggkv40+Lw4cPM+E1DtpDjLlbjsBKYzBeFdBM
eyAqKkoEZmZmbn4WdO6VTcJr1p3SDHTq1AnUMj09XQwE09jxrFmz6C/YK1KA
AHSWdJEiRchVE4TX0dExISEBvGzjxo005FehQgU88uTJE1oi5O/vT/u9nz59
mvYuaNSoEYlBhJfkv3btGqLReVvA8uXLdbT0WhJei4BWKVouCG+DBg1aZ6Nu
3boU2LFjR4tLaOkwRNOzGxgiTQrUTqG3GV/MzJf3S6Qa9/Hxedlaz2cw4WUY
BBNexp8WtHcWE16DaNq0KXO3nIKVxmC8KqDD34Fhw4aJQDogTwYtw8w74RW7
xwt6snjxYrNyCA4ep7WZN2/eTExMBG+lCMReBeEdN26cSHb48OFibJGWnAPT
pk37Nhvh4eEmZd8tWuBD9KdYsWJi6e6xY8foqfHjx+toiQmv9nEjuzSHhoZa
U9qRI0cozuzZs0Xg4MGDKVA74G4zPu0HAuzevVtEaNSoEULc3NxettbzGUx4
GQbBhJfxp0VKSkqbNm0WLVr0sgV5NTB69Gio6/Xwc14YWGkMxquCXbt2EU1A
mxWBV69eLZuNfCS88i7NdCY1sHDhQgoBT+nYsWOpUqVUpElFeHfu3CkSEeRr
+fLl4Mg6PI42CibCW7JkSZGCmNE9duxYHS29loQ3IiIiQwPxKSAXhBcJTlQw
fvz4sLAwCmzQoIFFMc6dO0cRJk+eLAI7d+5Mgdo9x2zG//jjj+laPkiLdkSs
WLHiy9Z6PoMJL8MgmPAyGAwGg8H4k+PevXv29vYmZR2rOBhLAETvxRDe9evX
099y5crFxMR88skndFCClvDKG9zRTuwmZZVofHw8XTdp0iRSAzoEjQmv2fCm
VXS8HbBy5Uo5XOh58ODBFGJtDa+YQG5Rb2JNrrzle3BwsEnZ0j8X8cUaXvnk
X1g1QkJCQl621vMZTHgZBsGEl8FgMBgMBqNnz55ikFecnW1WnGo6P10Q3jt3
7tBfcBwRjXbyzyPhpaO4XFxchAB0upmW8MpTr6OjoykwKSlJrPGU5y8htVsK
Hj9+bGbCq8Ag4RUDpvLibrM0jXzp0qUUYo3wikFeWgCuwtOnT2k0X7BRhHh7
eyOkdu3auYifnp5O25QNGjSIIlj8PvN6gAkvwyCY8DIYDAaDwWBcv35dTCQO
CAiYOXNmYmLirFmzqlSpIqYEi6NUaRsoJyenbdu2wZVasWJF0aJFZcILakl/
wS5FFjYJLziLSVlsu3Pnznv37q1du1Zs1KwivMgOmcLVX7JkCY1N16pV68mT
J8iXDqnx9/enw79AZsuVK0chtG8SE16zRHgrV64caQnQrVnhj66urlQp0dHR
CQkJW7ZsiYmJIZ0XL16cDpwyWye84pPFyZMnLUoiuDMq98yZM2JBrhhTpuOr
RH3ZjE/7JTo4OKxbt+7EiRNt2rTRF+DVBRNehkEw4WX8mWHxEGGBTz75xKQ5
GDd/s3iusHhy63MCXrixsbF0HR8fT/tjyEfTvpTyylJZg/YU3RxBHDmdL9by
IpFfBc+LDC/SRPMOWWMvUnKdE5/zgpSUlB49etSoUQO+NFhecHAw+J12waA1
vBIGnwshU1NTfX19TRpAUe+++65MeAcMGKCKA94kE17Ax8eHQtzd3eVjiXQI
L9JXJUuDdwDNRhaE19PTU44GAi7yxQWqVYQLGWgvLDMTXgX6m1bRcDnFTExM
pCnBKhQrVgyMUiRojfD27t2bwuXIMq5fv05fJGSEhoaKI8jpW4qHh4fB+MeP
H6dzqWToD2S/omDCyzAIJryMF4k7d+40a9ZMTMSKiIjA35coz0snvPv27YMG
5IU2+Qh9n3zevHnImjYwyaMYT548gUsmJmvBi4bnnCPP/PDhwy1atIBjBges
c+fO6JfyXl6VVK1atQoPD8cFXHqTtLipwBLe52ob+VjwvMjAhNcI8p3wPn36
dMSIEYUKFQLtqlatWq9evTp27Fi6dGmTchos8TKbeLUIr+rVo4+HDx/OnTu3
fv36rq6uYDSgsePHj8/MzExOToauNm/eLKKNGjXKz88PVKhBgwYff/zx9u3b
+ym4fPkyxdmzZw80jETKli2blpaGkMWLFyMCyLLIDgqnp+g18ejRo6lTp1as
WNHFxQUUZtu2bSdPnqQI1BuAINPfM2fOgEmB+KDbROdGg7kCV65c6d69e6VK
lUB8YK5DhgyR9/tFF40UYAYiJD09nZLdunWrjnJeJ8KbkpLSTxeyxm7cuDF8
+HBYBVinm5tbUFDQoEGDrl27Jie4YsUKelCM+RKOHDlC4fI2UyrcvHlz4MCB
eGehvurWrQujlc8wio6OxuOyAevHB/DuAwH38vKCIaHTgGwvW9/PBUx4GQbB
hJfxIqFy2F66u/vSCe9zdRr11SsLlkcxjh07FhAQQNffffedu7v79evXwSvp
/AubSExMhONdqlQpOIHw3+zt7eEc4m2ex/LKUgFwCydMmGBWPn3LM7vyi/fB
TUWR87EvLeCEggnvq0t4wadMyn6t8vxGtFzQH5OyV5I4MUcH+W7wzwNCyPwd
HP8z43UivIzXAEx4GQbBhJfxIsGE93lkYQ0vjPCOHDlSHN24ffv2HO0D+eTJ
E39//5IlS9JqKWDVqlW5E0ZVXlmqu3fv4taGDRsofXEYpblgDHRaBBPegobX
g/CioRUrVszNzY0WhMp4+vRpy5YtTdkHwr5OYMKbX2DCyyhQYMLLMAgmvAwj
2LhxY9OmTd3d3StXrjx8+HAYDJwHuHxmiTfNmzfPxcUFv2blGEHE9/T0LFu2
bNu2bWneLOLoLJYxK+7Whx9+2KhRI1dXVy8vr3bt2okFR8L5P3r0KPiUg4ND
iRIlEOHMmTMU4d69e7hbpUqV4sWL41nkvnfvXiH/Dz/8MGPGjLp16zo5OVWt
WnXw4MG0VE0Iv2zZsvr16zs6OpYrV65v3743btwwaxjH9evXIyIiKlWqRJPc
Jk+eLNbL5C4L8mMFKCOdXKAfkLV69ep5eHg4OzsHBgYuXboUgdZqjXxyPB4T
EwORoDQkGxsbC1GJrVjEsGHDyDM8depU8+bNUadBQUHz58+XM5K9fYSDsSIy
/Y2KioINyO4lHf8HB6l79+4wCRRKKMecvX5t3LhxInFYF8r12WefqYoj0oSK
OnfuDCOBEqANMcPQolTw6tPS0kB1cWvLli247tOnD00vJIdf5QlDXRMmTKhV
qxbU5e3t3a9fP/mAkoMHD7755pulSpUqXbp0+/btjxw5YnFKs741ykhKSkI6
FSpUKFq0KNLs0KEDNRaLtpG/yK+CUwSLTV7gzp07AwYMgELQOtAKhDnpmKhF
mXv06IH4qumCLVq0gPZu375tVr6fvP/++9QMkVRkZKSgdaKCUBc+Pj5hYWEW
s6CJnRAGdYfiBAcHJyQkaDWmMjabHVd8fDwKDott0KDB2rVrIefEiRORCHKp
U6fOrl27dGpKS3ghZJcuXcqXL49iorCbNm2Sm8CjR4+gKOgkOTlZmxotEZ09
e7bFvNDBDh06dPny5caLZrFjl6mljmmJ7hE9G3oGyIzusX///loyLkCP7Nu3
D30jHkFnCJJ+4sSJjIwMlLpMmTLg8q1bt7548aIQUqyg1MrGyCmY8DIKFJjw
MgyCCS/DJmieG1zEQYMGDRkypGLFivAwVYQX4fBV4Bdt3bp15cqVJmU3DPAa
MDt4dLgFJxMeKXwn3KpWrdqnn34Kjwu+Mf5+qgBJDRw4EH9Br0aNGgWnCC6W
vb09HTVIfgvcLbg3SBaUCl43QuCDwZeGV0buN3w/8PGuXbvCsSxSpAixsMeP
H9OOhWDKY8aMwd3ChQsHBAQ8fPiQhEe4r6/vewpoN87GjRubnyW8Fy5cAN+H
wwa6hERoU6bQ0FDyzHOXBVwy0m23bt2gAfzVz4U8VZAjOIRIlvaskA+eUIG8
3xAF0Db0hkoR3w3AX3A9bdo0MHHUrBBj//79uAZZgGuKgqBmaQsX+TiD6tWr
g4/T9ZkzZxCB+AvkLFGixJUrV2RqAIGpvCgIaoc2S4ESiMiPHTvWZGxTL0oT
NB+ywduHDYBDoZYLFSoEmc3PchAhlYo5almkLCpEgltOlgYO3qlTJ9oY8+rV
q2ZlfRbyQsGhKBQEhgrDpj1dZcKrb40y0FhMys6fSBB6IBMCycrMzNTaRr63
6/wqOCJYa/KUEdgNWjpS6Ny5MxKHGSByRESEvolalBm9Ae7OnDlThNy4ccPO
zk4cDdOrVy9EgH2OHDkyPDwc12DoND2eKqhnz55oYijslClTtOmjvLQdK5re
+PHjITDKAsmJ5VkjvDY7LlgCegO0NWgPaqRGjSaAgkBdJmWjV/AIazWlIrx+
fn7QJ+oCTaB79+60mw0IoJAqJiYGZYQ5iZWkMiAn4lDN2oTNokE2SL5CAvgy
wtGDUQr6pkXdI6oP7xcofNasWTVq1EBI06ZNrYlEjzRs2LBJkyZz58596623
qNVUrVoVfRpCmjdvbso+n4WEhDHIrx6xsxMjF2DCyyhQYMLLMAgmvAx9JCUl
wd+Dw3Pv3j0KefDgQYMGDVSEFy49bXVy9+5d+B4uLi5itwf4iohQs2bNJ0+e
6ExpPnz4MK7hryIahcBPhlNNtIX8FnhKYtdEBJJjAwcGPBEX+CtGIdetWwcx
yDEmbxx8TaQ8f/58hMAFIuHha0FsugWuAcqGQJRXJrxIHJ4qbZJJuRP9XL16
dX5lYTMXaAMOJ0g03UUPjzLKJzyqQOrt2LEjHbxItYmQOnXqmK1PaQZdJT74
8ccf01MZGRlwJk3SlpUy8BTceLpGapS4XNG0Tym8ZaodqIgOu5wzZ45Z2biM
xl5bt27t5eUFT7hVq1bHjh3TZkRpAjSLgECrEUkA2ZyEVMgONBy5wIZJpdDh
jBkzEEiVBTYkHGxKbdWqVSL93bt3w/7xOIgVrBrERIxd4nEUikSSCa++NcpA
1ZiePduRTq8gh/x5T2mW6ygvBddv8vj79ttvU1sQVk1UFJRH30S1ePToEfKi
qiQsWrQI8Xfs2GHO7kPq168vJkWgoulznNCnLIkWCxcupJ5NDDGDQNF3IbMV
wmuk4wLpRiOiu6NHj0YIGOv9+/cphLSRmJhoTSoV4QXQvYi7s2fPVjWBwMBA
kbgWaGUODg5CWh0YKZrKPmnz2EqVKon3hY5pmbN7ofLlywsChQc9PDyoe7Qo
FT2C7oKkgiSocYSEhYVRi0Pt02cTuYPlKc35BSa8jAIFJrwMg2DCy9AHnbyw
Z88eORAei4rwCreHhmAGDx4sxwebQKBq4M/8LEOhEx9Uo2CjRo1CIKyU/BYV
uRs/fjz5gRcvXqQBJjyuneJLI0ryAAocIZAm0AoSXiZQAI2ryhSG9vVV5Y5A
EHBwt3zJwpy9e7BOLmXKlDEpC1GtTfhUgdQrqxQuokkzF938LLe6dOmSSTlf
Q9YkjY+MGTNGm0u1atWOHDlC14MGDYJ/a36WGtCZGvJiTzAdhDRo0ADXNNDs
5OQUGxsLngvmS0M82kmelKa7u7tcfFgmAlEWlTnJUgG1atWiOETnZXuGTooU
KQJSZlYGv0CHVSZUr149+PBr1qzBg/KmpgC8Phpfk6tS3xplgCreunVLrCYG
myPDyJeF1TYh11FeCq7f5PFysbOzQ9XIiZ87dw4tQhBeayZqEf3796eU6W9w
cDDII/FlGhOPj48XkaFbR0dHHx8foU99yvPw4UPUiKBakBk2b3EygDA2Ix1X
dHS0uLV27VqEoKWIENGPWZNKRXhVTWDv3r2qJqA/X8Le3h49iSpQO//BYNFk
+0RnRfOWU1JSRKCOaZmzeyFV9xgSEmKyvjycHhGzuM3KMgpVvYsUmPDmO5jw
MgoUmPAyDIIJL0MfNDlTtWknfEIVbxLOxvvvv4+/y5Ytk+PTqehgGTqEt23b
tiYrOH78OPkt8LXkZIUfaFbGTUAMTcpc3D59+sAdEjwC1KNEiRIWS0fC0/CQ
qsiys3TixAlrsrVq1SpfskCgzVygZBcXFyJTnTp1WrJkCa01tgaxQFIOtEl4
ia917dpVfio1NRWBnTt3VmWByKVLl6ahFvyKozfkikYE+bRHgpeXF2mMpqbL
Hm96ejrIVJUqVVSPUJpwleVAWj+oIryyVGZlUTAoLS1L3Lx5M+KotoD29fUl
Lm/xpEUAPjz5+bJTTaAJ6qqq1LFGFdCy1q1bB6bWrFkzkXtOCa/+6nhrfr5c
R3kpuH6TP3/+vEXLMWKiFnHw4EFT9vSAr7/+2iQdG0pDparDWapXr466QBak
T5lpWgS4ZGJi4qRJk5AaTdvWJ7xGOi65ErUhcj9mESrCa7MJ0HJma6DRTzHh
hJAmgT6s5bRo0FubNm1MmgF0HdMy2+oeLcqv3QZQG6LtYJnw5heY8DIKFJjw
MgyCCS9DHzRbTEV48bKzyJvMVghvTEwMeTU6hJeWYsFDTtPg4cOHFp1/laN4
+fLlBQsWdOzYkWbEVaxY8fr16wh3dXUF/bFYOotbKGudJZqkGhYWppWNpnHm
PQuzskxYPxfS/Nq1a8Gh/Pz8TMpMctXguwyLG8naJLzEUFSElwK1+/zMmDFj
4MCBdH3s2DHBUuWKLqlA9SBCoDQhhoqkBAYGIjAzM1MOtOiyWiS8QiqaH2sR
skiNGjVasmSJWZk0jnpMs4QJEyZY5H3VqlUzWTqH15o1qrTq4+MDOga2u2jR
olOnTkVGRuaC8KKBpOlCPk3Soj7zUnD9Jp+cnGxSViLnwkQtgo5XJtI3a9Ys
RBYLnC0SXrIlOEVG9PngwYMmTZogWo0aNaZMmbJ//355z3CLhDenHVfeCa+R
JqAD+sRE2yZoQfuZ57RoT58+pdW+8vGyBB3TMtvqHi1KyIT35YIJL6NAgQkv
wyCY8DL0QbPFVKxq37591givxfmNtBsPKIAO4SW/WvWpH6ktXLjQ2nox4Qfe
u3fv0KFDwkH67rvvaI0hnbtKuyTJox7oIeHLrVixwiAbRQMBK1ENrNy5c2fe
vHm0rDXvWZiVgUj9XA4fPiyceehk9erVJmV3HWt1lzvCe/bsWVwHBATIsxDX
rVtnUvZ+UaUWFBQkbGPEiBHiGCC5oj09PVXua3p6uknZycecvQIR1SfuIl/Q
QBcXF9UyQ+PevpAKtQC/GuWys7NLSUnBdXBwcNOmTXEhbwMFsQ8cOGBWmG/R
okXlwS8IExcXl5CQQDNRVTN7MzIyaA8iuSr1rVEGbe8jL97MHeHNHWR95qXg
+k0ezMik7CIlm9PJkye7du165MiRXBBec/bUZbD4WrVqhYaGqsJVU5qdnJzK
ly9vUJ80AWDYsGEi5KOPPtInvDntuF464aUyVqpUyeKsg2nTpgnCa7xoc+bM
MSl7W6kG6/VNy8yE9xUEE15GgQITXoZBEOG9dOnSVwyGJdAKvsDAwDNnzlAI
CFGdOnVMynbB+NutWzdcgxDR3eTkZDc3N2dnZ7AzCtm4caNJWRMKSzt27Bj5
RXSL9u9FOK537twJugfHWGQEBwbOKhxaXNMo0pAhQ2TZ8BeBuAW2YlJ2ARW3
Zs6caVI2csE1zcl8++23hZ1PnjwZITNmzFAJTyD2ClHlTGk3IXBPioOkaCse
uG15z2LQoEEUrp9L2bJlS5cuDaZGd2k7ZTA4a3VH6lUFqioOdEaol8T47LPP
yOOdP38+PXL69GlypFGVclKoYtQ1yQNRQSs+/fRTukUVjWLimqZhIztSDqqb
Nmt699138ff48ePwh+GIgsvTsyRMy5YtVZLLaQoQE0fioryyVIRevXr5+/vT
dalSpaKjo61pjDbYEaICtCcSmP6JEydQEAcHB+iHbqEgNASmshZ9a5RBu51v
376d/oIG0r7l2kp5HpD1mZeC6zd5/G3cuDH+giXRXWTRunVrhMCA9U3UGhIT
ExGne/fuJmXHZhFOh0+BBZ8/f55CiAL37NnzKyt9iAq0nHbixIn0F1ZEO+OB
zqs0JiTPacelDRH9mDWpRASDTUC/3qF/4oMhISH79u0T4ags9Fp2dnY0G994
0RYvXlyoUCHYwMGDB7XZ6ZjWV5rXB0F0jxbl1z6iDdH24apXDyPX+FIBO42M
AgKYIhNehhF8ld19MRjWQO6Et7c3/MaIiAgfHx+QEZNyxMOX2a4vXHQRnzwc
Ly8vEI2uXbvCVS5SpAhFgEtvUlZvwduBmxQQEGBSDkl87733cJcGwsCbEAKi
5+rq6ujoCDcbt2jTY7idsmC0ThC3wJXo5IuGDRsOGDCgTZs2yAKO2Z49exDt
3LlzNP2ybt26uNu+fXt4cfDGU1NTtcIDiGZSdsqVM4Wn5+npiQfhACMRmukN
4gaXOC9ZLFmyhOa7TpgwYdOmTfq50HY9iBwZGYlKoa2e4dFZqzia9qwKNCnH
muCCzqaE6wvl07AOiUHTRMuUKWNvb9+2bVtEo12nOnXqJBIB/wVLBTsQgaC6
iEZyAigaaQPXqESwIZAmeKFRUVE0xRR5nT17liLTAA3SxF1QIeE8092YmBjk
hWLKaQrQ+COULMorSyW0jYLggmY4w9+W78rJpqWl1a5dm0gTpAJphf9fqVIl
UH7cnT59OmSDMEgNooIIoMh0ZpNsLfrWCCAFFBYXpHaIDYcclYsKpdTwyI4d
O1S2ke/tOr8Krt/kARQcbRlWjXINHDiQrFquMmsmag0wM3oQpkUSCoSFhRHX
RmdC3xNKlix5/PjxL630ISps374dZg9p0dENGzasSpUqRCHRU3344YeyxmTJ
c9RxaUNEP2ZNKhHBYBOwWfWnTp2ibZ1Q2Jo1a4aHh6NLR52ilkeNGkWj8waL
hpcCbV8G25gqYfny5ZSCvmnpd48Whdc+og3R9uGqV4/BNsJgMF4JMOFl2AQR
3m+//fYxg2EFP/zww5o1axo0aADaAl934sSJN27cMCk7KeEueUR79+6VH4Hf
CCbl4eFRunRpeLnJycni1pgxYxAOHwle1oYNG0Cf4RvDKaW78CrhiYEc4UFE
OHPmDIXTKAY8fzkXmnGHW7i+fv06fGk44UgZz3bo0AFOnYj58OHDcePGgWoV
L14ccUBDUARrwtOWy+np6apMkQWNFSIR0Fu4UnLDyV0Wd+/eBTvGI3Aj58yZ
o58LLmbMmAEnHJHd3d3Bp+Lj43UqjoZlVYFELXGRkpICFxTqQlKgJEIMmmcL
sTdu3BgUFASmhmhz58599OiRKuUmTZps3bqVQugYIBGBJi2jmLhGsoiPqgSL
h8MMXzc6OjojI0NE/v777+fNm4d6h4GB3/Xp0wdK0NaynKYAbVELaS1KRdYL
IgbKRpHhbIMuySmokhX1CN8Y9AGuMtUjATQc1AAGVqpUqY4dO+Ila9Fa9K1R
VAFkQ6WjyFARaCDEPnfuHC5QC8uWLdPaRv4ivwpOEXSaPHDt2jWyaiRetWrV
2bNnIzubJqqDSZMmmZTDfFXhsFLYKuwWSkN2kZGRohQW+xAttm3bhsehdjS0
adOm3b9/H9WHHgnyyxpTSW6849KGyP2YReS0CRipfShq/fr16MM9PT1BeyF2
t27dkpKScItOYjJYNDr4WAtZSB3T0u8eLUqufUQbYrFVyq8eIypiWARNab59
+/bLFoTB+P/IzMxkwsswgq94DS9DF/fu3YOzKs5+JaSlpZG3+bKlY+Q/6BBV
WhKYLyhWrJj+kkzGSwGvamQwGDkFr+FlFCjwGl6GQTDhZeiDdjiZMmWKHEgz
GFeuXPmypWPkPw4fPpy/hNfe3p4JbwHEtWvXmPAyGIwcgQkvo0CBCS/DIJjw
MvTx8OHDqlWrOjo6rlq16s6dO3CSFyxYQMekajfkZLwGoHNO85HwFi5cmAlv
QQNNI6fNtV62LAwG45UBE15GgQITXoZBMOFl2ER6errYmQQoVapURETEjRs3
XrZcjOeClJSUNm3aLFq0KL8SRGr5SJ8Z+YLg4GC0ZV9f3yNHjrxsWRgMxisD
JryMAgUmvAyDYMLLMIjHys4zGRkZL1sQBoORV6Snp3/zzTeqk44ZDAZDH0x4
GQUKTHgZBsGEl8FgMBgMBoNhE0x4GQUKTHgZBsGEl8FgMBgMBuPl4uHDh5/b
wvPbOuPWrVuUBSitTrTXifDevn1bR9VffPEFRYOfTCHffPONxccvXLhAIamp
qdp09u/fj/DnVHGwGYin48NnZGRcvnz50aNHL1vZzwtMeBkGwYSX8VzxySef
mEym9957z/gjiIxH8OCf6tgUUhQwbdo0ixGmT59OERBTP6n4+PhmzZrlu4R0
xOfL1tOrinfeeQfag/Pz4rOmY23pGq1JdV5qqVKlWrZsmZSUlLvEySr69u1r
M+vnhPztJag4Li4uFr1TBOKWKNRLrNPcKWHDhg179+4FYUEfcvr0aRGeu4Jw
h5DvgDNmsoWrV68aSeru3bs7FMDHM5g7ncgAfPDBBzrRXifC++mnn+qoukKF
ChRt5MiRFPLRRx9ZfLxfv34U0qVLF2upubu7r1mzRkeYtm3bltQgJibGWvzE
xMTKlSsXKlQIieMXzV8wdMKqVavKlStHuaPjGjVq1Gu50SgTXoZBMOFlGMHj
x4+nTJkSGBjo5ORUv379FStWPH36VI4AkhUaGopOtWrVqiNGjBD96itNeA8d
OlS4cGGV8Hfu3ImKiqpYsaKHh0fz5s0PHz4s37137x7eUFWqVIGigoODZ86c
qfqyivgtWrRwdnbGu6xz587CGxGEt3r16haFqVmzpkHC26NHj6VLl5qVF8H4
8eP9/PyKFSuGeomLi7O4ZhOBoDw2fdf89W9v3749ZMgQX1/fokWL+vj4dO3a
VXwkNwL9Wnj48OHYsWOrVavm4OCALLp165ajxPMLERER4stDgSK8UN1QBYMG
DYL2EAI7l3UIp7pXr14lSpSAoTZq1Gjfvn3WEierAOBa62etA6QPRel7g9bw
PAgvgA5Ne1cwgleU8KIfQBzUFCLD+xXhoiA5qggmvPkOvA4cJQiuJAemp6cb
Sero0aP0rOpIQR38mQmvnZ2dowbiXZwLwotXj7YekYv8oUkFV1dXLU2OjIy0
GHnZsmUUoUiRIniB0jW667S0NIqAeheB4Np0HR4e/rJVnv9gwsswCCa8DJsA
t23bti16y4YNG4LNBQQE4Hr48OEiwqxZs+hzKChM06ZNcQ1STETv1SW8eKGX
L19eJfzNmzfxcilUqFDHjh0HDBgARmBvb5+QkEB3wXZBwfBI+/btR48eXbdu
XdULKzExEcyiVKlSeLZ37954tmzZskhTKAosGL+pqakqYcDXxF19wvvdd9/h
7QbV4SIkJATxwWhGjBgB9mdt+JiOp7Hpu2ZmZj548CBfdHv//v3KlSsjx9DQ
UCgKbBdqgTeenJxs5HH9WoC5wmkXiXfv3h2JOzk5Xbp0KV+ENw6ZEaA6oL3H
jx+/YBnMlgivamLe2rVrEQhrob+XL1+GpaE6unXrhvbu5eUFP+3gwYM6ZYR3
B0vW7mhnkPDmopcQePLkCRQLnydfdEXFQfE7deqkvfvWW29RG6RCvcQ6VcFg
Vwlii7767Nmz6JRkRi8Ib44qIh87BIZF0AsI+OGHH6zFQXdn0fj1CS/qTpvm
n5nwCsZqEbkgvIcOHRLRUEE9evSg8IkTJ1rM4urVq7gLzvvpszhz5ozF+N7e
3vR5/O7du2bpg/mYMWMoNbwTTcqpc+TeT506lSIcOHDgZWs9n8GEl2EQTHgZ
NkHvwTZt2tD4IJwcsCfQjfPnz+PvjRs3ihYtWq5cuVu3bpmV929ERATiL1u2
zPzKEl6UQry5ZOGHDh2KEDiN9PfcuXPFixeHq09OL92dO3cu3UUg2BYURcO4
0J6/vz8cZvTMFGHVqlUifVJU//79wc7GjRunkmfSpEkIx12bhHf79u3EXPBq
RmQwPgrHSwFeOojJw4cP5finTp0SB069MPUSxQYNF/MEIDZ9JzHyuH4t7Nq1
C3cHDx4sEic9W/tU/vxQQIbAbBJeKAquNWyDGjgUJY/YXrx4Eb5T48aNdco4
f/58/Pbq1Usnax3khfDmL6g4gwYNAt+/d++efAscwdHRMTo62mChXiTy2FXm
jvAynjd0CC/a7PLlywMDA9FsEQEx0fquX79Od+Pi4oKCgujZChUqtGjRgsJT
U1M7depE0/KBMmXKxMTECDtnwmsNeSS8wGeffUbh1k7oozeg+OqoD7zEKbXx
48dTCGivLEl8fDz9FZOc0bfTOC/cs5et9XwGE16GQTDhZdhEt27dVDP3Fi9e
jJDJkyeblXerykcCAUFI06ZNzRpXFk5jkyZN4ExanABJ0BLe9PR0vEfwTndy
cqpbt+6mTZsoJnmnjx496tGjB1hbcnIy3IAPP/ywUaNGrq6uXl5e7dq1Ex2+
kGTv3r0+Pj5hYWE6RQZFAsEcOHCgqmilS5dWccbOnTsjDo1/Va5cGXdl5yQt
LU18dKWZhDKZRbtbunQpXoWyeM2aNYOLIs8Yx3VAQADChWZ0JI+KigKdxEW9
evVUTvuRI0eQnXyAMqoDMsMdqlSpkk1qJugbucf79u2DAeBxDw+Pli1bnjhx
IiMjAxUBJ8rNza1169YgStaS6tixI1JQzc1DUiBWNFqBW3hxV61aFUzW09Mz
ODhYDODarAX6lH38+HFxF4IhBB4g/ZVnoup7+OLu0aNH4Yog0xIlSsCoxFd3
yBAbG4uU4UuADUHgGTNmEG1UzUyjTOkrRM+ePeVcaCzm3Xffpb/wWuGToEZQ
fdAJlCwWCFAV4O+oUaOgBERACHLUH2S0SXiB2rVrI/z+/ft37txBslC4fBct
Dt61ahWDLBKKHBoaioutW7day9pa2ySrFujdu7dJAx0qJ3M9EgY2D+cf+kEz
h6ph8GfPnkXzQb4IREXojEtSCocPH8avambvhg0byI81WZrSfOnSpT59+qDl
Qnve3t7du3fHi5UehDwoY5UqVWDMKDg6RnRBZmXpAR5XTTxAY0RXdvv2bR2N
mTW92ZtvvqnfVSKp9evXo47QPCGhr68vOjf6RCkKotL88OHDKU0YJNoXZHB2
dkavAlok64quoQQ0eUrc398f9qn6XCBDu5Bcvz0a6fdeS+gQ3g4dOgjVQed0
ASZLs4MmTZokZrHCEsqWLWtWRv1gReIRvODoGklRmn9mwvvWW299qYHoKPJO
eNGNU/jq1astSkLT5NDGBw0ahJaLXmLs2LE0emsR3yoQPT+9WQByJ8grA2hU
guDn52f8q/IrBCa8DINgwsuwCXS/dnZ28jsXvaj4VEjvApkOw7kqWbIkfCrz
sw4M2IFNtmvWEF700nhfg3SDx8GNpOFIWlRIHldMTAxe7nBoL1++TBQVBAQe
F95BcNLAobZt2yYkgQOMyLVq1dJZ2QSmBvICZqryvuizqsr3XrJkiXiL4Sly
LQTg9eEu+B2u8f4yWV/xJ/Ki4chjx46JWykpKQhZsWKFTccPdQRGduXKFXAi
IyM+UBHoJBwYI2ORKsLbsGFD1ObcuXPhKuAv0gHdg+ONEFoWCg5lLSkoTeXT
ogtCZaFyUQQ4ZrSaCa7++PHj4WyDKRQqVIi8fZu1kJSUBBXJ0/xIgW3btqW/
0dHRMEKa2QUWg2trxkCVAicEpH7w4MGwwPbt2yMEfiOIIUSlWeugOaNHj+7b
ty/4FP7OnDnTrPhCMAb8pZlpghzBOFE6efMQpIxb586dMytz12GfYNZgT2PG
jIEGTMrcbGp9VAXwqRo0aDB9+nQoB9UtPj1Zg03Cm5GRAdMFW8H17t27TTkZ
4xNWQcsP0fCJrGmzttY20dxGjBiBW2jjUBTI5goJNJoPbVgTQEt4Q0JC0DXB
DsHO8LdmzZqoPuh/9uzZ9GFn2LBh+sUBfwfXgDHLt9CKwWRxS0t4QQlLlSpV
pEiRVq1aoXQgrTBX8FA4zOgMSecwFVDIrl27gjYi5qlTp1B2YS0EcHP0tKhf
fY2ZNb0ZIuh3lSiySVnNB+PHdfXq1fFXFFB8jVFVBK4DAwOhNIiENAcMGADJ
UbT9+/fLVb9nzx6IDSWjK0AZIQ/CLc4JJ8AnF/W7fPlyiA1R6fsYE14Z1gjv
unXrKBw1eOvWLbAedH1EYNEzUBztlGaiVMCWLVuQYGZmJvpwk7IIlDzAPzPh
tYiNGzdStFwQXlRE62zQa4I8AWuz099++22tAOhwrl27pl+ERYsWUUeHhikq
Dm83SoG+fpuVlyBtb1WuXLmXrfV8BhNehkEw4WXYBDxh+NVyCF6yJmVxKK7h
WQl3XQDcBz4MnD3hwICnNG3a1CbbNWsIr0mZMCnuwms1Za8gJo8LLtn9+/fN
yn5QJmVepdiaKT09HY4oqLeQBPjwww91ckdbqFOnDpzMR48eqbwvuGT4C/4l
x9+0aRMCp06diuv69eubnt1FMzExkbihWdnCiJwNvAHBmEAN4B4LYivygiMB
DwR+vkgE1BuOLniETccPvjeExwU6fxIVtKhatWogjPilWhCRadYT5DEbm3yr
IrwoBekZuqWCh4WF0SAg2BwtddQZ5ZGBp6hoNCd24cKFxCmEbwDyYspegGyz
FgSQOxQCH6By5cogCydOnDAijAyqFHiSYhNjiEp0Hq7O2bNnyaKET3Ly5En8
FRMIZa0KckTTuek7vFmZ9w5dwWOhv0gcbQQpi+wmTpwouDwlGB4eLj7sHzly
BCFU6dagQ3iRzvnz52nLsgULFiAEGeF6xowZUVFRaDg0qLd27VqLw7uqMtJn
B3A6bdZG2qaWZYNIwj0D4dIxJC3hFRQSRJ4Gv4TXd+bMGf1PMaI4oH4gcbS+
nmwJSRFT1hJe2kBGXiAPrurp6YlS0+p7VKtQINgKbtF2drgQEw/Miu9qyp5M
nqPezGZXiYxwjXqkW+jlEIIuWmWcckWINIX2zNnTJ+Tu16wsbcYFGJYwKmgY
ohrxK2JjY03Z61/MTHifhTXCS1tqoPrkL1dUC+IFpCW8cPYQSJ8NYdh4N/n7
+1McGutnwpuPhFeL0NBQHaXRppRoNdu2bUtNTR0/frzgyPpFQBchsggJCaEj
pdC3VKlSxaRskxUZGYmOy8PDQ5Dol631fAYTXoZBMOFl2AT4l9ifn4DuFD1n
jRo1zIqLbtKclUCfjtG9kwMD75E2s5o0aZLN7FSE193dXX7d792715S9EIY8
LjFm+u677+LvqVOn5NRo7AN2TpLYHPSEqKCHFocbiFyoBptoRGzIkCG43rlz
J66Dg4NTUlLAwfE2pCE/UhRNO3RycoKPB54LpolwhOzatUuVV/v27fHiI1ID
57ZixYpgl2YDjt+gQYOI9CF9etk1aNAAYuAvXqD4i3cuJYv6gmLFazoXhFfM
ljQr86hNz25sS/tlaafOagE3HhQJkWvVqnXnzh2zMoYLB0xwHGhgzJgxQjk2
a0FA+G9grCtWrLApiRZUKagOOZBcEdxCK4Cc8oAmGYCwMYuEFySuUKFCYiHV
nj17EB4XF2dWVsdrs0Mg5KdZ0JSgbOGoTZOtJaUm3WOJTMpMSPAvYmSgumQ5
0PD+/fshcKdOnUzPTsW3aBVmabsw4SiKrI20TRXNQcFhEg4ODmhNOqXTEl4x
Uxcgl17UkU11ieJAVFyAwlM4zRik7x5awrt8+XKTsohDOxxD32dKliyJBLUf
DWhV/pUrV+gvug6xFD1HvZnNrvKWAnEXfMfZ2VlrnFrCq0qTzFXufs3Z3zzB
gunDo3HQSCVsW2iGCa8Ma4QXr2MEVq1aVQ6kdUbihWJx0yr0kyBQeLmoegAm
vOiQMzQQJyzkgvAiwYkK8L4ICwujQDH+rsXdu3eRozwxiab3wBuxeLaCALqL
GzduoN+mIX7RJ5w8eVKcSQSgY6F9rsTH1dcGTHgZBsGEl2ETeD/CYZND4ECK
rpU+LMtLRYBq1aqh+8VrmhwYUGYPDw83N7cyZcrYHPVTEV5V/wyvTOVxCW+W
vntbxPHjx0kSUEKdrMmdE+RI5X3RYI2YcEigcVIRB29A2sXapGwJQvOTW7Zs
aVZorOnZ4RJwvaJFi1apUkWVF11DGFyfOHHClL2cUN/xw2sRLzU6lYDcdQgg
L1dE2YmM4BWJuqtUqVJmZibdygXhledma0OsrRWV8d1336FEYDTFihUDpZVH
n2E5iYmJkyZNCg8PF+4ZKcdILQigpGAcrVq1wt2VK1eacwiqCPkAF20twLGc
O3cunHbad9om4cU1mBF4BHlTkZGRKD6t1aK6tggUwSyt4ZXlyQXhPXjwYFo2
vv76a9mhogFomXRDhzVq1ABJR21S6xNAairLQWpgUl5eXrRUXGRtpG3K1QcD
aNOmjcnWfAyzJcJr0WgNqkvEBwXDtdhDBvL7+fkRL9MSXpguffeDltBfDRs2
DIGCxI0ePZp8UbS4Pn36bNq0Sbi1qAiEz5kzh1SH67Fjx4ocjfdmNrtKs3LG
a1xc3IABAxDNzs6OklIZp5bw2ux+zcpOBbQ7PZzzFi1axMbGql4HFnHgwAH0
fnhTiF7IzIT3WVgjvDQzHy8aOZCmBwA7d+40WyK869evpxDwoJiYGOhTTKNl
wqu/adWECRMomuolIvaGGjx4MIVYW8NLs45NyiiAQdnoa5jF1yjsgT5hye8C
+tgIiJW/uABDx/sLvfrNmzepkb5+JxMx4WUYBBNehk3Url3b3t5e3hiHSEf3
7t3N2avDVHvdg6TQkkByYMB2k5OTaSMF1TCcFvq7NFv0uAhEvcET0zSAR2pz
A1K8REqXLl2/fn14a/QUHFE8Eh0djWu8XO7fv4+/TZo0kZ+i2YzLly+XA0Hq
ITw8XhrfoeFI8ipVB8IGBgYiEC6fLB7+wnWkXYVHjBghCJG+43fs2DHizuZs
ZxUKkSNs2bIFgSNHjqSxALwKhX58fX0RQtfW9JO/hBdKBkMEQYAHrtq9CiQd
SjYpI+Pw1vbv3y9vZ22zFn5QIN+lCd6qjZiMwKb7TWseabPTrVu30mJhm4R3
xYoVJmXmKtwVNzc3uJ0Uh5pVWFiY1oDBhsxWvkvkgvDq1AsVWUwxJaB0CNy+
fTvakUoqrUhUWXCrYP8i6xy1TTxIy1dhGzbr6DkRXlHRKCOtMqCt58yWCC/J
nJSUNGnSJLidtHgWjFX0mZcvX16wYEHHjh1pYiE8T9pQ98mTJ97e3kQqaYml
2OotRxqz2VXCM6eDQXv06IGGj/e+vE+dDuE12P3ChYA9w07q1KlDxH/69Ok6
tYZSuLu7Ozs7q7a2s9jiaFybCa8A7VhlZ2dH3YIcCJBpaQkvzbpxcXERXxja
tWvHhNcI4f34448pWlRUlBxOG7sBdPC92TrhFYO8Fr8FoRV0VEAr9Ak0wuvq
6qqNf+nSJVXlmiWrQP9w586dzQrQ89BdegnKor42YMLLMAgmvAyboN07Dx8+
LEJWrlxpyl4yiZcjrmNjY8Vd6o1phS85MBMmTDAr3l2DBg0KFy6sv5oy14SX
PsOq1gjjDbJw4UKddYICtNGTNdCDPj4+cBrlz6r0kfzIkSNmZbwG2pCHsImI
0YRVWlInvwchFRKEBwLNqMSDuwsqhIzg84hPsvqEF+RLHFIATxvOJHxvOQLV
1Lx588iBtAZr+slHwnvt2jWQxHLlytHuNyqQ3yXvLEQTSoVy9GuhZs2aqn05
4JuZsldS5wj6hPf27dtw7IOCgoQ7inIZIbxEoCIjI8GRTdnbCpkV1oDWoRpT
g+uCKqPJtC+A8CIjk+bsTuoBVNNrtWUkwKppSJ2O96Wsc9Q26UMTFKsay7aI
50d46fsDeChReLE1t5bwXr16Fe1ajNveuHGDDoXZu3cvegPcEgpHieBaiy7R
nP3NBMylVq1aoaGhQpIcacxmV4lGAcIr1zsN99B1Hgnv2bNn5U3R8bd48eL2
9vbWqg/6oQ1j5UUQBPl9IUBkgQmvAG0NYVJ23E1NTUVHNG3aNAoRGwjQqhZg
4MCBFEI7saPL2rlzJ8wSzVNs1MyEt3LlypGWQGcIpqen0z6K0F50dHRCQsKW
LVtiYmLorFtYu9hr3RrhFd8WTp48qRUjMzMTbwSTMgkETQx1Sqt4TMre6RQH
rzzUl5hrR6ulPDw8IExaWtrcuXNpTyp6faB26G9gYCAkQfMMDg4mUXV2fn5F
wYSXYRBMeBk2Qasmu3XrRpP0YC3oVNE/k/uEvhrvAnTUYgEXjfmSM6NyzFJS
UvCOqFOnjs5BKrkmvOfOncMbAa6moJx4DYFO0makuThiUvsI7dlCBNaszEJE
2atXr06aoUll4nxYUBU6tYcm68LNK1asGLiAWBlE6dOuFKq8iAqNHj0av+vX
r1dpRisqLfVNTk4WIagFvPLopB6zsjAWHjVCTp8+rX38BU9pHjRoEMxAdSCL
AB3qSnsomZURW/J4J06caKQW6KTU7du3iwSXLl2KEHkfsFwbgFwL0KTp2U1F
iKkJ2iK2/NWqqH379p6enp06dfL19ZVnFNMRYOvWrRPVSsWhzc1eAOFFjnCM
y5QpI46vwgsCvpa1PYgsigT/0E2ByNpI2ySag34DVopWI46r1sfzI7xALQUg
EWjIYoqylvDSpyRhkObsnWQOHz585coV6jzFLaLP4gshrT6g6Ysy0chRb2az
q0RdeHl5iV4X5kRkhwqlIrxUEca7X/oeIuauoMGCz4Jfi45OBjoimt4pzuGS
Qf0eOkmhbeiHJmAz4ZVB2yaoULZsWTHmi/ZLlMekTEFBCG1/J4MWdQK0S96f
mfBag9iuMDEx0cnJSRsB73TRXZutE15x5pccWQa9pFSAW5WRkUERaN4IOkb6
ixecqF8B8Fmx48G4ceO0Ccorql4bMOFlGAQTXoZNwPegDZfCw8NnzpxJM23k
Abjp06eblK1icUGHS9atW5fe0VrKQMOL77//vrXsck14ReKgfmA3YFXu7u54
SdErIF8I761bt+BU4NWDxCdNmkSbh9BGx2ZlJjPeUPAk4d9CALorz3YmAgtq
BmcPb0a8sMB6aL8vVV7fffcdSBySwitMzEDTIbxnzpwRawwJ165dQ+JFihTp
2bMnKot271EtRxV4wYQX7MnZ2bmrJeD9DlefFn3HxMSA24Jx0PLYwMBAOsBU
vxbw4kO9g1AjtbFjx5KekaPYcTenxxJZI7zoNpE1EoeGQXXBYaFkVBkqjjxG
2ngTlrB48WKVisR6OtU2buBHJUuWRCIdOnSAx0JTuyMiIqhmXwDhNSvDiCgU
xIB6ITaKA8YBzzBHliPOhRRZ67RN8rQDAgLGjx9Pfh1akHw4kdjUWovnSnjR
3ZmUYR3ZBrSEFxQA5gqj7d69O2qNFtPBXNGKnzx5Qjv4IRDWCJtEiwZvFaf0
0mJhk7KdneqAYOO9mc2ukqZAwJxmzZqFEPQMIEHUjaM1iYKIiliwYAGdmmSk
+6W92pDmgAEDRowYQWceiYFFFYipwaiWLFkiVzHtLgthaNY33jXz589HwUHV
qRX8CQnvmDFj+imwuG3R1q1bW7ZsCdIKc8ILFy8X1aZhcXFxPj4+6N9gQmZl
q0l0p7hG/NDQUNTvyZMnKX3aI+L06dP0V2y4bRGvE+FFa+qnC3nS+I0bN4YP
H16/fn3akCQoKAitUrVPHSyZHlR9zj1y5AiF6xwht2/fPlQoXm1UoYgp72GF
1xYel/2u5ORkvCZQxehSqlSp0rdvX3nvUHQsINf16tXDqxb9RkhIiDhB+zUD
E16GQTDhZRgBOBdevrVr10bnGRwcPG/ePHmIFl0r3q2NGzdGRw1vBzxFfJbU
UoaHDx/ScSeqlZsCeSG8wNq1a0HJIUnp0qU7duyYmppqTRKbsPgIKAkICKgN
3nqtWrVSueIoFHxL0Cu8g/CKUd2F0uDFQTwUHylERkaKcTRtXn369DE9e8iL
DuEFb9KOmFy4cKFHjx4gZdAGag3kzsjhMtaQX4SX9iK2Bnpkx44dcCfoPT5j
xgzYDBxglELM79KvBfRpoB6gbOAgiANPgNxprbT6VmFzDS803LZtWzAReCnI
5d69exMmTEC+tKv5pk2bYOqQASEqFaFEjo6OYFLacUyYBIpZqVIlOkzq/fff
FyNlL4bwkv5bt24NsWHJbdq0sTgNT99yYGm0pkyWzVrbhEmEhYWhvA4ODhat
Qmdz9edKeGkjKZOyvF2bglyncD5RBLBIEHbUPjxh0bRxAWfVz88P1AMFhyWr
ZlnAszVZOWvYYG9ms6u8e/cu2CjEg6OOmoXdxsfHoxRI+ezZs6IgoiJgnOhS
jHe/CQkJ4PVojKjBqlWrzpkzx5pTYXGfcLlpQJMwOS8vL6gL7jrC/7SbVhVM
vE6El/EagAkvwyCY8DIYDAaDwWAwbIIJL6NAgQkvwyCY8DIYDAaDwWAwbIIJ
L6NAgQkvwyCY8DIYDAaDwWAwbIIJL6NAgQkvwyCY8DIYDAaDwWAwbIIJL6NA
gQkvwyCY8DIYDAaDwWAwbIIJL6NAgQkvwyCY8DIYDAaDwWAwbIIJL6NAgQkv
wyCY8DIYDAaDwWAwbIIJL6NAgQkvwyCI8MJgHjMYzwHr1q0zmUwTJkww/ggi
4xE8mJ6ejovQ0NCXXYgXAVIUEBsbazHC1KlTKQJi6ie1cePGZs2a5buEdOzm
y9bTnwI1atQw6eLChQsvUTy2BAbjTwsivLdv337ZgjAY/x+ZmZlMeBlGQISX
wdDHxYsXZ8yYUaVKlaJFi3p7e0dGRiYnJ1uMOXz4cDjDa9eupb/z58/H38GD
BxvPC5HxCB48evQoLurWrfuCC/vZZ581adLE09OzTJkybdq0OXTokLi1atUq
Lfvw9/fXJtK7d28/Pz9VYFJSUq9evaDAIkWKlC1bFonv2rVLVhQANmFRqoCA
AIqAmPryt2/ffvLkybg4e/bswIEDkR1qDUJOmTIFREkbH4GNGjVCyvrJojg2
4xiHjips1gJw4sSJLl26lC9f3tXVNTg4eP369fLdbdu2vfnmmx4eHih4hQoV
YK6In2tRDx482KFDB6Tm6OgYFBT00UcfCRkaNmzYp0+fXKSpaiYqjBw5snc2
WrZsiZiVKlXqLeHYsWP5VRG5QP5aQi6AKoDmZ82a9RJlYDAYDEYBARNehk18
/fXXlxkMW3jnnXfg4lauXDkqKio0NJQGXi9duqSKtnnzZjs7O9z9+OOPKWTB
ggX4O2TIEON5ITIewYPHjx/HRb169V5kSUGdihUr5uLi0rVr13bt2tnb24Pp
7N+/n+5OmjQJIoGItZUAnagS2bt3r7OzM6iWHJiSkoIQovD9+/fHg4ULFwYj
A7MTigK/w+/OnTtVCe7Zs0fcRUwd+dPS0sABoTpcgJ0hfkhISL9+/WhUbsSI
EdpHxo0bR1RaXzOpqalg0PmiZH1V2KwFME1w5EKFCoHV9ujRA7dgdUuXLqW7
SMTBwQGP4O6AAQNgP8jI19cXmeZC1AMHDkDtkA1igNu6u7tDVIiHW7m2T20z
0QHiIGb37t3zRfP5Aqq7lyhALnoVBoPBYLyuuHbt2sumUwwG45VHRkYGnPxm
zZr9+9//ppC+ffvC4Tx16pQc7aeffvL39yfqdPLkSQr89NNP8XfGjBnGs0Nk
PIIHv/vuO1wg3xdW0v/973+1a9dGYUHuKGTTpk2QoVevXvR39OjR+Pvzzz9b
S2HWrFlvvfUWyBqiValSRb4VFxdHs7uRC4UcOnSICKlQ1NChQ5F7bGysNlmE
4y5pRqcISLNx48a4AKtCZDB0Cv/Xv/4FeYoXL/7LL7/I8b/66iuwOaq1F6Zn
fVXYrIVRo0bh76JFi+hvenq6o6NjuXLlfv/9d/zt3Lkz7oKoijqlzxRCFTnC
wIED8ezhw4fp740bN0Clmzdvjuvc2afFZqIDxCFy98JqxyZgSC/SWrTIRa/C
YDAYDAaDwWBYw3vvvQf38tixYyIEFPjDDz8EV5KjgQWXLVu2W7duOoQXVLFF
ixbgg4JBaKElvJmZmW+//bavr6+zs3PDhg137NhBMcnx/u233/r06QPWdvny
ZbCbhISEJk2auLm5lShRomPHjufOnVNJkpSU5OfnB1qkzRp0RkVh/vjjj9Kl
Szs4OPznP//B3/DwcJRRR1etW7d+U4GW8IIIIxBlkQOrVq0KAgU2KsRr1aoV
CJFgglkKZatWrRrSFJrRESA6OnrZsmW4CA4Ohtg//vijuHX27FnU2vfffy9C
UB0QoE2bNpUrV7ZJYQTNoSH4EydOzJ49G497enq2bdv2yy+//Pvf/46K8Pb2
dnd3DwsLu3nzprWk9FVhsxZQBSrm3qNHDzxy+vRpXEOev/zlL3LKKDLuvvHG
G/SX5CcT1adOT58+RabiQQLMb926dSi+PK2dpAWZHTlyZPXq1Z2cnOrWrQv9
wDhVaVpsJjqwRngtsk5hdaKMGzZsgGLROnx8fIYOHfr48WO51KmpqY0bN4Yy
S5YsicYizwp7+PDhO++8ExAQAA0gBZTl119/lbOmoef169fLAtDMfPG14Ysv
vmjZsqWXl1e5cuXQdq5cuULhomk/ePAAhurh4aFtyxcuXOjUqRPaAv5CY126
dKHHqRUIMO1lMBgMBoPBYOQRoaGhdnZ2//3vf3XiJCYmwvk8evSozCayniUU
YCg22W6WhvBWrFgR3nLv3r3j4uIiIiJoOBJ0Iyvb8R49ejQcZvDEv/3tb8OG
DUNI/fr1QdIHDx4M2gsOdfDgQSFJVFQUIgcFBc2ZM0ebNY0zqlxocG0E3r17
N0shZSAIYKA//PDDt99+K9NSFbSEd82aNTNnzpRDQN8gIUoE3QpFgUHg4vz5
8yLa119/TfzCJuFFOmAuGRkZ//73v40MPkJFICMoiJExOxXhhVWgNpcuXdqr
Vy/8RTo1atRo164dQsD6abqytaT0VaFfC7AibdGQIAI3bdr0+++/o+oTEhLk
u6BOuAvmRX+HDx8OI0xOTsb1tm3bcG3RGLIUvmaNUj158gS54G7NmjX3798P
5gjBSEWg/5ChYcOGuIYqZCOx1kx0kBfCC6X5+flNnTp10aJFtWrVEkogYwPD
9fT0HDFiBFoWqCVCSpQoAY6PCN988w2aCYhw//79J0+e3KRJE9xt2rQpdQKU
tdlsLlKkSPv27WUBAgMDQU4p2ieffIJopUuXRhaDBg1ydHRE/SYlJWVlE96Q
kBBoCQ28e/fuqrZMe7gVKlQIDX/KlCkIIRv7+eefb9y4Qfva4RY0j782dchg
MBgMBoPBYOigQoUKZcqU+fzzz4ODg52dneGgwg1+8OCBiACm6erqOmbMmKxn
h8+yJMILOgBn2ybbzdIQXmD58uXi7uLFixEybty4rGzHu06dOj/99BP+pqSk
4G/fvn3/+OMPipyZmQnJIT9IB0kCqNiQDHKzV69eLQfS/kJnz54FmaLdn2gN
I4BSjxw5kkbNVNASXhUgEkgfCSwrinjEqFGjRMzY2FjQdjAsm4QXaq9Xrx4u
QAwRs0ePHu+//z4YGbgGfqkWRORdu3Yhzt69e7OMTVJVEd6wsDDSMwoC5oKQ
zp07E7kD3QbNQYg8vmxcFfq1cPPmTSqafHfHjh0InDdvnjZxUCSIirsbNmww
IowMmkq9YMGC6OhoVLqLiwuawJYtW6iYqinNyB1/0QroLkhfeHg4Qnbv3k0R
dJqJDvJCeH19fWFOdAt1QWvAcUHGVrhw4YsXL4oqoM8UoJBZykQFBweHq1ev
irvTp0+nTwpy1qDJsFWRxbVr1xAOso/rf/zjH+CnKO+9e/fo7rlz53C3du3a
MBvRtEGEyYpUbZlGwKF2UTTQc4TQLHee0sxgMBgMBoPByEfA9bWzsytfvvzG
jRvhIYOPwJUtUaLEt99+m6U49o0aNQoMDKQZjxYJ74QJE2iz2VmzZtnMTkV4
PTw85MHlpKQk4f+TkyzyGj9+PP6qJlrTfOw7d+6QJPqDnsRZVIx4ypQpRFuI
RZYrVw7cH07+/fv3Z8+eXahQoQYNGojVzQL6hBdMvGfPnogTFBREY2qyDw8e
AZ5OK1LBNSpVqgTKJmvGWrLvvvsukb7z588jJmoNVQMKg79Tp07F36ZNm1Ky
EB6KHTx4MD2YC8IrJpZnKfOoaa8tEdK4cWOEoAZtVrdWFfq1AM6LiwEDBsh3
aSh25MiRqsRhrrRz1zvvvCM+gxgHbY4EvfXv3//UqVOwtO7du5uUo6OyNIQX
ZmBSDusRj58+fRoh/fr1y7LVTHSQF8JLk9u1lULGBjOT79K5V7j1z3/+U3sX
gSDIUVFRctafffaZYMFZypcZ/P3mm29wffDgQZOySZqcCHUCGRkZpLqiRYuq
pkkLhYAvQ5P/+te/6O9vv/1Go8xGJqIzGAwGg8FgMBg5gqurq4pIgtogZNiw
YbieNm1asWLFvv76a7plkfAWKVLE09PT3d3d29vb5qifivAGBwfLd2X/n5zk
J0+e0C0aULOItLQ0kgSUUCfrjz76CHHWrFkjB+IRKhG8boik2vSJNpLaunWr
KilrhBfUeObMmcWLF4fSJk+eLFKTfXi6Pn78OK6//PJLXMfHx2fZIrwgdCDj
//d//5elbEWFmNA2eIqqINu3bwfnBU0LCAgQu2/lgvDKZE0bgvRtEl5rqtCv
BfApmqwr3yWDlBkQso6IiKAptdCezuRzHYAwqqgfVFerVq1ChQp9p0AmvB4e
HmXKlJEfB39HBNpDTL+Z6KxLzQvhVc2mEJVCBkZDsQLCusjkLIImMIusUWVO
Tk5od1nZX2ZCQ0MptRUrViAOqlLOAvyXDJtUV7NmTVVxRFsm7aFZTZgwoVWr
Vs7OziQAE14Gg8FgMBgMRr4DvqjKk//HP/4Bh7Nhw4Zw4AsXLgw/9v+yQWst
QTFwDX+YXFOw3cuXL69du9biMJwK+rs0awmvuEWLSY8dO/Z/GghJ9J3kzz//
XDsMTcla24Jp9+7dNIStCrdIeK9fv161alXQpZiYGNWWTbJ44KGOjo4DBw7E
NVIGUYLCs2wR3vPnz1evXp2uSXViW2PC3r17EThx4sTVq1fjYvPmzUI/NEmb
rnXMIB8Jr44q9Gvhp59+wkWLFi3ku8SR161bJyrF3d3dzc1tyZIlqg8UOQJV
ioq10U7dhw4dskl4qZkEBwfbbCaPHz+WzVUeJjZOeH/99VeTZtMqOYKK8Kra
grAu+qTQuXNnbTui+cly1rTHFEpKC6U/+eQTCrdIeEl1oOHapq0qDszDz88P
SgPb/eCDD7766ivaLpsJL4PBYDAYDAYj39GhQwcHBwd5v9mMjAwa+YLvarIO
eKfkmk6bNi1LGYJs1KgRnNgvv/xSJ7tcE17koh3VOnjw4KpVq8QaXn0n+c6d
O4gDH1uE4EEfHx8XFxewiaSkpMWLF9O0W4ENGzbgEfjkqqS0hPfBgwfe3t5I
TXWcE0ElHvgdKBsy9fX17dq1q0ozFoUHNZ46dSpd//7775D5zTfflCNs3LiR
prnSNG9rsKacfCS8+qrQrwX8BRVycnISs2GByMhIk7LCF9dHjhyxt7dv0qQJ
7TOWF1y8eBHJqra06tevH014sDilWR6jFIvKbTYTHRn0Ca88T/vy5cv5Qnj/
85//oJGqZlbA7OPi4sBqs55tdzR1efPmzWPGjHF0dKQVuFlWpjTT3lN/+9vf
bBJeOnnq888/FyFMeBkMBoPBYDAYzwk04iZ2BAL7oHm8K1eu1EbW2aU5S9lw
GGSkXr16tJLUInJNeNPT0+Go169fX8yavn37tqura7t27bIMO8mtW7eGhGK7
Hio7+e20YlEeof7nP/9Zu3btIkWK0LpFGVrC++677yJliGQxX5V4+/btMylH
x+IX+ao0o32cJpSC8oiQsWPHFipUiE7qyVJmnwYFBSFEHA0j4wVPadZXhX4t
ZGUv8l27di39vXfvnpubW2Bg4P8U4KJq1araVdW5AFKrW7cuuPmjR48o5Nat
W+DaZcqUASsk+wSzplvgxfgLtdPf//73v7RZlry0WUdj1mCN8NLa5LS0NPoL
5kvri/NOeHHdu3dvkzRRH3qgTcNo83DZWn777TcvL6/w8HBoiVYrE/7+9797
enqiXu7fv08htPi6Vq1aYtMqHcLbpUsX/BUzwJ88eeLn52fK3p5d/ozGYDAY
DAaDwWDkETQya1LOW5k4cSJtffPGG29YPKhIn/BmZe8itWLFCmvZ5ZrwisRB
/UaNGgVW5eHh4ezsTG6zQcILhgiqBe99+vTpIC94HH57RkZGlkJhaOcc/IKK
xsTEIJpJszUQQUt4wZJcXFx6WgLYgUo88DWQBfB3R0dHsdJWh/D+9a9/rVix
orxS9cGDB2AiIONRUVEoyF/+8heTZtmmwAsmvPqq0K8F4PHjx+XKlStatCiq
eNasWf7+/qbs7aZpOi4MQJsybY+clZNjibKUkcpChQqVLl0aeaGYqBQ7Ozva
yhiiIi9U0KJFi3bv3v3LL78EBATQQleYBx1LhCZjcflw3gkvbZsMwWAVCxcu
RKtEXvlFeKFqpAzzA/GMjY1t0aKFSdn4i8qishb6/AWQSgXooF7U9ciRI8Wx
RCSSTcJLRxohEPU7efLksmXLkm5Rj9evX9+zZw+uq1WrtnLlSvkALwaDwWAw
GAwGI3eAbw/eUadOHScnp9q1a8+ePdvaCJpNwgteQCe8qFZuCuSF8AJbtmwB
IXV1dYWT3K1bt2vXrlmTxBpOnTrVqVOnUqVK+fn59e7dW17WCuHnzZvXtGlT
2oALFMPipNwsDeGlnW+twSIHGTBgAHn4Ws1oswMvGD9+vCoQ7K9Pnz7gg9DG
G2+8AXJnbe+mF0l4barCZi1kKYwM/AssHkQYBPPAgQMUjgtrKYvqkKU1YhWH
Dx8OCwuDJOBuHTp0uHTpkrgFMggBwONgafj7008/jRgxAkQM5C4oKGju3LnW
Tq/OO+H9/fff58+fDxoIwg5yOnr0aDqhOF8IL/D999/369evcuXKdKbVihUr
xKIGlbXQZtSVKlXSWtfRo0ebN28OFaExhoeH//Wvf6Vwm4QXSS1btgz1i9xD
QkL2798PY8YF+p9169bBhDp37oxb+GvxcxODwWAwGAwGg8FgMBgMBoPBYDAY
DAaDwWAwGAwGg8FgMBgMBoPBYDAYDAaDwWAwGAwGg8FgMBgMBoPBYDAYDAaD
wWAwGAwGg8FgMBgMBoPBYDAYDAaDwWAwGAwGg8FgMBgMBoMhw/hxolpYO2D0
dYLOybmvLvJS6dagc25vjiAf8GrkcOEXqZnffvtt+PDhpUqVKlasWEpKyosR
yeDx0y9eV9aQF0ugwsqAqmvWrDl//nxxiHAeYfw4bwaDwWAwGAzGa4ACS3jj
4uLefPPNK1euvFz9FBzCe+LECSgkPj4+70mJSs/HNPNCc2QxCjLh/eCDD3C3
Tp06MM5vv/32xYj0JyS8wcHBoxSMHDkyKirK29sbgb169coX8ZjwMhgMBoPB
YPyp8Ouvv/7zn//8/fffc/HscyW8z2MUMhcoOIQ3Hx11Uen5mGbeaQ6J8ccf
f0C2f/3rX1kFj/AOHToUdw8ePPgiRfrtt9+gkP/85z/60X7++WdEe5GCWUN+
WYIAykWWcP78+byLZ1CfDAaDwWAwGAwGE94XiecxMlUACa+MgkZ4C4hNFnA8
D0tYuHAhwleuXPmyC8dgMBgMBoPBKIj43//+t379+uDgYE9PTxcXlzp16nz4
4YcIzJJ8eOFqpqamNm7cuHjx4iVLluzYseNf//pXSuSXX3557733ateu7eTk
VL9+/WnTph06dEiH8Iq5qQ8fPuzRo4ebmxuyhgx79uwRcX799VekExQUhOzK
ly8/ePDgzMzMrGyfWYAoxrVr17p27err64tStGrV6siRI1nPzoAVkJl45cqV
cW02myMiIry8vKpWrTpixAhrY2H37t3r06fPX/7yF0jbokWLjRs3Tp8+XSa8
KMs777wTEBDg4OCApGbPno0iWFM7IpNsX331VevWrV1dXRs0aLB8+XLSPOGn
n34aOXJk9erVodW6desiQbFWUVTNsmXLihUrJitk3Lhx+qUmqvjvf/8bVVa2
bFk8jpAFCxbQUD6l3K9fPzlNlBoy0NAq4cmTJ/b29tCbtminT59u165dmTJl
kHinTp3Onj2rojlpaWkdOnTw9vZ2dnYOCQnZsmWLXGoZ9EnBYtFkwnvhwgVk
5O/vX7RoUWTapUsXebo7zAbGU6NGDUdHR9TyG2+8sXv3bovZGdGMRUqrtUlr
mf7xxx8wZh8fH7nIsBMYABpOjuodj/Tt21dwwB9//BEXeAo5lihRomXLlklJ
SXK5RHtPSEho0qQJzBjR0IrPnTtHt0Qzx4N+fn6dO3fWt2p9deWvJWRZJ7wf
ffQRwlesWEF/0RfNnTsXyvTw8IACUQUQCWqXZYY+0ZZhLd27d7emTyNlF+lc
vnzZiGKt9Z8MBoPBYDAYjOcHYm0gC0OHDoU7DVccfz/44IMsDeGFhwY6CUoY
FxcH9xUh8OuePn0KhlitWjX8rVWr1pgxY6KiouBnVqhQwSbhBbkG5Xz77bfh
bcbExBQpUqRQoUKnTp1CBHjRoLqUaWxsLPzSwoULly5d+v79+3Aa4UXj1vz5
8/fv3w/mBXoLZxt+5qBBg+B7V6pUCels2LDBJuFFqXHdvHnzpk2bgkyBceMv
KIOWqIKWwh/G3TZt2kyYMCE8PBzXVEYivN988w0cbLiy/fv3nzx5Mvxe3EKy
//3vfy1qAAVBBPjSoD89e/YEwaHUBg4cSBHgt5NT3bZtWxSqYcOGuAY1lr9F
4Ck42/DtQfbxt3fv3lAIaIURwgu1N2rU6P333586dSrcb4TAnxcpb968GcUU
aYJB4Przzz8XCa5btw4h9GFBxscffwzlozrwIFQK2SAhKI+gOYmJiahKlBrC
jx07FlQat1DFFrV048YNWQy5aILE7du3DxfIFHGmTJnSqlUr/AXH/Pnnn0nP
MAyEoEZQ0h49eoAPIrIgIzKMaMYi4VXZJIiMTqZUInA98fiuXbsQsmbNmhzV
OxIfP348MSncJS6J+FA7LMrFxQUNCnab9SzhHTZsGK5RL0gclBxy2tvb00xs
auZov7BktL45c+boW7W+uvLXErKsE16kj/CrV6/iGoKRxtC0J02ahA4BXBt/
Fy5cKFfx6NGjUS6YSkREhEV92mzRqnT+9re/2VSstf7TVg/NYDAYDAaDwcgT
4ILCN4ObTX/v3r0LsgB/LEtDeOGdXrx4kaLBwYYTjkC493DwcNG3b19B7q5f
v+7s7GyT8AKguiJw3rx5NIonrtevXy/ufvHFF/Cf33nnnaxnqQeoMRgu/FI4
qBTzxx9/9PX1hcdrk/D6+fnhGt4psYk//vgD3j5ClixZIj+CuyEhIQiHDy8C
t2zZQkUgwgttODg4kNdNj9CXhE2bNlnUQEZGBj0Ot59C/v73v9eoUQMhpGTS
wJgxY0g26JZYNg0UkgZAaq5du5b1LBewWWry1cGRxUgcEcl69eplWRrWR+AP
P/xgZ2cHz18k2LJlS1iOis5///33rq6uIHdigBUqhXqppBAMZYSTX61aNTGM
juoDX0DN3rlzx6KirBVNkLhu3brhIjo6WjwCZoEQkFBcr1q1CteILERdunQp
MVNtXgY1Y1FO+a5+piChuAa3Es92794dxNBsNue63mH8Mi8Gtm7dioZMRE/o
KiUlhZqqGPHMzMxEPVaoUAEPim2QExIS6K6+Veuo6/lZwvDhw/9PAToZVDFY
LQJnzZpFcSAqZfHgwQMKuXTpEn2nkqu4Tp06P/30k347MlJ2kY4RxVrrP7MY
DAaDwWAwGM8TtM3ptm3btGORKu5DLFhg6tSpRPcqVqxYtGhR1VDFxIkTbRJe
Dw8POdPjx4+LR+rXrw8arprfGBwc7OPjk/UsuThx4gSRVjnm0aNH4+LixLRh
+ZZM/cqXL296dkUhDbw2atRIfuTevXsIbNCggSwPrmksCRqA067VDwLh4oJB
W9TA7du38UjVqlXlNEE0EDh58mRcIztcP378WNw9ffo0TTYWGhCjXbkgvDT2
RwBhIYKWZYXwZikMFwyF6gtZoGj0aUJGfHw8HpkwYYIcCB4H8yA9HzhwQPWV
Azh8+LDq44YMm4T3H//4B7Qkplv/9ttvNBhH5vHLL7/g7o8//ihqDeo1WVmb
/P/Yu/N4m8r+/+PHVJlDIpESklJSSZEIlTkZKlSilFIkSpMiGhARooSUUpIy
kykp0e1LB8eQZMjs7EZ1567O7/3bn4frsdrjOob25ryef5zH2de+1lrXWnsN
13uvYftcMhHb6X039kT1UiO0KJQRvIBZwerWW2+1yof3uW/YsEH/FCtWTI0P
vyrYLSs7g+mdQbEvrBQzbWxuzYm7VsdYXMduTQinJfn+++/bXOvT16Lbv3+/
G2r27NnembI2uw8x2vL0Oe9uPH4WbLT9ZwYAAACOpQ8++MAu1j399NNbtGgx
YsSIPXv22Fsh2Uf9N++Adn/luHHjsmXLduGFF4aMVl3QuIFXAdZb6A1ldoI4
XO7cuTP+GS7UYP0/fPjwaFOJEf3OOOMMZYSQoRTrihYt6i2xfnjnzp1DatpF
jFo4//nPf1KiqF+/fsQlYAnl5ptv9hauWbNGhS1bttT/hQoVKl68uPfd9PR0
vVujRg23BPTZ2VuHEXhDLtuOG3htOdsF50OHDtX/4T8LZT181yqnYsWKFnMG
DhwYbUG5i05DxA28tmQmTJigeFW3bl235rgwopA+derU3r17N2vWzC6pjR14
4y6ZiO0MeTf2RPv06aOXWm30/1tvvaX/586da28d9ufes2dPxbGU4HXy7du3
nzRpkvsSwC0rO1kc0bJly2xsbj2Pu1bHWFzHek0wCrmKt4MHD7ZNySX9L774
4qWXXlIyrVChgo0zJPC6RBxtefqcdzcePws24v6TwAsAAPAvCAQCb7/99p13
3nnOOeekBC/w++STTzKiZx9jHTZ113PkyBEeeNWHjBt4Y4Qye9DNukgy/hku
rLs7atQon1Ox9GpTUcYPD7wqLFiwoLdk/vz5EQOvSqzLaheUNm3aNLy1W7du
jbgE0tLSwgOvFdrDgsKDz48//ui+JQiJV3EDr3euIz7fOG7g1WizZcvWpUsX
/X/VVVdddNFF4TP11FNPRYw5Wj0s5tjzhfr16xe+oLznNL3iBl4ttNKlSyvr
Ke0OGzbs//7v/zp06OAWzi+//FK7du2U4A3mzz77rAL7G2+8ETvwxl0yEdvp
fTfuRDdu3OgSUIMGDUqVKuWuCj7sz102b948dOjQm266qXDhwio/99xzd+zY
4Z2vW265Rf9o6w5f/gcOHAgZW9y1OsbiOtZrQgjNcsqhXyayW6RLlCjRtWvX
jz/+ODU1NTzwRvzUMsIuEfc/75lasIbACwAA8O9YsmSJu/v177//HjduXErw
YTsZ/gKv3ipbtuzJJ58cckmzneI57MCrBpx00knq6rt31TalWu+djNZNtSj3
wAMPeEelGK4saWdRbV4cC8g2lSJFiqT885Lm77//PiX45B/vIFYYfkmzPeRK
S+CPP/5Q4Ao5Ya0FomktX7484hKwmw3PP/987zgnTJigwkceeSTj0KWt3osz
3X2CGT4Cb4y5PrzAKzVq1FC0tLuPQ25zNnZfc8iFrD/88IM9R1oNs68OQk51
ff3112rezp07Iy6ouIFXGTzlnw/U8gbeKVOm6P9u3bp5141jHXj9TFSfrwKp
wl3OnDl79erlLT+Mz/2nn3767LPP3Jr8+++/2w2zCp7e+bIcqk3G2/IZM2a8
8sor7lZT18i4a3WMxXWs14QQ2vxTgo9Q03LLli2blqG7V2L79u2HEXgzO++Z
WrCGwAsAAPDvUIQpVaqU6x9u3rxZ3bC6detm+A681tkLeWhV/vz5jyTwKtva
/y4PTpo0SSUvvPCCa5j96oq6+sWKFcuXL9+mTZus5i+//FKmTBnNlDrYKcFH
oboH4yhB21lsm8qpp57qncpff/1lP8cT8kQjvVuzZs2UmA+tskfFKrG6Qe6/
/3531incqlWrbHD30Cq1zc5/ff7553r57LPPekOTlm2DBg3cWbOIHXVLN3ZC
MMZcZyrw2jjNyy+/rJJbbrlFWSBiKlF80yKN8agiBTGtb4UKFXLPAvrtt9/s
fu1oP+HkbUbEwHvjjTfqn9TUVKuvyGPPIluwYIFrs/uRVi3Gpk2bqsSbMZ2j
FXj9THTQoEEquffee1OCt3m68sP43LUl2rcQ7kZgGTNmjEr69u3rna+1a9fq
s9MCd/cXa6spUKDADTfckBEpUcZeq2MsrmO3JoQH3t27d5coUSJnzpx79+61
zeqmm25y79q109p+I37EMb44ytS8Z3bBZhB4AQAA/i32OJ3zzz//4YcfVvfb
fsXjvffey/AdeH/99Vd7vLD9LJEyo+Ln9ddffySBV/386tWrpwSfH9WzZ8/W
rVurQ6s8aM9EtZN6CgLDhw/fvn37+++/nyNHDnWwNawqly9f3gVJC6qXXHLJ
gAEDFDeU+7wNUypXB1sD1qpVq3v37vYoZi0Kd/NjvXr1Tj75ZLVWHWn7oZnr
rrvukUceadKkSe7cuW3k1mVV4lDuVqdX+euJJ56wK1rbtWsX7XdF7eGxZ511
Vq5cudS11hxZJnVPQj5w4IDNSP369TVT9oAsNT7kJ5Ktsp1SVMsVstQhjz3X
PmNdyDgzDj3Ry5oRMriWUqVKlTKCOcv9GI0W6eWXX3722WfbjNj5x48//liz
rGWuOXUf1tixY6Otn95mzJgxIzzwjh492hrfu3dvrcxagW2cN998c1pampKI
Jle4cGGtmf369dMysfs6K1eubF+YfPrpp2qtsoz/JROxnd534040I/gbr1pQ
KtSq4h1Ppj53t2EqTl511VX6v06dOo8//rjmXWFTgeubb74JmS+79OLcc8/V
Kte5c2dFTm2t9nVB+GYee62OvbiO+ppgzbviiiu6HPLggw/ecsst9rXV888/
nxE8K12mTBlN97bbblPU1XZatmxZtV8br43Zf+DN7LxnasFm/DPweldCAAAA
HF0HDx7s379/xYoV8+bNq06aYqYihr3lM/BmBM/OqMuq/rxGop7tiBEjvOk1
XNzAmxHsuz711FMKC4qW6sSqG+lu7lOgqFKlykknnaQG22+bLl++XPm3RIkS
6uQrI7sLXPfu3duxY8eSJUuqa12uXDk1zJ7qbFNRKFDHdc2aNQq26hKry62e
qmVqY79tav1zxb22bdtqJJqEYoVaG3KOZvfu3Qr7qqDRKpsPGTJEyzbaYleD
rRkffPCBlpj6xpqjwYMHu581yQg+v/eBBx5Q1tMItRz69u3rzqGHdNR/+eWX
pk2bqpqW/6BBg2LPtc9YFzJOq2ZXcbvTXuGDZwQvwb3hhhsUPIsXL96iRYvt
27d7F6N89dVX+rBUQcu8Ro0a9lul0XiboUgbHngVQNQ85RrVqVat2rRp09av
X69/VP+1117LCF70riWsd7WSv/DCC0qUzZo104dozz0Of5xX3CUTsZ0h78ae
qLn22mtTPL8BdBifu3fD1OqnxHTOOecoOmnZanLu7GrIfL399ttXX321GqNq
zZs3t1/kyYiSy2Ks1bEX11FfEyI+pblw4cLa3j/88EP3zZI+/UaNGmnPcOaZ
Z959990//fSTdiOKrtqHZGQm8B7GvGdqwXr3HrH3lgAAAMDhUTRwnfN/mXL6
8djFVY5WNne/2gwAAAAASE45c+ZMVOC1JxEdX4H34MGDp59+ert27RLdEAAA
AABAHNmzZ09U4F28ePFxFHj/+9///vzzz/369VOboz13GgAAAACQPBo2bJio
yJmamqqpDxs2LNHLwBe7ADtXrlz2lGwAAAAAAE4Mf//9965du9xPrgAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAkOSWLl36rm9btmxJdHuPst9//93N3erVqxM4EgAAAADA0dW6desU3956
661Et/co27Vrl5u7Xr16xa78559//nKI/j+8kQAAAAAA/h0EXv9ZddasWa7y
pEmTDm8kAAAAAIB/x5gxYzr+U/bs2S275cmTJ+StZcuWJbq9R9lRCbw//fST
W0TTpk1L9DwBAAAAACI76aSTLNOVKFHC/1AKff/973/Dy/fv33/gwAH/4/n9
9981iJ+a6enpf/zxh5+aPwZFfOuoBF6ffvjhh3379nmvhT6KSwMAAAAAEFfc
wNuzZ8/TD1F8UwysWLGi6ruTm4qizz77bLly5dyoChQocM0110ycOPGvv/5y
49FLN54VK1ZMnTr1kksusfr58+dv0KDB2rVrQyatADhs2LCLLrood+7cVrNY
sWJNmjRZtGhRSE2l79dff10jzJs3r9XUIBdffPHQoUN//fVXVy1a4H3vvfc0
Zmtbu3btfvvtt9atW9euXdtVrlGjhkqWL1+uynv37nUzMmDAgJCWzJkzp1Gj
Rvny5bMBs2fPftlll6kZmhdvtcNYGgAAAACATIkbeO+77z6X+z788EN3CbQF
3j179pQuXTraXcBdu3Z14xk7dqwrv/POO8Mrn3LKKRs2bHD1Dxw4UKVKlWhj
7tGjh6v5v//9zxtOQ1x77bUHDx60mhEDryJqrly5rPC6665Tdv7ll18ijsrO
80ZLzUr3HTp0iNaMSpUqbdu27bCXBgAAAAAgszIVeM844wz3vwXeZs2auZJ6
9ep17tz5xhtvLFKkiCtct26djccb8UTTrVatWq1atfLkyeMKmzZt6qb74IMP
unLl2Z49e3br1q18+fKucOrUqVbzueeec4WXXnppp06dWrdu7Y3h7ulb4Vn1
yy+/dA2oW7eunYf9448/NK2bbrrJVW7UqJFKUlNTM6IH3scee8yV582bV/Ny
++23n3XWWa6wcuXKyuaHtzQAAAAAAJmVqcCbO3duRbzFixevWrUqEAgcPHjQ
XULcpUsXN8jKlSvdIG+++aYVeiNe2bJl3Y/8bt269dRTT3WB2o3ELpy2HO0K
Dxw4ULJkSSvv2LGjFV555ZVWcvXVV//9999W+Ntvv7m2KYZbYUhWXbt2baFC
hVym1iDeGc/UU5q///57d5q4VKlS7uSsGty4cWNXf9y4cYe3NAAAAAAAmZWp
wDty5EjvW0qIsw7ZvXu3Ff7666/9+/d3gwwePNjKvRHv7bff9o7nlltucW+5
J1MVL17cpezHH3/8P//5j90R/O23364M2rRpk9WcN2+etcHFTCXxGTNmZMuW
zcbQunVrK/dm1TvuuEOzbP/XqFEj/FlbmQq8r7zySrS527lz5ymnnGJvNWjQ
4PCWBgAAAAAgszIVeJX1ItZJTU19+eWX27VrV7lyZXeTb4zAu3Tp0miTcA93
0thS/qlw4cLNmzd/9dVX3flQLxWOHj363nvvrV69uguYMQKvV9WqVb3P1zKZ
Crze+3B/+eWXkFFdffXV9pZS/OEtDQAAAABAZmUq8LpbUJ20tDSlxfBkeuSB
94cffmjTpk3OnDkjRtT69evv2bPHau7bt69FixYhFfLly+eGjRt4RYE9ZNYy
FXhvvPFGKylUqFD4Mmzbtq29mytXrsNbGgAAAACAzDqSwHvgwIGzzz7b3tJ4
WrZsOWHChDVr1iiKHnngNenp6ePGjWvVqpW7s9WpWbOm1VH4dYW1a9ceNWrU
smXL1FR3t2+0wKscWqZMGfs/b968ISeOMxV4XaTNli1b+HXI9erVs3c1F0ey
NAAAAAAA/h1J4P3www/dWzNmzHDl//nPf45W4HX+/PPPzz///OGHH3Y/cSuK
w9u2bXMve/fu7eqrqTly5IgReBs1avTXX39NmzbNlVx//fXeKWYq8Pbr188V
LliwwDueAwcOuFPe1apVOypLAwAAAAAQ15EE3kGDBrm3VqxY4crvueeeIwy8
U6dOLXGI4rO3co8ePaxm9uzZf/7558WLF7thR40a5aqNHj3alUcMvC6rNmjQ
wBV6nx/lDbze8ogjSU1NdYVVq1b99ddfwxsszz///GEsDQAAAADAYTiSwPvB
Bx+4typUqKC8qZjp7mY9ksC7c+dOV1K6dGkl6xkzZih1PvroowUKFLDyK664
IiP4rCpXs0iRIgMGDBg/fnynTp3c6d24gXfTpk1uIWgM+/bts/JFixa5ypop
5e5AIJAR/Xd4mzdv7sorVqz44osvaoE0bNjQFRYvXvynn346jKUBAAAAADgM
RxJ4f/3117POOislzAUXXOD+79Chg1XObMTr1q1bSnT58+dfvXq11bz++uvD
K5xxxhnuN3YrV65sv88bLas+9thjrrxNmzZWuHfv3pBHZtmFzdFG8sMPP1xy
ySXRGqzGfPnll64ygRcAAAAAjrUrr7yySlD9+vUjVujfv3+VQ/7888+Qd9et
W1ezZk0X0HLnzq0MePDgwcaNG9sgl112mf1g7rRp09x4XFYNn4T3iU/vv//+
NddcE5Ics2fP3rJly6+//tpV27dv32233eYq5MiRo23btoFA4JFHHnGjtVuM
9+/f70q81z8fOHCgVq1aVn7ppZeuWbPGyl999VXvLxxZ4I02ElE+1ewXKVLE
2+CTTjpJzdu6dau35mEsDQAAAADAv2/Lli0zZ85UCA1PxEdOAXPVqlWzZs2a
Pn26/vnhhx8iVtu7d++8efO++OKL33777ehOfeHChVOnTtXc+Tzf+tdff6Wm
pipiT5kyZenSpZylBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAkm/8BAAAAwHHozz//THScQrL7v//7v/8A
AAAAwPHm66+/TnScQrKzwLty5cpVAOLRlmJ710Q3BDg+rFixQtuLDjSJbgiA
o8MOgvQbkQysV0bgRVwWeHfv3h0AEM/3339vB/pENwQ4PmzYsEGbzDfffJPo
hgA4OhQutFHraJjohgCBnTt3EnjhB4EX8I/AC2QKgRc4wRB4kTwIvPCJwAv4
R+AFMoXAC5xgCLxIHgRe+ETgBfwj8AKZQuAFTjAEXiQPAi98IvAC/hF4gUwh
8AInGAIvkgeBFz4ReAH/CLxAphB4gRMMgRfJg8ALnwi8gH8EXiBTCLzACYbA
i+RB4IVPyRN4ly1b1iemgQMHJrqNsaSmplo7P/30U5+DbNu2zQaZMmVKopsf
GDFihFoyaNCgRDckqRF4/du1a9ebb77ZqVOn5s2bt2/fXmvXokWLEt0o/NsI
vF4vvvhi7MOcllWi2xjLkCFD1Mhhw4b5H2TWrFk2a5s2bUps4z/88ENribo9
VjJgwADvwu/Xr9+YMWPmz59PlIstSwXeSZMmhWykffv2HTVq1IIFCxLdNPx/
BF74lDyBd/To0SkxFS1aNNFtjEUHU2unujQRK6xZs+bxoJkzZ1rJ6tWrbZAO
HTokuvmBCy64QC0544wzfNafOHGizc727dsT3fZ/D4HXp7ffflvrUvhWXKtW
La32/sezcOFCW82SPAggGgKvV/78+WMf5t56661EtzGWs88+W40877zzolUI
Py5069bNZu3zzz9PbOPvuOMOa8m7775rJYUKFYr4KRQoUGDw4MGJbW0yy1KB
95Zbbom2tV555ZXr16/3OZ709HTbNMaMGZPoeTqhEHjhU/IE3o8++uiqQy6/
/HLbn+TJk8cVNmzYMNFtjCVu4J0zZ45V0B7PSjZu3Giz9txzzyW6+ZkOvG3b
trXZWbduXaLb/u8h8PoxYsQI1yUoV67cjTfe2KBBg6JFi7oS/+d6XnrppZA+
Ko4vBF6vevXquSNa4cKFbd2uVKmSK3RfhyanuIE3/LgwZMgQm7WE7zZjBF5r
YdWqVd2HIq+99lpiG5y0smbgrVixoq0nl1xySa5cuaywevXqPsezd+9eG6R+
/fqJnqcTCoEXPiVP4PVS78j2DEphIW+pq7wqaN++ffv37583b55io72ll5qX
6dOnz507d+3atd6htm3bZkPt2LFDL9evXz9jxgxtIOGTVoXPP/986tSpy5Yt
i7hYVq9ePXv2bHVL3GVRJjzwanCb6Jo1awKRAq9mwSp8++234bOpqaglu3bt
CnlLzdYg6kYGgleNagksXrw4vJrV1GwuWLAgWr5IS0tTq7Zu3RqIEnj1Qcyf
P3/atGlffvnlnj17vG+Fd2zUJJsdV8fNoGuAFoVe2qezZcsWTd17vk+TU4OX
L19+tFako47AG1dqaupJJ52kFUN/lXxduRZdu3btQjYBozVQ6/DHH3+8ZMmS
kE5UjMCrDV9riwbxrpluJdTeIKTE1bGV0LviRWuAbWuaI+90tZbaCNWBSfTC
Pg4QeKNp3LixrdvaDXrL3YHju+++CwSPON7bZGLsk4/WoUGDLF26VJvDwoUL
N2/e7H0rPPDqIGKtVbczEOm4oLmwCiGt1Ra6YsUKNSP8kg/vUV4vVW3WrFnu
QO+lg4gaqYO+Dsduk48mWuDVnspb7eWXX86ePbvKixQpYh0GhMiagVd9PFeo
ea9SpYqVWwfP0eajDVYbdchOL2Lg9W6z6gdqPfeOJ9pmaLTC64Cl/YCN3DYZ
685lKQRe+HTcBV53zFKqrVChgrsGTH9Lly4dcrWJCyZDhgyxwuHDh1erVs3V
ufbaa3XEtDrp6ekPPfRQvnz53LuFCxd+6qmn3KQXLVp06aWXeidRvnx5RWN7
NyTw6uCuketlzpw5J0yY8PDDD+fNm9cqnHzyyTrOBqJc0qz9pGVPoyPvrbfe
6t1z2rG4Xr16zz77rEZu1YoVKzZp0iRXR606//zzvU294YYbvP127RjdvGTL
lu3RRx8NCbzr16/Xbtk7htNPP12L0d4988wz3Tec+fPn79SpkwpdfTcV9Xms
RL0gKylbtqz1l5544glN19698MILly1b1rRpUzetyy67zA4ByYbAG9d9991n
H2KXLl1C3tJGoc7DjTfe2L17dyvRnkcp2AKy0QbYtWtXe1dr1CmnnOIu9nDf
pWtL9G4jRYsWdd8yaaJW6HoO2kitRJ0Hm6I2QL2sUaNG3AZccsklVui9oLpS
pUq2xVlvHLEReKOJFnjVW7byRx55RFuT9pM6lATi7ZMDR+nQ0KdPn1NPPdW9
myNHjmbNmrnrk0MC7xtvvGG7cc2LutwRjwvhlzRrP6ADq7Zo7yasQ7NrgzvK
T5ky5ayzznLHqbvuusvVUcf+5ptvVvPcSNS20aNHx1jgPgOvuINRkl9hnigE
XtHqZ+Vu89ECUV/OrZPaHps0aWJf1Lz55pvudgZV0P/KqgHPNvvKK6/oYGc9
w0C8zVDUq3TXJ5QrV+6jjz7y9j+zFAIvfDp+A6/rx+qQpB6CHWe1x1BWsiAs
VapUsaFc4FWF3LlzK3a5Lu4999xjdRTBrKRMmTJ16tRRX8Je9u3bNxD8JtlK
tOepWLGixmw9Cu24tm3bFvhn4N2/f7/2TlZ5/Pjxenfo0KFVq1a1Cpq6+hiB
SIF3+vTpVqKRa0bOOecce3nuuefa9+eBQ3tICwLqDJx22mlWR3s/a4nCrIVr
ta127dpahjaIlpidk/ruu+/cUOqiuP9TPIH3yiuvtBK1oVq1ai6t24MalFlK
lChhJddcc82AAQMCmQm81nspXbq0NcwWlP6qxB0s2rRpk+jVMAICb1zqDNsn
6Ode3Y4dO1rl4sWLey/y1NE/EOwqu865sue9996rwi+//NI2dq2BLVq00LHe
Kjz55JMBz3UU2pwDnj2JvPzyy4HgI3Tspd1HELsBgwcPtpfuiy/1baykc+fO
iV7SxwcCbzRxA687xlngjb1PDhyNQ8Orr75qgxQoUECTKFWqlL1s3769TcIb
eJWj7SDYoEEDO3sb8bgQHni12VqJWqipuC+Z3VbmjvKal4IFC+qI7L4dHTly
pNVRlLCSiy66SNOyNKFqkydPjrbA/QfeMWPGeHcjCJE1A6/W5NFB6k+2bt3a
+ir33Xefq1mrVq2UYM7VFlG3bl3buNTn2bFjx4wZM1Ri4ylatKgSrvUirI62
aBubBd64m6E2PSvR4DoC6oDo0jSBF4jm+A28OgjqqGQXezz88MNW+NVXX1m1
66+/3g5/tk92gVd9Bjulu2LFCusYKL3aIDpu6qUOr3bs3rdvnyKndiPqBgeC
D+GxMbjvkHv27GkldteVN/Bqv2QhbuzYsa7l4Zc0hwTe9PR0BduU4CngTz75
xOo88MADVuexxx6zEttDahdnJ5fVzoYNG3o7TurYh/QNBg4cmD9IiyvgOQfX
u3fvQPDCGHcdmgXeNWvW2Eu3M3/vvfespF+/flYSfulapgKvnXTQPsqdEbAS
LRMriXGbWAIReOOyEze5c+fW+uwKhw0b1s3DVjwpUqSIKtesWdNeuhVPfQwr
Cb+kuU6dOtZnsKu8tLVqC7WtZtOmTZqofTGlPnDg0GZra9TNN9+skqefftpG
aBc5x27A1q1bbXYqVapkFZ5//nmrYOeLEReBN5q4gVceffRRvbt8+XI/++Qj
PzTYVUnaguxSXo3BAqzbG7vAqxHapqFDrfda5fDjQkjgdaeitIXa0TktLc0d
+OxbMneU1z828gkTJliJfRGqQvvKumrVqjaV7777Ts3WjHjPAofwH3jdwVrZ
PNGrSTLKmoE3XKtWrVw1t4oOHTrUStyzLJ599tlAlEua3Xf+OjxNnz598eLF
gXiboY5x9q1y3rx57YcPUlNTbcMk8AIxHL+B9+OPP3aFimzamWi3oF7B+++/
36NHD3c1iHW0XOD1XvJkCVd7FXvpnpRVoUKFrl27TpkyxZ1UDQR3MnuD1Kme
Nm3aM888E5LdXOB15XZBlxM38GqDdUd5N9SuXbsKFCiQEnyqhpXYHtK9DHi6
MereBzxfD+ror72o9roh95jYiQPtIV0kUW/Bvqt3Z3htZrdt2zZv3rwBAwa4
kwuu8UcSeIsXL+7q2K47vKRkyZKJXg0jIPDGZd8jhQReJUpvPyFkNdOGtmTJ
EoVidyWhsoBVCAm82tLtgmR1CWYecs8991gd9aVV57bbbrMGqFds3+1YSenS
pQPBpwaleL7mitsAdbCtZMWKFXp59dVX6/9LL7000Yv5uEHgjSZu4NXa6C2P
u08+8kODjqE2FX1kY8eO7dixo43T7Y2tX12kSJGCBQvqHx1nvUfJgI/A6246
8N6Y7KKBHaDdUd7dSqCG2Une6667LhDcD7jzwtWqVXvqqac++eQT7y0Gihgt
PN54441AZgKvuw7EviVDiKwZeNVLOTtIhxJ3fYW2Eat29913W8nkyZPtwKQ+
oW0+tiHHCLznnHOO93AZezNU98PG4074yqhRowi8iY5TSHbHb+BNS0tzhdo/
PP3009obuB61u4MpJPB6H31jN7G6XzsKuXk2JfiF8w033OBO5YwZM0b95PBJ
hAReR50B7yPr4wbeDz74wF7alWDR2ulu+nAV1FG3Ae2GI32at956q2ueUYq0
Szq1rOzimZCnXltPxiUR9R/UcXIXGLuxHZXAq2m5OhZvw0sIvMcp94WPdyn1
6NGjfpDdkedWs1WrVjVq1Ejh1AZx61u0wKv6KdH1798/EPxhFHs5e/Zse67I
okWLrH+u7r19feRuIo7bALfZ9urVa/PmzVaBn6v2j8AbTdzAq63GWx53n3yE
h4ZA8M4dHYy8P9ZjkwsJvF4vvPCCt5FxA6876ex95pv3tuWA5yjv/QmAkLnT
4dhdPm2U4tu0aWNrmn2v5Tz44IOBzATe119/3WqqX5Ho1SQZZc3A672HV2uv
+6LVbluz07IRVahQIRAz8NatW9c7xdib4fvvv2+F3sPQV199ZYUEXiCa4zfw
eg+F6otaofYbr732muborrvushL/gddMmzbt/vvvd/chpgQf+rFr167Jkyfb
y4suukj7GR2gX3nlFSsJCbx58+Z11yF7v6KPG3jnz59vL+1uRMfuUjz33HPt
ZdxejRv5888/X6dOHffYH7EfgLPO/9VXX+2dit3wZUlEw9oXmGeeeaaW7axZ
sxYuXBjSeAIvInKbnt1yG+Kyyy5zq5l2O2XKlLGeqjYZbUE60FtvPFrgVXqy
l7Vq1XopjF2Wqa3V1l71tNVP0Nq+f/9+6wC7ex+spp8GBA6tkNrw7QSZNij3
pDvEReCNxs9Dq1yhn33ykR8arEkaj/bYEyZM0A7cNtjwwKsK9g2zWuW9Wz9u
4HUVvL9NoMOuFdoTM/wE3kDwwmbN1+23365l4mbEHkbXpUuXqzzsR3X9B94b
brjBak6cODHRq0kyIvAGPNvp3XffHTj0TY7WpfADkw4cgZiB17tWB+JthlOn
TvVuLMbtDQi8QDQnRuC18zjWs7USd7mXz8C7adOmYUFffPGFvavNp3r16jbU
smXL7LbcFM9twp06dYoYeO3+xGuuucZevvPOO1Y/buDdvn27XbWlrrW7vuWz
zz6zwiZNmlhJ3F6N5lElb775ptsbuBsPLYPYwjn55JPd9WwzZ860CpZEXJZ/
/fXXrYL7xjtG4HWXg7oHLLtz1gTerEMbiH0drb92oDf79u176KGHvKvZokWL
7KXCptVZunSplUQLvGJ3K3gDqbajSUFuxbMOg32xYw+Is+/E7PRuiRIlrJqf
Boj6FVZ48cUX62/z5s0TvYyPJwTeaDIVeP3sk4/w0KAOud3t7r4LVQXb3EIC
r12BOW7cOBvWO8W4gbdfv3720nt+yn1LNmXKlICPwKudjB2v3YVeWmh29YiO
a9EWuJ/Aq4Xgvj/XjiLkp5RgCLzqarqL8y1juqOb+/0sbSOTJ0/WgckeK+cz
8MbdDLXO23jUkXNDuZMsBF4gmhMj8LoHID/55JMff/yxjt0ph/gMvNu2bbMz
O0pbo0aN0tFTPQS7gDlv3rzey1fatGnz0Ucf9enTx+4lDA+8tsNRz9lGqIOm
/TKaO4HbsGFD+0o8/CnN7pmxDRo00GhHjBhhV21pr+geYxW3V9O6deuU4AO7
nnjiiVmzZk2bNs1lc9UMeB5BWa5cOU1i4MCB7nmelkRGjhxpL7XLVTOGDx9e
rFixkM6V+yDeeOMNO+Hldvi1a9dWoWKCG4rAm6U8++yzbgO84oordCzWGm53
jtvFw7aaqQNsdc4999zx48dr7XX3FLi86bbcrl272rZsZ2m1FTzzzDPLli3T
Fm0PsSxSpIj7CUJ3r2LKoa/BZ8yY4Urc5uanAYHgt2Hu0WopYd/zIzYCbzSZ
Crx+9slHeGhQH97O+eqQp/Grr27PfgwPvO4ZVu57XRfDw48LIYF38+bN9lg5
TUuHUSVc1wYdke0r67iBV0dDd6zRlrto0SIdte0oFuP++miB13oaovny/kLZ
e++9l+h1JEllzcCrld/WE/UM3fP8tTLbWrpixQrrE2oLnTt37sKFC93zH6zf
pXXbTl6o36WOt32XEr7N+tkM3RX7LVu2HDdunLfHS+AFojkxAq/79ttoR6Fu
tv1vz7Hxc0lz//79UyKxB1pq9+W99Uk7Lh1q7X91vANhgTfgeRiyPVtAR3/3
nA3t5QKRAu/27dvtyfZe2os+//zzrtlxezWrVq0KubnJ9ZRsH5uenm49H0d9
Jy2HlENJxPVJHHd/ijvR7B6HknLoKVuaHfdsfOMuDCPwZjXamtyNsY7WLvUE
tO3YaqYju12p5VxyySXWBdU6YOuqu1IrJXiCNRA8utmTo7zU/XDfCMm3337r
bnW0b9c1lAut7odL/DTAuKsXzjzzTHcZCfwg8EaTqcDrZ5985IcGdyGTUWXb
G+sYZM+jCAm87nvdIkWKbNq0KRDpuBD+s0Q6Vnp/C8+UL19+2bJlVsHPJc32
JLoQ2ufMmzcv2gKPEXhDaDPnF3hjyJqBN9xFF13kfhQsEFz5vV+YGLt/3NiD
Uo09tC3iJc1xN8OvvvrKexl/SvB7HvuHwAtEk5yBd9euXUOC7GkAXrNmzbK3
7IHtzqRJk5o1a1azZk3FTM2UwpdVs0ukdCS1l967jSZMmKCS1157zZV88cUX
2js1bNiwatWq2gXde++97grnQPB8kIJb9erV27VrN3v2bDXAxmkPlly7dq29
dINs3brVSoYOHWoP6Jg5c6Y6JwrjN954YyCYnqxCSIdHc609njohDRo0UG/B
PanSaGwa5IMPPnAl2vvZeLTJu0kPHjy4RYsWGoka3LJly9dff937kJBA8JfQ
NTuqoNnUYtFENQb3Rb32q506dapRo0arVq3sx5X0lk3FHsupbv/TTz99zTXX
aAz2o6WB4PMDFd411E033aR2ukVkv9wkGpVe2v1irhkRS+y5msmGwOtfWlpa
796969evf/nll2treuaZZ7777juVDx8+3L7xDgSX5xNPPFG7dm1tFwMGDNAq
qhXb1hl3vb3WBA1+5ZVXPvTQQ1aSnp4+atQorb0q1IB9+/YNv6nW1jRxz251
Jd4k66cBAc/vHrqnXcEnAm80OjbZmuaugTTffvutldud5k7cffKRHxq0V1dl
bbN16tTp2bOnNiu1wcZgP5iiHbX+dxdFB4KbhvfAF35cUCKwCvY7Ykb/9+rV
S4cJbcJt2rQZNGiQd6uMeJQPn7sZM2bocHPddddpD6Ojdo8ePXQUjrHA3Whd
N2DkyJFDPLRf0oeyatUqvtSKLUsF3unTpw/5J62K77zzzmeffRZeeenSpZ07
d9bmo2NKx44dvY8iDwTPArdu3Vo9QG1ithKGr9UBH5thILgFPfLII6qgNf+l
l15SF9eOUAMHDkz0Avu3EXjhU3IGXiA5EXizJndBqXaYiW7LcYbAC5xgslTg
TTY7duzoFaT86woVnO0INWPGjEQ38N9G4IVPBF7APwJvVjN69OiWLVvazVn2
/CtkCoEXOMEQeBOrcuXKFm+bN28+cODATp062Q1EVapUyYKdeQIvfCLwAv4R
eLMadyf++eefv2LFikQ35/hD4AVOMATexNq4ceMdd9zhnpsqefLkad++fcjN
EVkEgRc+EXgB/wi8Wc3q1avnzp2bNTsSRwWBFzjBEHiTgfrtq1atmj9/vg5S
7lEVWRCBFz4ReAH/CLxAphB4gRMMgRfJg8ALnwi8gH8EXiBTCLzACYbAi+RB
4IVPBF7APwIvkCkEXuAEQ+BF8iDwwicCL+AfgRfIFAIvcIIh8CJ5EHjhkwXe
LVu2fA8gnm+//Vbbi7aaRDcEOD6kpaVpk1m3bl2iGwLg6Fi1apU2ah0NE90Q
4PvvvvuOwAs/LPACAAAAwPGFwIu4LPCuW7duAwAAAAAcD+wiIgIv4rLA+9tv
vyW6IQAAAADgyy+//ELghR8EXgAAAADHFwIvfCLwAgAAADi+EHjhE4EXAAAA
wPGFwAufCLwAAAAAji8EXvhE4AUAAABwfCHwwicCLwAAAIDjC4EXPhF4ARw7
P/74Y6tWrV588cXwt4YOHaq39NfPePr27dupU6dEz80x8eCDD/bu3Tt2nenT
p7/yyivffffdwoUL9U9qamqMyrt379aC/fDDD49Fax977LFWMX3zzTcJXJgR
/fzzz2rYe++957P+nXfeOXDgwES3Oqp169bdfffdTZs23blz57EY/4EDB7S4
3nnnnUTPKADEQeCFTwReAMfOrl27UlJSGjRoEFLevXt3K/e587n22mtLlCiR
6Lk5JsqUKVOzZs3YdbSgtLimTZvWsWNH/aPMG6OyIqfqPPvss8eitXfccUfV
QypVqqQJnXbaaVU91qxZk8CFGdG+ffvUzscffzxahfvvv3/cuHHuZYECBZo0
aZLoVkf2999/lyxZUi28/fbbd+/efSwm8cMPP2hxPfLII4meVwCIg8ALnwi8
AI6d8MD7559/tm/fXoVt27b93//+53M8mzZtWrt2baLn5pjwE3hnzpz56quv
bt26dfHixfondqj8448/Vq5ceYzSkNfq1av1OerT/JeXWGbFDbwnnXSS8qN7
mZqaunnz5kS3OjLboI5pGiXwAjheEHjhE4EXwLETEniVxW666SaVdOvW7e+/
/w6vv23btrlz52qnFJKFf//99wMHDtj/Bw8e1DFO//z111/Lli2bPXv2xo0b
w0eldzds2DBnzpy4SfmXSNTUjOAJNf2vKUZrjFG1devWKY1auSqE7FRjNMYF
Xg27dOnSRYsWBQKB8Ebu3bt34cKF4btr79LQ4N9//33ENv/666+fffaZpm6L
PbyCSr744gtNQhPy+eFGC7x//vmnxqb26H9lc+8s//TTT5qFWbNmrVixIrwB
VqJ1QJ+p5kWLMWTM+/fvX7JkidaQiBdORxt5eOBV2zQ5LUmtZvpHgbd169b6
Ry23DyJk0v/9739Xrlw5f/788KuIVVnv6p/09PRPPvlEH58CY9xFpxlZsGDB
1q1bQxaXt82q8Pnnn+uD837WWos0L08++aQG+Tso9vrpc2P58ccfP/30U3Ua
1ZiIgde+RdGS37JlS7TPWh/0zJkzVS3ipg0ARx2BFz4ReAEcO97Aq6573bp1
9TLiLb06YF100UUph5QoUeKDDz5w72oM7pLm559/XhXUry5Xrpyr37hxY4uo
RqnnjDPOcO9ecMEFX331VbRGpkRiHX7FWP0/ePBgb/3rrrvurLPOci+//PJL
vbShcuTIocoK9ZoXn42xwDty5MicOXNahdy5c48ZM8ZV2L17d5MmTdzgqta7
d2/3hcCzzz6rQuVcjUf/jB07dvv27d5LmpU++vTpkz17dhv87LPPVrD1Xhet
fPTggw9my5bNjb9Dhw5+DgrRAq/mV+XK19dee63+ue+++zKCmfGhhx5y8yjF
ihWbPn26DWIhS4tOk3YVihcvrqZaBUUqjcc7+DXXXOO+GYg98pDAq1ysYbWQ
VeHdd9/1fuhquSqcfvrp7pJmLb3hw4fnyZPH1bn66qu//fZb78d3++23Dxo0
SKnZKqiyPoVoC01bgcK1G1uNGjXee+89/aOA7z7uhg0bugr58+d/7rnnvGu+
sy4o9voZd2PRp3///fe7twoXLqztzht4tQS0qmhxuTr16tXbsWOHvauMrxIt
yVq1arkKlSpVchUA4Ngh8MInAi+AY8cF3vT09CuuuCLapZLKa3nz5j3vvPNm
z56tDv+iRYuqVKmiynPnzrUK4YH3nHPOee21137++WeN+bbbblPJqFGjrIIG
18vatWsvW7ZMDZg8efKZZ56pGPLdd99FbORn/3T55ZcrHs6cOTPDR+DdsmXL
ySefrDRhp/8UFooUKaJ5cYE3bmOUmJSVKleurL2x0secOXNUQSV23lBx49JL
L82VK5cilaaVmppqM9urVy8b3AKvQrRi10cffaRJhATefv366WXHjh01L998
803Xrl3VPG/gveWWW5TTtVTVpI0bN/bo0UPvKrPH/XBjB141SSFIaW7Dhg0q
VGpTYZcuXTQVtXDKlClahopXdjbQAu8ZZ5yhpLl582bF+Y8//tgWi43z5Zdf
VgU1XktJI7SZcs8xiz1yb+DV2nXxxRcXKlTIorTWHy0WLd6mTZvqHzud6g28
Wsc0rD5xHSi1lirJKoFq5O4UsD4+NVsf94oVK9RsVdPHpxFGO6reeOONWtr9
+/ffunXrqlWrtGLbx2GB9+DBg+eff75aPn78eGVGBVXV17v6dDKCJ5FtdXrw
wQfVWoVWn4E3xsZid4W3adNG09Kn/8QTT9h3I247femll/SyQ4cOaWlpWrbD
hg3T2lu+fHlbPy3waglotdm7d6/m+sUXX1TJXXfddYS7DgCIi8ALnwi8AI4d
C7yXXXaZ4o9yRIECBdQ3Dr9otl27dko33hNnqlOwYMHq1avby/DA27NnT1dZ
KcbSkL1USlKH33vV8VdffaUK999/f9wGP/roo6o5cuRIexk3UNxxxx0KCN7L
RBVpNYgLvHEbo8SkBLRp0yZX4ZlnnlEFy4l2+q9Pnz7eBlSrVi137twKLxmH
Am/btm3du97AqyCZL18+BU/v4DfccIMLvF9++aX+V8zxVrCbrOM+fip24NWM
WyYyiqitWrXyXrirSKVqe/bsyfAEXu/BSCH0lFNOsf9vvvlmVfAuRi2TV199
1c/IXeDVCqalXbJkSWU3b4ND7uF1gVcB9rTTTitdurT3muE333zTu0pohFoB
7MMyffv2VYWIF9Lb0u7evbsrUWjViu0C7/Dhw/X/Rx995Cr8+eefl1xyiT5E
O6cf8m2Gz8AbbWPRWqfGX3vttd7B7777bhd4bf3RCuOtoMWuCvaYLwu8devW
9VZQ5K9Ro0YGABxjBF74ROAFcOxY4LVzTOpdWxisU6dOyB2Lelf56Jt/qlmz
Zq5cuaxCeOD99NNP3eC///67nfbKCJ6z0/+tW7cOGZuSi3J37NYqOKQEb5B0
JXEDhVp+5ZVXet/VrClAWeD10xglpgoVKoQ3Q5PW/w899JD+t5s9HUsctgQs
8Nr5aOPNRAsWLND/3gukMw5FNgu8/fv3t0tSvc1T3lfhG2+8EXtxxQ68ISHd
S7PzzjvvaNGpmtaQjEOB95ZbbvFWUwjVkrT/7TzjVVddNX78eBvE/8gt8DZu
3LhYsWJ2sjJkkGiBd+PGjSFpMSN4EjZHjhyuqfr4ypYt662gBauhtHDC22ZL
O+RXpTp37uwCb8uWLU8++eT169d7P4777rtPFaxHd3iBN9rGMnHiRP0f8oNN
dsW7BV5bfzQSb3s+//xzFd57770ZhwKvPh3vGCpWrKhPKgMAjjECL3wi8AI4
dizwKn24kGLde3dFbkbwHJa7gTScXWUaHngtDxpvH37lypXRRnXuuefGaOrb
b78dfilm7EChlmfPnr1Vq1Yho9L8WuD105jwpzR7A2+zZs20cEK+H1C8TQne
rptxKPAqIrl3vZno9ddf1/9KJd7BLcVY4LUrWiOK+1u0sQOvlqe3MD09vXv3
7ldeeWX+/Pm10C688ELF/JDAa5+g4w28WtRKi+5eaS20bt26Kcn6GbkFXlGM
vf766/XPnDlzvBOKFnjnzp2ryu48slOqVKmqVau6jy8k3MUIvLa0Q55qZSnY
Aq9dyR/RokWLMg438EbbWOzy4+XLl3sH37lzpwu8tv5EdPPNN2ccCrxvvfWW
dwwEXgD/DgIvfCLwAjh2wn+W6I8//rjssssU4tz9uVK4cOH69ev/EIndhuk/
8FoiUHc9fFQ//fRTtHYqo+XMmbNx48b2nF4nYqBQsHKBolChQnXq1AkZW8GC
BS3w+mlM7MBrEcklO2OnaKdNm5ZxKPB6n1rszUR2Sn3ixInewe2pRBZ4H3/8
ccvL4S30XpAcUezA++6777oSfYj60HPlyvXAAw/MmzfPjji9evXyH3idtLQ0
pTCtD1qFypUrp9Up7sgt8DZq1EgfrtKcPrIzzzzTmzqjBV77viL8F41z587t
VulMBd6ePXvqLe/l6xmHrqK3wKusWrx48Ygbgv9Lmr3rZ+yNZfz48XZ+3zu4
uo4u8E6ZMsU+yvD22OXlBF4ACUTghU8EXgDHTnjglc2bNysSnnbaae5Rrkp8
Z5xxhvcxy0oxXbt2dScZ/QfejGDeDAmh6enpHTp0CLl00/nyyy/z5MmjmBC+
J7RA4X2stPr5BQoUcIGievXqeumN0qtWrUrx3MMbtzGxA+/QoUP1/zvvvOOt
0KZNGxXab8XGDrxKsuGnre2pvBZ47THF3gdiy4cffqgYazfAxuA/8CriqaRz
587eal26dPEfeJ966in3sGJz77332uXBcUce8pRmLcyUf971HC3w6rPOmTPn
1Vdf7R3zkiVLNHiPHj3cx+c/8NpVBO6BUcYe5maBt1u3bgryIb8CPGjQIGV5
++YnYuCNsX7G3lhWrFih/++55x7v5OyMswVerVf6X5HcW0HdBn3oy5YtyyDw
AkgoAi98IvACOHYiBt6MYKRSudKinbeaM2eOXjZr1swuYFahnQtzV5NmKvC+
8MILduulna7VAdEedet+48Zr48aNhQsXLlmy5Nq1a3d57N+/X+8GAgENqEhi
T+VVw+yUqwsU06ZNs8s7rYKGqlatWkrwkU0+GxM78P7888/KX6VKlXIBavz4
8cpELVu2tJexA68ouym1aYHby9mzZ59yyimqMHz48IzgCffy5ctrEu5ncZYv
X16oUKGLL7447ofrP/Banr3++uvdCXS1x37rx25Pjht469Wrpwrz58+3l1rO
NWrU0HxpecYdefjv8LZo0UIlU6ZMsZeailueGf98SnPXrl29iXLLli0XXHCB
Rq6F7D4+/4H3v//9r+oXL1585cqVVmL3Jovlx23btuXOnVsLX/9YhQkTJmTP
nt0t5JAPN+76GXdjqVOnTo4cObRS2ctPP/20YMGCKZ6nNDdv3lzLx12grgZc
eOGF+fLls9+EIvACSCACL3wi8AI4dqIFXnnggQdSPE+sVc88Z1ClSpVOO+20
lOAv6dhZrYxMBt6DBw/eeeedKcFfRFV2UOdcox0yZEjEFtoDoMJVqVLFKtgj
ixVSFA3UBrWkQ4cO3t/hffTRR5VA8+bNq5YrGmiOypUr587qxm1M7MArCxcu
tJ/xVTJVM/SP6rt7ouMGXr20O0MV6s855xyFWbtz013nrKOA/UirZur8889P
Cf5Wr/eJ2dH4D7wZh5KjwlTt2rXVjLJly9rvH2mZfPXVV3EDr/ozBQoUSAne
D37eeefpn1y5ctmDguOOPDzwqkSpVquZPTC8dOnSJ598sj4yS53ewPvTTz/Z
jyAXLlxYOU7ZUwtw8uTJ3o/Pf+CVpUuX2mOZ7XuGChUq2HPJ3HXOSuuahEo0
m3bP8tVXX61OXcQPN+76GXdj0QetpaSSokWL6nNPCd5fr/G4wLt79277jd0i
RYpcdNFFWuz6INz9CAReAAlE4IVPBF4Ax87//ve/lStXhlyiaZQE9Zb3OLVh
w4aRI0eq/9+/f3/tmryVNQb3Oy979uzRgN47TJWLVfL99997B1F4UXLU2JQu
Q55y7LV///6VkXh/aGbmzJmKSwoCM2bM+PPPPzWhkB+dWbFixQsvvPDMM8/Y
43AVWNq0aeOzMWlpad64mhH8SaaQGQwEAhMmTOjZs2e/fv0UJ933ABnBPKLK
3qvBbcGq3PspvP/++wrmSvfbtm2z0+v2ECSjQ4AqPPnkk5rN9957z/srPDEo
OmlC7lyk8/PPP6s85NFMMn/+/Keeeuqxxx7TJDR3f/311+uvv969e3fNvpZq
+CeoBeVdPX788UfV10LQICNGjAh5VnPckYfU17RUaOfxN27cqI9PlS3mr1mz
JmSNXbBggdZJhWhFbO+CjfjxKU1rzO6HesNpyYwZM0Zje/vttzVTanPKoYez
uc/0zTffVIU+ffp4b3WP+OHGXj/9bCx694MPPtAYXnzxRTvRr8F37tzpHWT2
7NnPPfecFpGWqtrs3lJvU2Ozs72OPWXazyoEAEeCwAufCLwAcNgGDhxYu3Zt
b1qx31q1O2QTTlG3Xr16vXv39hZ26NAhT548lvXwb1KyrlmzZsgzxCpXrlyx
YsVENw0Ajj8EXvhE4AWAw7Z48eKcOXNeddVVkyZNWrRokXJu0aJFS5UqFeME
37+sffv22bJl6969+7x586ZNm2b3eD722GOJbldW9Ndff11yySUFChQYMGDA
p59+qnXmhhtu0MfhvUYaAOATgRc+EXgB4EgsWLCgTp06p556qpJv+fLl77nn
nqQ6eXrw4MHnnnvuvPPOs7svL7/8cvsBXyTEvn37HnjggVKlSmXPnv3000+v
Xbv2woULE90oADguEXjhE4EXAI4K7621SSjJm5fV8HEAwBEi8MInAi8AAACA
4wuBFz4ReAEAAAAcXwi88InACwAAAOD4QuCFTwReAAAAAMcXAi98ssC7Y8eO
vQAAAABwPNi+fTuBF35Y4AUAAACA4wuBF3FZ4F23bt0GAAAAIDrrN65duzbR
DQE2pKWlEXjhh+24du/eHQAAAACiU7hQv/H7779PdEOAwM6dOwm88IPACwAA
AD8IvEgeBF74ROAFAACAHwReJA8CL3wi8AIAAMAPAi+SB4EXPhF4AQAA4AeB
F8mDwAufCLwAAADwg8CL5EHghU8EXgAAAPhB4EXyIPDCJwIvAADICjp16lQ2
TLly5apVq6a3Nm7ceOwmPWfOHJvcqFGjEr0YjsiJFHivuuqqstHpI1Od1NRU
e9mqVauQwa+44gqVn3feefZy69atEcdToUKFevXqjRw5Mj09PVpLli5d+kgk
+/fvjzbI5MmTtdLWqVOnSZMmPXv23LBhQ0iFcePG3XHHHddcc03z5s3Hjh2b
6IV9TBB44ROBFwAAZAU33nhjSnSlS5fevn37UZnQokWLSga9+OKLVvLhhx/a
VFzJURntv+9ECrxnnHFGjPVBH5nqaGbtpdJxyOBFixZVefbs2e3ld999lxKT
Amy0lvTu3TviIHv37g2vrODctm3bkJp58uSZO3euVdizZ0/dunVDKjRq1Gjf
vn2JXuRHGYEXPhF4AQBAVuACb/fu3Uce8vzzzytCWnn//v2PyoTmzJljI3z8
8cet5KgE3vDR/vtOyMA7MpJ169YFDivwlihRwo1k+PDh9957r5XnzJlTAS1i
S1q1aqUKlSpVqvdPEc/wjhkzxkbYpEmTiRMnagXWmPWyQoUKVqFnz55W4Z57
7nn33Xf1114qVid6kR9lBF74ROAFAABZgQu8M2fO9JaPHj3aytu1a+cKN2/e
PGjQoA4dOrRp06ZPnz7r16/3DpKenv7OO+907ty5RYsWHTt2VM1t27bZW0uW
LHnqqadshM2aNXvzzTcD/wy88+bNe/jhh9u2bauhNm3aFNLITz75RIPffPPN
Gq2GdWflIo5Woaxb0EcffaRRPfroo7169bL6a9eufeaZZ+64446WLVved999
b731VsgJPoXWIUOG3H777Rpq6dKlGr+NavXq1TGW4QkZeGPUOYzA6y5ydjSs
vbV48eKIU1HUDV8to9E6qconnXSSO//bsGFDG78F6nPOOUf/X3PNNW4Qq1C6
dOkYl1Ufjwi88InACwAAsoJogfeNN94Iueh06tSpxYoV814RevLJJ6uavbtj
x45q1aqFXDJaoEABJVm9q3TpLbdA5AKvYkiuXLncuyVKlFiwYIGNVmHEnQ10
Lr744rS0tGij/fTTT+3l3XffrTijf6699lqVT5gwwTsVoza7M4xKtRdccIF7
K3/+/BajxO5djYbA6/gPvNWrV7e37KMMsW/fPq1dejc1NXXs2LFDhgzRRxDj
8uP33nuvX79+w4YNcyUWqMuUKRMIXs+cLVs2vXzggQdchWeeecYasHLlykQv
9aOJwAufCLwAACArcIFX/f93D3nllVeUFFR46qmn2snNLVu2WJapWLHixIkT
x48fr3/0MkeOHF988UXAc8flbbfdpneffvrp0047TS/Lli2rd1XH5YvmzZsr
ewY8gVeUNPv06XPrrbfay3POOcdO1Y0YMcJKFHuVuHv16nXSSSfpZc2aNaON
1gXeU045JWfOnIpad955p7JSwYIFVViyZEm1TaNVCrZqdl5Y3D2eTZs2VWMU
q13zsmDgrRmmc+fOVucwAu+ZZ57p1i6tHt27d7fyli1bRmzGl19+aePRGug+
hcqVKy9fvjx2+7WiajW4/fbbVT9fvnyTJk2y8sKFC9sn62pqRbXRzp49O9FL
/Wgi8MInAi8AAMgKYjy0qmrVqsuWLbNqCoBWuGjRIitZsmSJldxzzz16qeRi
L0ePHm1ZVdHmvvvuu//++3ft2hWIeQ9viRIlXFp0J23HjBmjl2effbb+v/TS
S12D27dvbxWUiSKO1gXeYsWKuZN3aWlptwS5BKTYbtWefPJJvVywYIG9bNas
mVVQsxWWs2zgDWdfMgSO3kOrevToEfEJVAHPPbllypS566676tWrZy8rVqwY
bRDj1gfRUO7y+EaNGtn3M0OHDl29evXw4cPd6X6tqIle6kcTgRc+EXgBAEBW
4ALvqaeeWjSoSJEidv2n0sEzzzxj1ewJQnKLh3KNSmrVqqUKL774ogsa+fLl
U9bo27evy8uBmIHXe6GpndqTBx98cPv27fZ/2bJl3USvuOIK75nZGIHXkrjX
V199NWDAgNtvv71SpUrWeDfgyy+/bC9dIhbNQpYNvL3CjB492uocRuDVulT0
EK0e7osO7xriNXfuXE3x6aef3rx5s5V07tzZTz5dv369VtpmzZpZ5fLly9tj
xlesWOGma+ySaXFPcj4xEHjhE4EXAABkBRHv4V27dq3druueAlSjRo1o5+lK
lSqlCvv37x87duyll14a8m7z5s3toUAxAq/3SbkKOC5ZL1++PMb5QaWhQMzA
G/KTN506dbJyxbFy5co1btzYO6C7yFaDu0HcecYsGHhj1FF4jB14FW/tZbR7
eF966SUrb9++vc+GzZs3zwaxM/JxPfbYY1Z/6NChVrJq1Sqt7UrZhQoV0tql
z90qxH4i2XGHwAufCLwAACAriPbQqvr161u50o1etm7d2uXfECGPEkpLS3vl
lVeaNm1qN9vKBx98EIgZeNu2besGd9WUa9R1t3PNd999d/h0o+XoiIF3+vTp
VtisWTN7uLQLUCFneN0tvQFPaCLweu3YscM+F3sklLNr1y47b37WWWdZSbTA
u27dOiv3PjbZa/bs2Vo9PvnkE1ei9dMGifgjVl27dm3cuPG9997rStyK8cQT
T0ScxJ133pkSvLDhBPspXgIvfCLwAgCArCBa4L3++uut/LPPPtPLgQMH2suP
P/7YKqSmpirVKmXoLWXPa6+9tmrVqt6riIcMGeKNkC6AdO/e3Sq4wJsnT56l
S5eqRF0v9ywpy5j2aCz9tRuBRWm6cZAl8fDRRgy8rv3uQb7uElkLvIsWLbKX
l19+uQJdIBhjTz/99CwbeOdHojm1au7u5r59+1pg1EJzD7XWp2PVogXetWvX
Wvlll10WsRm2GuTPn9+e4bxnzx53Rt6e+z137twOQXaFs30hkyNHDrvHXCuk
a4w9yqxBgwZFixYtX768/VSWuvr2OKyOHTsmepEfZQRe+ETgBQAAWUG0wKsw
a+XTp08PBKNouXLl9DJ37txt27a98847LRnly5fPntLcpEkTq1+5cuV27dop
nligKFiwoD04SJHWKpx99tk9e/YM/PMpzcq8tWvXLlWqVEhimjx5spWcf/75
999/f/369e3cYt26da1C+GgjBl43LWUojdzdCJwSfHSS1XEntUuWLKnA5b3l
MwsG3ojcuXitFe4maH12WmLuhL6WsDrSVi1a4HUXriuBRmzGW2+95cZWo0aN
EiVK2Ev3VOdhw4ZZSbdu3QLB7yvsIVRqxpVXXmnPGLevSuzrC/eNh1bLq666
yj7cU045xR59diIh8MInAi8AAMgKogXep59+2sobNGhgJStXrqxZs6Y3/lx8
8cULFy60d7du3dqoUSMXgoxyx4wZM6zCvn37LrvsMisP+R3e9u3bKzG5oZo1
a2an4cxrr71mvyljlGgUt90J3/DRRruHV2HNjaRYsWLjxo1TUtP/5557rv0U
r4K5exqwJeguXboQeCMG3kDwGuOqVauGVNDaYl+AmGiBNz093X4iOVu2bO+/
/37ElgwePLhQoUJuzDly5OjUqZM9gSoQFnjl7bffdrnY1K1bd9WqVW6E3bt3
dw+qkqJFi3ofUHbCIPDCJwIvAABAuOXLl7/55ptjxoxZsmRJ+LtpaWmTJ08e
MWKEKsydO3f//v3ed/fu3auIMXz4cNUJGVBBZvr06W+88YY7ORjyriLnq6++
qsE3btwY8m6M0YZQFlN81oSihVMFsaVLl44ePXrq1Kmq427s9Ya4cCdS4M0s
JUr7xLXE7PLjo2jbtm0zZszQ5/7RRx+Ff+7hlPW01o0aNWrixIl2xXuI9evX
v/vuu0OGDFGbT9R+PoEXPhF4AQAAso6FCxeeHdSkSRO7KfXbb7+tXLlySvCq
7JDkHiIrB14kGwIvfCLwAgAAZB0Kue4e3gIFClx88cV58+a1K2knTpwYe1gC
L5IHgRc+EXgBAACylPT09HfffbdFixbVqlWrVKnSdddd99BDD6WmpsYdkMCL
5EHghU8EXgAAAPhB4EXyIPDCJwIvAAAA/CDwInkQeOETgRcAAAB+EHiRPAi8
8InACwAAAD8IvEgeBF74ROAFAACAHwReJA8CL3yywLthw4ZvAAAAgOis37hu
3bpENwT4Zv369QRe+GE7LgAAAAA4vhB4Ede+ffv2AgAAAMDxJj09PdFxCgAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAACA5LVv3769AAAAAHC8SU9PT3ScQrL7v//7v/8AAAAAwPHm
66+/TnScQrKzwLthw4ZvgESztTEtLS3RDQG+0QFUa+OaNWsS3RDgm9WrV2tt
TE1NTXRDgG/Wrl2rtXHlypWJbgjwzfr16wm88MMixu7duwNAolnE2LZtW6Ib
AgTWrVuntXHz5s2JbggQUL/OvppOdEOAwJYtW7Q2rl69OtENAQI7d+4k8MIP
Ai+SB4EXyYPAi+RB4EXyIPAieRB44ROBF8mDwIvkQeBF8iDwInkQeJE8CLzw
icCL5EHgRfIg8CJ5EHiRPAi8SB4EXvhE4EXyIPAieRB4kTwIvEgeBF4kDwIv
fCLwInkQeJE8CLxIHgReJA8CL5IHgRc+EXiRPAi8SB4EXiQPAi+SB4EXyYPA
C58IvEgeBF4kDwIvkgeBF8mDwIvkQeCFTwReJA8CL5IHgRfJg8CL5EHgRfIg
8MInAi+SB4EXyYPAi+RB4I1txIgRH3/8cbdu3dasWZPotpz4CLyxaVXUCjlo
0KA5c+Ykui0nPgIvfCLwInkQeJE8CLxIHgTe2N5999358+cPGDBg48aNiW7L
iY/AG5tWRa2Q48aNW7JkSaLbcuIj8MInn4FXm+1V/7Ry5codO3bY/9WrV2/W
rNmYMWOs8rRp03r06KF/9u7dq3+qVKlSuXLl1q1bh3/1qi5lhw4dLr744kqV
KrVr127t2rWxmzF+/PjXXnvNW6KjW5MmTaK9xPHFZ+DV6urWw7p16/bp02f/
/v0a6tZbbz1GDfvss88effTRIUOGaJWOVmJeeeUVbRr2/4QJE7p27frCCy+o
e+Cts2fPnqFDh3bp0uXVV1/1Dj5lyhTv8XHx4sWPPfbYSy+9tGvXLu/gmtk3
3nhDY3aDa4Sa7kMPPaRtMD09XZO7x+OBBx7wDj558mT3lv5XiQYZNWqUNtW5
c+dane3bt6vZjz/+uPYPIYti06ZNeuvhhx+ePn16tMoxBj+O+Ay8qampbm2s
X7++2w3GpZFrHTi8tmkTaN68eUhhw4YN4w54VHaPPXv2tPmtU6eO1oSQ1TuG
ffv2aRv3U1Nr+NixY70l2vNr/5/Zpvbt2/fEOMniP/DWqlXLfTqafW3dfsZ/
JGujaN8bst/2szbefvvt33777ZEvnC+++EKbgzoSNWrU6N27d8g+2Vnx/9h7
8yefjvb/353IHQlCENzEHoIgGDIYO7GH2GIX+xLEvsUegoxlMIh9C2JfgpvY
Y4ngrSiFt1JUvt74KFnO3/B91Llqruqcfr3GmbHMi/Tzh6kz/erTp0/3s6/r
ep7Tp/vSpSe8UMSb+vnnnydMmPDkd/ECIbzg7dOnj7ARWuKJwj/NfhJLZbMR
bp8/fz71s56WrWCQEtbGxcVVrVp14MCBv/32W8RstF7As6cVEdn4TAOh2IQT
vA4hEVLw/ve//42Pj/8/AyIx3nzzTfmX+B9f880335CZQOWTTz7hANfD0MM2
QkikARnMMomKK1SoMH/+/Pv37xNFJyYmlixZMpqrEnz77beTJ082UzAa//nP
f6L96/BiIaTghU7//ve/lXgffPBBUlISbuX9999/FrXCUcLMbdu2DRgwoGvX
rhFTBJs3b/7Xv/7FYPF85VunTp1du3bh8jgwC+zVq9fnn3+O2GzSpIkEmVR+
8eLFBQoU+P777yXPvn37Pvroox07dpDTvARASCLzt2/f/umnn37xxRekyAEp
9erVGzFiBO3zQwoYLySapxNkoqPlV1qblC+//LJbt25cq2zZskeOHCGFCn/9
9dfr1q0rUqSIqfgInmlkhiHSgwOprZ052ukvFkIK3l9//bVEiRJQ8e7du8RL
BQsWDPlUnzj5448/Tl/d6OKiRYsGEvfu3fvYE5+KeYRvS5Ys4ZavX79ORzMA
UbIhmxRVEiYnxYo3UcBkiJfWqjJ84PmT33KGI7zgxTbiT+mds2fP4rWXL18e
pvwnYSPAGgQC+zBshAxQ4glb5vjx44ULF8bSQkJuvG/fvo0aNYqY88nJH/Gm
fvzxx3bt2j1hyS8WwgtevBieDjZevny5S5cueMyQl3iSzrLZeOLEicc+l3sq
tuLOnTuwEW+OiSbEnTNnznvvvUeIa+dkuDHonuRaEdn47AKhmIUTvA4hEV7w
1qhRI5Aoglf/vXbtWq5cuTxD8A4aNKh3794SCxEqB57Pz5w5s0+fPmbKmjVr
cOsUS/jNT1WqVBk8eDDBefXq1du2bYu9IuDp3Lkz7qxy5coTJ070nOB9uZAm
wav/9u/fX56j4lnQj7Vr1+7QoYP4O8LmatWqQd1Vq1Z5flAHbdCbpEBOYebC
hQurVq1aq1atlStXSoGdOnUyn/RS+Ny5cz3//VS+fPnwYnaK578iqVmzJlcX
wTtjxoxjx45xgA565513zPpTAZFRREoSZF66dInwnvBPBW+DBg0OHTrk+W9v
A4+dW7ZsKVVFoiIt//zzz7i4OP6SglxlaGhOqkeVAu/UEhISLl68yMCXUc+J
uXPnfvDggee/VmN8nTt3rkKFCpKZVsJl67ncI2JHjknnRuzMqZz+YiG84IV4
+i9cIrjyUnhF+2PE6AhYjTEcM2YMXQY/KVYlBjTgJ3qkY8eOUsiePXsg6u+/
/z5ixAjMINmEAytWrKBYKA03ChUq9MUXXxBPtmjRQibPyDsROnH+/Pnt27cn
mzQ+Naxfvz7/TpgwQcwjw0TmIXAiw8fzX9ouXboUu81A2LZtm+cPxqZNm/Lv
7NmzA68M4IAMKAFcFd7u3r0bW82F5LHkrVu31MIzXrip7t2758iRg2pgzDHp
8Jb2QZd5PnWpJDc7cuRImouR26NHDy5EgTLWVPAGGtYe1LTbkCFDKJzbwVn8
AwUvFlKOe/bsuWjRIs+PjWkfGpOupCjPt3JLlixp7OOXX355LBs9y1SiNKdO
ndqqVavk5GRibPJQPv0idi8aG1EE/EtHoy84i1GGOti+fbtcK9pZqbCRAbV+
/XozhcK5iwDHMLBZsmSRh4cBosqUGEYTtNEhxt1duHAB/lAaDSJNKtUjzOCA
psBacq6YcUoWBoopfrmRJsErDhFARQjp+X6EhqWRacZTp055Fhu9FMGLmYIG
0J7eFz+LycJ+eql2os1GDOn58+fD2AosLaGpVBhHf/XqVZuNGHPpbjKg4s34
GdM6bNgwswUgD9YswMbNmzfnzZsX6jIcbJrRGpCwSZMm5hAjJ3zDv7du3Vpa
XthIs3BH8fHxFELDRgyEMLnfffddRrPmWcEJXoeQCC94EbOfGPAswQsYwpgm
FbyMSsZswYIFGXf4kcDb2zZt2qxbt06OOWWxD0JxRugrr7xC2Pzw4cO33357
3rx5ZGAso5cJeEqUKEGsSHzOAMdocAm8mNaqYcOGTvC+uAgveF999dVvfPTt
2xe9dvjwYWiTKVMm0QU4iGXLlkEPQmgEozzzxN8RmeTPn584HE9XtmxZ3N+B
AwcqVqyIK4G3pUuXxr9w+sGDB80PweAwIZ8c45Uox07B6eBe8c5EPurfPf9t
LBkk5jTBiCPeQxiKqhW0a9dOBS+jpl+/fkjgSpUqmXk8X78ULly4WbNm7777
rnhzAYOCG0doa8qUKVNELJigBagkQ7J48eI0140bNziQn4g9kMO0G2NTUnC7
BAZ2F3AWnpdGsDOHOf2FQHjBmy1bNowPwpNIQyJqbB0m6+7du3/99RcEoJsg
4WuvvSaP9OlobJ1IDHqcEEgmdsJJmXdH5+7cuZOu/Oyzz2A7ESC9RmmEdlAC
o00ibN+0aZPna0kI6aWEiARXdCIEu337dvbs2Qm/y5QpI3PXKVDycF2Rmdyg
PMlEWsI3DhgRRGUcEN3JGwS0cOCVQUDwIlEJI2muAgUKMAQYC9SH8BXjTLgr
eQhEOUXf8DJy4b/nf3qJVeeUokWLXrlyhdHKmCWU5S4YHdwFA5O78FIEr92w
9qBOTExkIPAvFciZM+c/UPA2b94cQtKAtD9NSmK3bt1ER/Tp00dcarFixegj
z2cFkfZj2Wibyl27donthWMwZNSoUWTGpGCdaPxobCSYF4Wyb98+OAwlxowZ
w3CQykc7KxU25siRI/A6b/jw4TJDwOSYFm4TlbbNnDkzqpkr6hCDYCVLloSK
3AsFyqMbKYEhg0Inw5dffomNhYFZs2alEHJyioyslxtpErx0JWzEP+Kwbt68
6fmUk9iPxheDGWCj5zf1mTNn8DKEgvyL1pO5Cmi3SZMmpd6JNhvRyyFtBZAK
ADQj5t1m44ABA0gkw9atW+GwPl/y/A8KGBdmCxC4YjBtNsob3og0o85EDlg5
c4ihl+XrLaJlTJ+XwkZMq8yoX7NmDfdiB0Ke/wXWC/15UepwgtchJMILXizP
/xjwIglerMH9+/dV8AoYttu2bWPI43/N74mI5dTNLV26FCNQr149ImRzSsYH
H3xAaO35b/GIl8gzYsQI+YmcgwcPxkyhsrVW1NMJ3hcX4QUvrm2ZD4y8uF1o
gz+VDERQ0GPgwIFi7T0/BCIFf4cLkBQoilOATnhk+aCVOGf+/Pn25QiwOVGO
q1atSjxjpyBhoD01J1wnONRnO0hIPDi+NTDnE7dFAIljZRRooil4c+XKRSjF
eNm/fz+e3Ty3e/fuMB/3PX78eHnfSjaGUvny5XVAeX5cx/Cxv+A7evSovIMg
ZiO4vXbtmr6gJMCgNTZu3Kgz9JKTk+UNoNn4xJyEvvINr5059dNfIIQXvEWK
FLni48iRI8R1IgZhxcyZMwnniFiwS/CzRIkScgrBDKKDaCdPnjwk9urVS9IJ
ihCPxGMICjoOLiGihZxwAIlBNC7v2ugFnTYA2SjHM8TCtGnT5CdGBPJEr4sp
TkXwiqAgboQ2Dx48IOiSs4gqUxe8DLTZs2fDfy4ktaXmPXr0SEXwnjx5kgPI
v2LFCrwPIzEwn5a7oJXkWOqsb3gDDWsPav7VyX5Eif9AwYtQhY00FC0s75sY
5klJSYTTDHaZK160aFH44Pl2gMZ8LBttU0k0rl8RwhCVPxgH4oqIbISr8Equ
C7hcNMFrnkX+VNjIKRIkKNAjjK8Ax7Rwm6i0rZavQ4wGJJ6RbB07duSmpISH
Dx8imszLwUD0lByLsMposjxzpEnw0uA0JvkZ0ehBzw8dv/vuO7wYwk2cRYCN
HGTLlo3uI4O4TkY6neX5TIOTqXeizUYVvI+1FREFb4DDlC/TJAAy2RS8XGjz
5s1mC6DTuSObjSJ4I9KMq8hDJ3OIERJwm5KTwFufKWGuzY6wA6GMJsszhxO8
DiHxFKc0MzZlOqUKXozb1atXNQMGCuuh/+LjxPopEhISbMEr3/io4O3bt6/8
hDvGfropzS8T0jelWWDSRuw8EZq8ywDQBvFrfmwl/g4KDR069H99nDhxIuKy
aZwrXoOoD92Br7dT2rRpU98HQXhcXNyePXsoWecSlylTRpnPKYSUooi5EXl7
JTAFb4UKFXCRnv8uGNdvrm4hj5XkmMs9evRIPgqWGV8KhLasHWeCoEKlOmMf
F0xN8KRiAbg6Hvn06dPyANnzZ4LNmjVLTyczgo6hp9P27MypnP5iIX1Tmmkc
wptffvmlVKlSmER6qmXLliJ4lZ8qeGkoerZ8+fLyBpYgqmTJknScNBqxk4hE
cPDgQcYF0bioFZgDK4RF0K9QoUKeIRb061cRC6TLcw9UT0DwwnkVvDIzQQQv
pMqXL5+cRc5UBC85MeynTp0iUGzcuLHU9ty5c2guU/B269bNFLwIN26Hqw8a
NKhRo0ZQHeMvOSmK1jPvwhS8dsPag7pTp04bN26UlH/4lGYahxAajhUsWBC/
DJmnTJmigleyqeBNnY22qaQXtOVhiLxBBgwHzo3IRhiLfJYZ+LALjpmCl19z
5Mhhn/XgwYNU2IhMkNdtAjIXK1aMURngmJdCJJuo1FbL1CEm7xAlG6pEZCwl
IDTy5MkjBhCG79+/32SgE7wBmFOaOeu1116TD23oMk7fvXu3Cl6TjRy8/fbb
2K4OHTrosi30ERyWR8Spd6LNRhW8j7UVpuCtVKmSCN4Ah/HOUMLzGUsMbApe
bJR+9SNo2LDhypUrbTaK4I1IM64iZZpDjGzclOTkRhgOwmeibpmJwSnr16+3
A6GMJsszhxO8DiERXvAWL158noGLFy8yfvGtHM+dO/eLL74gg4xWFbyM/fj4
+C1btjA8x48fj5UwZzXjMhj4GIdt27Zh9zp37oxrfqzgxfFt2rQJO4BTE5Pr
BO9Lg6creM+cOUPARkCCjsOf3r592/Z30Jg80AkSFilSRDw4Mk0+LBIQjUNd
Sps2bZp4WztFoVOax40b16JFC3TK7NmzqZhMLBTgqQcPHszVBw4caM6FMAUv
9cdHHz16tF+/foHFGInzkbecPnLkyLp16xJ5vvHGG5MmTZrsIzk5WbIRuNqT
6wg2ZCDjeSmHunn+LEduGWfKaD1w4IDnv7ZesWLF4cOHERdmjL1582ZacnIK
5GNPO3O0018shBe877zzjlhFOh3tiTXbu3cvcQhNirEihsckRhS88loTItGq
Mi0TPsgjFM+fC1e9enWacdGiRZxL35mCN0uWLAMGDKAf27ZtC+G9KIIXk9uq
Vasvv/ySnBBMXoKgEYi7qDnxXkTB6/nvO2CFnFW2bFnzlslMUMotUB+MtjxX
uXfvHpUktINCqFpagHj1rbfeotg9e/ZwXQz4rVu3oB+UQHY1adJEPpcj+uXW
GFBwft++fRQC7aMJXrth7UFN+3MLhw4dWrp0KRX4BwpeGoreoQ3pOOTqnTt3
8ubNe/z4cdqE5h02bBjO1xa8qbPRNpVmNM6FMFNcAkcv5URj49SpU5s1a0ZO
zBdigVFGbYkEkC3QWOYq2GelwkaZYo0YhzzwAZEi+jfAMc+XDJcuXbKJGlHw
gvr161Nb2Eg7SJlyU4yaIUOGMDDJkJSU5ARvKkDwYmpgI70syxd4vgjF0+Ge
oEqDBg2IP23BK03Nhfjp9OnTnt81DGfZSiD1TrTZGE3w2raCRHjOcFi2bBkW
JqLgnTFjBt4TNg4fPvz11183nTumjDtq3749N7J161au0rp1ay8SG/kXC09+
m2YRBS/879KlC3cB1UVTSxMlJibK3eHHu3XrFlHwwtLAe+eXCU7wOoRESMF7
8+bNhX8HjoOBr//iBHURvCtXrmBG5BhLQhBI0I4ojrhKHkOe4H/ChAnylQGR
DJXRNSj4VZbTwVDIrxgijAPuRmzg/fv3da0h+1+HFwshBS8+wpy7KzBpgyeS
Z54oU0J9AnJ52Xrjxg19vwlF5UNdSEUESDZ9Jkw5AVcO/WAp8lBdm50i2LFj
h3ym5PlzmZAk0FWnPwmgNN6fQTF//nzz4TB1MxeYgvyyOlZg8wL+xX9xOp4O
whPvmQNTloajVtEWqUD443wpecuWLdqe8syKiFFScJooaJrFnJIhbWVeSySS
nTna6S8WQgpezJo2CD2uW58QQdFHRE1EaMQqJj8xYrQMMgS2SApsFPqRrgv4
eP56QfQUAllIhdGTbHSZvIzgVzpaXn6J6UOwKJNXr17NTxAG1UP/Qlp5nQEh
CeGoFZcTGhAxyiXILBQipOQsxgX1qVWrlnnLZJb75YoXLlzQdEqgqlRJZwly
RcIzUffyEdn06dPnzJkDP6Fc7969oaKMDjhDQMu5MkLNu5D70nsPNGzEQU0K
98uFCCNfjt1CwwtebKP0zpIlS2T9NGmZ/v37E2yjW2lkSLtmzRqZLEr7MJDD
sDFgKq9fv64tD68IuZE2aAFx2dHYKD9RB4YDVyQzQyM5OZlziRaEn/ZZqbDR
80nLXVMmET49Lok2x7hlmeAdICqn69hUmnm+oeaikG3FihXmECPywXSTzr+k
mwxEoQSs/UuJ8IIXGyVsXLRoEdZMmvHcuXMMTyLDq1evYh9QvgE2eilN7flT
PsQx0bD6jZKXaifabJR+CWkrNm3axLnr1q2Tpc9sNlJVKMGlqarMrgmACsA0
bk2drM3GgwcP9u3bl/JtmnEVaQ1ziPETGRjFRB3mEPP8UEHSCSciBkIU8oQr
QscynOB1CImQgtfB4TkgpOB1cHgOCCl4X1Z8/PHHEydOJAj87LPPEhMTM7o6
/3SEF7wvJRwbYwrhBe9LiTFjxnTq1Onw4cMTJkz4p216G4NwgtchJJzgdYgd
OMHrEDv4hwveu3fvJiUljR8/3nzH55BR+IcLXsfGmMI/XPD+8ccfq1evHjt2
rL35iMPzhxO8DiHhBK9D7MAJXofYwT9c8DrEFP7hgtchpvAPF7wOMQUneB1C
wgleh9iBE7wOsQMneB1iB07wOsQOnOB1iB04wesQEiEF77Vr13Rtefvfp4jN
mzfbO4eGx/Xr12X/MsXx48ej/eQQawgpeP/8889Vf8eTqJKbN28G+G+neP5i
GsrMhw8fUtWIoybiT4QHgZtiBAVWuxLcv3+fC+mmP56/QAopMm+Kv78aMNcL
8nyG60+6RREFBhZRsVM8P5w2SyauDpOS7jZ/IZAmwYshXbx48Zw5c8z1vZ8z
oI2ukZImbNq0KWL60aNHt27daqbIJixyfPr06du3b8vmWWFw/vz5AGMdwiO8
4F2zZo1YRbo1kH+/DznGRJBTf/r+++91tb0jR47oKj1nz57VfVsUZ86cmT9/
/rx582y2m8YZbx6xwrt37541a9bSpUttQ8RPmkgcSw3hWMQS5BLr16/XZeLC
IBrVHdKE8IL3p59+UjbqJpUPHjzQFdJSAbYFi5qUlMS1Hpv5wIEDTxIG4I6P
HTsG2WwbdeLECdlIK02Vp0A3/f75wAleh5AIKXjxhrq1uv1vWjF06NBoFkxW
fbfTCSZTj+Xu3r0bFxfXuHHjcuXKdenSRdN79OgR7SeHWEP4bYlee+21rw1o
qJYm4Llq167dpEmT999/X/YDslMERP66uyVRXMmSJVu0aFG0aNGA44v4E3xm
sGhpRJKwsXnz5u+9956sNK5YuHAhiRC1dOnSFy9e9Px1nqkJp1Pgf//7X9zx
xymgnoEduGrVqlWnTh35VVZnJVqoUKECibozoJ0iWLFihZZcvHjxMWPGhEnJ
GJY8L4QXvMnJydgWYvjExMSyZcvKZk/PH/ATnqTjxGhbuXXt2vXVV1/Vzalx
E7ly5YJ48m/Dhg1/+OGHatWqhbyKubuHQ1qRpm2JJk+eTGv37t27QIECiFNJ
hx558+bNkyePrPqOMs2ZM6eE9yiXTJkyTZo0SXJWqlRJ93L66KOPsmXLpvoX
jBw5kgwzZ84k/4cffvjFF1+YV+cqcEbMcs+ePblcYJueDh06tGzZErVLOdA1
sJC7btuK165Zs+bEiRMj3iPZuDsuMWTIEArRXaEfC7dr4VNBeMGLo2nXrh09
NWrUKGyjcAxHFqCNDcwpvbxgwYJp06apO04lDpwwYUKaHn0EwMiCzNC+V69e
gZ9gmhkMhKm89/d9Eh2eKZzgdQiJJxS8f/31F/aHMGbXrl3yxurAgQOy/RCy
Zc+ePXhVIv+zZ89ivvjX85/zly9ffsqUKffu3Qv85BmC96effqJYLkRp2KJP
Pvmke/fu165d27p1qz5ANu0thrFPnz6ev54ATk2eJZ46dWr+/PkRf3KIQYQX
vG+++WYgMUBFdIo+X/3xxx8RL/LqIbBHfP/+/T3/fWvhwoWhh53C8a1bt+Lj
47Nnzy7nIhgl/Nu4cWODBg3MOtg/HT9+vGLFipyrHhOBIBHgzp07k5KSzNOJ
TiX+JMwbPHgwB0WKFJEQFymN9zczDxo0aPXq1WZKoUKFzLfGd+7cIeX+/fsc
N2rUaNu2bXaK3bbEmVWrVjV3EAuT8lIipOC9ceMGVktbgx4kcJJ39KdPn0YX
rFmzRmwapu/ixYsrVqyg37F+mDKsk7w7SOUncPjwYYzkvn37ZI7BwYMHEaHz
5s3j0moMN2zYIIIXgcNFYZecSyLFosFl/0rP3+mSW6N8riIVExVA4Zs2bTJf
uiF4a9Soga2Wf+FwQkKCCN6Anfd8i019EDIrV66EIXIK1aAycmmC3hkzZqxd
u3bhwoXklAzcdWJiIvSWwUU7XL58meFj5nHw0ih41cphRmhzOV62bBnSg4Gv
8hAxAg04mDt3bps2bapUqeL5o/uNN96QKSKo0ZIlS44dO1YjfFx25cqV9aE0
kUOdOnXMngpskt6vXz9THWBRX3/9ddlUxfP3VQnsniaCl5uNi4uTLUQjQnWx
57/RpvJepGjE5mQ0qjukCWkSvMo3MVCEfBzoA2G6DLcbePbr+U9d6D45PnHi
xIgRI8w40LOsInwQWx0wKefOncOkYAM5C9PHMZfDZOENMaHQQKgSsJMQmzwE
kHhJFbzUnCpp5RkjS5YsYXzpLBcCmDlz5ixfvvzhw4cieLHGlKk3Qjq/EpG6
KPQpwgleh5AIL3gJcXelYNy4cSJ4iWGaN2++fv36li1bjho1yvO3D8AscECx
BEtQMUeOHPhZvFKtWrUwUBIQciIGJ/CTlyJ49+7di3YgfciQIQgHFEerVq16
9OhBmEdct3jxYgxazpw5zflUGB8ieTL88MMPZcqUESNGlW7fvh3xJ4cYRHjB
S9SkbBRfaVOxcePGRM6oA0J0Ai36HdLihrSctm3b6uPiDz74APdtp3Biw4YN
kajvvPOOOFDYiJz5+eefBwwYwEAwKxbtJ0guHhMeomoRCxMmTDAfGgu6detG
fIgMQRTzl6LIKT8RrFI3zXnkyBFu0zwXkufKlYvr1q9fH4lBDMAgatasmfyK
ix8zZoydYrctoywwizVMykuJkIKXcC7izhQEVxi6devWITpQGZ5PUUhFhE9X
EnjzL1oSQZH6T4T98IGfYK/sIkrUB6UhGCHcYh8dOnSoXr06/ESqtG/fXizq
1KlTPT/gHDhwIDKTAFLmc1Jsnz594DlUgYeerwLgOXcR4DOCFylUvnx5+bdF
ixbJyckieAN2Xi4Eu4gze/bsKTRDKHE7VKZixYqkc1MlSpRAekyfPh077/kh
a+nSpblBaE9lIDx5UDrEhMgWRkpGUyCGkCbBS5SOYSSuhhU6mYpuQh3AhLp1
60oKzJGZHjjZ48ePlypV6ubNm5xbs2ZNyYBWpbPQCHnz5hWRS0+lokO9FMH7
/3z88ssvkAcJYGbASlMrlELEmB8lu3r1amoi7I0GsomwhU4wRwSI7QJsTkaj
ukOakD7BC/BQuB5MK7bR811JmzZtli5dinWCmeaJmCZogC/DzoikNeNA2ypy
gJu2TcrkyZMhIUaYi2J/sGlYJGxLnTp1OEhISOASnmUnGW7kgUiYcRG8cCw+
Pp4BopUnMPjyyy9hIDmvXLmC0Ebhyh7TmEcijWzZsnFdSitWrBhchXhVqlSR
fcnJKfbT4cnhBK9DSIQXvIzZL1LQ1AfpDHPkCYUwionqvUiCF20iL5UwFBQi
eRAFEX8SwYtbx7jduHEDg/bee+95/sZn6mdRLpgy8/sjBXkwKV26dBFtYs5O
CfzkEIMIL3gzZ86sbCRs8yJR8fbt2+XKlSN+hl0Ry6lXr56+JiAGO3nypJ0y
aNAgIZ4KXs9/Tkskj3DQiX+KiD+p4CV0JBr87LPP0EFIkq+++so8d/bs2bjm
zp074091m3hCCxw6Q0lnljJAuKnALG4GC2wnhrxz5w53QZ0ZIB07dpRfGUf8
aqcEKk88bMrqkCkvK0IKXuIlIhw7vXHjxvq8AjELPwnIR48e7flCT9/X586d
2/Nj9Wg/FS9eHA3y66+/Es5JCoJ3xYoVeiGkCkEabIefWbJkkddnVF5E5blz
5zDv2GTkqswoLlq0qESqaF7CP8/nNvYcsRC4BX4lWCXqO3r0KO1QuXJl6pCK
4N2wYYPnfwLP/RKj6pAhz08//SRzXKVkBBR/W7duTaJ8Ek4sSsTIv8OHD5c8
hJFuyw9FmgQvVotQnEAdlyffXNO2tCf9funSpezZs4vYxGjQEffu3StSpAj9
RXCO3eBENILn+1l+xQZyFhZJLBiyUXrZ8xlOOsWKBRbQ45kyZfrIh5g4c0UC
wc6dO6lh2bJlq1atGgj7OatQoUKJiYnQ3nw4GQDZMKpUFfvPPYqJtl1AgJNe
dKo7pAnpFryjRo1CyYpmpH9z5Mhx5swZhj86EbYEzoV7Y8eOxbwQHMp8JI0D
basogtc2KZBZ7TOmT2YjdOrUadmyZRwsWbJEZiAE7CTDjbrJFC/GUfv27d94
4w1xwSp4sbrQm6CFG+FcylmwYIFciMJF8MrnAyNHjqTau3fvxoRK3bByQ4YM
yehufEngBK9DSDzhlGYsA65nxIgRGKKA4D1//rwI3jx58shZuFQxTSp47Z9E
8G7fvh3LIA+TA4KXnG3atPn2228DNcSP65pUlL9x40ZCLJkuZf+U0QPUITKe
ZEqzTUXP7+74+HhxWzbIpmuYvP/++7jvQAoOF5/Vzsfrr78O8XB5ugwaQWP+
/Pm1NJgZ7ScVvDhB/KaoAAon5NM8lIyDluCQn0REEKySB+9p3sLmzZv1BiNi
7dq1OHTOJSLVxqFZ7JTAiU2aNNElicKnvKwIKXh37NgRCNX4Fy7BRvkQ2/Pf
oBGM6UesHMNM+YkI3DO+b7V/euutt4iXxqQAGYLg1ccyXKJcuXKiX+BVvnz5
JF30JgedO3fm6kR9HTt2VMErDMTMiuBFJq9fvx5Li7A1b0QEL3wj5Js3b96M
GTNswSt23vMjW6kVsSLiAt0d+F7S/IZXfqIoLqG3xvA380Rbz+GfifRNaUZa
Vq9e3fPXzcClfuoDk6LvN+WzSqEB3cfojouLkyma69atQ2jIKQkJCWI67EC9
e/fu5jvfwJTmAOhi1csAYRtYDIRRI5+iTJw4Uaej2DCnNN++fZsxgoW0XUCA
k150qjukCekWvLCI9hfNSAnYKB3+kEGzoRPnzp2r/xLLyXwPjQNtqyiC1zYp
mD41KWr6yCNPpPGtIngDdhLC6Be4WL+2bdtyOajuGYKXRqCSnEWMwYU6dOhg
PuU2v+GVatMO5cuX17qZA8HhSeAEr0NIPKHgJW6R12eYCHExpMv8ogULFojg
zZQpk3zCQOAkk6lU8No/SZBDITKzFG8VELyoYH0FYAJLJR/qcnrNmjV37do1
bNgw+WzH/imjB6hDZDyJ4LWpSHxOmDfah+dLAMhmTmhfvHixRHqXLl0S3xRI
IYi6koJcuXIR23N6oUKF5ENd/gbWCIr2kwpegMuTb3jnz5+PctE8t27dwonL
Z2UMh/r16yMZ8PLnzp37zYd+F9mqVSt7rdFDhw41bNhQpn4NHDhw5syZ9+7d
oz7oNRIJAw4ePGinmCUQN3I583VMmJSXGCEFL1alQoUK+pJr0aJFElr3799f
Pp9EpGDW6L70CV4Mo0wgh1Qyd1oF740bN1C75qpEWNQjR454/mq08IFb0InB
7du3jyZ4RX5SJpw3J8CI4OUGS5YsWaVKFUpTwRuw814kcYGYkokKs2fPhpO2
4MVEi/IidERqQXgneKMhHYIXQzpo0CD6hWbMnz//5cuXJQNmsHDhwmIrUK/Z
s2cXe8K4LliwIF0jP2GC0LxyCh1ENgggL4X37t0r6QcOHMiaNWsYwYuIZghc
u3YNQmpN5syZAy09/7mNWG9VstSBCkyfPt38VaHZuLUlS5aIsbVdgM3JaFR3
SBPSIXhxYXQ3zU6XiWbEmcqsA35F/cm8AkWRIkWUZocPH5bvOzQOtK2iCF7b
pIQRvLadDAhe3DfVps7btm2TysNPxLs4ZZmnjWCXGSx4ScYRDj0geGXOs8zA
mTRpkv1Nk0P64ASvQ0iEFLz79u0zl57QfzEmRFxE4IxojMmJEyeI1ePi4gjJ
JkyY0L17d3mN27p16+rVq8fHx8uaPAgQwqfr16/bP2FDUBkbN24sU6ZM8+bN
Bw8ejJ9avXo1npfwac+ePZia+ilYuXKlVgnLQzWIPEuVKjVq1Ch8N9I44k8Z
PTodoiKk4IWu9tqwASpu2bKFY5wUdOJASA55zE0ucLg4PohExC4ywU5RkCjD
BPJzocqVK1MaMtPME+0nWMdPcnzq1CnYTh6EQyBggM84RM5NSEigwujrDw3I
RGJqyIkyUcoE/hdfj5qmZT7//HPR9Ywj/iW/SP6IKQoCgPHjx6c15SVG+FWa
r1692qJFi9KlS9N9yEyMqucvGtasWTOMm348S3AlJuvcuXPESHIuvEr9p0uX
LtFfVatWrVixojyjQKTI8gWIayJ/tYfyjRuo4YNqwApoQx4Sv/zyS0wot0Ot
hMkIH5lUT53linSuKV74VVTtxIkT5e0G1ZOZ8AE77/nv/qRWhJrCVdwBlyYb
fKYx9R71iuSkYuTByC9dutRsBy/FF2Q0C2IF4QUvVBGLgZPt1q0brMCUde7c
2czTqFEjeU6CmcIWyYdFnvECl66h18zHg/hi+YwIiQHZcNBk6N+/P3LG/PoS
alEBu1b0ptDjxx9/xAAyKEqUKMGooXqeT2npd8yvLs3BLcP8K1eu6K8Kssk9
Uk7Lli3lMaMdjdicjEZ1hzQhvOClC6SnsIQEjWJO8cKfffaZ55Ohio+aNWsG
SkMeNmjQgP7FqGLN5NGZxIHw2baKFI51sk3KkiVLlDxq+rBs8iQEAStLXgTs
JKzTjQymTZsm7huaIaIxZVL56dOnFypUCPsmtpeSGWVUiQozKAhjtISkpCSZ
WAjlKvpo06aNe97ytOAEr0NIhBS8T0JF+ZQsTT85/DMRUvA6ODwHpGkfXgeH
Z4rwgtfB4VkjvOB1cHjWcILXISSeteB9+PBhmTJl0vqTwz8TTvA6xA6c4HWI
HTjB6xA7cILXIXbgBK9DSDxrwevgEB5O8DrEDpzgdYgdOMHrEDtwgtchduAE
r0NIOMHrEDtwgtchduAEr0PswAleh9iBE7wOsQMneB1CImMFL8HkTz/9dPr0
6ae7GueDBw+4qSdcS/bOnTtY9Qxpln8sQgreR48e/U8KZFlj8Mcff4j/pRDP
XxOS7tPEJwSFyOIqZlXN9a9MXLlyRStg/0piKvtLRsPVq1dl6VQB3H7sfYXJ
kybQ7GfOnDl16lT41Ta4Wcb40+qF54yQgjciG4GsGaX/Pnz48H/+DmdeHMIj
vOAVnw6uX7+uDLx27ZosD6sIsDFg3xwcUkF4wQvxhGC4MA3zcJ0BJ+jY6JBu
OMHrEBIhBe/9+/fbtWv3wQcflC9fXrbJI5weNGhQXFxc9erVZQE9wfLly3Ud
V6xi69atq1Sp0rRp05s3bwbKHDt2bKlSpbp27VqnTp0SJUocPnz4afH/q6++
+te//iWr1oc/JZAyY8YM2Zrc4bkhpOD99ddfs2XL9umnn7Zq1er999+vX78+
agJ5Iitwym4mkydP/vbbbzXxCfGBD/2XYl955ZUvv/wyYmbGiOcvGWrvFg1I
DOy/EAa6n4LA3OMvGnQnjh07dgRWnE4rCD969uyZkJDQt2/f7t27ly1btnfv
3mFefc6bN4+RlY5eOHfunG6JklEIKXgjspH0N99802QyRX2aAnK++uqrskt4
AFjLoinInj375cuXbSsaza4SW0J+ubqd5+LFi3Xr1sVif/7556bBP3DgANnM
OtSsWROtlLGN7xBAmrYlgmDQjL5mqN64cYPEGjVqmNtn474/NZArVy7d1MCG
6dMFcCw+Pl62FLQjATsl9UjA4YVDeMH70Ucf1a5dG47VqlWrUKFCwpkvvvji
66+/1jwh2fjXX39NnDgRFmFmR4wYIYkLFy6M8yG7/NiRqsDkMCMiZ86cYmOh
cUa3pcOTwgleh5AIKXhRfx07duTg/PnzsjvkmjVrZBfRo0ePSoRPEE6w98Yb
b6gtGjJkyKRJkziYO3eubPiowP6gczWGP3ToEMYHg/bgwQM8OxZJbCkh3H//
+1+JOfnVfAYY7aUw2YoUKTJ69Gjd5BQbqG9eCORkq4WrV68SAMi2fbjgvHnz
XrlyBcPLFTHmBLFcVF7BkHjSh9sU8lkjvOCV3ZkFuNTdu3fra0RT8GoiXQzJ
f/nlF8rXE+nrw4cPk247bnofTuo7OBxomTJldL8MhgP/quC9cOECflxfoMgb
XhW8FK67fngpghchwymiTSLyk1qhUhluks7ooDKkSLgogpcUCtHmChBVBC+1
QqUyDO/du8ewkpHOJbh3qRuZjx8/bkahXFS2yZbo+s6dO5UqVZLggUTyc6Fv
vvmGZtfdkTiF6+qcCvIcO3aMZhHBa77hpQv279+vewqbDc5Il1oxhBcsWNCm
TRsunXFkTIPgtdnoWYLXBHLg448/prnEpkXcfAdmIlu8SFY0ol2lZ7GoWbJk
EaNq5yHg3LlzJwddunSZP3++nAXf0ET68GT9+vUQO1OmTC/iG/mXG+nYh9fz
txCVrWwDgtfEqlWrILBszx1go+3TBd27d8+dO7ds7GJHAnZKKpGAw4uINAle
4Ynnb3PfunVrzxK8JpSNnuU6cX+oXZwX9K5cuTIKlzrIzra3bt0i6oOudqRq
c5iBINs0O7wccILXISRCCl5cWL169YgAN2zYIC6sU6dOREfya4kSJQiYcZcE
eFOnTlXDUrp0aXSl5++Eq/t6C4jNZPc0hfjZXbt2VatWrWrVqjt27OCiFSpU
GDZs2IcffkiERiV7++jQoQNxXbRJL5RQu3ZtwvucOXOKjvjhhx84S37lJwLU
RYsWVaxYEcGCkSSwXLlyZbZs2SZMmED+UqVKERtwOQJ1wnWpKlccOHAgSsqc
sujw1BFe8BYvXhxHJioJWUccKNvBe9YbXkn89NNP27ZtO3r06Jo1a/bp08fz
d/zEe8KuZs2aBd6W7tmzh5R+/frxd/ny5Z4veHHQcEAyxMXFTZw4UQTv0KFD
69atyzGaVB5f/+c///EMwQvlRAEJSERTtG/fnsCPAULkYPPz9u3b8JPLwT25
KIVzyrhx4+DnkiVLuPc8efLg2UeNGpU/f355jRIgqgheBjghR4MGDVCaiKyz
Z896/ttGSM4BpfXs2XPs2LHcaXJysueHIo0aNaIQMkjk0Lx5c9QuTUpORn3T
pk0bN25MKEvoIvtyyiQN/pYrV45RifehfagJwopi5Q2v9AItT00ovFChQuZQ
olYEOUTFRCbdunVjpLds2ZLSZBPYjEJ4wWuz0YsueBcuXIjGlJ8ePnwIW2xT
RjpmUJ5C2FY0ol3t0aMH3UGMJ2InkEf2Q5ece/fuhfNeikamc5X/pFAx7LkT
vLGGNAlemAMhT548ibkToxRN8PIrDJTHgDYbbZ/u+QTG3GFMRMjYkYCdkkok
4PAiIk2CFwsDGy9evAgxFixY4EUXvCYbPct14uaUw3jzdevWJSYm4sE1ZcuW
LXakanM4KSkJ14aDJtFFdC8BnOB1CImQghf7Ji8CsmbNKrt4E5rqg7vq1avr
y69vvvlGDcvbb7+tj5qzZ89uFohZk1lzlPxRCqgJchU5IK+K9u3bJxYVD0u0
LydSVQwa1ixaVYnDV69ezQE2jcp4kQRvu3bt0A7E8BzTAl6KSMH6vfHGG/Je
TwQveVatWiVjKj4+PiDSHZ4uwgteuqm2D9hC9I7WeKzgXbx4see/2UdJcYDm
ks+IUFUBwVuhQoVjx455vuQRYqBizp07RzZKRp2hAeGGCF7cLtz4448/evXq
NXPmTM8SvAGQ2KJFCzlG+kFRm5+QE1/s+WxHBnq+4GU4cAC3kTbUPHPmzFL/
QYMGMUBsouqU5jFjxpCBA1vwUqykEKCiWGl/nbmNomcE3b9/H1HMv9QHce35
UQchKyN0zpw5lIzylRYGEyZMGD16NHpcX+J07tzZFLyo2s2bN3v+60vz7S1i
nOBcCi9ZsqTnj9nPP/88Y9kYXvDabPSiCF7EJq332EBx+PDh+j2FbUXtlEWL
FhFDcqCCN5DnypUrSnKYLHOYYSycoTIB/tNNTvDGGtIkeNG5sDEuLq5ixYri
4CIKXsY7bBTDkgpMn854b9iwIeZOBa8dCdgpqUQCDi8i0iR4ISFshIH4XImg
IgrekGzEuvbv3x8z+/DhQ2gpMZ7nO1PcnB2pCkwOy1tgKDpr1qwSJUqEX5LC
ITbhBK9DSIQUvNiHpUuXev70SyJStGqrVq30EwkEwuXLl+XYNCyFCxeWB2j4
x1y5cpkFVq1aVZ/d/T8fxGCEuwjeNm3aSDrlN2jQoG3btmhYmYJCmM11dT6e
DaLobNmyURRmtqwPL5Lgpf7oCGJ7Srt48aJnCF4J770Uwfvo0SMERaNGjYjh
saLqxx2eBdI3pXnYsGEIhMcKXuk7kYG4RbSenG4H/IRk+j1R48aN4QCnUDFY
hF6DORs2bFDBm5iYCEs7dOhQq1Ytcb6PFbzoRDn+7rvvcNM2Pz/77LMtW7aY
Z1FbmTItStD8hlf0rE3UkIJX3D1jjRP37NnDLUux33//PaOeIUmV+Ldu3boS
q0ybNk1eOvMrZ61YsaJYsWLSVi1btqQFUOt644QWpuA9ffp0ly5dSpcujdQy
Fy1B8DZt2pTBSDtIz75YgtdmoxdJ8F64cAFuIBlSLxByYjl1frhtRQMpGL3c
uXNPnz6dxsf6EUlSZzsP40IKpAL16tXbv38/wR6njB07Nm/evHPmzNEKOMEb
g0jflOY1a9bI5/O24L17926ZMmXkMWDqMH06tgV6kyJzYCC/HQnYKalEAg4v
ItI3pZlT8ufPj2WzBW9INi5fvhxXgt+U1dimTp2qq690794dttuRqvxqctiE
ToFweHHhBK9DSIQUvPXr15fpi6BSpUqnTp3CXo0cOdLzTV+hQoX0+1bTsBAD
b9y4kQMsHiWYBS5ZsgRLqB9oHD58OHPmzCJ49fMKvKTMg1q1apUk9uzZU8WC
509WCXz+NnPmTH27xK8FCxY8duwY2gE94vnetkCBAvhoRIrYamSL5FfBqzpC
BC+OW9fbIWZwgveZIn2Cl7gLB5omwcsBTJAYDHrYb3iRZpJ54sSJnv+Gl4od
OXKkefPmZcuWZbyI4CUDzBHyU4eIghfWmav1kojwlOM+ffogRW1+jh8/Xq77
8OFDMiNmVZlGE7w2UW3BixwW545sjyh4aX+KldqigwgeqEC+fPnu3btHIc2a
NVu9enX58uVp8FGjRiFdPV896ZJHmzZtIqhmtCLYJYVhq4KXYjlLWqNbt27y
vYA0HUpZ5mzQyC+64BU2epbgRXKSTa2owl4ZYNGiRfoAxItkRQMpDx48WJuC
t956a+XKlUSP9lnFixcXowdLMd2EgnJKUlISrJMlXwRO8MYg0id4k5OT5YFV
QPAyDDEX9rJ7EdepMH06A1Now4hmaOOg7UjATkklEnB4EZE+wYtXzZkzJ/Y/
IHijsTHgOiEwpZlGlRShE9lwdpcvX7YjVTk2OTxhwgR5eMtZpUuXlm0dHF5c
OMHrEBIhBS+CtFSpUsSxlStXRnV6/lIAVatWJbrjr8ylFJiG5ZdffiE8Hjhw
IM7x+PHjgTIJ6Ym3CYmbNm1KaN26deuA4G3bti0/DRgwgBSiteXLlyOK66eA
Asms7+kEZcqUMZ/XURNqe+3atSJFihBDUg41IUClkgR1st6sRHqciMqwBS+D
iEtwC9SQwL5Hjx4ZPbhfZoQXvK+//vqHPiBG3bp1b926lVbBu2LFCsgJPfip
YsWKZvn79u2DGAiucuXKLVmyxEsRvF7KR6+e/6gEB40UhTmwAi7hsmvWrInW
CAheGEWUqIWTWK1aNYjNdRMSElCUNj8RRwy0zp07Qzl5XfhYwWsTVe80MTGR
oPfcuXOzZs1CyxNsoFUjCl7P/ySZnzhmiAnbp0+f3qJFCzQvefbu3UuoQ5tw
oHfUq1cvykezUzgNTuPTI82bN2/VqlWtWrXMN7wYkLi4OHkHTX24i0yZMtHd
M2bMoM5DhgwhA+KLMEYMzp49ezKQjeEFr81Gzxe8EEzS4cbYsWOzZMnyoQEC
MxqfFpCl8xSwaP/+/fqvbUVTsas6pdnOs3nzZiJAzCldYOomN6X5hUCaBC8j
kX6nWzk4c+aM5wveEiVKKPdWrlwJ8SSbAH5GZKMX5e2YTmm2IwE7JfVIwOGF
Q5oEL/aEfseZFitWTD5pwQdh55V7U6dOtdnoWa6zb9++b7/9ti5iLx994Ebx
Go0bN8ZzeZEiVYHJ4UOHDlEybghLi/jN6LZ0eFI4wesQEuH34ZVFbs3VXP/8
888LFy6kvpskZxHZ6mquEcuUEtAO9s65Mv3Y81/9RNRB8qnjY0HJFGVWgxs5
deqUVp4DahLxXK5LzHD//n1O516e+mh1UIQUvE8Fq1evvnr1KpfD/bVs2TLw
64MHD86ePRtm5x14KznhGBQKuZQ34evFixf18bXNT1LOnz+fpt1hohFVKiYL
IxOLyiLS0e5l6dKlhDFo8NmzZ0+ZMkXS586dS7hClCKLuSGaAicSJHMJnW7B
fV26dCni/iOXL1+mkrZBkL7gRG5ZovpoJTw3hBS8zwG2FU3drkbLAwegWcRF
oR1iHOEF7/OHHQnYKWEY6/CiILzgfQ4gbDCf0tiRqg3Jk7G7ADg8LTjB6xAS
4QVvDAIrp98OO7wEeJ6CF0FXqVKl7t27y8fjGX3rsYKuXbvWrl27S5cu1atX
v337tqY/ePDg6NGjq1atOnDggJn+EiN2BK+DQywLXod/GmJK8Dr8w+EEr0NI
vNCC1+Elw/MUvJ4v4m7cuGF+JeTg+cGM26zBc4LXIZbgBK9D7MAJXofYgRO8
DiHhBK9D7OA5C14Hh1TgBK9D7MAJXofYgRO8DrEDJ3gdQsIJXofYQVoFr5PG
Twuy55GDCSd4HWIHTvA6xA6c4HWIHTjB6xASIQXv9u3bzYV99N/vv/++ffv2
HMyaNatgwYKyFt9HH32k2/BFBNby7bff1hWPN27cKEvzkVimTBkOevXqhWcv
UqSInhL4V7Bs2bImTZp07drVXNvn3r17TZs2Ne9o/vz5Bw4ckOMbN25QeL16
9YYMGSLL+AguXbrUqVMnOU5OTv4oBbKnm2DAgAGy/qrg0aNHeorDU0F4wQvf
ihYtWqNGDVgnKzo+C/z444+P1TtVqlQxN9qg8rly5Ro9erSdE5ZWq1aNA4bM
YzdjfUa4du3akSNH9N/Tp09/8sknCQkJtWvXrlixIkOJDGHKKVGiBH/tIflY
yPZDLwRCCt4LFy5UqFBBjjE+DRo0kMW+wtzpm2++KTtGCSjnscuURbNgpnXC
wPJvw4YNZe8n8NNPP7Vq1YoUWXUcnDx5skOHDlB3xowZulpgwKZxCbWEhw8f
9vxtZSBM69atZe3fiCkOzwLhBS9uVNaG+uuvv/r27duxY8fff/89jClLBxth
4KBBg+rWrduvXz/9tD+iXzY9rCB1xtoplABjce4SXeDTPzLAnXpRGAvzW7Ro
sW3bNvPq3377rb1HmENIhBe8cEM3zoBdeEB4gt+hN1M/kZwYOv0XOpkrNkfE
b7/9BhuxaSNHjpQhYKcIzJjQTrl582bPnj3r1KmjrMa4tW3bFqs7fvz4kOtS
Ojw3OMHrEBIhBS+mRjcPNf9du3Yt0Q4HX3/9tew+6fkrKhcuXDiV+Gfu3Ln4
IPwy8aGZ/sEHH5w9e1aOiTbfeecd/SnwL/juu+8Q3Xfu3JkzZ46pOLBLmTNn
lr05Ll++3Lt372zZsukuk1jR5cuXEzyQrv73/v37lStX1r058Krr1q37Xx9S
w0OHDn322WeZMmVSC4+vxJIHquTwhAgpeOlWCCb+C++D5KSDomUm6gu8vrRT
YEvAi5GHREgecT0r3T/a80n77rvv6l5+ixcvLlCggG4pSDmaGVkhy5YyZFLZ
7J48j11H16xAxBRuR/fiNPOY+9smJyczcHTZN6oKq9Gw5kJwgWL1dmTrJV3l
knRCi4hVRUOZkYac+EIgrfvwkpMwW/aiCtxpxO4AWbJkKVasmMZ+5n5A2OSI
kZVtwWzr1KZNm9mzZ9M7RGiYProsZ86cZLt69Wrp0qWJ6+gUWAoJOYW4LjEx
0Ytk0zCJtIBYQuqDPClatOjFixePHDlSvHjxiCkZ3WkvLdK6Dy/kad++PYNd
nmaYpozRGvC8glTYKPbQPgVJgiigbmPGjMHzelH8csDDPpaxdgp3AXWR7Vja
EiVKXLlyBavyvyno37//ggULPIuxmLL8+fPDc6KRihUryu7qYPfu3ah72Tbd
IR1Ixz68hIgJCQniAXVreIH54E7x4Ycf4uW3bNki/7Zr187cK9z2gKBJkyYI
2xs3bvBXtjK3U+yY0E5p0aIFJhF7TkzbuXNnz3+0u2/fPoRwgwYNIHZGN7/D
3+AEr0NIPAvBC2bMmIEP8vzncvbOQRUqVDh+/DhWBXVgpqdJ8GJIyYyrxfGp
9eO6EyZM0M0ocZcYW/WhOM1u3bpJzsOHD8vrNs9/44b5VXeMgMJFEv5duHBB
UggUKadgwYJq4X/55ZedO3c6wft0EVLwQobs2bPv2rVL1puCA5xy/fp1wnXJ
MHz48HXr1iUlJRE14WTj4uI+/fRTVKSdQlgo++FWqlRpyJAhnv9WlzxlypSB
z3nz5kUOmJsXbN++ncC+Ro0akETeX0DaYcOGjR8/XjKQf+jQoSJ4IRVBGi6S
y8ElglWhnApeLmrOhWAwMjSIErmEvI9QTnI73BRnUVrt2rVr1aoVHx+P3LBT
yDx69Giiu5o1azLEGB23b9+uXr06FZPXH/juVatWnTx5kvyyVwixROvWradM
mcLY4admzZp5vo4rX748J5YtW1ZqS1WJgakeka2oOXnPS0dQT9JLlSoluxUr
MALUhJ+oITE2ESZBtWz4G/tIk+CVvYZ1R3LzTgPdYZ4Ljbdu3Vq1alV5xCES
AyNGAEY3nTp1iuCKrtH8ES1YwDpBaeStFEjhrVq1IsjMlSuX7JwFT6AWekEZ
S2g3cOBAz7JpZKZMbCyWUHb9gM9i1UHz5s3JbKdkdKe9tEiT4P3tt98aN248
atQoSdm8ebOastWrVzOiMRqYgoBgichGtYfLly/HDsiQV3Ts2FGelsB8xIUX
xS8HPOxjGWunHDt2TLYOB+PGjZs2bZrWgctJNGIzljrr8GFYoXrk6pg1zLsT
vOlGWgUvLhK3ItYPO4OnwFoePXqUbsXl0X3lypULPAQmAx6nWLFi4tRE8Kov
wxtS2ptvvmmOiKxZs8pz1wcPHmDxIqYEYsKIKVBaHonDvZYtWxJM6mNMuKe7
9TnECJzgdQiJZyR48bDi/lAigbdpRNoE0hxs2rRJJacgTYI3X7582Chi6QIF
Csg8PVwzlUEEqeAVBJ4Nev4sRASLJOL1MGKYbnXHGMbPP/989uzZePkVK1bo
WeYTb7k1J3ifLsJPad6xYwfylq4nzBbNSNfgW+VXqEgAhpMieJMXHIQ9BD92
yqJFi0RBkAgb8bnIt3fffVeeOQfe8D569Ch//vzCgaVLlxKGeT5poTQxpNQB
XTNv3jwRvHhGWe4YpQmdRBN5huDFF1Omlj99+nR5/Xr69GlGBwfURH7idrgp
/HKePHnkITmFDxo0yE45ceIE3JZ7RDfNnTuXOmTOnFle3Ogb3n79+m3cuJET
ob3cEeqbm2K0co/8i0SVp+vEJ0WLFmVYEUxKIdRNBK/8pSXlcT0dYU7VJmol
LJGHEugsueWX8g0vdqBy5cq00t69ezVd7tTuDvNcJAZ/e/To8dVXX3kpFmby
5MmYNWk37FjE1x+mBROodSKeJ56URPoOwns+tRDgqJ5GjRqZ5VBhCKxbkJs2
7fLly5yCaJo6dSrqm4HAMapBfh0wYEBycrKdktGd9tIiTYI3ISEBizRr1ixN
FFN27949TIpIgMWLF3fp0sU8MSIbTXvIiA4Mh+vXr3NWoUKF3njjDXnYZftl
28MKUmGsnbJ+/frPPvtMUigW8yXHiGJsi0ywsRlLOMEwPHXq1Pnz5ymka9eu
DChMNP+OGTPGCd50I02CF1SsWLFDhw6aqG94cTpYSM+fM4whMk/EV3IJsjVt
2tRLieJMX+b5g8LcZAEtLD4XE5opUyboaqdITjsmDKTAEyqAMdQd7aETASG0
NHeXdogFOMHrEBLPSPCiI7p37x6xKKI+/KO89MEEXbx4UX9Kk+AleMMJer7K
wOdihQg4ieGRvTly5EAQ6eNl05QR0VEBLn38+HH+xRXihYn61qxZQ63kIw6d
UEoeDLJe0QneZ42QgveBD89XoIis0qVLr1ixIqLgHTFihKQg5Ui0U/r27atv
5YiU0CMEeKJkPUvwUjeo9akPhDZxneeTlvQ2bdocPHgQ34qDVsG7b98+1HTb
tm0JPgmubMEbwLVr1+Bq+fLlBw4cKPOKbcGrwxBRDI3tFIaeTqhmgDAMcff6
XkYFL3KJsb9582auKE2aO3duwlrGI0ECKW+99RbtIDfLyKJuGq8yskzBe+zY
MYYz8eTEiRMD8fDy5cs7duxICxD9ysS2l1LwYn+Ii06ePEl/yaslvVO7O8xz
RWLQnrQtzaiC13yBFUDAginUOt28eZP+kkSCScJ7JAPEu3LlCkqH7pBQE01B
JEnXmF9tB2yafts7f/78nj17TpgwgbpJCv8y6OyUjO60lxZpErxbt269detW
4cKF9YN9MWViIiQFAui354KIbDTtoQ3E5urVq7HD27ZtE18Z8MsMCtvDClJh
rJ2yZcsWDJGkJCUlDR48WI6xMPL1riDAWM9/Ose9cwv9+/cfNGgQppUDggQG
AuMoMCPFISTSJHjHjRtHTFWtWjWdxqyCF6ejOWGO+S2PCF4OMFNkVsEbmGNg
4vr16zhc/HJiYiKeOmKK4LGC1/N9IkzDUWoKvqBfv34m3xxiAU7wOoRESMF7
9OhR8/kbwkHei0UUvBiKuLi4wBoRykxMHKHX//nA4wwbNkx/NQUvVcqaNat+
aoRAkPfCioSEBPGe2F6C89u3b49IwZtvvjl06FDdS9Q0Zbh7+dhHQJgqp2DH
qNj48eOxafrO4syZM/Hx8ZrZCd5njZCClx7UD1E9/w0CYQxdU7lyZUlBforg
FTXn+R4WEWGnELHrDKUOHToQqhHgaZ6A4EUv5MuXTx4p40n37NnjpQhedDcj
omLFirBRBC8HZBbdKm8THit4GWXkf/jw4cqVK8XPohMlhIOTInhVdUJp1Iqd
QmRozuJDxTMQNI8K3vbt22/cuJG7K168OJJt9OjRpUuX5qBOnTryQTRxhbCd
+hCs/v777zpxAgFlCl7u/f/zMXz4cDMYYHiigmXRD1ryJRa88g2v569OgF2S
sE3u1O4O81yRGABhQvujl0XwpvLuKWDBFGqd4Gf+/PnlNcTSpUuxsehQ1Swc
I7rv3r1bqlSp/fv3BwoxbRq9jJaR4+Tk5AEDBgjBJIXw9dSpU3ZKRnfaS4u0
fsPr+QMQ2ShfZIgpQ0gyrsWC8WuDBg3MEyOy0bSHNjhF/CxmKleuXCjfgF9G
Ygc8rJ6bCmPtFAyjGjGMjH4MhZYRw+JFYizGhxBFUrDP/Lps2TKpD3StW7fu
1q1bM7pjX0ik4xtePGbBggXFRKjghWPCTwoMuAYVvLdu3SpWrBiuRARvYJ6A
CTLAcM9/SAIPI6YIUhG8cI+oT6Y0MI7gMNyTt8ye//l5zZo1M7r5Hf4GJ3gd
QiKk4MWdNW/enGAYjTBkyBAJkr2/C94yZcp07dqV+AeXqn4N4ZmUlKTl4G7k
C0EBVggrp4/1TMHr+Z9LlCtXbuzYsagSnKNM8lTs3LkTWU2ESQRIpG3+FG1K
88WLF19//fVPUjBo0CDNY064wodyI/Jwz5TtTvA+a4QUvDgjnBf6dNasWcRR
8O38+fPosjx58qAUpk6dCpFE8ObNm3fkyJFIWhhLrGinIGpKliyJEiEEQq5S
iBngIRPgnjknnyCKRFhXoUKFdevWeSmCFw4XKlRI3kGI4L137x7cnj9/PpUk
MwLzypUrAcHLWDBFB6Edpc2ePbtjx44yf69GjRrcILEB9yuCN2fOnJBzzpw5
sJG41E6RVbwYEdyUMNYMEhDpeHMiw8OHD5NIQIgiI/OZM2emT5/O0NZ1XagM
MSH3Qqgs44t2a9iwIeOCv/KYXUIU4s/69evTJrVq1ZJZlIygkydPEtsQqFAO
Q5jGkQcLRYoUkRdAsY90CF4AB6S55E7t7tD28QyJAWglWcbHFLwYTJ296aVq
wUzrRC9ArSVLlpQvX56hwS3Q1wMHDpw0aRJshyQrV67Mly+flqML4Zo2jRCU
zCh0SitbtuylS5e4F0yufAspEaCd4vCMkA7BC+hxxi8xvJoybAWWE7uEqdm9
ezd5IAY086Kw0bSHkFZfEAswm9goTBY2QRYFiuaXU5nS7FmMjZiCSaSqiYmJ
WFGZvsUIRUPppFabsQhwwhIqCT/RKeYqcG5K85MgHYLX8z9EwnFwLj66U6dO
SGB4Qr8sWLAAtkh3KBtV8Hr+Y0PYGBC8RK3iwvRaGKLq1avDkMqVKx88eDBi
iiD1N7zUoUGDBrBaVuSAYBTSvXt3SiMi1YcqDjECJ3gdQiJN+/ASKRG+Ynx0
tjC2izDe85/C/eyDWNpcmOXq1avyhE2AhTR39vH8eZh6dfxaYClIUojNiBsj
OnpqvmLFCnuHF+pgftlBHeRZMRrkZwPiRgV4Rv0XdU8kQMm69K6AyNb84pJs
+u2bw1NB+G94aXw043fffffDDz/oNIA7d+4gQuEDHPvtt9+Qt1999ZXMppPH
yHaK589TWrt27ebNm4V7XB3CyE/QVT5rNS996NAhrisPfDyfokLgy5cvC7dx
wTdu3JDT8d34WcqETuh0WQaNISMjiHMDHwRR+cWLF0M/ebHLpbdu3UoMSTbC
A9kCBuoqOe0Uz48EGKTcowQDiHHlNsc0kby23rRpE+6bkJiYlnKQ1TKWFefO
naP+5sto7n3VqlWMaLkR4T9VpYaEpseOHZNspEunoKNpK/69du2avGpBBb8o
AUNIwYu5UzJ4/oxQeWigdxrojkD76Il0Df2ChcHWqZHkwFw0OxULFrBOEIme
0n1hIBLdTYrMuFZzLdDANWDT4C3jgo7TRqACGzdu3L59u2oHO8XhWSC84IV+
6v44gIdQ1DRl+/fvx1zoYOdA+BaRjaY9pK9tl3fixAnGuOwBJIjol00PK0id
sXaK2BmCAf2qHatojg4vCmMZepxoXsvzR3cgFHEIj/CCl2zmkuDy/I3T5Ssk
z6crXkZnUikbcTFmXArxZP8CZRHc5qyA2REPZX6mYad4RkwYLUWiC/1shBGE
U16+fPljd1NyeP5wgtchJNIkeB0cninCC94wEHmbesqLBZG3qaekCQTA6N/x
48ePHTuWKDFMOP3PQUjB6+DwHBBe8Do4PGuEF7wODs8aTvA6hIQTvA6xg6cr
eC9dumS+eouY8mLh9u3bgY9/7RSHpwUneB1iB07wOsQOnOB1iB04wesQEk7w
OsQOnq7gdXB4EjjB6xA7cILXIXbgBK9D7MAJXoeQcILXIXbgBK9D7MAJXofY
gRO8DrEDJ3gdYgdO8DqEREjBe+bMmRp/B4nNmzd/iqTlEuPGjUvrWW3btn1s
5SdMmGDWfMaMGVu2bKHyurgWl9Z9/QSPHj1atGjR0KFDv/vuO10VYdeuXaNG
jdLFou/fvz937tzhw4ebKznv3Llz5MiRa9askX8fPHhAntGjR8u8U9xEfwND
hgzx/Hm2T7EZX2iEFLw///wzfWqm/PHHH7Jkkx6kFXS07K+hB88H0Ikr3rp1
K9q+1dFw7949czk4h6eO8IK3SZMmDO2rV6+qkWnatKkaAc9ft6p+/fozZ87U
FLp7/vz5+i981rVMTWBApMCEhITWrVtrmbZBltV7fvnll7Fjx06cOFEXGtq7
dy8WCWsmi/YsWLDANEGyKsvp06c5a+HChWrr7BTPXyXmq6++imYPI6bYZ4Hd
u3fr+kj8unz5ciykrnpEPZOTk7Gr3Ky59iCJuqqMfRadNXXqVFJk+WvPn+0/
e/Zs7j2w+5K5Ni/Nok0hHztcv3598uTJ06dP/+233ySPnZIhCC94Bw4cKN1a
t25d4UaDBg3wemZj9ujRQ7apFfDrgAED9N+1a9fqlqk2AmTGmQaoSAU8f8m+
r7/+mqZTcxqRVBcuXLD3BqKvdTWqMDQLpPz555+rV68eNmyY6b5PnTo1fvz4
efPmmYtqwigqGbh0KjSzU7DD0AyGE0p5/sA0x9e3337rRaKZ0HXSpEkB73/u
3LkXYjPr8II3KSlJ7qhPnz5CD2hJ5GN6eYYkjNJVxdLERu/vZI7GRgE82bdv
nxxTAchAV+oqWNwRnUIUSi9Iis3YH3/8ccSIEbNmzTJXuDI5TFiofT1mzJho
5aSD1XZKILyMmCIwWW2nQF0IbBpPOyWW4QSvQ0iEFLwEY/Hx8f9nwPNDqadI
Wi6hO8uHR9GiRQMLO9to167dkiVLtOb4OyxP9uzZ1RJyaeyteUqvXr0+//xz
1CuhLLLX861urVq1MDiNGjWSSJWYtm/fvhi6uLi4VatWkYLja9Wq1Y4dO+rU
qYMtxTlWrVoVKb1+/frKlSsT5lHVH1JAJFCvXj3vhdqZ9FkjpODF6QS2htQt
bvUgrcBpBg6eD+AJngVOpvVTXN1R1+EZIbzgffvtt4nqCWVLlCgBe+/evUtv
FixYUGUd2q1KlSrmFmywNHfu3LoJlL1NhoDS3nzzTTFcZK5Zs6boNdsgE+Qz
fPLnz0+oT4DNtUjE7mF5Nm7cSPQl1vXo0aNifzZv3lysWDHqTLxXsmTJbdu2
EWR27drV81dSDaQIZKsasbe2PbRT7LPQjIsXLy5QoIDe7JdfftmtWzdsZtmy
ZY8cOeL5+zp98cUX27dvxzwSW3q+WSDCfO211zTADpxFGFmoUCHyYGk5kFX6
33//feTGhg0bOJDL/fzzz4MGDTL3kqtQoQKmWxrk1q1bVPK9995buXLlnDlz
KlWqRCF2SkaxMbzgrV27Nr3g+fsTofqhwdmzZ2ELSk0y4PSLFCkCVfTZIJYE
h6hSC45Jy0dEgMw0vjCwTJkysIsDGu3atWt0Dc0uO7lEJBUCZ926dRQVuBbM
/Ne//iXPf8LQzE7BojZs2BAKCZdIQeZ89NFHEIY7VUrTm/h33ebmsTSLmIKv
RzJzIzQptuLmzZvq4rt06SIbMwVoRqfAUsiJ6ODquoAwAgSydezYMaM4Fh7h
BS8tRqjj+fsTEVBBj8uXL9MyKmnhDwaBwaXb1aWJjQEyR2Sj5ESWUqzYT6gL
8WALZObqdMr169cph3+xmXAbzWszluPSpUvTiXSrvPSxOYxC5F/pa9n2yy4n
fawOpNjhpZ3iRWJ1IAWbzI3T2jgOmvHixYt2SkbT7TFwgtchJMILXhngJlq2
bMlfxgX6sVq1asePH+/UqdPUqVPJie7DmON5GzRoII80GX3Vq1cnm1g/DFHv
3r3HjBmDv+jQoQOegksQ4bRt2xb92LNnzwcPHhA06mNkxOnVq1cZ0ZMmTaIc
LoHq8XzBi0vFu+G5ZMcEzELAPBJMiiBVUOF+/fpVrFhRbEJEwSuBLlf5+OOP
OeCiss/CpUuXsKUc4LPEFEycOFE2ayPElYdmd+7coTI07LvvvisF7t27t0WL
Flo+9pbYlRGK+c2SJYsZVf6TEV7w0ik0GjQggiXU7969e44cOSZMmKAH0Cwx
MbFu3bq4AAJ+z/d39DKOoHnz5tK5ZPvuu+88v0+nT5+uB3BMHuZ85cPzu4+4
HY7RyzCTvpMnn0RT+Dvx3aJHZAuGpk2bmnsxBMgPiJ9xi9SHu+ASEEbe8OLO
CE3x/n369JGdiRTDhg3jFMYL3goLT/yAVwoQ2+EpIh2C19yQF+KdOHFCjrFs
hN/QlShIUhC8SD+0gLxvUsGLCTUffYjg1X+JjXPlyuVFMchCMzmGG5AZC6zz
Twi6zCkBhEwYLs83rXPnzvV8o5QvXz54a6d4/qsTDLVucW7bQzvFPoufsHjc
u9wsDEf1y145BFedO3cmBfsvzEdQMFo9f4sQzsqTJ49EaPZZND7NIm9PGN0M
STpOH58y1rDnHHBR3JMpeIl18X1E4HJFhC2huPzEQDt06JCdklFsTJ/g1Wgf
l7po0SI5JlzH9GG79A0UEgM3ijOVFlaJoRbShE1mwQcffICylmPZDFeO6T50
gU0quM2FmjVrZvpr7hEryi2I4A1DMzuFyISO8/yNX+k1DohDpO+oiY6v8ePH
4z5U8D6WZnYKsggxK6dTFEzTG6GnsOQyugM0w2hrMDBt2jTcjeerb6qNK3mJ
Ba9OYoGK+k52w4YNcIA2kUDLi85GO7TzIpFZYLLR8w0pPMG6iuDdtGmT7HTv
+bNi8L+k4OIlpVu3bgsWLLAZO2XKFHlLwmDMmTOnFBvgMMSgMvS+bkJnl5M+
VgdS7PAyYsAZYLWdQisJAz3/YSOD2k7JaLo9Bk7wOoREeMFLRPFJCogovJRX
k1gzAhiZz4ONwtFguhMSEjAamHesEBaJ0BGbj8FnsKMalixZ8ttvv7322muy
+RrBHrEflyC0Q0JyOioAZ8RAk73sPd+JE09iFbk6xXJM/CZXlFlDRDL9+/f3
fNEUmIZB+QRRWvm7d+8ieDFK8kaGmtiC1/MnbmF4cWfiKPPnz68zQJBUnm8z
0byNGzfG+Ny4cePWrVs0SPv27QliKY1qECpny5YNq8IdEVuWL19eC8dyig30
3BteA+EFb9asWXE6eBBogH223/ASNjRq1IgY+Pr164ULF+YvNJCZUVh7AjbP
l6jCW8y7GH85WL58ubhjulIkDP8uW7YMViNhCKIgM84RhsCK+/fv04OYXLqY
dCJ8isW5a21t8h88eBAyQCfulAMEr1abyzEoIEy/fv1oCi3kypUrCAful8sR
dBFHuTe8zxrpELyMdywMkQb9qE+xrl69CgOxWsnJyfoZCN1N4UOHDpU3UCp4
4Ya5PWhA8IK8efMSTQUMsmxNBds5gKXoxL59+5JCUIch9Xz+UDd5J+X5003J
JgoRTu7Zs0fSq1Spcv78eTuFEAuBQ6iv0tW2h3aKfZZAbxazWbx4cUk8deoU
VdI8nNWqVSviXk2hSWWQRjxr9OjRhLh169bF9prXIjOtobdDe6rg5afXX3+d
iI4LcS7/0lb4Efm1T58+2AE7JWO4mF7BC9+gBF4MiyRTRrEhBQsWxB6eOXOG
8FjeWWNJ8K24dcQmKSox1EIqIpJZYEoMhkCXLl1wu6VLl8ZyRqSZHJvv70QL
YCrRPiKOwtDMTmEkUklkCDcom4Nzy1hUBl2lSpXEoW/btg0ewigVvI+lmZ2y
efPmNm3aSArOBc2r5cArUdY2zfbv389VYDg9QiKRkuc/W5g+fTrj4iUWvLQY
bKSL6Rd9+EZfb926lTGLFZX966Ox0Q7tIpJZEBC8rVu33rlzJ+GoCF4cPeyl
SvT+yJEjzTLxvwQV3JrNWHRxxYoVqXCxYsWWLl2qp5gcxmLQuShryCZ8sMtJ
H6sDKXZ4mUrAqayOlkJMBZMbNmxIgBEtJWbhBK9DSIQXvIQN/5MCCQJV8Mqb
As+Xn/L8k2APX8ABzo6Ibu3atUhL+a6BgKRHjx7ITFLkLAL+efPmcQl9xHf8
+HFCF1vwUmxg4h9XlE+EUon/8WszZ87UyuOsRfB6/iRkBnVEwUu2AwcOUAF5
EkicqUIse/bs/Fq1alVEKzEkHmratGkMt0yZMkmkQZyGt/X8x30YFkwfhZBf
TieQxhqrcXaCVxFe8DZt2lSOOSCkiSh4YZ3kgW94zzVr1iBg6VAUa2Bqoj5t
lgMhJ46JaARinDt3jk7E18yaNYuwBC9GsIevxItJtEPnoqBr1aq1aNEiwioi
ZDNQt8nPeNEMMMcUvLhLXCo6yP52BjYy1rjWa6+9RhM5wfuskQ7BW6RIkSs+
MAvEdfL+nSgLxUFEBDcyZ84selYELxEvP8kU/VSmNJspGB8ikIBBlmcjiOVq
1aphgjZt2oTWIPHatWv16tUrW7ZsgwYNIKFOsSb81g9SGjVqJLNlPP+tNFFi
IOXEiRP8JcKnMnny5Ll9+zbDJ2APPctCPnz40D5LftWbpXr6Tpy6yWMisi1e
vJhojb/mjWuEZp9FxEt7MtCoNo5DHmcRBY0bN47RZH7DawpemlEbhHE9ePDg
sWPH6heddBYVsFMyio3pE7wYMdhIn2I3hg0b5vmOMl++fCN8ZM2aVXKKxOCg
Q4cOmKZUJpFGJLPAlBgYOmwjcQUShtFBl9k0k2PzWhCDTqSPOB158vvvvz+W
ZhFTunfvTm/iFzCn8qI/V65cU6ZMgVqQoUCBAsh2Bgia68KFC6VKlTJn46RC
Mztl48aN+nENTkEeuXv+RJ22bdtGo5nnz/NHO0POFi1a0JLkx5FxF/QCBUoQ
FctIn+Clc2EjJ+LyGKfSyLgzmAkHaBDJGZ6NEcksMNlIIcOHD6d5uRDeGVoi
crGK3AVdX6lSpS1btnj+EOvWrRt+XMypzdj58+e3bNnyp59+oq85S8Nms4bc
oGh5xDi6mAFol5M+VtspdngZMeD0Qghe6rxhwwadCB0xJWbhBK9DSDzJlGYV
vLoMiH5RizKViRAieDlu3Ljx//qQjyPQFPpkVQUv0ZqkYB8++eQTU/BiXogn
e/Xqpc/Y0S+Ei3rF1AWvPaVZBC8ekICQYk3BSyIp8vqDwsW2VKlSheDN81+O
4CK5Ba3/5cuXCc9oQwnzPP/xL/bW8z/o0Nrq1DjM7+jRowPN6OCl6xveVAQv
XknykBmPRscRSAi1dPKS50/pkbfteuD50/bgwIIFC2bOnKn0IEyKj48nUoIV
aGfCKpnqgF+A8DDk7t27uFE8Jl5Py7fJT5laATyvCl6IB5coBMGiXlgAfyhW
PlfEjTrB+xzwhFOasYqw4s8//yxYsKBoMQAT5FmHCF7Pn1CHFCUoCiN4iehk
lm9Egzxo0CA1xQR4c+bMYUDJzDp5FQK1OOaO3n33XZ0w37dvX5n5AP3QAgSB
gRR8RP0UEJ0SqTKUAvbQsywkDWKfJVdUwQuZUSLifUiRR4uyfoKpQQQaodln
4RT0vRgjhaiVPNWrV6c1At8FmIKX0qTCchYXXbp0qX7C//HHHyOO7JTnz0PB
E05phnvIK883mBMnThQ2Qhh5ZKcSQz4jxVVFlBjRyCwwJQa2EeMpxxADjWDT
TH41xQKVEcLkzp0bM7tnz57H0ixiijwUkjIpSh4riS+GNtmyZdu3b59cKCEh
AaEkT6cfSzM75fTp01xdTpS1jPRG5IF/RJrBbX3BPWTIEJwONJP6EEjkz58/
sIRmDOIJpzRzOjYBo4TvQ9UKnaCHvAQJyUYvCpkFJhsJt6R5CRdLliyJboWc
ukpknz59vv32W3kNYRphm7GwRW+BCEEnzJgcPnDggK5uh9EjOLHLSR+r7RQ7
vIwYcHqpCl4qrG+rITCBsZ2SMSQLDSd4HULi+QheLDzycOXKlQwlIr29e/dG
FLyEdhwcPnwYZ4e/wEtinX7++WcKyZEjB/EkKRilQ4cOJSYmyoQNW/Du2LFD
/Y4gFcHr+YtwEq8G3vDiynE6XG7gwIEyXXDJkiUtWrRAsHTq1InyaTGM8/Tp
06k2ZlYenlMBzDvVIzSSt94Y+a+//po83LV6PWpuTrbBBrqFmgXpFry3bt0q
Xrw40aAeEABDMFp+xYoVKEQY2LJlS3rz6NGjPXv2lIgiKSkJmqE9ZZKAHnj+
WlKvvvoquhXWcaDBG3JDPgqDPxpW8Zdjup5jfCLslcywFDba5MfRFCpUaOvW
rdu3by9cuLD5hpd/ZQhwFXwWJXMjDx8+JLBs27btxYsXiY4yZ85MK23btq15
8+aBpRcdniLSIXgRU/N8jBs3ji7evXs3XRwfH685d+7cKXZPBS+YOXNmpkyZ
JNYicFJD4fkCDdlCgfQ7lIPbMkUTYnM8zwDcQOYQCEEMmIPlREpjObHb2LEB
AwaoxYP2+iDR82Mk5MCZM2emTZsmktNOUejk5IA9jJhinyUwX2cTbXLLVJVW
YoBgjd94441JkyZN9qHPrLy/x2yBsxinWFGGGM1btWrV9evXM65xDZNToB8y
BwQvZ23atAmLXalSpYMHD969exerjqrduHEjLYC+s1Myio3pE7xE8nADH1S2
bFk6BUojALUvKA31hy9WieH5AfArr7wiAbxYSC05GpkFpsTAzOLmIB4VoOOw
YNFIFfH9nU5pDkMzOwVTzx1x9ZEjR8qbRDw+noJa9evXz5yJncqUZptmEVPg
Gy4Gi83Qk96BY/ny5dO1oCPSjNiJIQCpypQpI4+hBC/3lGY0KWyEErJyCwIQ
fydLrwgYs/R7NDYGQrtoZJZ/A1OaBTqlmWzYT/iMqcRQX758efz48fSpWowT
J07YjJ0yZQo6F2uAZIYn+lDO5DB5mjRpAh8WL15csWLF33//3S4nfay2U+zw
MmLA6aUqeOnHIkWKYDNpDc5iUNspGU23x8AJXoeQCCl4b968ab5vEsi6EKdP
n1aThfWQlRsZcTKakHLyHIwSCOxRHDKVjivqonxIWmJFMuARZK0AnZqCm8BI
rlu3Do0jsT1ejBSskzgXvSKXw5V4/hsTc2aL5+ujwIdI58+f16dznr86isyC
Uzx48ACzjHPEsqlFpcLUTU3x7du35cNhUiQQoibYc2JL3T2EKIXQd/jw4Tqp
6dGjR4FlQMgsetkhpOC9ceOGzhGir0WlTp8+XdYMkQPChkWLFhHwjBo1SpbB
vHPnDoE0EYvuTEEhcG/16tVSlB5IZn3IiaNR1QP9ZEMKiG3uF8CxcIxfdVEU
9I4MjQD5PZ+lQ4cOnThxIsSgDvBNVtbi9mELxJP52AwT2ctANC8l4PTJifzB
21KCPSodnhbCC150JR2EgVqYguXLl8tTLPhgzk7HUEBL6W5z9xNsgqwyipEx
IxO6XstEtekpMGrh3yGXw4QOHjwYCqlNxjphkcyPTyFhwB7CWM6aPXu27gxi
pwiI7XWh6YA9jJhin+X5407XByZdtLxsF4JVN29qw4YNehYjQl/bBc4C6H1G
OikyxLh9sxx9L0N7mtu+4HdGjx5NTC77+Hj+uJZJFzpZ107JEIQXvPDk+vXr
HBByy+1jwWT9NPo9EL6isMR1mpTYunWrNIhYSE2PRmb5l84yB4tQCJOrq/dE
JBU9pY2vwMrpN55haBZIYTAi1bGiiYmJyhmqJ8sHmdsS8avGIYLUaWanIJ24
Rzy4LM7p+e7J3KnQi0QzIhBpHIyMmZNxkYGzCMIjvOA9evSorEX/ww8/CBvh
zJ49ezB6FBLYg4lxClGjsTEQ2kUjsxwH2CigcDWMnI7FwFTK23aUtWkxJFuA
sdQZtmBOcdzmAoABDkMhmEYcoo8ybOang9V2ih1e2ilapcCnuGYK0hh+UkO1
k3ZKLMMJXoeQCCl4HRyeA0IK3jBA8AYeYjg4pAnhBa+Dw7NGeMHr4PCsEV7w
Ojg8azjB6xASTvA6xA6eouBds2bNhQsXMvqGHF5gOMHrEDtwgtchduAEr0Ps
wAleh5BwgtchdvAUBa+DwxPCCV6H2IETvA6xAyd4HWIHTvA6hIQTvA6xAyd4
HWIHTvA6xA6c4HWIHTjB6xA7cILXISRCCl687aq/g0RZZudpgUvoaj/hsWXL
lidZOfPs2bMRV0imJrpgbxg8evRo8+bNM2fOXLFihVs4N91wgtchdhBS8N69
e1et4vbt23Xpzh9//FEXNrl169bKlStnzZqlq5ZFAwZ58eLFc+bMMdfY9Pw1
VUhcvXr1jRs3Ur+u4PvvvzcXKcVOSs4dO3boIkJYzoBVv3z5suevEmMmUqUL
Fy6YKRRC45hbeFy7du2HH354+PAhNdS1UB48eMC/OBd+MmNjHEdgrR6HxyK8
4F2zZo1006ZNmzT/6dOnz507J8fEh/Qd3oq/svuejfDsomd1KSG6nvy6Mg8n
akfv9xG4CoWYUYTWXIEjluW25EK6Rh/UhVowM8ylHZ46wgve3bt3S1euX79e
Yy1dYtTzV4KiE2fPnr1s2bLUYyeKwoQuXbpUYjN6P8AWWcryt99+oyjoDQdk
72/T0BGnBQaRSeZoZXr+enqB6p05c2b+/Pnz5s0L2GqH5wwneB1CIvy2REWK
FPnaAImdOnV6iqTlErJHfJqg2xKlD+LN7XRqEliejig02oq4d+7cef/992Xn
wd69excqVEi2DnFIK5zgdYgdhBS8v/76a+7cuTGJ06ZN69ixIxZJTtHdYbAk
77333qRJkxYuXFi3bt2uXbtGKyo5OblcuXIEdYmJiWXLliUI9PxdTurUqfPJ
J58kJSVNnDiRomRp02jX9XwdkTVrVt3W3PPt5NChQ8k8aNCgYsWKicrAcr72
2mumVZe1SbmEZBYQ133zzTc1atTQFOLJP/74Iz4+nnjP85c+rlKlComev2+L
3mDPnj379+/v+eucV6pUScTIokWLKMpctNkhDMIL3n//+9+TJ0+mm3BGBQoU
kPVadXeYa9eu4a0GDx5MR3Tp0iUuLs5ctVgRnl3U6q233pLHzhs2bMiUKZOs
nUuxWbJkEdUJ0/LmzZsnT57AtT766KNs2bLpwrkzZszgilBddlcBVLJmzZry
6/Dhw1955RURO6hgbi3MpR2eBcILXroSHtKVQ4YMgUXyrmTt2rWy2yM2oVat
Wh06dMA2YnMKFy4crUzytGzZErU7cuRIyoGfEFtIkj9//i+++IKDNWvWcHrx
4sXHjBmDzWnduvXHH3/s+fR79dVXJTNGCR5qhBYgc8Qyr1+/Xrly5aZNm5Ys
WXLAgAGSk2pg05DVGPb/v717/5Vr7vcA7gciLqXENS6NO6UtVYemBKVV2rQH
dY1LNUU8OIj2uAchbo0EUSH9pe5U+2iJuP1CSRwVITuKCGkiehLC/A3nnfme
rswzu2XtSu1vPa/XT7PXXrPWmr2/8/l+3rPWzIwbN67+L6v9GxN4aenPfA9v
+VqWTz755IsvvkgPlpk04TG3H3744RUrViQGPvroo1mn9DmZg5555plEwoGB
gU630L3++uu5b1q7cmK3BN6VK1emhpTvPkidaV7dfeONN8pnvGdUL1y4MJsq
U2dK3+eff54lr776anmxOo8lv039zJrlG2Q63RMcOary8fhZIYe3atWqpUuX
ZqotrzquXbu2fBx9mU9zJHksmW0XL16c/abNSH1OpM1jXL16dV8WnjFjRnrR
5sfcsXzNZe9fJk/J3EgHWw4ph9r7KmLf6+f/tgRe6tE+8CYhNj8m0qa8dNYH
3iS7/LZUnk73PNSRRx5ZvjUmhaLcKL7++ut99923OYmQOpM+Ks38NV3NaqlF
afVTRTe230jMvO+++7LaZ599VpakTjZf+5uitPfee6fmpChtv/32gx9RNtus
XCTwDu7oyheMpsrNnz+/Cbkpy2PHjl2yZEkqf8JUc8Yt/Woa2jyoUaNGNSep
aW9Igbd5ETjBNimy0xN4Z82a9eSTTzYrZ/IqL/n2jcahjq7ytSxJ0Oecc868
efM63WsSRo8eXVZ4+umnZ8+ePXXq1N7vWMkukiBuueWWvqGVtqH5nuh0ERmi
Za7PEycRJkGm043G2VebXbM5DCnwNv1SwmP+R52ewHvPPff0fid4gmo5mZKe
sPf7eVNFt9122+YLsNKV9X63Y+9X7qZnS6lpfpVRlyGUp0OeFM3Cq666qhly
gwfz4G3miXP77bd3um1bSnSWL1u2LBG4uToiLeXJJ5+srA0XgZeW2gfezCD/
XO/LL7/MwnRNnW41GDNmTCbW9IcHHXRQOp+UtRSQVIDcmDRpUgJs6tWECRPS
8GQuO+yww1IxEjD32GOPm2666YUXXsisl9k2uxg5cuT111+fYJglKSkvv/xy
UwzTPWZ+TFHK3VPu0gGW1+4y31144YVJu1mhTOiTJ0/OHJp1jj766PId7nPm
zEmZfeqpp4455phU2nQOObyZM2dmp6ljOaT0fnl0uZFDzQZztAm8CfgvvfRS
Qm4q83fffZc+IdtJS5CFd911V/OXyco57A2esOj9y2SDOebsPceQVjCl8smu
9Ip77bWXq6ALgZd6tA+8qSepisuXL08wTMUrr1+VwJvfHnXUURu8Y/qu3ktB
kgU2eM1MEmKpt40rrrgifd3G9pt0kJLy/fffJ+M0X/DdG3jj+OOPT0uZPiFt
5D97lBcVk3RSLcuScuVhtp8C2KzWXBT9yiuvZMupcr2X2WRHaQsPPPDA3sPO
saV0Z2HfV2fS0pAC79KlS/NveuyxxyZOnFj+7yXw/vbbbyNGjNjgdN83Goc0
usopvGx8//33zxSZIZGFt912W+a+skIm0zfffDPTX4Jzs4uEjmSNL774Ip1A
75XVvYE3jj322DfeeGNgYCBT58qVK5PQs3DatGnly+7/cNdsDkMKvBk/GUhp
ydKbpa/r9ATeDIzmrESv3KX8fxvTp0/PYF60aFE5Y9KrN5x+/vnnGZ/z5s3L
jprzCCXw/m9XcnTq1cKFCzsbGcyDt5m7lO/gzqNOZUuCzpPl8ccfH+5/Av9P
4KWl9oE3098/1nv99dc7PYG3OQGR6aa8zJXOrVzhlgJV1h8/fvz/dCXkJtWW
wFveYZF8mjkuu0hELdtJ1E09HBx4s6lM4mVJ2X72WM6eJDhffvnlKU2pimWF
1LQE3uxo5513/vjjj3P3lNyTTjopnUOWlIhaAm82NXfu3HKv5NncJfk0LWWn
ewHYuHHjOt3XHjdY4r799tvddtut3E4POa4rTUXfX+aTTz7JHzklNPN1inlZ
mO4lKzdnfxB4qUf7wDty5Mj/6rr44otPPPHEcrKgBN70+c01mb/vgQce6D2T
29hxxx37rgBJLbrrrrs2tt8E59NPPz29aKJKSnQpdH2B97TTTnvttdfSJ2y9
9db/6FE62ATeSy65pCy58847O93+M8W5We3TTz8t28k2U0uThXsPr2TbI444
ou/NJgkpu+66a57jw/2P3SINKfBee+21GRWZPSdMmFDehFgCb/41GU5tdjek
0ZVJc8qUKUkuU6dOzY9ZedWqVc0l/bljmofcJWEkM2NziVcagA8++CDLMwn2
vh+8L/AuWLAgA/6RRx5Jn5BcvM8++6xbty4DKbnjD3fNZjKkwDt79uyMotSN
jMbSRDWB95BDDmn/7YEZchnYo0ePPu6443o/oKA3nJZjS5eYnWaAJZlmzKQQ
bbXVVv/RlQ4wXV+5DH6Dg3mD2+x0L2gcO3ZsieFnnXXWc889V5afccYZGcAZ
4b0XTvBXEnhp6c9c0twE3ibBNe+oTb+UuNrpxtIUuhSWMWPG/Pd6qRUJlWmK
yr1K6swuUjrKksxZp5xySm/gnTRpUqbgCy64oGy20ewxyxN4M7k33Vf2ksCb
R7f77rs3u868mc6hb9f3339/uWSl0byHN03v7wfe2GWXXcqHvTTPvu22267v
L5OeIU1mluSQysKU5dT/9MPDXS0qIvBSj027pPnee+9Nl9VZH3iTUFJ/mit7
O90LTsoLhn2WLVuWZqx3SX5MM5Yq0fdRVyWubmy/J5988uTJk/+zK23Yq6++
2vnXwJu+Lqkhz7U/eUlz7p6qniPJIy1v5i3SaiaPX3fddb3vVs4W0uKmXRw/
frwvBdgEm3ZJczr58gpwc0lzhkTvbPXwww8/+OCDgzcypNGVHJ0EesMNN5Rh
kP/1zTffnCXlUuQszz+93CVp5dZbb83CJUuWHHDAAWVhJvdm6u8MCrzvvvtu
HkJ2Wi5dLqMrGyy//f1ds5ls2iXN33///U477ZT60wTe6dOn957JXbFiRbq4
wRtJsWoCZqSLO/PMM5sfe8NpYml62nJ73bp1icbpDPsuaW5scDAP3mYakilT
puTAmouWy1mb3k1ddtllzvkOF4GXlv6awFsuRS5vwchs9fzzz28w8I4cObK8
hXb+/PkLFixIK5V62Om+wTa/yhScQnfFFVd0upUzPVvayL7Am7tnSblC+NJL
L73ooouyTnl5udONwDnawYH37bffPuGEE1KHf/311xS67Oh3Am+W9L0mmbyc
lq9c5pe/ZCbrbbbZpvcvk7vkGMrK5513XhZmOk6xzaQ/3KWiLgIv9diEwJs8
Mm3atJIsmtNM559//jXXXFPOKbzzzjt77rlnOTn10UcfpbI12/nll1/Gjh3b
nCZ44oknUos63TdXpl41XdxDDz2UYpWVN7jfL7/8cq+99mouEE2cKY1lE3jz
oFKgyjvp/mTgTY9XTkmvWbMmc8GHH36Y24899ljySx5sCm8qZ7kO57333hs1
alT5S1588cXlk6wYkk0IvCmk1157bfkoyCbwJt6edtpp5dr1TIv77bdfuaa0
bzQOaXR1ui/OjBgx4quvvup0P+o2txMlOt1Rnbs0ETvpdf/99//tt9/y22b6
y3yd9ZvPmOoLvJmX99hjj4yfcj1Y8lFWTqptVtjYrtl8NiHwZiQsWrSoXHPe
BN786tBDDy1Xffz0008TJ07Mf7/TvTK5/EOL3O59oWbhwoXpo5rf9obTtJcX
XHBB87kx5ZzCBgPv7wzmvm2myqUjXbteBmSSb8Zk8zrkW2+9tcMOOwi8w0Xg
paWWgXfVqlVpb/oWnn766Z3uRcuLFy8uS84666yyqQTJUuWWLl36wAMP5Eaq
wdFd6bUyPjMXN5/JnNbu2WefzS7mzJlz6qmnpkLOnDkzM3KK6pQpUxIMk1sT
ZjOes/H0S8cdd1w6wPLxF80es7vy1tpnnnnmqKOOypSXwHvllVd2uh94NaHr
xBNPTInOZvt2nRt33HHH+PHjDz/88Ntuu63TfQWvfNR8Ymz61U73FenRo0e/
//77ebB9vV8m4lTgMWPG5NFl8n3xxRfLXZq/TFY499xz87hmzZqVxiPbWb58
+bHHHjt5vfLaNQIv9WgZeDNox613/PHH33jjjeXs0ty5c1MuOt1veMntlKw8
8VOFknnLHQd/FPzAwMCMGTNShbJyqmsTcpN5Uz0Sh/OrSy65pLyhbIP7TV6+
9957mw0mWeeO69atS50sa6bA3n333aUhTOUc96/KBxyl8etrZVPHShlvJLmc
ccYZzcTx0ksvnX322elLS40tC1evXp0f82fMBptv98izO8fQfBohLbUPvJkf
y38zgy2TYBkt6efLxz1lMsoAyADLLHnEEUeUT/zuDBqNQxpdne783ntl+/Tp
08vu8hTIlN17eFOnTs1TYNKkSb2XPVx33XXNmb7MyL176XQTx4IFC8rtPJuO
OeaY8swqNrZrNp/2gTf1qoyi/NfS15WPolqxYkVzhjThN71TRuPBBx98yy23
lJc1EjDLe8oaKSAZh9nIQQcdlCJZRnWR5qr5wqME2Nw3q2Wb2WApaClTeVL0
HdjvDOa+bV544YW9RbIE4TyQdG55BmUkX3311WlH80CG+9/yb0rgpaWWgXdL
kTk0xafMpAmtvRfaUT+Bl3q0DLzwF2gfeGFzax94YXMTeGnpbxZ4O93LXSZM
mDBt2rQ5c+Z4I8+WReClHgIv9RB4qYfASz0EXlr6+wVetlwCL/UQeKmHwEs9
BF7qIfDSksBLPQRe6iHwUg+Bl3oIvNRD4KUlgZd6CLzUQ+ClHgIv9RB4qYfA
S0sCL/UQeKmHwEs9BF7qIfBSD4GXlgRe6iHwUg+Bl3oIvNRD4KUeAi8tCbzU
Q+ClHgIv9RB4qYfASz0EXloSeKmHwEs9BF7qIfBSD4GXegi8tCTwUg+Bl3oI
vNRD4KUeAi/1EHhpSeClHgIv9RB4qYfASz0EXuoh8NKSwEs9BF7qIfBSD4GX
egi81EPgpSWBl3oIvNRD4KUeAi/1EHiph8BLSwIv9RB4qYfASz0EXuoh8FIP
gZeWBF7qIfBSD4GXegi81EPgpR4CLy0JvNRD4KUeAi/1EHiph8BLPQReWhJ4
qYfASz0EXuoh8FIPgZd6CLy0JPBSD4GXegi81EPgpR4CL/UQeGlJ4KUeAi/1
EHiph8BLPQRe6iHw0pLASz0EXuoh8FIPgZd6CLzUQ+ClJYGXegi81EPgpR4C
L/UQeKmHwEtLAi/1EHiph8BLPQRe6iHwUg+Bl5YEXuoh8FIPgZd6CLzUQ+Cl
HgIvLQm81EPgpR4CL/UQeKmHwEs9BF5aKoH3p59++hmGWwm8a9euHe4DgZ+/
/vrrjMYEjeE+EPg5UTej8dtvvx3uA4Gff/jhh4zGgYGB4T4Q+PnHH38UeGmj
BF4AAIAti8DLH1qzZs0AAADAluabb74Z7jgFAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAwObyf6YvFy8KZW5kc3RyZWFtIAplbmRvYmog
CjggMCBvYmogWy9QREYgL1RleHQgL0ltYWdlQ10KZW5kb2JqIAo5IDAgb2Jq
IAo8PAovTGVuZ3RoIDM5Cj4+CnN0cmVhbQpxCjYxMS45NTkgMCAwIDc5MS45
NDcgMCAwIGNtCi9JbTAgRG8KUQoKZW5kc3RyZWFtIAplbmRvYmogCjMgMCBv
YmogCjw8Ci9Dcm9wQm94IFswIDAgNjExLjk1OSA3OTEuOTQ3XQovUGFyZW50
IDEgMCBSCi9UaHVtYiA0IDAgUgovUmVzb3VyY2VzIAo8PAovWE9iamVjdCAK
PDwKL0ltMCA2IDAgUgo+PgovUHJvY1NldCA4IDAgUgo+PgovTWVkaWFCb3gg
WzAgMCA2MTEuOTU5IDc5MS45NDddCi9UeXBlIC9QYWdlCi9Db250ZW50cyA5
IDAgUgo+PgplbmRvYmogCjEgMCBvYmogCjw8Ci9LaWRzIFszIDAgUl0KL0Nv
dW50IDEKL1R5cGUgL1BhZ2VzCj4+CmVuZG9iaiAKMTAgMCBvYmogCjw8Ci9Q
YWdlcyAxIDAgUgovVHlwZSAvQ2F0YWxvZwo+PgplbmRvYmogCjExIDAgb2Jq
IAo8PAovQ3JlYXRvciAocGRmdGsgMi4wMiAtIHd3dy5wZGZ0ay5jb20pCi9Q
cm9kdWNlciAoaXRleHQtcGF1bG8tMTU1IFwoaXRleHRwZGYuc2YubmV0LWxv
d2FnaWUuY29tXCkpCi9Nb2REYXRlIChEOjIwMTQwODA2MTY1MzI2WikKL0Ny
ZWF0aW9uRGF0ZSAoRDoyMDE0MDgwNjE2NTMyNlopCj4+CmVuZG9iaiB4cmVm
CjAgMTIKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMjYxMzc2IDAwMDAwIG4g
CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDI2MTE3NSAwMDAwMCBuIAowMDAw
MDAwMDQyIDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwNzg5
OCAwMDAwMCBuIAowMDAwMDA1NjQ4IDAwMDAwIG4gCjAwMDAyNjEwNDYgMDAw
MDAgbiAKMDAwMDI2MTA4MyAwMDAwMCBuIAowMDAwMjYxNDM1IDAwMDAwIG4g
CjAwMDAyNjE0ODcgMDAwMDAgbiAKdHJhaWxlcgoKPDwKL0luZm8gMTEgMCBS
Ci9Sb290IDEwIDAgUgovU2l6ZSAxMgovSUQgWzw0MWMwNTBiZmVlOTNiZTQw
OTA2YzNhM2VmNmVmMDE0Yj48MzlhNTRkODM2NzZlNmRiZWNmODc2NzJkMDc1
YTE0MzU+XQo+PgpzdGFydHhyZWYKMjYxNjcxCiUlRU9GCg==

--===============6236561538251940482==--


From nobody Fri Aug  8 01:01:08 2014
Return-Path: <markzzzsmith@yahoo.com.au>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243DE1A04C5 for <ipv6@ietfa.amsl.com>; Fri,  8 Aug 2014 01:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level: 
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 tk_zJiWzyQAv for <ipv6@ietfa.amsl.com>; Fri,  8 Aug 2014 01:01:05 -0700 (PDT)
Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782EC1A0564 for <ipv6@ietf.org>; Fri,  8 Aug 2014 01:01:05 -0700 (PDT)
Received: from [98.139.214.32] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 08 Aug 2014 08:01:04 -0000
Received: from [98.139.212.239] by tm15.bullet.mail.bf1.yahoo.com with NNFMP;  08 Aug 2014 08:01:04 -0000
Received: from [127.0.0.1] by omp1048.mail.bf1.yahoo.com with NNFMP; 08 Aug 2014 08:01:04 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 710576.37820.bm@omp1048.mail.bf1.yahoo.com
Received: (qmail 21199 invoked by uid 60001); 8 Aug 2014 08:01:04 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024;  t=1407484864; bh=iHRdd6VvSXxL6e0JdwRWK24hgBLi5Hp5yCUs+b2EAFg=;  h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XCVMZeGXMD6izMtq6FmVJpZTt4ojUw5ilbo1e0cbux7FKbb8q8qpzQc+6KD1tf6obfnu7wqGqW/cZjzbJhW83IO/BRXeDWQ9XyIrkGFInSbV2jPvKjUnjQiI36xKCzOENrZvBDgpKYvNJdCnpnTqOHr82GlKPWy1e3Isr8Y5YDw=
X-YMail-OSG: OhKeP7gVM1kuNzh18OiAmY3g7R3WGmeO0JHlclbwkx7sdGr 24GbFP2jlK9xQnsF_PhEx4a9ZA6hja2HVhfy.3nz02AdXShQe8lFOTyo9Gut gcCzkxurfror4F2pVgaFwQBCHMNXYvQWeHPIn0Qxv8DzhOq9yG63eazmIVze EBsqTZySLus6SfhbaNQW.dGV4kjQFwiwFo8r8sDnVzEhJ..x8uaqU14da6p0 j9Kivs_lExgMe2jqTr4i4F9wAqzFX1D.cgRhdhPLCH3JNa52vUCyKCqlL6GR 2jP.9xQ3h4HUWR1VpohdZoksTtBi_5FsyQp9Tlv8VDOgEnLXJvIVs8LkFOPN V2otoEEk9zpR9wg_9LLciHJgxoWy_tE..xoFOtI2AKR9giZgRn8isfYy8Kl0 3rSlZDjpuJLoAAaN8lpxGJDALI3fKtVpi4wSLT7xyWt0co1rsbXxPrPjf_6. AkOwL6YwSMYfOE_mWYVyjmVYmIUjda1BtNqNHXzMHNTPRUWzih7Z.GvkhZoW mOQ3gXGEwf0q4avm8y3DbxRDdn71fN2sU.iPckUQxdqm3d6HNTkZWkw--
Received: from [150.101.221.237] by web162201.mail.bf1.yahoo.com via HTTP; Fri, 08 Aug 2014 01:01:04 PDT
X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBBbGV4YW5kcnUgUGV0cmVzY3UgPGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb20.Cj4gVG86IGlwdjZAaWV0Zi5vcmcKPiBDYzogCj4gU2VudDogRnJpZGF5LCA4IEF1Z3VzdCAyMDE0IDEyOjA4IEFNCj4gU3ViamVjdDogUmU6IEltcG9ydGFuY2Ugb2YgU0xBQUMgKFJlOiBBbmFseXNpcyBvZiA2NC1iaXQgQm91bmRhcnkgaW4gSVB2NiBBZGRyZXNzaW5nKQo.IAo.IExlIDA3LzA4LzIwMTQgMTU6NDgsIExvcmVuem8gQ29saXR0aSBhIAEwAQEBAQ--
X-Mailer: YahooMailWebService/0.8.198.689
References: <776E0CDC-3D76-4066-9AC6-2BA151C0312E@gmail.com> <53E27607.6070105@gmail.com> <1407378535.24444.3.camel@tachyon.blake> <53E2E89D.2080300@joelhalpern.com> <CAKD1Yr3zF3s=iFuRr3pN+k-hw0d04iL23DHU7WqEUZmGBe-itg@mail.gmail.com> <53E3829A.9060002@umn.edu> <CAKD1Yr2nY_hxD2US=MC3=926Yd_KyVrM3m+M41Ap4aVfm1rMTw@mail.gmail.com> <53E3884E.8040503@gmail.com>
Message-ID: <1407484864.5345.YahooMailNeo@web162201.mail.bf1.yahoo.com>
Date: Fri, 8 Aug 2014 01:01:04 -0700
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Subject: Re: Importance of SLAAC (Re: Analysis of 64-bit Boundary in IPv6 Addressing)
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>, "ipv6@ietf.org" <ipv6@ietf.org>
In-Reply-To: <53E3884E.8040503@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/GvSPd-_iCU1GpeW7WQIsqN-Sg_U
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Aug 2014 08:01:07 -0000

=0A=0A=0A=0A----- Original Message -----=0A> From: Alexandru Petrescu <alex=
andru.petrescu@gmail.com>=0A> To: ipv6@ietf.org=0A> Cc: =0A> Sent: Friday, =
8 August 2014 12:08 AM=0A> Subject: Re: Importance of SLAAC (Re: Analysis o=
f 64-bit Boundary in IPv6 Addressing)=0A> =0A> Le 07/08/2014 15:48, Lorenzo=
 Colitti a =E9crit :=0A>>  On Thu, Aug 7, 2014 at 10:43 PM, David Farmer <f=
armer@umn.edu=0A>>  <mailto:farmer@umn.edu>> wrote:=0A>> =0A>>  And after a=
 short while, the race to the bottom ends at /128, and=0A>>  we're all forc=
ed to implement NAT because customers don't want to=0A>>  pay twice to conn=
ect two devices to the same network.=0A>> =0A>> =0A>>  Do we have to drop t=
he NAT-Bomb?=A0 There is no consensus to change the=0A>>  64 bit IID at thi=
s time, but 64 is not a magic number. Considering=0A>>  alternative IID siz=
es or even a variable length is NOT equivalent to=0A>>  condoning NAT.=0A>>=
 =0A>> =0A>>  Of course it's not equivalent to condoning it. The road to he=
ll is=0A>>  paved with good intentions :-)=0A> =0A> One good intention is P=
refix Delegation.=0A> =0A> But unfortunately Prefix Delegation distributing=
 /64s to whomever asks=0A> is not making for an intuitively simple - aggreg=
ated - addressing=0A> architecture.=0A>=A0=0A=0AIf I understand this statem=
ent correctly, I don't think PD was designed with the intention of just del=
egating a single /64, but rather an aggregate of many /64s.=0A=0AThat being=
 said, at some point it is necessary to aggregate routes to scale. A broadb=
and ISP supporting millions of subscribers is not going to be able to perma=
nently delegate a prefix of any size (/64, /56 or /48) to the subscriber re=
gardless of where they're connected to the network, because of course it wo=
uld involve trying and failing to carry all of those routes in all of the I=
SP's internal routers.=0A=0AAggregation at geographic boundaries seems reas=
onable to me - if people move far enough (different city, different suburb,=
 different PoP etc.) then they should expect to have to a different delegat=
ed prefix. As an ISP you could offer, at additional cost, to preserve their=
 original prefix, which fundamentally charging for the individual route tab=
le slot they're occupying in all of your routers.=0A=0A=0A> Alex=0A> =0A>> =
=0A>> =0A>>  --------------------------------------------------------------=
------=0A>>  IETF IPv6 working group mailing list ipv6@ietf.org Administrat=
ive=0A>>  Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A> =0A>>  -=
-------------------------------------------------------------------=0A>> =
=0A> =0A> =0A> ------------------------------------------------------------=
--------=0A> IETF IPv6 working group mailing list=0A> ipv6@ietf.org=0A> Adm=
inistrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A> ------=
--------------------------------------------------------------=0A> 


From nobody Fri Aug  8 02:05:53 2014
Return-Path: <ot@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A431B290F for <ipv6@ietfa.amsl.com>; Fri,  8 Aug 2014 02:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 1eHxEKhvOALE for <ipv6@ietfa.amsl.com>; Fri,  8 Aug 2014 02:05:50 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB6C51B28FC for <ipv6@ietf.org>; Fri,  8 Aug 2014 02:05:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=356; q=dns/txt; s=iport; t=1407488750; x=1408698350; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=dBUAbYK+7bzevHe17fbX0g7juYCUpdtxnSFsibOgXt8=; b=ifPe1lJYMo12gXIrxANdlgz0Gzgktn9d3Ts3g2583ycImD15sC0g7g84 B1BSXt5pFcEskQUrtcYfU8r+9jUBAWTqlE4OmMWPEPJApdbc+J1TPGf52 TQ4o854x/Lhnm/byS9D1zaMH8m86SwFtvFo8hAYGZki/S9sm/NBU7opri A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEAE+S5FOtJssW/2dsb2JhbABa2gR3hESBfYhVn3OlMxeOahEBhAaBHAWcJZRyg1k7gTw
X-IronPort-AV: E=Sophos;i="5.01,823,1400025600"; d="scan'208";a="132146642"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 08 Aug 2014 09:05:47 +0000
Received: from dhcp-lys01-vla250-10-147-112-122.cisco.com (dhcp-lys01-vla250-10-147-112-122.cisco.com [10.147.112.122]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7895kln026986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ipv6@ietf.org>; Fri, 8 Aug 2014 09:05:47 GMT
From: Ole Troan <ot@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: Co-chair - paternity leave
Message-Id: <56E04B0A-C726-47B3-B7BF-8BEEC606A3EF@cisco.com>
Date: Fri, 8 Aug 2014 11:05:52 +0200
To: 6man WG <ipv6@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1971.5\))
X-Mailer: Apple Mail (2.1971.5)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/L-I4LRpYPYqQ1iAIi84LxG6gyik
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Aug 2014 09:05:51 -0000

All,

I'm going to be on diaper duty for the next 14 weeks. I'll try to read =
email, and I'll have an eye out for 6man issues, but please allow for =
slow response times.

The plan is to have the 6man WG meeting in Honolulu as usual. Up until =
then I hope we'll get most of the current working group documents =
advanced.

Best regards,
Ole=


From nobody Fri Aug  8 13:19:16 2014
Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375011A854D; Fri,  8 Aug 2014 13:19:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 OTAOQlL_zmXU; Fri,  8 Aug 2014 13:19:11 -0700 (PDT)
Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E5F1B2A18; Fri,  8 Aug 2014 13:19:11 -0700 (PDT)
Received: by mail-pa0-f49.google.com with SMTP id hz1so7747279pad.22 for <multiple recipients>; Fri, 08 Aug 2014 13:19:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N5Rshfp2LvAE3j8XyNOFpQrIQaNzsw9XRKZvIjwbBxI=; b=d0Yi0x23Ko20GJoMY3M+3vt7k4iJWKByXF5s5uL4Mn+0U7zRDez2o6953pCqfRGxPT XVrSrfATsrOPtFvyACH+zH0E8hVop9NtxLzCkz6g5wMlUSbLbVyIU3dvcynzeb1+BFH8 BQ8/eAKiYljwC8oEnK3xO4wEq1tiPqHHYjRwzrOXwyUT3PD1wiRE3NVDgcSuSCbMTJZc T2xTdQMTy8joWtljTl6/iKpJYrmTNa5EfCkaE8x888pzky26nMI+qRa5elPRsIzyEO5s 9ZtFue4u9pw/HgEAVDKQ/Ep6HEZdkBwEYOTkjBzwqNyLm9jWCXX2xjuDLqj84ftBYoMz ne/Q==
X-Received: by 10.66.123.75 with SMTP id ly11mr20247823pab.82.1407529150895; Fri, 08 Aug 2014 13:19:10 -0700 (PDT)
Received: from [10.82.101.34] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id cb8sm28710727pad.8.2014.08.08.13.19.08 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 13:19:09 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com>
Date: Fri, 8 Aug 2014 16:19:05 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/4VMHg37cqnC6xzczCtlNrcrpeTQ
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Aug 2014 20:19:14 -0000

On Aug 5, 2014, at 4:11 AM 8/5/14, Pascal Thubert (pthubert) =
<pthubert@cisco.com> wrote:

> I think I see what you are saying, Phil.
>=20
> I can split 1.3 to isolate the deviations to 6437.
>=20
> I also need to move the following text from section 3 in that new =
section=20
>=20
>  This may seem contradictory with the IPv6
>   Flow Label Specification [RFC6437] which stipulates that once it is
>   set, the Flow Label is left unchanged; but the RFC also indicates a
>   violation to the rule can be accepted for compelling reasons, and
>   that security is a case justifying such a violation.  This
>   specification suggests that energy-saving is another compelling
>   reason for a violation to the aforementioned rule.
>=20
> Proposed update for that text:
>=20
>   This specification updates the IPv6
>   Flow Label Specification [RFC6437], which stipulates that once it is
>   set, the Flow Label is left unchanged. [RFC6437] also indicates that=20=

>   a violation to the rule can be accepted for compelling reasons,=20
>   but limit those compelling reasons to security related issues.  This
>   specification indicates that energy-saving is another compelling
>   reason that justifies a violation to the aforementioned rule.

Well, I personally don't read the text in RFC 6437 as saying "a =
violation to the rule can be accepted for compelling reasons".  To avoid =
arguments with difficult individuals like me, you might take a more =
neutral approach:

This document updates the following text from RFC 6437, "IPv6 Flow
Label Specification":

OLD:

   Once set to a non-zero value, the Flow Label is expected to be
   delivered unchanged to the destination node(s).  A forwarding node
   MUST either leave a non-zero flow label value unchanged or change it
   only for compelling operational security reasons as described in
   Section 6.1.

NEW:

   Once set to a non-zero value, the Flow Label is expected to be
   delivered unchanged to the destination node(s).  A forwarding node
   MUST either leave a non-zero flow label value unchanged or change
   it only for (1) compelling operational security reasons as
   described in Section 6.1 or (2) use as specified in RFC-to-be, "The
   IPv6 Flow Label within a RPL domain".

- Ralph


>=20
> What do you think?
>=20
> Cheers,
>=20
> Pascal
>=20
>=20
>> -----Original Message-----
>> From: Philip Levis [mailto:pal@cs.stanford.edu]
>> Sent: lundi 4 ao=FBt 2014 20:23
>> To: Ralph Droms
>> Cc: Pascal Thubert (pthubert); Michael Richardson; Routing Over Low =
power
>> and Lossy networks; ipv6@ietf.org
>> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
>>=20
>>=20
>> On Aug 4, 2014, at 11:10 AM, Ralph Droms <rdroms.ietf@gmail.com> =
wrote:
>>=20
>>>=20
>>> On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert)
>> <pthubert@cisco.com> wrote:
>>>=20
>>>> The change is now done, Ralph.
>>>>=20
>>>> The only difference between =
draft-thubert-6man-flow-label-for-rpl-03 and
>> draft-thubert-6man-flow-label-for-rpl-04 is
>>>>=20
>>>> Updates: 6437 (if approved)
>>>=20
>>> I suggest adding a section to your doc that explains exactly what is =
being
>> updated in RFC 6437.
>>>=20
>>> - Ralph
>>=20
>>=20
>> I agree. I think some of the text in 1.3 can be re-used for this =
purpose.
>>=20
>> Phil


From nobody Fri Aug  8 13:36:53 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0751A0109; Fri,  8 Aug 2014 13:36:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 T_5zgP63Jthn; Fri,  8 Aug 2014 13:36:49 -0700 (PDT)
Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53E41A00D8; Fri,  8 Aug 2014 13:36:49 -0700 (PDT)
Received: by mail-pa0-f44.google.com with SMTP id eu11so7889438pac.31 for <multiple recipients>; Fri, 08 Aug 2014 13:36:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jCX5VXOLf5w1EYCN3Mnngzz3q94BWCN1WAGlc48IhS0=; b=bxiqODlEtd+zxkz8jT68rR43wYDrNkoShv/9RRF7l+PTHjdFQgBl+MIU6KCtrXIRyD Vq6iPgRiGJm+naEjjgxRL3I5gFNL10UIrwwJ/uyBdWiYiO6wDpugbpUXFB8QKCfz0b7b 2h6Wrlf61qbhhH9dD8wl20Uadrhd1qsS2vpm6iSvtZkt2Lbt+SyxK8vFsP3Xa8HAyhUu FTq7kdqZaqPhyVGALQ5Rkh0tTacfWqDoQ57smyM1Bkto7wwpI+0g7WamvWrjPbtD/jsw nnar/fynuN5IOcoiMu0XjQTLK9QXrVfjzecm8Ye/HeR/nQQkpeacsjN1JPmeQVIoKFGl sBAA==
X-Received: by 10.70.89.43 with SMTP id bl11mr3647102pdb.163.1407530209289; Fri, 08 Aug 2014 13:36:49 -0700 (PDT)
Received: from [192.168.178.23] (146.197.69.111.dynamic.snap.net.nz. [111.69.197.146]) by mx.google.com with ESMTPSA id om8sm5709726pdb.58.2014.08.08.13.36.46 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Aug 2014 13:36:48 -0700 (PDT)
Message-ID: <53E534E8.4050304@gmail.com>
Date: Sat, 09 Aug 2014 08:36:56 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ralph Droms <rdroms.ietf@gmail.com>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com>
In-Reply-To: <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/CN4-zTYGXW5XDmrFoJhQSN2YLaI
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "Pascal Thubert \(pthubert\)" <pthubert@cisco.com>, "ipv6@ietf.org" <ipv6@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Aug 2014 20:36:51 -0000

Ralph,

On 09/08/2014 08:19, Ralph Droms wrote:
> On Aug 5, 2014, at 4:11 AM 8/5/14, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> 
>> I think I see what you are saying, Phil.
>>
>> I can split 1.3 to isolate the deviations to 6437.
>>
>> I also need to move the following text from section 3 in that new section 
>>
>>  This may seem contradictory with the IPv6
>>   Flow Label Specification [RFC6437] which stipulates that once it is
>>   set, the Flow Label is left unchanged; but the RFC also indicates a
>>   violation to the rule can be accepted for compelling reasons, and
>>   that security is a case justifying such a violation.  This
>>   specification suggests that energy-saving is another compelling
>>   reason for a violation to the aforementioned rule.
>>
>> Proposed update for that text:
>>
>>   This specification updates the IPv6
>>   Flow Label Specification [RFC6437], which stipulates that once it is
>>   set, the Flow Label is left unchanged. [RFC6437] also indicates that 
>>   a violation to the rule can be accepted for compelling reasons, 
>>   but limit those compelling reasons to security related issues.  This
>>   specification indicates that energy-saving is another compelling
>>   reason that justifies a violation to the aforementioned rule.
> 
> Well, I personally don't read the text in RFC 6437 as saying "a violation to the rule can be accepted for compelling reasons".  To avoid arguments with difficult individuals like me, you might take a more neutral approach:
> 
> This document updates the following text from RFC 6437, "IPv6 Flow
> Label Specification":
> 
> OLD:
> 
>    Once set to a non-zero value, the Flow Label is expected to be
>    delivered unchanged to the destination node(s).  A forwarding node
>    MUST either leave a non-zero flow label value unchanged or change it
>    only for compelling operational security reasons as described in
>    Section 6.1.
> 
> NEW:
> 
>    Once set to a non-zero value, the Flow Label is expected to be
>    delivered unchanged to the destination node(s).  A forwarding node
>    MUST either leave a non-zero flow label value unchanged or change
>    it only for (1) compelling operational security reasons as
>    described in Section 6.1 or (2) use as specified in RFC-to-be, "The
>    IPv6 Flow Label within a RPL domain".

I *really* don't think RFCs are algorithms to the point where we
need to do this. I see no reason why flow-label-for-rpl can't simply
declare itself an exception to this clause of RFC 6437.

   Brian


From nobody Sun Aug 10 09:29:18 2014
Return-Path: <cabo@tzi.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B421A07A1; Sun, 10 Aug 2014 09:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.149
X-Spam-Level: *
X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 2X0LjHp8OfE6; Sun, 10 Aug 2014 09:29:11 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611AC1A079F; Sun, 10 Aug 2014 09:29:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s7AGT4Yg016758; Sun, 10 Aug 2014 18:29:04 +0200 (CEST)
Received: from [192.168.217.106] (p54890283.dip0.t-ipconnect.de [84.137.2.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5716C1B3; Sun, 10 Aug 2014 18:29:03 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com>
Date: Sun, 10 Aug 2014 18:29:01 +0200
X-Mao-Original-Outgoing-Id: 429380941.471819-dfbf150314bf00e9194c8a1c7e1ac4ac
Content-Transfer-Encoding: quoted-printable
Message-Id: <64A628BA-EADA-4738-BB8D-2CFFDE8E6CF0@tzi.org>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com>
To: "ipv6@ietf.org" <ipv6@ietf.org>, roll <roll@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/l3-_NbkRIEjGqxaqXelFWPLEj_Y
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Aug 2014 16:29:13 -0000

So far, we have mainly discussed the need for an optimization (it seems =
we now agree there is a need) and the interaction between the normative =
components of RFC 6437 and those of the draft at hand.

I=92d now like to bring up a different question:

Is this the right approach?

I have written up what appears to be a more natural approach in the =
strawman draft:
http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-00

Why are we doing the flow-label thing and not the more natural thing?

[ ] because the flow label hack works on packets that leave the 6lo =
networks.
    =95 but do we really need to optimize this on the non-6lo networks?
[ ] because the flow label hack has been around for a while and is now =
cast in stone.
    =95 is it?
[ ] because there is a flaw with the way this has been integrated into =
the 6lo framework.
    =95 ______ (fill in the flaw)
[ ] because ______ (fill in the reason)

Inquiring minds want to know.

Gr=FC=DFe, Carsten


From nobody Sun Aug 10 09:48:35 2014
Return-Path: <trac+6man@trac.tools.ietf.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C967A1A07A2; Sun, 10 Aug 2014 09:48:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.669
X-Spam-Level: 
X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.668] autolearn=ham
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 IbgRt-3lZIF0; Sun, 10 Aug 2014 09:48:32 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 9D80A1A0470; Sun, 10 Aug 2014 09:48:32 -0700 (PDT)
Received: from localhost ([::1]:57692 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <trac+6man@trac.tools.ietf.org>) id 1XGWIH-0002t1-PF; Sun, 10 Aug 2014 09:48:29 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "6man issue tracker" <trac+6man@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: pthubert@cisco.com, mariainesrobles@gmail.com
X-Trac-Project: 6man
Date: Sun, 10 Aug 2014 16:48:29 -0000
X-URL: http://tools.ietf.org/wg/6man/
Subject: [6man] #5 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Evidence about energy consumption
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/5
Message-ID: <067.98c5b4aa0bdf702996c666086d0b809d@trac.tools.ietf.org>
X-Trac-Ticket-ID: 5
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org
X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/6Zj1BH22IZXEGt12VTXrANjwYok
Cc: roll@ietf.org, 6man@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: 6man@ietf.org
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Aug 2014 16:48:33 -0000

#5: draft-thubert-6man-flow-label-for-rpl-03 Evidence about energy consumption

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08755.html

 From: Philip Levis <pal at cs.stanford.edu> Date: Tue, 29 Jul 2014
 17:02:17 -0700

 I'm worried by the fundamental premise of the approach:

 "The 8-octets overhead is detrimental to the LLN operation, in particular
 with regards to bandwidth and battery constraints.  The extra
 encapsulation may cause a containing frame to grow above maximum frame
 size, leading to Layer 2 or 6LoWPAN [RFC4944] fragmentation, which in turn
 cause even more energy spending and issues discussed in the LLN Fragment
 Forwarding and Recovery [I-D.thubert-6lo-forwarding-fragments]."

 The basic assumption of this paragraph is that energy consumption is
 dominated by transmission time. Has anyone presented any actual evidence
 -- i.e., actual energy numbers -- of the cost this introduces?

 Because

 "This specification suggests that energy-saving is another compelling
 reason for a violation to the aforementioned rule."

 makes the assumption that the energy saving is significant. Breaking the
 end-to-end nature of the flow label for some tiny saving seems like a
 mistake. But if this would actually save a significant amount of energy
 that couldn't be saved through other, simpler, means, then it seems like a
 great idea.

 My fear is that this area -- low-power link layers, energy saving
 protocols -- is an area that is still new to the IETF and tends to have
 very subtle issues. What's being proposed here is pretty significant.
 Simple, intuitive arguments might not hold up to scrutiny in real
 networks.

 If you look at it in this light, one comment the draft makes is especially
 troubling:

 "But if we consider the whole RPL domain as a large virtual host from the
 standpoint of the rest of the Internet"

 This is completely contrary to the deep, fundamental premise of the
 Internet of Things and when we started down the path of bringing IPv6 to
 LLNs. Before 6lowpan, LLN devices were typically considered peripherals,
 devices that connect to an Internet host through other interfaces and
 protocols (USB, ZWave, ZigBee, etc., etc.). This gave greater flexibility
 on what those networks could do, but it placed a hard barrier on the
 Internet. You needed new tools, management interfaces, software, and
 policies for managing the two sides of the network. E.g, you manage your
 IP network and separately manage your embedded network. The big promise of
 6lowpan and all of the subsequent technologies the IETF has developed is
 that instead, we can consider it IP down into these networks as well.
 Considering an entire LLN as a virtual host goes back to this segmented
 model, and so is a step backwards.

 In summary, this draft presents a tradeoff: break the end-to-end behavior
 of the flow label for improved energy efficiency. I'd argue strongly in
 favor of this draft if "improved" meant "doubles". But if it means "5% in
 1% of use cases", this seems like a poor tradeoff. The IETF 90 slides say
 it's a "show stopper" for SDOs. I'm not sure what that means? Is there any
 greater detail on this? I'd like to make an informed engineering decision,
 but don't have enough data to do so.

 Phil

-- 
-------------------------------------------------+-------------------------
 Reporter:  mariainesrobles@gmail.com            |      Owner:
     Type:  defect                               |  pthubert@cisco.com
 Priority:  major                                |     Status:  new
Component:  draft-thubert-6man-flow-label-for-   |  Milestone:
  rpl                                            |    Version:
 Severity:  In WG Last Call                      |   Keywords:
-------------------------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6man/trac/ticket/5>
6man <http://tools.ietf.org/wg/6man/>


From nobody Sun Aug 10 09:50:49 2014
Return-Path: <trac+6man@trac.tools.ietf.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37B21A07AE; Sun, 10 Aug 2014 09:50:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.132
X-Spam-Level: 
X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.668] autolearn=ham
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 m0clkZqS6Lw7; Sun, 10 Aug 2014 09:50:45 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 A912E1A0465; Sun, 10 Aug 2014 09:50:45 -0700 (PDT)
Received: from localhost ([::1]:57824 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <trac+6man@trac.tools.ietf.org>) id 1XGWKS-0008KK-J1; Sun, 10 Aug 2014 09:50:44 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "6man issue tracker" <trac+6man@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: pthubert@cisco.com, mariainesrobles@gmail.com
X-Trac-Project: 6man
Date: Sun, 10 Aug 2014 16:50:44 -0000
X-URL: http://tools.ietf.org/wg/6man/
Subject: Re: [6man] #5 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Evidence about energy consumption
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/5#comment:1
Message-ID: <082.2f6b36f09458a02d96c3e91fa0512248@trac.tools.ietf.org>
References: <067.98c5b4aa0bdf702996c666086d0b809d@trac.tools.ietf.org>
X-Trac-Ticket-ID: 5
In-Reply-To: <067.98c5b4aa0bdf702996c666086d0b809d@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org
X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/UOMjOx3kciJx1oQOR0mMzPisXtQ
Cc: roll@ietf.org, 6man@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: 6man@ietf.org
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Aug 2014 16:50:47 -0000

#5: draft-thubert-6man-flow-label-for-rpl-03 Evidence about energy consumption


Comment (by mariainesrobles@gmail.com):

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08756.html

 From: Brian E Carpenter <brian.e.carpenter at gmail.com> Date: Wed, 30 Jul
 2014 13:36:44 +1200

 On 30/07/2014 12:02, Philip Levis wrote:
 ...
 > "This specification suggests that energy-saving is another
 > compelling reason for a violation to the aforementioned
 > rule."
 >
 > makes the assumption that the energy saving is significant.
 > Breaking the end-to-end nature of the flow label for some
 > tiny saving seems like a mistake.

 I can't evaluate whether the energy saving is significant.
 However, I don't have any deep faith in the e2e-ness of the
 flow label. The reality (as RFC 6437 tries to recognise)
 is that it's a mutable field, and is therefore untrustworthy
 for e2e use. It has value for load balancing if all packets
 of a given flow have the same label, whether the label is
 set by the source or by a border device. For that reason,
 I think the usage proposed in this draft is OK.

 However, I do agree that at least a hand-waving estimate of
 the % energy saving would be useful.

     Brian Carpenter R

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

 Source:  http://www.ietf.org/mail-archive/web/roll/current/msg08761.html

 From: Philip Levis <pal at cs.stanford.edu> Date: Thu, 31 Jul 2014
 15:11:21 -0700

 On Jul 29, 2014, at 6:36 PM, Brian E Carpenter <brian.e.carpenter at
 gmail.com> wrote:

 > On 30/07/2014 12:02, Philip Levis wrote:
 > ...
 >> "This specification suggests that energy-saving is another
 >> compelling reason for a violation to the aforementioned
 >> rule."
 >>
 >> makes the assumption that the energy saving is significant.
 >> Breaking the end-to-end nature of the flow label for some
 >> tiny saving seems like a mistake.
 >
 > I can't evaluate whether the energy saving is significant.
 > However, I don't have any deep faith in the e2e-ness of the
 > flow label. The reality (as RFC 6437 tries to recognise)
 > is that it's a mutable field, and is therefore untrustworthy
 > for e2e use. It has value for load balancing if all packets
 > of a given flow have the same label, whether the label is
 > set by the source or by a border device. For that reason,
 > I think the usage proposed in this draft is OK.
 >
 > However, I do agree that at least a hand-waving estimate of
 > the % energy saving would be useful.
 >
 >    Brian Carpenter

 *shrug* My thoughts are pretty simple. I'm sure you know all this (as one
 of the authors!) but I'll revisit for everyone else's sake. 6437 states

 "A forwarding node MUST either leave a non-zero flow label value unchanged
 or change it only for compelling operational security reasons as described
 in Section 6.1."

 So, this is a MUST. Either the RPL flow label draft contradicts 6437 (and
 should say so explicitly), or there should be an explicit update to 6437.
 In fact, the current draft is misleading and incorrect. It says

 "but the RFC also indicates a violation to the rule can be accepted for
 compelling reasons, and that security is a case justifying such a
 violation.  This specification suggests that energy-saving is another
 compelling    reason for a violation to the aforementioned rule."

 This is *not* what 6437 says. It says for compelling operational security
 reasons, not compelling reasons, of which one case is security.

 Having been researching, implementing, and deploying low-power protocols
 for over a decade, I've become exceedingly skeptical when someone proposes
 a protocol with energy as a motivation without quantifying it. For
 example, there are tons of protocols in the research literature which talk
 about using transmission power control to save energy (trading off range
 for power). But almost all of these papers ignore the fact that (unlike
 mobile/cellular systems, which the authors have been publishing in for
 years) RF is a tiny sliver of power in low-power networks. So reducing
 your transmission (RF) power by 99% only reduces your radio power by 50%.
 Generally a losing proposition. This is the same reason why power saving
 in WiFi involves synchronization on AP beacons and not adjusting transmit
 power. If someone doesn't quantify the potential benefit based on real
 hardware and protocols, then it could be based on mistaken assumptions.

 I mean, it doesn't take much here. Start with a working low-power RPL
 network. Send packets with sizes following a reasonable distribution based
 on an actual application. In one experiment send just those packets. In
 another add the 8 bytes. In a third add 8 + the IP-in-IP encapsulation.
 Measure the energy cost.

 And, generally speaking, if you can't demonstrate the problem very easily,
 then perhaps it isn't a real problem at all.

 All that being said, I think using the flow label in this way is a good
 idea, and definitely valuable. But as it is now, doing so violates 6437,
 and so the assumptions implementers make when reading 6437. I think the
 bar for doing so should be high, higher than vague suggestions and hand
 waving which might not be correct.

 Phil

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08763.html


 From: Xavier Vilajosana <xvilajosana at eecs.berkeley.edu> Date: Fri, 1
 Aug 2014 10:50:15 +0200

 Dear Phil, all,

 I do not completely agree :)

 Let's look at what IPHC does at the LBR when a flow label is elided and
 has to be inflated to be forwarded to the IPv6 network, this standardized
 behaviour is somehow interfering the end to end notion of the flow label
 as the content is being populated at the border of the LLN. For me this is
 not different than changing the scope of the flow label inside the LLN to
 transport RPL information and resetting  it at the LBR once data moves
 outside of the network considering that inside the LLN the flow label has
 no meaning.

 Looking into an article we wrote some time back, "A Realistic Energy
 Consumption Model for TSCH Networks". published in IEEE Sensors

 we know that the charge used by a mote (something similar to telosb) to
 send 127bytes is around 69uC and to receive them is 72uC (considering the
 optimal case where receiver has a guard time of 1ms and the network is
 synchronized).  By using the flow label instead of the RPL extension
 header we save 5bytes which give us a gain 2,71uC per data packet per hop
 when sent and something similar when received (i.e ~5uC in total), this is
 a 8% saving (accounting TX and RX side) considering that motes are always
 using 127bytes packets.

 If we go to a more realistic case where motes send ~50bytes packets, the
 charge needed to send/receive them is something around 27.5uC and being
 able to save 5 bytes represents a 10% saving for the sender and 10% for
 the receiver (~20% saving if we look it overall per hop).
 If we use batteries that power the mote for 5 years, a 20% saving gives us
 ~1 more year which I think is pretty significant.

 regards,
 Xavi

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08764.html

 From: Carsten Bormann <cabo at tzi.org> Date: Fri, 1 Aug 2014 13:23:44
 +0200

 On 01 Aug 2014, at 10:50, Xavier Vilajosana <xvilajosana at
 eecs.berkeley.edu> wrote:

 >
 > Let's look at what IPHC does at the LBR when a flow label is elided and
 has to be inflated to be forwarded to the IPv6 network, this standardized
 behaviour is somehow interfering the end to end notion of the flow label
 as the content is being populated at the border of the LLN.

 No.  With IPHC, the flow label has always been there, it just was
 transmitted in a very compressed form.

 I think the visceral reaction that most of us have in using the flow label
 as a mesh routing header is that this blurs the layer boundaries.  So much
 for O, R, F, and rank.  Putting the VLAN (“instance ID�) into the packet
 is a significantly larger change, because it essentially extends the IP
 service interface by a VLAN ID.  We normally try to hide IDs of this kind
 below IP.

 Now, I’m not saying any of this new architecture is wrong.  I just think
 what we need to do is discuss this as the architectural change that it is,
 not as a simple optimization.  (The need for some kind of optimization of
 IP-in-IP mesh routing for small-packet IoT applications is pretty obvious
 to me.)

 The other story is that we are retracting RFC 6437 and turning the flow
 label into the “field you may trample on in your lower layers if you have
 a good reason�.  Cynically, one could say this is proper payback for
 designing this field without a compelling purpose and no protocol
 evolution story attached to it.  So the evolution just eats it.  Teachable
 moment.

 Grüße, Carsten

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08766.html

 From: "Pascal Thubert (pthubert)" Date: Fri, 1 Aug 2014 12:56:40 +0000

 > No.  With IPHC, the flow label has always been there, it just was
 transmitted
 > in a very compressed form.

 My take is that you are both providing angles on a same thing. It does not
 make sense for a LLN node to waste compute power and bandwidth to get a
 random through that is of use only in the core of the internet, should the
 packet ever get there. So the flow label is effectively zero - or
 something locally significant in specific standards, which is not design
 to serve the purpose of load balancing in the core. So in either case, we
 need the root to 'inflate' the zero flow label, or replace it by something
 that fits the core of the Internet. That behavior was not specified so far
 and it should be. This document is covering this particular gap.

 Cheers,

 Pascal

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08767.html

 From: "Pascal Thubert (pthubert)"  Date: Fri, 1 Aug 2014 13:25:06 +0000

 > I think the visceral reaction that most of us have in using the flow
 label as a
 > mesh routing header is that this blurs the layer boundaries.  So much
 for O,
 > R, F, and rank.  Putting the VLAN ("instance ID") into the packet is a
 > significantly larger change, because it essentially extends the IP
 service
 > interface by a VLAN ID.  We normally try to hide IDs of this kind below
 IP.
 >
 > Now, I'm not saying any of this new architecture is wrong.  I just think
 what
 > we need to do is discuss this as the architectural change that it is,
 not as a
 > simple optimization.  (The need for some kind of optimization of IP-in-
 IP
 > mesh routing for small-packet IoT applications is pretty obvious to me.)
 >
 >
 I agree, Carsten.

 An angle is that we allow for localized usage of the flow label as opposed
 to end-to-end.

 Another is that we allow for different semantics within a local domain, as
 long as the packet that leaves the local domain fits the requirements in
 RFC 6437.

 As you point out, it is worth noting that we include information about
 flow isolation and rules by which a flow will be routed, which is akin to
 Multi-Topology Routing though MTR is based on TOS bits.

 It would be good to design an architecture that encompasses such
 capabilities.

 We'll note that ISA100.11a is shipping with a flow label that contains an
 index to a state (so-called a contract) that is installed on the nodes on
 the way and by and large extends the notion of PHB on a per flow basis.

 Cheers,

 Pascal

-- 
-------------------------------------------------+-------------------------
 Reporter:  mariainesrobles@gmail.com            |       Owner:
     Type:  defect                               |  pthubert@cisco.com
 Priority:  major                                |      Status:  new
Component:  draft-thubert-6man-flow-label-for-   |   Milestone:
  rpl                                            |     Version:
 Severity:  In WG Last Call                      |  Resolution:
 Keywords:                                       |
-------------------------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6man/trac/ticket/5#comment:1>
6man <http://tools.ietf.org/wg/6man/>


From nobody Sun Aug 10 09:57:13 2014
Return-Path: <trac+6man@trac.tools.ietf.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5841A0573; Sun, 10 Aug 2014 09:57:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level: 
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham
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 1M2n7VcU1bTN; Sun, 10 Aug 2014 09:57:11 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 2787F1A0005; Sun, 10 Aug 2014 09:57:11 -0700 (PDT)
Received: from localhost ([::1]:58025 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <trac+6man@trac.tools.ietf.org>) id 1XGWQf-0001Jq-MX; Sun, 10 Aug 2014 09:57:09 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "6man issue tracker" <trac+6man@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: pthubert@cisco.com, mariainesrobles@gmail.com
X-Trac-Project: 6man
Date: Sun, 10 Aug 2014 16:57:09 -0000
X-URL: http://tools.ietf.org/wg/6man/
Subject: [6man] #6 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Updates: 6437 (if approved) - add section with explanation
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/6
Message-ID: <067.68f1bb748fae1493f1a4cf0c34b41253@trac.tools.ietf.org>
X-Trac-Ticket-ID: 6
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org
X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/I6w5oeBKo-Ldq5FseiKqxbd0Biw
Cc: roll@ietf.org, 6man@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: 6man@ietf.org
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Aug 2014 16:57:12 -0000

#6: draft-thubert-6man-flow-label-for-rpl-03  Updates: 6437 (if approved)  -
add section with explanation

 Source:  http://www.ietf.org/mail-archive/web/roll/current/msg08761.html

 From: Philip Levis <pal at cs.stanford.edu> Date: Thu, 31 Jul 2014
 15:11:21 -0700

 On Jul 29, 2014, at 6:36 PM, Brian E Carpenter <brian.e.carpenter at
 gmail.com> wrote:

 > On 30/07/2014 12:02, Philip Levis wrote:
 > ...
 >> "This specification suggests that energy-saving is another
 >> compelling reason for a violation to the aforementioned
 >> rule."
 >>
 >> makes the assumption that the energy saving is significant.
 >> Breaking the end-to-end nature of the flow label for some
 >> tiny saving seems like a mistake.
 >
 > I can't evaluate whether the energy saving is significant.
 > However, I don't have any deep faith in the e2e-ness of the
 > flow label. The reality (as RFC 6437 tries to recognise)
 > is that it's a mutable field, and is therefore untrustworthy
 > for e2e use. It has value for load balancing if all packets
 > of a given flow have the same label, whether the label is
 > set by the source or by a border device. For that reason,
 > I think the usage proposed in this draft is OK.
 >
 > However, I do agree that at least a hand-waving estimate of
 > the % energy saving would be useful.
 >
 >    Brian Carpenter

 *shrug* My thoughts are pretty simple. I'm sure you know all this (as one
 of the authors!) but I'll revisit for everyone else's sake. 6437 states

 "A forwarding node MUST either leave a non-zero flow label value unchanged
 or change it only for compelling operational security reasons as described
 in Section 6.1."

 So, this is a MUST. Either the RPL flow label draft contradicts 6437 (and
 should say so explicitly), or there should be an explicit update to 6437.
 In fact, the current draft is misleading and incorrect. It says

 "but the RFC also indicates a violation to the rule can be accepted for
 compelling reasons, and that security is a case justifying such a
 violation.  This specification suggests that energy-saving is another
 compelling    reason for a violation to the aforementioned rule."

 This is *not* what 6437 says. It says for compelling operational security
 reasons, not compelling reasons, of which one case is security.

 Having been researching, implementing, and deploying low-power protocols
 for over a decade, I've become exceedingly skeptical when someone proposes
 a protocol with energy as a motivation without quantifying it. For
 example, there are tons of protocols in the research literature which talk
 about using transmission power control to save energy (trading off range
 for power). But almost all of these papers ignore the fact that (unlike
 mobile/cellular systems, which the authors have been publishing in for
 years) RF is a tiny sliver of power in low-power networks. So reducing
 your transmission (RF) power by 99% only reduces your radio power by 50%.
 Generally a losing proposition. This is the same reason why power saving
 in WiFi involves synchronization on AP beacons and not adjusting transmit
 power. If someone doesn't quantify the potential benefit based on real
 hardware and protocols, then it could be based on mistaken assumptions.

 I mean, it doesn't take much here. Start with a working low-power RPL
 network. Send packets with sizes following a reasonable distribution based
 on an actual application. In one experiment send just those packets. In
 another add the 8 bytes. In a third add 8 + the IP-in-IP encapsulation.
 Measure the energy cost.

 And, generally speaking, if you can't demonstrate the problem very easily,
 then perhaps it isn't a real problem at all.

 All that being said, I think using the flow label in this way is a good
 idea, and definitely valuable. But as it is now, doing so violates 6437,
 and so the assumptions implementers make when reading 6437. I think the
 bar for doing so should be high, higher than vague suggestions and hand
 waving which might not be correct.

 Phil

-- 
-------------------------------------------------+-------------------------
 Reporter:  mariainesrobles@gmail.com            |      Owner:
     Type:  defect                               |  pthubert@cisco.com
 Priority:  major                                |     Status:  new
Component:  draft-thubert-6man-flow-label-for-   |  Milestone:
  rpl                                            |    Version:
 Severity:  In WG Last Call                      |   Keywords:
-------------------------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6man/trac/ticket/6>
6man <http://tools.ietf.org/wg/6man/>


From nobody Sun Aug 10 10:05:52 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762B91A0470; Sun, 10 Aug 2014 10:05:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level: 
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 wp9DyDK7ExnF; Sun, 10 Aug 2014 10:05:43 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3E91A0465; Sun, 10 Aug 2014 10:05:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2649; q=dns/txt; s=iport; t=1407690343; x=1408899943; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CMXbo64V9nzRzIRAx8nC5eVBs7dzRZcmgode8wOu/rE=; b=EiWDcCjEJLzPS4YKpM2gDQ2Q8lt5xTmoXu5r3XdlE/qghALJPP4Cq0DW BT0XsnfsXsM7xRm5NNBJGVOX96+jre+Ea3GKrkht30aWhNmKzVQ8xMkDC /aMZpTv1ErTycaqQlH6Chq2zQ0wWDjIrAXf7rL7SC2Xm8MRggpvi1JPAA E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhoFAAym51OtJA2B/2dsb2JhbABagw1SV8xlCodIAYEHFneEBAEBAwEBAQFrCwULAgEIRicLJQIEDgWIOggNwSIXjxkzB4MvgR0FkRmEJYZxgVeTJINcbA
X-IronPort-AV: E=Sophos;i="5.01,837,1400025600"; d="scan'208";a="346448595"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP; 10 Aug 2014 17:05:41 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7AH5fYp008745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 10 Aug 2014 17:05:41 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.109]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Sun, 10 Aug 2014 12:05:34 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPtLgxSf6MzwEzQpSdG5woHqaOoJvKESgJ
Date: Sun, 10 Aug 2014 17:05:34 +0000
Message-ID: <3EE25B75-0EA3-4DE5-82CC-049C173E2A0B@cisco.com>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com>,  <64A628BA-EADA-4738-BB8D-2CFFDE8E6CF0@tzi.org>
In-Reply-To: <64A628BA-EADA-4738-BB8D-2CFFDE8E6CF0@tzi.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/W1-YudJiMpb5TiURo1RIqGOGEbs
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Aug 2014 17:05:45 -0000

Hi Carsten

I think you jumped too quickly on my suggestion at 6lo.

It makes a lot of sense to work on a 6lo routing dispatch and in particular=
 enable the compression of all RPL artifacts.=20

It will take some time to figure out what goes in there but my suggestion a=
t 6lo includes routing header compression, RPL option, but also source dest=
ination if we decide to route fragments.=20

I hope this happens and I'll see with Laurent if we use a respin of his dra=
ft or I start a new one.

This work will be beneficial in the long run, but doubly fails to address t=
he issues at stake here:

- the draft proposes to update the rules in 6437 with stateful and with dom=
ain scoped operations. This is used by the draft itself but also by publish=
ed and deployed standards that came up before 6437 (eg ISA100.11a) and we a=
re now acknowledging and legalizing a de facto situation.

- it will take a year or 2 at best to agree on the new routing dispatch and=
 its operation. We need an improvement now. And btw we cannot necessarily a=
ssume 6lo together with RPL, I know of at least one RPL implementation that=
 does not use that compression.=20

Finally, Using a dispatch for the RPL option alone seems like a waste, but =
that is a discussion for 6lo. I'll publish there when I'm back from vacatio=
ns.
=20
Cheers,

Pascal

> Le 10 ao=FBt 2014 =E0 18:29, "Carsten Bormann" <cabo@tzi.org> a =E9crit :
>=20
> So far, we have mainly discussed the need for an optimization (it seems w=
e now agree there is a need) and the interaction between the normative comp=
onents of RFC 6437 and those of the draft at hand.
>=20
> I=92d now like to bring up a different question:
>=20
> Is this the right approach?
>=20
> I have written up what appears to be a more natural approach in the straw=
man draft:
> http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-00
>=20
> Why are we doing the flow-label thing and not the more natural thing?
>=20
> [ ] because the flow label hack works on packets that leave the 6lo netwo=
rks.
>    =95 but do we really need to optimize this on the non-6lo networks?
> [ ] because the flow label hack has been around for a while and is now ca=
st in stone.
>    =95 is it?
> [ ] because there is a flaw with the way this has been integrated into th=
e 6lo framework.
>    =95 ______ (fill in the flaw)
> [ ] because ______ (fill in the reason)
>=20
> Inquiring minds want to know.
>=20
> Gr=FC=DFe, Carsten
>=20
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From nobody Sun Aug 10 10:31:39 2014
Return-Path: <trac+6man@trac.tools.ietf.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28EF51A066B; Sun, 10 Aug 2014 10:31:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.031
X-Spam-Level: **
X-Spam-Status: No, score=2.031 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FB_CIALIS_LEO3=3.899, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.668] autolearn=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 B2Nqg1t3YyNL; Sun, 10 Aug 2014 10:31:32 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 C89A51A0651; Sun, 10 Aug 2014 10:31:32 -0700 (PDT)
Received: from localhost ([::1]:59761 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <trac+6man@trac.tools.ietf.org>) id 1XGWxt-0004CE-Ev; Sun, 10 Aug 2014 10:31:29 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "6man issue tracker" <trac+6man@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: pthubert@cisco.com, mariainesrobles@gmail.com
X-Trac-Project: 6man
Date: Sun, 10 Aug 2014 17:31:29 -0000
X-URL: http://tools.ietf.org/wg/6man/
Subject: Re: [6man] #6 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Updates: 6437 (if approved) - add section with explanation
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/6#comment:1
Message-ID: <082.61f02ac8f587a6aec989ea442d929943@trac.tools.ietf.org>
References: <067.68f1bb748fae1493f1a4cf0c34b41253@trac.tools.ietf.org>
X-Trac-Ticket-ID: 6
In-Reply-To: <067.68f1bb748fae1493f1a4cf0c34b41253@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org
X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/UDTPFlmrzqqDMqkVo_I12IBD_sE
Cc: roll@ietf.org, 6man@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: 6man@ietf.org
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Aug 2014 17:31:37 -0000

#6: draft-thubert-6man-flow-label-for-rpl-03  Updates: 6437 (if approved)  -
add section with explanation


Comment (by mariainesrobles@gmail.com):

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08763.html


 From: Xavier Vilajosana <xvilajosana at eecs.berkeley.edu> Date: Fri, 1
 Aug 2014 10:50:15 +0200

 Dear Phil, all,

 I do not completely agree :)

 Let's look at what IPHC does at the LBR when a flow label is elided and
 has to be inflated to be forwarded to the IPv6 network, this standardized
 behaviour is somehow interfering the end to end notion of the flow label
 as the content is being populated at the border of the LLN. For me this is
 not different than changing the scope of the flow label inside the LLN to
 transport RPL information and resetting  it at the LBR once data moves
 outside of the network considering that inside the LLN the flow label has
 no meaning.

 Looking into an article we wrote some time back, "A Realistic Energy
 Consumption Model for TSCH Networks". published in IEEE Sensors

 we know that the charge used by a mote (something similar to telosb) to
 send 127bytes is around 69uC and to receive them is 72uC (considering the
 optimal case where receiver has a guard time of 1ms and the network is
 synchronized).  By using the flow label instead of the RPL extension
 header we save 5bytes which give us a gain 2,71uC per data packet per hop
 when sent and something similar when received (i.e ~5uC in total), this is
 a 8% saving (accounting TX and RX side) considering that motes are always
 using 127bytes packets.

 If we go to a more realistic case where motes send ~50bytes packets, the
 charge needed to send/receive them is something around 27.5uC and being
 able to save 5 bytes represents a 10% saving for the sender and 10% for
 the receiver (~20% saving if we look it overall per hop).
 If we use batteries that power the mote for 5 years, a 20% saving gives us
 ~1 more year which I think is pretty significant.

 regards,
 Xavi

 ----
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08764.html



 From: Carsten Bormann <cabo at tzi.org> Date: Fri, 1 Aug 2014 13:23:44
 +0200

 On 01 Aug 2014, at 10:50, Xavier Vilajosana <xvilajosana at
 eecs.berkeley.edu> wrote:

 >
 > Let's look at what IPHC does at the LBR when a flow label is elided and
 has to be inflated to be forwarded to the IPv6 network, this standardized
 behaviour is somehow interfering the end to end notion of the flow label
 as the content is being populated at the border of the LLN.

 No.  With IPHC, the flow label has always been there, it just was
 transmitted in a very compressed form.

 I think the visceral reaction that most of us have in using the flow label
 as a mesh routing header is that this blurs the layer boundaries.  So much
 for O, R, F, and rank.  Putting the VLAN (“instance ID�) into the packet
 is a significantly larger change, because it essentially extends the IP
 service interface by a VLAN ID.  We normally try to hide IDs of this kind
 below IP.

 Now, I’m not saying any of this new architecture is wrong.  I just think
 what we need to do is discuss this as the architectural change that it is,
 not as a simple optimization.  (The need for some kind of optimization of
 IP-in-IP mesh routing for small-packet IoT applications is pretty obvious
 to me.)

 The other story is that we are retracting RFC 6437 and turning the flow
 label into the “field you may trample on in your lower layers if you have
 a good reason�.  Cynically, one could say this is proper payback for
 designing this field without a compelling purpose and no protocol
 evolution story attached to it.  So the evolution just eats it.  Teachable
 moment.

 Grüße, Carsten

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08765.html



 From: Pascal Thubert (pthubert) <pthubert@cisco.com>  2014-08-01 15:44
 GMT+03:00


 Hello Phil:

 The end-to-end principle will not break in pieces if we reuse the flow
 label field within the LLN.

 FYI, it will break nothing since there is no assumption in the Internet
 that the flow label will be carried unchanged. Consistently, there is no
 native way to secure the flow label to make sure it was not tempered with
 (IOW it is not protected by ULP checksums, IPSec AH or ESP transport
 mode).

 The last call at 6MAN is where I expect problems with the use of the flow
 label field in this draft to be pointed at. I'm happy to report that there
 was no trace of bigotry there, all the contrary. 6MAN will confirm whether
 this draft conforms the spirit of the existing RFCs and so far I gathered,
 from all but you, that it does.

 About SDOs: To be very clear, ISA100.11a made a clear condition to
 acceptance of 6LoWPAN that we compress the UDP checksum - 2 bytes. And we
 made that happen.
 As the standard is now considering what new work may be taken in, RPL will
 not be considered if we waste those 5 bytes, simple as that. Sorry that
 you missed the ROLL meeting, but Pat Kinney was very clear on that both as
 vice chair of 802.15,  and as chair of ISA100.11a where he "fought over
 every byte". " Both hats say that this is what we need this".

 We'll also note that each additional octet in a frame is an increased
 chance of loss and retry. This is an argument that I hear frequently at
 IEEE and the people there as well as at ISA100 are very sensitive to frame
 size in general.

 The distribution of the frame size and the cost of security depend on the
 application and the app layer. With high levels of security, if the
 distribution includes NLPDU around 80-90 octets then the extra bytes will
 cause fragmentation, which will add all sorts of new problems to the
 picture.

 The benefits are quite clear, both on actual numbers (thanks Xavi!) and on
 the political arena where such a waste of bytes is just not defendable.

 Please reconsider where you are placing your efforts and what you are
 trying to achieve...

 Pascal


 ----

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08766.html



 From: "Pascal Thubert (pthubert)" Date: Fri, 1 Aug 2014 12:56:40 +0000

 > No.  With IPHC, the flow label has always been there, it just was
 transmitted
 > in a very compressed form.

 My take is that you are both providing angles on a same thing. It does not
 make sense for a LLN node to waste compute power and bandwidth to get a
 random through that is of use only in the core of the internet, should the
 packet ever get there. So the flow label is effectively zero - or
 something locally significant in specific standards, which is not design
 to serve the purpose of load balancing in the core. So in either case, we
 need the root to 'inflate' the zero flow label, or replace it by something
 that fits the core of the Internet. That behavior was not specified so far
 and it should be. This document is covering this particular gap.

 Cheers,

 Pascal

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08767.html



 From: "Pascal Thubert (pthubert)"  Date: Fri, 1 Aug 2014 13:25:06 +0000

 > I think the visceral reaction that most of us have in using the flow
 label as a
 > mesh routing header is that this blurs the layer boundaries.  So much
 for O,
 > R, F, and rank.  Putting the VLAN ("instance ID") into the packet is a
 > significantly larger change, because it essentially extends the IP
 service
 > interface by a VLAN ID.  We normally try to hide IDs of this kind below
 IP.
 >
 > Now, I'm not saying any of this new architecture is wrong.  I just think
 what
 > we need to do is discuss this as the architectural change that it is,
 not as a
 > simple optimization.  (The need for some kind of optimization of IP-in-
 IP
 > mesh routing for small-packet IoT applications is pretty obvious to me.)
 >
 >
 I agree, Carsten.

 An angle is that we allow for localized usage of the flow label as opposed
 to end-to-end.

 Another is that we allow for different semantics within a local domain, as
 long as the packet that leaves the local domain fits the requirements in
 RFC 6437.

 As you point out, it is worth noting that we include information about
 flow isolation and rules by which a flow will be routed, which is akin to
 Multi-Topology Routing though MTR is based on TOS bits.

 It would be good to design an architecture that encompasses such
 capabilities.

 We'll note that ISA100.11a is shipping with a flow label that contains an
 index to a state (so-called a contract) that is installed on the nodes on
 the way and by and large extends the notion of PHB on a per flow basis.

 Cheers,

 Pascal

 ----------


 Source:  http://www.ietf.org/mail-archive/web/roll/current/msg08768.html



 From: Philip Levis <pal@cs.stanford.edu> Date: 2014-08-01 19:21 GMT+03:00

 On Aug 1, 2014, at 5:44 AM, Pascal Thubert (pthubert) <pthubert@cisco.com>
 wrote:
 >
 > FYI, it will break nothing since there is no assumption in the Internet
 that the flow label will be carried unchanged. Consistently, there is no
 native way to secure the flow label to make sure it was not tempered with
 (IOW it is not protected by ULP checksums, IPSec AH or ESP transport
 mode).
 >
 > The last call at 6MAN is where I expect problems with the use of the
 flow label field in this draft to be pointed at. I'm happy to report that
 there was no trace of bigotry there, all the contrary. 6MAN will confirm
 whether this draft conforms the spirit of the existing RFCs and so far I
 gathered, from all but you, that it does

 Pascal, I don't think this is a question of spirit or anything. I mean,
 I'll repeat, 6437 states

 "A forwarding node MUST either leave a non-zero flow label value unchanged
 or change it only for compelling operational security reasons as described
 in Section 6.1."

 If the point is that experience and use and the spirit of the flow label
 has changed from this MUST, then we should explicitly state so. I'm not
 arguing that the above prescription is right; but it's what's written.
 What worries me is the idea of directly contradicting the text of a prior
 RFC (the one explicitly on flow labels, no less), without correspondingly
 obsoleting that RFC. This isn't a SHOULD. It's a MUST!

 I've always thought that using the flow label in this way within an LLN is
 a good idea. The problem is that you can't do so without violating a MUST
 in the RFC that specifies how flow labels are used. It sounds like the
 letter of that document doesn't match the spirit of it -- so let's fix the
 letter, so it says what was intended! Why is there such recalcitrance to
 do so? Or provide any quantitative basis for the claims of battery power?
 You've been proposing this for nearly 4 years now...

 I personally see two reasonable ways forward:

 1) (As Carsten mentioned) Update 6437 to embrace these new and valuable
 uses of the flow label.

 2) Provide evidence that using the flow label in this way would provide
 significant enough gains that violating a MUST in the RFC specifying the
 flow label is worth it.

 It seems like you're advocating a third:

 3) Violate a MUST in the RFC specifying how the flow label is used without
 any evidence that the actual energy savings are significant.

 As for what I'm trying to achieve, that's pretty simple. I think it's a
 terrible mistake for a standards body as important as the IETF to rely on
 the spirit of the standard rather than the letter of the standard,
 especially when they contradict. If you are one of the hundreds of
 thousands of network engineers and software developers who work in the
 Internet, you can't know that a bunch of people in a meeting decided that
 the spirit of a specification differs from its text. All you have to go on
 is the text. When the founder of the next YouTube or Instagram or Google
 or Nicira takes my class and I ask them to write their code to follow an
 RFC (which I currently do), what should I tell them MUST means?

 Phil

 --------------
 Source:  http://www.ietf.org/mail-archive/web/roll/current/msg08769.html



 From: Brian E Carpenter  Date: Sat, 02 Aug 2014 07:58:39 +1200

 On 01/08/2014 23:23, Carsten Bormann wrote:
 ...
 > The other story is that we are retracting RFC 6437 and turning the flow
 label into the “field you may trample on in your lower layers if you have
 a good reason�.  Cynically, one could say this is proper payback for
 designing this field without a compelling purpose and no protocol
 evolution story attached to it.  So the evolution just eats it.  Teachable
 moment.

 RFC 6437 co-author hat on (but only speaking for myself, of course):

 My opinion is that the draft doesn't retract RFC 6437. As I already said,
 6437 attempts to recognise the reality that middleboxes can mess with the
 flow label, and to set conditions for that messing such that remote
 systems
 can still use it for load balancing. Since it's unprotected by checksum or
 crypto, there is a strict limit to how much it can be trusted anyway. As
 the RFC says:

    There is no way to verify whether a flow label has been modified en
    route or whether it belongs to a uniform distribution.  Therefore, no
    Internet-wide mechanism can depend mathematically on unmodified and
    uniformly distributed flow labels; they have a "best effort" quality.
    Implementers should be aware that the flow label is an unprotected
    field that could have been accidentally or intentionally changed en
    route (see Section 6).

 It is true that the RFC also says

    A forwarding node
    MUST either leave a non-zero flow label value unchanged or change it
    only for compelling operational security reasons...

 There is a case for arguing that flow-label-for-rpl should carry the
 legend "Updates: 6437 (if approved)" because it adds another exception
 to this sentence. There is also a case for arguing that flow-label-for-rpl
 is a stateful mechanism, out of scope for RFC 6437 according to
 Section 4 of that RFC.

 Either way, I don't see a problem.

 Regards

    Brian

 --------


 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08770.html



 From: Pascal Thubert (pthubert) <pthubert@cisco.com> Date: 2014-08-01
 23:27 GMT+03:00

 Phil,

 Though I attended the discussions and have a clear reading of this work
 I'll certainly defer to Brian on whether there is a violation or not.

 OTOH you need to understand that there is no need for a bis to update a
 MUST in an RFC. We recognize the imperfection in our work and are always
 ready to revise and amend after due consideration.

 This process takes is another RFC and best judgement from the original
 group that the new text is indeed valuable and not breaking the original
 objectives.

 We are going through that process.

 Pascal


 -------

 Source:  http://www.ietf.org/mail-archive/web/roll/current/msg08772.html



 From: Philip Levis <pal@cs.stanford.edu> Date: 2014-08-02 9:02 GMT+03:00

 On Aug 1, 2014, at 1:27 PM, Pascal Thubert (pthubert) <pthubert@cisco.com>
 wrote:

 If the proposal is to have an Updates: 6437 (such that someone looking up
 6437 will see a forward reference and know there's an update), I'm all in
 favor! That seems entirely reasonable. In that way, as I've always said, I
 think using the flow label is an excellent solution. I just also think
 doing so is significant in the context of 6437 and so should correctly
 acknowledge so. Someone reading 6437 should be able to easily learn
 there's another exception. It seems like an Updates: would do that well.

 That being said, I don't think the energy claims in the current document
 will hold up to much experimental scrutiny or actual network measurements.
 Xavier's back-of-the-envelope calculations don't include preambles, slot
 padding, or idle listening. TSCH is nice in that it has much lower idle
 listening costs than ad-hoc algorithms, but they are far from zero.
 Reducing overhead is valuable due to the corresponding increase in MSS and
 reduced memory pressure: the energy argument is a red herring.

 Phil

 -----

 Source:  http://www.ietf.org/mail-archive/web/roll/current/msg08774.html



 From: Michael Richardson <mcr+ietf@sandelman.ca> Date: 2014-08-02 22:08
 GMT+03:00

 Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
     > OTOH you need to understand that there is no need for a bis to
 update a
     > MUST in an RFC. We recognize the imperfection in our work and are
     > always ready to revise and amend after due consideration.

 Perhaps this document UPDATES 6437 then?

 Michael Richardson

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08775.html



 From: Michael Richardson <mcr+ietf@sandelman.ca> Date: 2014-08-02 22:23
 GMT+03:00

 Philip Levis <pal@cs.stanford.edu> wrote:
     > The paper is very helpful, thanks! Can you comment on what is a
 typical
     > idle slot configuration in a TiSCH network? Can you provide some
     > insight on what fraction of energy is spent in data communication
     > versus control and idle listening?

 Here is a recent post with some real numbers:
   https://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY
 it concerns diet-ESP, but the numbers are correct.
 Michael Richardson
 -------------------


 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08776.html



 From: Pascal Thubert (pthubert) <pthubert@cisco.com> Date: 2014-08-02
 23:48 GMT+03:00

 That sounds right, Michael, though slightly on the overkill side.  And
 this is consistent with what Brian suggested. This can be added during the
 rfc editor process I expect?

 Pascal

 > Le 2 août 2014 à 21:09, "Michael Richardson" <mcr+ietf@sandelman.ca> a
 écrit :
 > Perhaps this document UPDATES 6437 then?

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08777.html

 From: Ralph Droms <rdroms.ietf@gmail.com> Date: 2014-08-02 23:56 GMT+03:00

 >On Aug 2, 2014, at 4:48 PM, "Pascal Thubert (pthubert)"
 <pthubert@cisco.com> wrote:

 >That sounds right, Michael,

 I agree that "updates 6437" is a right thing to do.

 >though slightly on the overkill side.

 I disagree that it is overkill.  In my opinion, draft-thubert-6man-flow-
 label-for-RPL pretty clearly contradicts RFC 6437, so "updates 6437" is an
 appropriate action.

 > And this is consistent with what Brian suggested. This can be added
 during the rfc editor >process I expect?

 It should be added as soon as possible, certainly before it goes to the
 IESG.  In my opinion, the change might warrant a new or extended WGLC;
 that action is up to the chairs, of course.

 - Ralph


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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08778.html


 From: Philip Levis <pal@cs.stanford.edu> Date: 2014-08-03 0:41 GMT+03:00
 >
 > Here is a recent post with some real numbers:
 >  https://mailarchive.ietf.org/arch/msg/ipsec/TsI1OPGL-84AjZGB_RMyhqOPucY
 > it concerns diet-ESP, but the numbers are correct.

 Michael,

 I'm confused on what this email message is supposed to be providing: the
 energy cost of sending a bit? That's pretty simple to calculate. The
 tradeoff between CPU and network is also very well known, going back to
 Pottie's "Every bit transmitted brings a sensor node one moment closer to
 death." If you look at the behavior of most micro controller based
 devices, the MCU is insignificant -- and 95% of its energy is spent
 handling interrupts (per-byte, over an SPI bus) for the radio. Yes, unless
 you're doing something quite silly, the CPU cost of compression is almost
 always absolutely worth the benefit in terms of reduced transmission
 energy.

 My question related to the fraction of radio energy in TSCH that is
 consumed by data transmission/reception versus everything else (idle
 listening, guard periods, control frames, etc.

 To give you a data point -- early low-power link layers continually
 transmitted a packet (or wakeup frame) until receiving an acknowledgement
 from the intended receiver. Receivers periodically wake up, listen if
 there's energy on the channel, and if so, stay awake for 2 packet times
 (in case they woke up just after the preamble of a packet). If there's no
 coordination between receiver and sender, this means a sender must send on
 average for 1/2 of a wakeup interval to deliver a packet. E.g., 0.5s.
 Clearly in such a protocol a few extra bytes doesn't matter in terms of
 energy. Of course, TSCH is much, much better than this, I only mention
 this protocol as a simple explanatory example -- but what's the actual
 number?

 Phil

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08779.html

 From: Thomas Watteyne <watteyne@eecs.berkeley.edu> Date: 2014-08-03 6:36
 GMT+03:00

 Phil,

 There are two parts in answering your question. Let me describe both, I
 will then justify why the answer is "it depends".

 a single slot

 Let's consider for starters only a single TSCH slot: mote A sends a packet
 to mote B, which replies with an ACK. This timeslot is depicted below
 (borrowed from [1])

 (Please go to the source to see the graphic)

 Let's assume that the IEEE802.15.4 frame is 127B long, i.e. full length.
 Let's assume, finally, that you are using the default 10ms timeslot
 template from the IEEE802.15.4e-2012 standard [2] (Table 52e), no CCA.
 This is the radio-on time on both A and B:
 mote A
 transmitting the data packet: 4256us

 listening for ACK during the guard time (i.e. idle listening): 200us
 receiving the ACK (~15B long): 480us
 mote B:
 listening for data during the guard time (i.e. idle listening): 1000us
 receiving data: 4256us
 transmitting the ACK: 480us
 From an energy point of view, you also need to account for the time is
 takes to switch the radio on/off and for the possible energy consumed
 between the data and ack, in case the radio is kept in a state allowing it
 to TX/RX fast. Good embedded engineers will reduce this overhead through
 firmware and hardware wizardry.

 Considering only time, the radio on-time budget can hence be cut into:
 total: 10672us
 transmission of data: 8512us (~80%)
 desynchronization overhead (i.e. idle listening during guard time): 1200us
 (~10%)
 ACK overhead: 960us (~10%)
 From these numbers, you see that the actual data transmission accounts for
 ~80% of the radio-on time budget.

 Of course, this timeslot template is the default one. If you are very good
 at keeping synchronized, you might be able to shorten the guard times and
 reduce the desynchronization overhead.

 full network

 Now the fun part.

 In a TSCH network, the communication schedule indicates to every mote what
 to do: transmit, listen or sleep. You can tune the TSCH communication
 schedule any way you want. In fact, the 6TiSCH WG was created to define
 mechanisms for centralized and distributed managements of this schedule.

 Your goal should be to match the amount of bandwidth in your schedule
 (i.e. the cells used for transmission and reception) to what is needed by
 the network. If every cell you schedule is used, the single slot results
 from above carry over to a full network. If, however, you schedule has too
 many cells, some might be unused. In that case, the transmitter will keep
 its radio off (i.e. consume no energy), while the receiver will have to
 listen for a full guard time, or 2ms when using the default timeslot
 template.

 So there you go: it depends. In the best possible case, the portion of
 radio on-time spent of exchanging actual useful data can be very high
 (80%+), but it's easy to mess things up, resulting in a large number of
 over-provisioned cells.

 For a (hopefully clear) overview of IEEE802.15.4e TSCH, take a look at
 http://tools.ietf.org/html/draft-ietf-6tisch-tsch-01.

 Thomas

 [1] http://tools.ietf.org/html/draft-ietf-6tisch-minimal-02


 [2] http://standards.ieee.org/getieee802/download/802.15.4e-2012.pdf

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08780.html

 From: Philip Levis <pal@cs.stanford.edu> Date: 2014-08-03 20:28 GMT+03:00

 Thomas,

 This is great, thank you! Precise, technical statements. What I conclude
 from your text (correct me if I'm wrong):

 1) If 802.15.4e uses maximum sized frames (127 bytes), the data
 communication time (reception or transmission) within a transmit slot is
 80% of the total radio-on time. I appreciate that you separate the costs
 of the two sides (e.g., idle listening guard period on receive).

 2) Following Xavier's analysis, using 127-byte frames means the RPL option
 increases data communication time by 4%. This means, from 1), that it will
 increase energy consumption by ~3.5%. Or, supposing his 8% number is
 correct (I still don't understand how he reached it), the energy
 consumption is increased by ~6.5%.

 3) For smaller frames (e.g., the 50 bytes Xavier suggested), the idle
 listening on the receiver takes a larger fraction of the radio-on time, so
 his 10% number is too high.

 4) None of these calculations consider the control overhead or, as you
 point out, inefficiencies in slot assignment. E.g., if you have a low-
 bandwidth, low-delay network, then you will allocate slots (for low
 latency) that you do not use (low bandwidth). For networks that are
 perfectly tuned, as you suggest, you can approach the transmission slot
 gains in 1) and 2). But they do not consider the costs and time of beacons
 or management time slots. Or radio wakeup overhead (dead time): my
 understanding is that on modern chips this is about 300us? I think your
 ACK timing considers RX/TX turnaround time. So in that way, 1) and 2)
 represent the absolute *best* savings this might give you.

 So my conclusion from this data is that, in the absolute best case --
 assuming the radio is all of the system energy, you have a perfectly tuned
 TSCH schedule, etc., etc., using the flow label will save <10%, and often
 on the order of 5%. For simpler, less efficient and tuned MAC layers, the
 savings will be less.

 5% or 10% isn't huge, but it is significant and valuable. I've just been a
 bit confused as to why this proposal has been trotted around for 4 years
 and yet no-one had yet even done this simple calculation, so WG members
 could make an informed engineering decision. IMO, a 5-10% savings in
 already highly tuned networks is above the bar and worth it. In most
 networks, the savings will be much less, but the benefits of reduced
 memory pressure and larger application payloads without fragmentation are
 more than sufficient motivation and justification of the value of the
 approach.

 Phil

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08781.html

 From: Ole Troan <otroan at employees.org> Date: Mon, 4 Aug 2014 11:50:57
 +0200

 I see the principles in these two documents as mutually exclusive:
 RFC6437: middleboxes can mess with the flow label
 -flow-label-for-rpl: networks uses flow label field as an immutable
 protocol field

 you can't both use the flow label as an immutable protocol field and have
 middleboxes rewriting it.

 cheers,
 Ole



 ----------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08782.html

 From: Michael Richardson <mcr+ietf@sandelman.ca> Date: 2014-08-04 17:02
 GMT+03:00

 Philip Levis <pal@cs.stanford.edu> wrote:
     > 5% or 10% isn't huge, but it is significant and valuable. I've just
     > been a bit confused as to why this proposal has been trotted around
 for
     > 4 years and yet no-one had yet even done this simple calculation, so
 WG
     > members could make an informed engineering decision. IMO, a 5-10%

 my opinion:

 1) the exact calculation was hard to really do until 6tisch made it
 clearer
    what the duty cycle was going to be.

 2) it took awhile to come back to figuring out how to deal with the flow
    label issue.

 3) it is now clear exactly how close many of our packets are to the 127
 byte
    limit, and how much the HbH header hurts if it is the reason we go into
    two fraglets.

 4) we had other things to worry about!


 Michael Richardson

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08783.html

 From: Michael Richardson Date: Mon, 04 Aug 2014 10:15:15 -0400

 Ole Troan <otroan at employees.org> wrote:
     > I see the principles in these two documents as mutually exclusive:
     > RFC6437: middleboxes can mess with the flow label -flow-label-for-
 rpl:
     > networks uses flow label field as an immutable protocol field

     > you can't both use the flow label as an immutable protocol field and
     > have middleboxes rewriting it.

 This is my take.
 Case 1:  packet is within the LLN.  No issue; the sender sets the flow
 label,
      and we know (by design) that there aren't any (non-RPL) middle boxes
      that need to rewrite it.

 Case 2: the packet has to leave the LLN, travel across the Internet, and
      enter another LLN.
      Here the arguments about the LLN being a kind of virtual host from
      the document are relevant.  The flow label, when it crosses the
      Internet, would be immutable.  Prior to this document, the flow label
      would have been compressed out, been zero, and the DODAG root ought
 to
      have set it in some consistent fashion anyway.
 --
 Michael Richardson

 -------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08784.html

 From: "Pascal Thubert (pthubert)" Date: Mon, 4 Aug 2014 15:41:55 +0000

 Exactly;

 It can be argued that the LLN is a single something that is a more complex
 form of the classical host-router link from the L3 perspective.
 RFC6437 understands that the host can leave the flow label to all zeroes
 and allows the first router to set it in a recommended fashion.
 The draft pushes that role to the RPL root that is effectively the gateway
 from the LLN onto the Internet.
 Upon the WLLC discussion I have added " Updates: 6437 (if approved) " and
 posted an update with no other change in the text.

 Cheers,

 Pascal

 -----------

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08785.html

 From: Pascal Thubert (pthubert) <pthubert@cisco.com> Date: 2014-08-04
 21:01 GMT+03:00

 The change is now done, Ralph.

 The only difference between draft-thubert-6man-flow-label-for-rpl-03 and
 draft-thubert-6man-flow-label-for-rpl-04 is

 Updates: 6437 (if approved)

 Cheers,

 Pascal

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08786.html

 From: Ralph Droms <rdroms.ietf@gmail.com> Date: 2014-08-04 21:10 GMT+03:00

 I suggest adding a section to your doc that explains exactly what is being
 updated in RFC 6437.

 - Ralph

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08787.html

 From: Philip Levis <pal@cs.stanford.edu> Date: 2014-08-04 21:23 GMT+03:00

 I agree. I think some of the text in 1.3 can be re-used for this purpose.

 Phil

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08788.html

 From: Philip Levis <pal@cs.stanford.edu> Date: 2014-08-04 21:24 GMT+03:00

 On Aug 4, 2014, at 7:02 AM, Michael Richardson <mcr+ietf@sandelman.ca>
 wrote:

 >

 >
 > 1) the exact calculation was hard to really do until 6tisch made it
 clearer
 >   what the duty cycle was going to be.
 >
 > 2) it took awhile to come back to figuring out how to deal with the flow
 >   label issue.
 >
 > 3) it is now clear exactly how close many of our packets are to the 127
 byte
 >   limit, and how much the HbH header hurts if it is the reason we go
 into
 >   two fraglets.
 >
 > 4) we had other things to worry about!

 Michael,

 1) doesn't depend on 6tisch, it's based on 15.4e timing, and could have
 been calculated for any other low power link layer. Years ago.

 2) The proposal isn't substantively different -- in terms of bytes
 sent/saved -- from the first version of the proposal suggested in 2010.

 3) The analysis so far hasn't even touched this issue.

 4) The entire introduction/motivation for the proposal is saving energy!
 But no-one thought it important enough to actually estimate how much
 energy it would save (in a best case, typical case) before a last call?

 Here's my worry -- the tradeoffs of low-power networks are very different
 than the kinds of networks the IETF typically deals with. It'll lead to
 protocol decisions a bit different than always-on networks. But that
 doesn't mean it should be used as a blanket justification or motivation.
 Otherwise it's just smoke and mirrors (energy is critical! battery is
 critical! we therefore need less CPU-intensive compression schemes! here's
 a new one. we need less CPU-intensive cryptographic schemes! here's a new
 one.). If energy is so important, and this would be such a big savings,
 then why the recalcitrance to estimate it?  It doesn't help my confidence
 in the engineering when some of the back-of-the-envelope analyses
 (Xavier's) have basic arithmetic errors that seem incognizant of how to
 measure energy.

 Phil

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08789.html

 From: Pascal Thubert (pthubert) <pthubert@cisco.com> Date: 2014-08-04
 21:52 GMT+03:00

 Hi Ralph:

 This is exactly section 3.

 The section provides a scope of applicability (the RPL domain) and the
 changes from RFC 6437 that become acceptable within that scope.

 Cheers,

 Pascal

 -------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08790.html

 From: Ralph Droms <rdroms.ietf at gmail.com>  Date: Mon, 4 Aug 2014
 15:44:10 -0400


 On Aug 4, 2014, at 2:52 PM 8/4/14, Pascal Thubert (pthubert)
 <pthubert@cisco.com> wrote:

 > Hi Ralph:
 >
 > This is exactly section 3.
 >
 > The section provides a scope of applicability (the RPL domain) and the
 changes from RFC 6437 that become acceptable within that scope.

 I disagree.  Section 3 explains how draft-thubert-6man-flow-label-for-rpl
 can be interpreted as following RFC 6437 rather than describing the
 specific ways in which it updates RFC 6437.

 For example, as Philip wrote:

 > "but the RFC also indicates a violation to the rule can be accepted for
 compelling reasons, and that security is a case justifying such a
 violation.  This specification suggests that energy-saving is another
 compelling    reason for a violation to the aforementioned rule."
 >
 > This is *not* what 6437 says. It says for compelling operational
 security reasons, not compelling reasons, of which one case is security.

 - Ralph


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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08791.html

 From: Brian E Carpenter <brian.e.carpenter@gmail.com> Date: 2014-08-04
 23:44 GMT+03:00

 Ralph,

 It also says that there may be stateful ways of using the flow label.
 It's almost a matter of taste whether the RPL usage is a change to
 the phrase that you quote, or a stateful usage within an RPL domain
 (reverting to stateless use when leaving RPL). I agree that the draft
 could usefully be explicit about this.

    Brian

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08793.html

 From: Philip Levis <pal@cs.stanford.edu> Date: 2014-08-05 3:18 GMT+03:00


 On Aug 4, 2014, at 1:44 PM, Brian E Carpenter
 <brian.e.carpenter@gmail.com> wrote:

 > It also says that there may be stateful ways of using the flow label.
 > It's almost a matter of taste whether the RPL usage is a change to
 > the phrase that you quote, or a stateful usage within an RPL domain
 > (reverting to stateless use when leaving RPL). I agree that the draft
 > could usefully be explicit about this.

 I'm a bit confused -- the MUST statement is in Section 2, entitled "IPv6
 Flow Label Specification". There doesn't seem to be any text that suggests
 this restriction is dependent on stateless operation. My interpretation,
 based on the title and its placement in the document, is that the text in
 this section applies to any and all uses of the flow label. How am I
 reading this wrong? Should I be reading the final MUST ("… MUST choose
 labels that conform to Section 3 of this specification") in Section 4 to
 implicitly mean that Section 2 doesn't necessarily apply? Or is it
 optional for stateless as well?

 My (admittedly naive) reading is that Sections 3 and 4 related to how
 source nodes choose a flow label. (S2: "To enable Flow-Label-based
 classification, source nodes SHOULD assign each unrelated transport
 connection and application data stream to a new flow.")  This is distinct
 from what forwarding nodes do to flow labels, which Section 2 covers.

 Phil

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08794.html

 From: Brian E Carpenter <brian.e.carpenter@gmail.com> Date: 2014-08-05
 4:06 GMT+03:00

 Philip,

 I think you're right that it could have been worded more precisely.
 My personal mental model has always included something like the
 RPL application (i.e. a specific usage of the flow label within
 a closed domain) *and* generic stateless use by default, but I
 don't think that model has ever been the general consensus, so
 what is supposed to happen at the boundary between such a closed
 domain and the rest of the Internet has never been written down.

    Brian

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08795.html

 From: Pascal Thubert (pthubert) <pthubert@cisco.com> Date: 2014-08-05
 11:11 GMT+03:00

 I think I see what you are saying, Phil.

 I can split 1.3 to isolate the deviations to 6437.

 I also need to move the following text from section 3 in that new section

   This may seem contradictory with the IPv6
    Flow Label Specification [RFC6437] which stipulates that once it is
    set, the Flow Label is left unchanged; but the RFC also indicates a
    violation to the rule can be accepted for compelling reasons, and
    that security is a case justifying such a violation.  This
    specification suggests that energy-saving is another compelling
    reason for a violation to the aforementioned rule.

 Proposed update for that text:

    This specification updates the IPv6
    Flow Label Specification [RFC6437], which stipulates that once it is
    set, the Flow Label is left unchanged. [RFC6437] also indicates that
    a violation to the rule can be accepted for compelling reasons,
    but limit those compelling reasons to security related issues.  This
    specification indicates that energy-saving is another compelling
    reason that justifies a violation to the aforementioned rule.

 What do you think?

 Cheers,

 Pascal

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08796.html

 From: Anand SVR <anand@ece.iisc.ernet.in> Date: 2014-08-05 20:18 GMT+03:00

 Hi,

 The discussion has been very interesting, more so because it is bordering
 on the legality of the usage of the word MUST. I agree with Philip's take
 on this. But after reading the RFC, I got this impression that the RFC
 meant to be a facility or a feature with certain usage guidelines. The
 MUST usage is more to imply stronger than SHOULD so as to discourage
 people from modifying it. I suppose at the time of writing, the authors
 might not have foreseen that in some point in future the value can be
 changed for other reasons. Therefore the use of MUST MUST be taken with
 the right spirit it is meant to be taken rather than literally :)

 Anand

 ---------------------------------------------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08797.html

 From: Philip Levis <pal@cs.stanford.edu> Date: 2014-08-06 7:57 GMT+03:00

 I totally agree that the document leaves the question open of whether
 there could be future uses. The use of the flow label in that way doesn't
 go against the spirit of the document and so we shouldn't reject the idea
 out of principle. But it does go against the letter of the document --
 hence the need for an Updates: or other explicit note that this is the
 case.

 Phil

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08800.html

 From: Philip Levis <pal at cs.stanford.edu> Date: Thu, 7 Aug 2014 10:35:01
 -0700

 Seems reasonable to me, although a bit cumbersome. I'd suggest

   This document updates the IPv6
   Flow Label Specification [RFC6437], which stipulates that once the Flow
   Label is set, forwarding nodes do not update it unless there are
 compelling
   security reasons to do so. This document argues that saving energy in
 LLNs
   is another sufficiently compelling reason to modify the Flow Label.

 Phil

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





 Source:  http://www.ietf.org/mail-archive/web/roll/current/msg08803.html

 From: Ralph Droms <rdroms.ietf@gmail.com> Date: 2014-08-08 23:19 GMT+03:00

 On Aug 5, 2014, at 4:11 AM 8/5/14, Pascal Thubert (pthubert)
 <pthubert@cisco.com> wrote:

 > I think I see what you are saying, Phil.
 >
 > I can split 1.3 to isolate the deviations to 6437.
 >
 > I also need to move the following text from section 3 in that new
 section
 >
 >  This may seem contradictory with the IPv6
 >   Flow Label Specification [RFC6437] which stipulates that once it is
 >   set, the Flow Label is left unchanged; but the RFC also indicates a
 >   violation to the rule can be accepted for compelling reasons, and
 >   that security is a case justifying such a violation.  This
 >   specification suggests that energy-saving is another compelling
 >   reason for a violation to the aforementioned rule.
 >
 > Proposed update for that text:
 >
 >   This specification updates the IPv6
 >   Flow Label Specification [RFC6437], which stipulates that once it is
 >   set, the Flow Label is left unchanged. [RFC6437] also indicates that
 >   a violation to the rule can be accepted for compelling reasons,
 >   but limit those compelling reasons to security related issues.  This
 >   specification indicates that energy-saving is another compelling
 >   reason that justifies a violation to the aforementioned rule.

 Well, I personally don't read the text in RFC 6437 as saying "a violation
 to the rule can be accepted for compelling reasons".  To avoid arguments
 with difficult individuals like me, you might take a more neutral
 approach:

 This document updates the following text from RFC 6437, "IPv6 Flow
 Label Specification":

 OLD:

    Once set to a non-zero value, the Flow Label is expected to be
    delivered unchanged to the destination node(s).  A forwarding node
    MUST either leave a non-zero flow label value unchanged or change it
    only for compelling operational security reasons as described in
    Section 6.1.

 NEW:

    Once set to a non-zero value, the Flow Label is expected to be
    delivered unchanged to the destination node(s).  A forwarding node
    MUST either leave a non-zero flow label value unchanged or change
    it only for (1) compelling operational security reasons as
    described in Section 6.1 or (2) use as specified in RFC-to-be, "The
    IPv6 Flow Label within a RPL domain".

 - Ralph

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08804.html

 From: Brian E Carpenter <brian.e.carpenter@gmail.com> Date: 2014-08-08
 23:36 GMT+03:00

 Ralph,

 I *really* don't think RFCs are algorithms to the point where we
 need to do this. I see no reason why flow-label-for-rpl can't simply
 declare itself an exception to this clause of RFC 6437.

    Brian

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

-- 
-------------------------------------------------+-------------------------
 Reporter:  mariainesrobles@gmail.com            |       Owner:
     Type:  defect                               |  pthubert@cisco.com
 Priority:  major                                |      Status:  new
Component:  draft-thubert-6man-flow-label-for-   |   Milestone:
  rpl                                            |     Version:
 Severity:  In WG Last Call                      |  Resolution:
 Keywords:                                       |
-------------------------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6man/trac/ticket/6#comment:1>
6man <http://tools.ietf.org/wg/6man/>



From nobody Sun Aug 10 12:07:26 2014
Return-Path: <cabo@tzi.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF761A0144; Sun, 10 Aug 2014 12:07:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 j1-J_PzNJ3YF; Sun, 10 Aug 2014 12:07:22 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA89C1A013B; Sun, 10 Aug 2014 12:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s7AJ76mi024556; Sun, 10 Aug 2014 21:07:06 +0200 (CEST)
Received: from [192.168.217.106] (p54890283.dip0.t-ipconnect.de [84.137.2.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 16E7C233; Sun, 10 Aug 2014 21:07:05 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <3EE25B75-0EA3-4DE5-82CC-049C173E2A0B@cisco.com>
Date: Sun, 10 Aug 2014 21:07:04 +0200
X-Mao-Original-Outgoing-Id: 429390424.421653-c3b8ef77752a6542f150a16a6fef2551
Content-Transfer-Encoding: quoted-printable
Message-Id: <6F21CB8D-F598-4C74-8E79-25C1F92A9561@tzi.org>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com>,  <64A628BA-EADA-4738-BB8D-2CFFDE8E6CF0@tzi.org> <3EE25B75-0EA3-4DE5-82CC-049C173E2A0B@cisco.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Px3uLpvXmtOFwR-341y-ALQnupA
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Aug 2014 19:07:22 -0000

On 10 Aug 2014, at 19:05, Pascal Thubert (pthubert) <pthubert@cisco.com> =
wrote:

> - it will take a year or 2 at best to agree on the new routing =
dispatch and its operation. We need an improvement now. And btw we =
cannot necessarily assume 6lo together with RPL, I know of at least one =
RPL implementation that does not use that compression.=20

I don=92t understand why we can=92t do the saner equivalent of the flow =
label hack now and come up with a source routing header (which is not =
covered by the flow label hack) later.

Please tell us more about how ISA100.11a uses the flow label; that is =
information that has been lacking from the discussion so far.

Gr=FC=DFe, Carsten


From nobody Mon Aug 11 03:09:19 2014
Return-Path: <hosnieh.rafiee@huawei.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869E01A03BE; Mon, 11 Aug 2014 03:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.869
X-Spam-Level: 
X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
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 iI3BmUNbMfu6; Mon, 11 Aug 2014 03:09:00 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B4F1A03CF; Mon, 11 Aug 2014 03:08:59 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLC49296; Mon, 11 Aug 2014 10:08:58 +0000 (GMT)
Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml406-hub.china.huawei.com ([10.201.5.243]) with mapi id 14.03.0158.001; Mon, 11 Aug 2014 11:08:54 +0100
From: Hosnieh Rafiee <hosnieh.rafiee@huawei.com>
To: "saag@ietf.org" <saag@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: FW: New Version Notification for draft-rafiee-rfc3972-bis-00.txt
Thread-Topic: New Version Notification for draft-rafiee-rfc3972-bis-00.txt
Thread-Index: AQHPtUu1hZVwp9zHy0mEie4X4EglR5vLLOLA
Date: Mon, 11 Aug 2014 10:08:54 +0000
Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A25B4C@lhreml513-mbb.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.221.82.100]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/YpcU6w7jyOjIUvhzuPPpdFOuCPM
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Aug 2014 10:09:04 -0000

Rm9sa3MsDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IHRoYXQgYWRkcmVzc2VzIHNv
bWUgcHJvYmxlbXMgd2l0aCBDR0Egc3BlY2lmaWNhdGlvbi4gDQpUaGlzIGlzIHRoZSBzb2x1dGlv
bnMgdG8gYXR0YWNrcyBleHBsYWluZWQgaW4gdGhlIGZvbGxvd2luZyBkcmFmdCBhbmQgYWxzbyB0
aGUgZGlzY3Vzc2lvbiBhYm91dCB2YXJpYWJsZSBsZW5ndGggcHJlZml4IGFuZCB0aGUgc2VjdXJp
dHkgY29uc2lkZXJhdGlvbiBmb3IgQ0dBLg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh
ZnQtcmFmaWVlLTZtYW4tY2dhLWF0dGFjay0wMg0KDQpXZSdsbCBiZSBnbGFkIHRvIHJlY2VpdmUg
eW91ciBjb21tZW50cy4NCg0KQmVzdCwNCkhvc25pZWgNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl
LS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy
YWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEF1Z3VzdCAxMSwgMjAxNCAxMjowNSBQTQ0K
VG86IEhvc25pZWggUmFmaWVlOyBaaGFuZ2RhY2hlbmcgKERhY2hlbmcpOyBIb3NuaWVoIFJhZmll
ZTsgWmhhbmdkYWNoZW5nIChEYWNoZW5nKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0
aW9uIGZvciBkcmFmdC1yYWZpZWUtcmZjMzk3Mi1iaXMtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lv
biBvZiBJLUQsIGRyYWZ0LXJhZmllZS1yZmMzOTcyLWJpcy0wMC50eHQgaGFzIGJlZW4gc3VjY2Vz
c2Z1bGx5IHN1Ym1pdHRlZCBieSBIb3NuaWVoIFJhZmllZSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRG
IHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1yYWZpZWUtcmZjMzk3Mi1iaXMNClJldmlzaW9u
OgkwMA0KVGl0bGU6CQlDR0EgU2VjdXJpdHkgSW1wcm92ZW1lbnQNCkRvY3VtZW50IGRhdGU6CTIw
MTQtMDgtMTENCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTYNClVSTDog
ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1yYWZp
ZWUtcmZjMzk3Mi1iaXMtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tl
ci5pZXRmLm9yZy9kb2MvZHJhZnQtcmFmaWVlLXJmYzM5NzItYmlzLw0KSHRtbGl6ZWQ6ICAgICAg
IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJhZmllZS1yZmMzOTcyLWJpcy0wMA0K
DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBhZGRyZXNzZXMgdGhlIHNlY3VyaXR5IHBy
b2JsZW1zIGV4aXN0aW5nIGluIHRoZSBjdXJyZW50DQogICBDR0Egc3BlY2lmaWNhdGlvbi4gSXQg
YWxzbyBleHBsYWluIHRoZSBjaGFuZ2VzIHRoYXQgaXMgbmVlZGVkIHRvIHRha2UNCiAgIGludG8g
Y29uc2lkZXJhdGlvbiB3aGVuIHRoZSBwcmVmaXggbGVuZ3RoIG5lZWRzIHRvIGJlIHZhcmlhYmxl
Lg0KDQoNCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0
aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt
aXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg
YXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg==


From nobody Mon Aug 11 05:41:25 2014
Return-Path: <internet-drafts@ietf.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B028E1A06E5; Mon, 11 Aug 2014 05:41:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 VOAYjiHd7HwG; Mon, 11 Aug 2014 05:41:21 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69ABE1A068E; Mon, 11 Aug 2014 05:41:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action: draft-ietf-6man-multicast-addr-arch-update-08.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p5
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140811124121.10066.27471.idtracker@ietfa.amsl.com>
Date: Mon, 11 Aug 2014 05:41:21 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/E_SNrMay0E6sK0Chu322ZnlbnyM
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Aug 2014 12:41:23 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

        Title           : Updates to the IPv6 Multicast Addressing Architecture
        Authors         : Mohamed Boucadair
                          Stig Venaas
	Filename        : draft-ietf-6man-multicast-addr-arch-update-08.txt
	Pages           : 10
	Date            : 2014-08-11

Abstract:
   This document updates the IPv6 multicast addressing architecture by
   re-defining the reserved bits as generic flag bits.  The document
   provides also some clarifications related to the use of these flag
   bits.

   This document updates RFC 3956, RFC 3306 and RFC 4291.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-multicast-addr-arch-update/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-multicast-addr-arch-update-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-multicast-addr-arch-update-08


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

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


From nobody Mon Aug 11 06:54:39 2014
Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15E41A01DC; Mon, 11 Aug 2014 06:54:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.235
X-Spam-Level: 
X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
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 1MwI2iCiGG0m; Mon, 11 Aug 2014 06:54:38 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 576FA1A00C6; Mon, 11 Aug 2014 06:54:37 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.01,841,1400025600"; d="scan'208";a="134723257"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 11 Aug 2014 13:54:35 +0000
Received: from dhcp-10-61-111-110.cisco.com (dhcp-10-61-111-110.cisco.com [10.61.111.110]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7BDsYcV019128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2014 13:54:35 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1971.5\))
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Ole Troan <otroan@employees.org>
In-Reply-To: <53E534E8.4050304@gmail.com>
Date: Mon, 11 Aug 2014 15:54:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1971.5)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/7C1m_CSNc5VOJa0_bctAsJInel4
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "Pascal Thubert \(pthubert\)" <pthubert@cisco.com>, Routing Over Low power and Lossy networks <roll@ietf.org>, 6man WG <ipv6@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Aug 2014 13:54:39 -0000

> I *really* don't think RFCs are algorithms to the point where we
> need to do this. I see no reason why flow-label-for-rpl can't simply
> declare itself an exception to this clause of RFC 6437.

I must admit I'm uncomfortable with this draft and its approach. how can =
we be sure that we aren't opening a Pandora's box?
I'm worried that we set a precedence, and we'll see a new set of =
creative proposals for the use of these 20 bits.

cheers,
Ole=


From nobody Mon Aug 11 13:26:28 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D011C1A0002; Mon, 11 Aug 2014 13:26:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 B9y-KyjDNWLL; Mon, 11 Aug 2014 13:26:22 -0700 (PDT)
Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F7AA1A013B; Mon, 11 Aug 2014 13:26:22 -0700 (PDT)
Received: by mail-pd0-f175.google.com with SMTP id r10so11222975pdi.6 for <multiple recipients>; Mon, 11 Aug 2014 13:26:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6JFg7k7qbRCwyF0PghWdOOmyeOMe5+KS3o+Mlb9w+Tw=; b=OHP0/VsFyh/+cYdAW+IxSma7RKIr8JkX22uF4PZH+CZLoKL0J3lwE7UY8V0vYYq7dx RF24mmQyztWoQ1FRLMe+/NjTruc/sA3BTbxhx6sQyXRUr4TYXWYQcrgxm0uJh7WkqIwO RK+GZHXxK6sb5wXLGpQDJbDVnt3eiXPN0Rvq8lviEhPpIv5pnVD+fTWwb58+0SXhpUYT bpYsdZ9xIVWVwgtgSGM5MzxQymGJU3/NzoR9ivTLLTbPF9rcC8bUi8CiJNXCWDklcnpc EYtsVBUFmoJmtm5gkbg5yqqEZaJOXw3Phjy4B2BK6e2WzwRjCuzSs5F6hwb6mZ6qSvTe MNDA==
X-Received: by 10.68.106.66 with SMTP id gs2mr76758pbb.141.1407788782157; Mon, 11 Aug 2014 13:26:22 -0700 (PDT)
Received: from [192.168.178.23] (110.199.69.111.dynamic.snap.net.nz. [111.69.199.110]) by mx.google.com with ESMTPSA id dr9sm18824938pdb.78.2014.08.11.13.26.19 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Aug 2014 13:26:21 -0700 (PDT)
Message-ID: <53E926EB.9000505@gmail.com>
Date: Tue, 12 Aug 2014 08:26:19 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ole Troan <otroan@employees.org>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org>
In-Reply-To: <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/PxmRgBBDm2kY0UAdKfQWU48Ddf4
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, "Pascal Thubert \(pthubert\)" <pthubert@cisco.com>, Routing Over Low power and Lossy networks <roll@ietf.org>, 6man WG <ipv6@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Aug 2014 20:26:24 -0000

On 12/08/2014 01:54, Ole Troan wrote:
>> I *really* don't think RFCs are algorithms to the point where we
>> need to do this. I see no reason why flow-label-for-rpl can't simply
>> declare itself an exception to this clause of RFC 6437.
> 
> I must admit I'm uncomfortable with this draft and its approach. how can we be sure that we aren't opening a Pandora's box?
> I'm worried that we set a precedence, and we'll see a new set of creative proposals for the use of these 20 bits.

Well, that has been the case for a long time: see RFC 6294.

I see the concern. Actually that's why I don't want to see a formal
update to 6437, because the only rational update would be to allow
any closed domain to invent its own usage. We had that argument at
length during the development of 6437, and decided against it.
Therefore, treating RPL as a special case is the remaining option.
But does the ROLL community actually have consensus that they want
this special case?

   Brian


From nobody Mon Aug 11 23:08:36 2014
Return-Path: <trac+6man@trac.tools.ietf.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A981A0311; Mon, 11 Aug 2014 23:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level: 
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham
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 8Py_fbzJ13Kn; Mon, 11 Aug 2014 23:08:31 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 B036D1A0493; Mon, 11 Aug 2014 23:08:31 -0700 (PDT)
Received: from localhost ([::1]:60249 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <trac+6man@trac.tools.ietf.org>) id 1XH5G1-0000Ng-C0; Mon, 11 Aug 2014 23:08:29 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "6man issue tracker" <trac+6man@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: pthubert@cisco.com, mariainesrobles@gmail.com
X-Trac-Project: 6man
Date: Tue, 12 Aug 2014 06:08:29 -0000
X-URL: http://tools.ietf.org/wg/6man/
Subject: [6man] #7 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Relation with RFC 6294
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/7
Message-ID: <067.e9596359accc0ff63acaa0599b521b5b@trac.tools.ietf.org>
X-Trac-Ticket-ID: 7
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org
X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/91hnlQ1gw3IPM8HCQGiy0KsArzo
Cc: roll@ietf.org, 6man@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: 6man@ietf.org
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Aug 2014 06:08:33 -0000

#7: draft-thubert-6man-flow-label-for-rpl-03 Relation with RFC 6294

 From: Ines Robles Date: 2014-08-04 22:18 GMT+03:00

 Should this draft (draft-thubert-6man-flow-label-for-rpl-03) update RFC
 6294 as well, section 3.5 last paragraph, since talk about rpl-07 Section
 7.2, which is related with flow-label-for-rpl?

 specially this part of RFC 6294:""..Such uses
   tend to encode specific local meanings or routing-related tags in the
    label, so they appear to infringe the dependency prohibition or the
    immutability of the Flow Label field.  The ROLL group has indeed most
    recently opted not to use the Flow Label field for these reasons,...""

 I think it should update this RFC as well, to have all the rfcs in
 accordance.

 Thank you,

 Ines.

-- 
-------------------------------------------------+-------------------------
 Reporter:  mariainesrobles@gmail.com            |      Owner:
     Type:  defect                               |  pthubert@cisco.com
 Priority:  major                                |     Status:  new
Component:  draft-thubert-6man-flow-label-for-   |  Milestone:
  rpl                                            |    Version:
 Severity:  In WG Last Call                      |   Keywords:
-------------------------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6man/trac/ticket/7>
6man <http://tools.ietf.org/wg/6man/>


From nobody Mon Aug 11 23:10:01 2014
Return-Path: <trac+6man@trac.tools.ietf.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A821A03B5; Mon, 11 Aug 2014 23:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level: 
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham
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 sZU6KX-AKx6S; Mon, 11 Aug 2014 23:09:58 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 8D7331A0311; Mon, 11 Aug 2014 23:09:58 -0700 (PDT)
Received: from localhost ([::1]:60270 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <trac+6man@trac.tools.ietf.org>) id 1XH5HR-0000UF-Ij; Mon, 11 Aug 2014 23:09:57 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "6man issue tracker" <trac+6man@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: pthubert@cisco.com, mariainesrobles@gmail.com
X-Trac-Project: 6man
Date: Tue, 12 Aug 2014 06:09:57 -0000
X-URL: http://tools.ietf.org/wg/6man/
Subject: Re: [6man] #7 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Relation with RFC 6294
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/7#comment:1
Message-ID: <082.8a32746b4ccb455599e0dc90e61ef1c4@trac.tools.ietf.org>
References: <067.e9596359accc0ff63acaa0599b521b5b@trac.tools.ietf.org>
X-Trac-Ticket-ID: 7
In-Reply-To: <067.e9596359accc0ff63acaa0599b521b5b@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org
X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/H6jAg6HJu0R_5eME7ApsnaLGz-Q
Cc: roll@ietf.org, 6man@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: 6man@ietf.org
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Aug 2014 06:10:00 -0000

#7: draft-thubert-6man-flow-label-for-rpl-03 Relation with RFC 6294


Comment (by mariainesrobles@gmail.com):

 From: Adrian Farrel Date: 2014-08-05 17:07 GMT+03:00


 “In as much as this I-D diverges from the statements in the IETF consensus
 document RFC 6294, I will have a relatively high bar for the demonstration
 of consensus on this document.



 I understand that RPL runs in a walled garden. In particular, while there
 may be control flows from outside the RPL network to inside it, those
 flows *currently* run through an intermediate application (such as a
 server). I also understand that in the future, when flows run direct
 between external and internal nodes they will still run through a gateway
 router. In the former case the flow label is terminated at the server and
 so we can safely describe the RPL network as a walled garden. In the
 latter case, however, it is not possible for the flow label to be
 preserved end-to-end, and the gateway router must impose a flow label on
 outgoing packets, while the flow label delivered to an end device will be
 meaningless.



 In order that this document be successful one of two things is going to be
 needed.

 1. A clear statement that packets from within a RPL network that use the
 RPL flow label MUST NOT flow out of the RPL network, together with an
 explanation of how this is policed and guaranteed. More precisely: how
 will a router in the Internet know that the flow label on a packet was not
 applied by the source host?

 2. A change to the flow label architecture has to be considered acceptable
 by the IETF community. It needs to be written up clearly stating that it
 is OK for a gateway router to proxy the source host and insert a flow
 label, how the gateway router determines what value to set, and why it
 will not matter to a receiving RPL host that the flow label has been lost.

 Furthermore, I think some consideration of end-to-end traffic that
 transits a RPL network may be needed.



 I don't believe that any of that should be presented as an Update to 6294.
 Rather, I think that this document needs to be completely clear *and* a
 new revision of 6294 will be required with the associated changes.



 Of course, an answer to all this would by IPv6-in-IPv6 encapsulation, but
 I doubt that that is considered acceptable in a world that is so short of
 bits.



 Cheers,
 Adrian

-- 
-------------------------------------------------+-------------------------
 Reporter:  mariainesrobles@gmail.com            |       Owner:
     Type:  defect                               |  pthubert@cisco.com
 Priority:  major                                |      Status:  new
Component:  draft-thubert-6man-flow-label-for-   |   Milestone:
  rpl                                            |     Version:
 Severity:  In WG Last Call                      |  Resolution:
 Keywords:                                       |
-------------------------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6man/trac/ticket/7#comment:1>
6man <http://tools.ietf.org/wg/6man/>


From nobody Mon Aug 11 23:21:25 2014
Return-Path: <trac+6man@trac.tools.ietf.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D8E1A06DB; Mon, 11 Aug 2014 23:21:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level: 
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham
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 9i4K5MLaQRVD; Mon, 11 Aug 2014 23:21:22 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 A32131A0320; Mon, 11 Aug 2014 23:21:22 -0700 (PDT)
Received: from localhost ([::1]:60864 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <trac+6man@trac.tools.ietf.org>) id 1XH5ST-0008DB-5v; Mon, 11 Aug 2014 23:21:21 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "6man issue tracker" <trac+6man@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: pthubert@cisco.com, mariainesrobles@gmail.com
X-Trac-Project: 6man
Date: Tue, 12 Aug 2014 06:21:21 -0000
X-URL: http://tools.ietf.org/wg/6man/
Subject: Re: [6man] #6 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 Updates: 6437 (if approved) - add section with explanation
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/6#comment:2
Message-ID: <082.2a9a64f571bdc35b1c300be0302eaa91@trac.tools.ietf.org>
References: <067.68f1bb748fae1493f1a4cf0c34b41253@trac.tools.ietf.org>
X-Trac-Ticket-ID: 6
In-Reply-To: <067.68f1bb748fae1493f1a4cf0c34b41253@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org
X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/cRU49-nY3toLZNoMEjtUXuRgR38
Cc: roll@ietf.org, 6man@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: 6man@ietf.org
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Aug 2014 06:21:24 -0000

#6: draft-thubert-6man-flow-label-for-rpl-03  Updates: 6437 (if approved)  -
add section with explanation


Comment (by mariainesrobles@gmail.com):

 Source: http://www.ietf.org/mail-archive/web/ipv6/current/msg21030.html

 From: Carsten Bormann <cabo at tzi.org> Date: Sun, 10 Aug 2014 18:29:01
 +0200



 So far, we have mainly discussed the need for an optimization (it seems we
 now agree there is a need) and the interaction between the normative
 components of RFC 6437 and those of the draft at hand.

 I’d now like to bring up a different question:

 Is this the right approach?

 I have written up what appears to be a more natural approach in the
 strawman draft:
 http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-00

 Why are we doing the flow-label thing and not the more natural thing?

 [ ] because the flow label hack works on packets that leave the 6lo
 networks.
     • but do we really need to optimize this on the non-6lo networks?
 [ ] because the flow label hack has been around for a while and is now
 cast in stone.
     • is it?
 [ ] because there is a flaw with the way this has been integrated into the
 6lo framework.
     • ______ (fill in the flaw)
 [ ] because ______ (fill in the reason)

 Inquiring minds want to know.

 Grüße, Carsten

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

 Source: http://www.ietf.org/mail-archive/web/ipv6/current/msg21034.html

 From: "Pascal Thubert (pthubert)" <pthubert at cisco.com> Date: Sun, 10
 Aug 2014 17:05:34 +0000

 Hi Carsten

 I think you jumped too quickly on my suggestion at 6lo.

 It makes a lot of sense to work on a 6lo routing dispatch and in
 particular enable the compression of all RPL artifacts.

 It will take some time to figure out what goes in there but my suggestion
 at 6lo includes routing header compression, RPL option, but also source
 destination if we decide to route fragments.

 I hope this happens and I'll see with Laurent if we use a respin of his
 draft or I start a new one.

 This work will be beneficial in the long run, but doubly fails to address
 the issues at stake here:

 - the draft proposes to update the rules in 6437 with stateful and with
 domain scoped operations. This is used by the draft itself but also by
 published and deployed standards that came up before 6437 (eg ISA100.11a)
 and we are now acknowledging and legalizing a de facto situation.

 - it will take a year or 2 at best to agree on the new routing dispatch
 and its operation. We need an improvement now. And btw we cannot
 necessarily assume 6lo together with RPL, I know of at least one RPL
 implementation that does not use that compression.

 Finally, Using a dispatch for the RPL option alone seems like a waste, but
 that is a discussion for 6lo. I'll publish there when I'm back from
 vacations.

 Cheers,

 Pascal

 ---------------------------------------------------
 Source: http://www.ietf.org/mail-archive/web/ipv6/current/msg21036.html

 From: Carsten Bormann <cabo at tzi.org> Date: Sun, 10 Aug 2014 21:07:04
 +0200

 On 10 Aug 2014, at 19:05, Pascal Thubert (pthubert) <pthubert at
 cisco.com> wrote:

 > - it will take a year or 2 at best to agree on the new routing dispatch
 and its operation. We need an improvement now. And btw we cannot
 necessarily assume 6lo together with RPL, I know of at least one RPL
 implementation that does not use that compression.

 I don’t understand why we can’t do the saner equivalent of the flow label
 hack now and come up with a source routing header (which is not covered by
 the flow label hack) later.

 Please tell us more about how ISA100.11a uses the flow label; that is
 information that has been lacking from the discussion so far.

 Grüße, Carsten

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

 Source: http://www.ietf.org/mail-archive/web/ipv6/current/msg21039.html

 From: Ole Troan <otroan at employees.org> Date: Mon, 11 Aug 2014 15:54:35
 +0200

 > I *really* don't think RFCs are algorithms to the point where we
 > need to do this. I see no reason why flow-label-for-rpl can't simply
 > declare itself an exception to this clause of RFC 6437.

 I must admit I'm uncomfortable with this draft and its approach. how can
 we be sure that we aren't opening a Pandora's box?
 I'm worried that we set a precedence, and we'll see a new set of creative
 proposals for the use of these 20 bits.

 cheers,
 Ole

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

 Source: http://www.ietf.org/mail-archive/web/ipv6/current/msg21040.html

 From: Brian E Carpenter <brian.e.carpenter at gmail.com> Date: Tue, 12 Aug
 2014 08:26:19 +1200

 Well, that has been the case for a long time: see RFC 6294.

 I see the concern. Actually that's why I don't want to see a formal
 update to 6437, because the only rational update would be to allow
 any closed domain to invent its own usage. We had that argument at
 length during the development of 6437, and decided against it.
 Therefore, treating RPL as a special case is the remaining option.
 But does the ROLL community actually have consensus that they want
 this special case?

    Brian

-- 
-------------------------------------------------+-------------------------
 Reporter:  mariainesrobles@gmail.com            |       Owner:
     Type:  defect                               |  pthubert@cisco.com
 Priority:  major                                |      Status:  new
Component:  draft-thubert-6man-flow-label-for-   |   Milestone:
  rpl                                            |     Version:
 Severity:  In WG Last Call                      |  Resolution:
 Keywords:                                       |
-------------------------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6man/trac/ticket/6#comment:2>
6man <http://tools.ietf.org/wg/6man/>


From nobody Tue Aug 12 00:15:17 2014
Return-Path: <mariainesrobles@googlemail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADEE1A0739; Tue, 12 Aug 2014 00:15:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 qo2bFEa2WOIR; Tue, 12 Aug 2014 00:15:11 -0700 (PDT)
Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B621B1A06F3; Tue, 12 Aug 2014 00:15:10 -0700 (PDT)
Received: by mail-vc0-f173.google.com with SMTP id hy10so12832003vcb.32 for <multiple recipients>; Tue, 12 Aug 2014 00:15:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gy1XcLulMPFJ974RoRkizcPmuzDx/+yImn7r2EW3Ulo=; b=0gQU4mrY+pJh2L8KtAMzV9WY60dZUYU+FzMFZDCCjlavGtGRoBHLeHiCMt5a8pdchj lQ7zCM6e4qeFT/DdcXSjVaNKJpa4M7QLUQcBpwKsZ47nXv6UgQLHQtEray57WdONlQXz 4J++NmxXPQoObmSElvHDhXD5L50gX3agL4XQsbJt6F3UTlscrDnaJNRC/tDI82C/owMM mFr1VkQVPwGQ7jhXHzh7Iu0yJz01cZBW9FJSnE62KD2ehZJvSVsdN98fBvcxyOYRD2UF CqA3JMCnFrOKmOIqwRHVqkU8TPqacE25jbNFKy0ObIAj+4/GwGp4k87tCiyx3uSkCE73 DT0g==
MIME-Version: 1.0
X-Received: by 10.52.136.196 with SMTP id qc4mr22062846vdb.22.1407827709780; Tue, 12 Aug 2014 00:15:09 -0700 (PDT)
Received: by 10.220.58.69 with HTTP; Tue, 12 Aug 2014 00:15:09 -0700 (PDT)
In-Reply-To: <53E926EB.9000505@gmail.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com>
Date: Tue, 12 Aug 2014 10:15:09 +0300
Message-ID: <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Ines  Robles <mariainesrobles@googlemail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary=bcaec51b12bd8beb5e0500696ec5
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/aEMuA0o4KRJ8eso-vLXkThzab8A
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Aug 2014 07:15:12 -0000

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

Hi,

On April, it was discussed and got consensus in ROLL [
http://www.ietf.org/mail-archive/web/roll/current/msg08634.html].

This technique saves bytes, as was demonstrated by Xavier in his
implementation [ start on Slide 41 -
https://bytebucket.org/6tisch/meetings/raw/712902bb451d113494a7045e9730f1bb50335a79/140720_ietf90_plugfest_toronto/ietf90_toronto_plugfest_slides.pdf].
Maybe we should enumerate the advantages and disadvantages of using it.
(Some of these are tracked in ticket #5, #6 and #7).


Anyway, demostratedIt needs the 6man approval to go forward.

Cheers,

Ines


2014-08-11 23:26 GMT+03:00 Brian E Carpenter <brian.e.carpenter@gmail.com>:

> On 12/08/2014 01:54, Ole Troan wrote:
> >> I *really* don't think RFCs are algorithms to the point where we
> >> need to do this. I see no reason why flow-label-for-rpl can't simply
> >> declare itself an exception to this clause of RFC 6437.
> >
> > I must admit I'm uncomfortable with this draft and its approach. how can
> we be sure that we aren't opening a Pandora's box?
> > I'm worried that we set a precedence, and we'll see a new set of
> creative proposals for the use of these 20 bits.
>
> Well, that has been the case for a long time: see RFC 6294.
>
> I see the concern. Actually that's why I don't want to see a formal
> update to 6437, because the only rational update would be to allow
> any closed domain to invent its own usage. We had that argument at
> length during the development of 6437, and decided against it.
> Therefore, treating RPL as a special case is the remaining option.
> But does the ROLL community actually have consensus that they want
> this special case?
>
>    Brian
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>

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

<div dir=3D"ltr"><span id=3D"docs-internal-guid-4d9442ff-c908-7f9f-be4d-b83=
e2c368d11"><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-b=
ottom:0pt"><span style=3D"font-size:13px;font-family:Arial;vertical-align:b=
aseline;white-space:pre-wrap">Hi,</span></p>
<br><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0=
pt"><span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline=
;white-space:pre-wrap">On April, it was discussed and got consensus in ROLL=
 [</span><a href=3D"http://www.ietf.org/mail-archive/web/roll/current/msg08=
634.html" style=3D"text-decoration:none"><span style=3D"font-size:13px;font=
-family:Arial;color:rgb(34,34,34);text-decoration:underline;vertical-align:=
baseline;white-space:pre-wrap">http://www.ietf.org/mail-archive/web/roll/cu=
rrent/msg08634.html</span></a><span style=3D"font-size:13px;font-family:Ari=
al;vertical-align:baseline;white-space:pre-wrap">]. </span></p>
<br><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0=
pt"><span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline=
;white-space:pre-wrap">This technique saves bytes, as was demonstrated by X=
avier in his implementation [ start on Slide 41 - </span><a href=3D"https:/=
/bytebucket.org/6tisch/meetings/raw/712902bb451d113494a7045e9730f1bb50335a7=
9/140720_ietf90_plugfest_toronto/ietf90_toronto_plugfest_slides.pdf" style=
=3D"text-decoration:none"><span style=3D"font-size:13px;font-family:Arial;c=
olor:rgb(34,34,34);text-decoration:underline;vertical-align:baseline;white-=
space:pre-wrap">https://bytebucket.org/6tisch/meetings/raw/712902bb451d1134=
94a7045e9730f1bb50335a79/140720_ietf90_plugfest_toronto/ietf90_toronto_plug=
fest_slides.pdf</span></a><span style=3D"font-size:13px;font-family:Arial;v=
ertical-align:baseline;white-space:pre-wrap">]. Maybe we should enumerate t=
he advantages and disadvantages of using it. (Some of these are tracked in =
ticket #5, #6 and #7).</span></p>
<p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt">=
<span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline;whi=
te-space:pre-wrap"><br></span></p><p dir=3D"ltr" style=3D"line-height:1.15;=
margin-top:0pt;margin-bottom:0pt">
<span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline;whi=
te-space:pre-wrap">Anyway, demostratedIt needs the 6man approval to go forw=
ard.</span></p><br><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;=
margin-bottom:0pt">
<span style=3D"font-size:13px;font-family:Arial;vertical-align:baseline;whi=
te-space:pre-wrap">Cheers,</span></p><br><span style=3D"font-size:13px;font=
-family:Arial;vertical-align:baseline;white-space:pre-wrap">Ines </span></s=
pan><br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014-08=
-11 23:26 GMT+03:00 Brian E Carpenter <span dir=3D"ltr">&lt;<a href=3D"mail=
to:brian.e.carpenter@gmail.com" target=3D"_blank">brian.e.carpenter@gmail.c=
om</a>&gt;</span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 12/08/2014 01:54, Ole Tro=
an wrote:<br>
&gt;&gt; I *really* don&#39;t think RFCs are algorithms to the point where =
we<br>
&gt;&gt; need to do this. I see no reason why flow-label-for-rpl can&#39;t =
simply<br>
&gt;&gt; declare itself an exception to this clause of RFC 6437.<br>
&gt;<br>
&gt; I must admit I&#39;m uncomfortable with this draft and its approach. h=
ow can we be sure that we aren&#39;t opening a Pandora&#39;s box?<br>
&gt; I&#39;m worried that we set a precedence, and we&#39;ll see a new set =
of creative proposals for the use of these 20 bits.<br>
<br>
</div>Well, that has been the case for a long time: see RFC 6294.<br>
<br>
I see the concern. Actually that&#39;s why I don&#39;t want to see a formal=
<br>
update to 6437, because the only rational update would be to allow<br>
any closed domain to invent its own usage. We had that argument at<br>
length during the development of 6437, and decided against it.<br>
Therefore, treating RPL as a special case is the remaining option.<br>
But does the ROLL community actually have consensus that they want<br>
this special case?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
=C2=A0 =C2=A0Brian<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
_______________________________________________<br>
Roll mailing list<br>
<a href=3D"mailto:Roll@ietf.org">Roll@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/roll" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/roll</a><br>
</div></div></blockquote></div><br></div>

--bcaec51b12bd8beb5e0500696ec5--


From nobody Tue Aug 12 01:40:57 2014
Return-Path: <cabo@tzi.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830921A079F; Tue, 12 Aug 2014 01:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 uBnI5sB4P3yw; Tue, 12 Aug 2014 01:40:53 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F2101A0376; Tue, 12 Aug 2014 01:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s7C8eM80025798; Tue, 12 Aug 2014 10:40:22 +0200 (CEST)
Received: from [192.168.217.145] (p54890742.dip0.t-ipconnect.de [84.137.7.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 67334B76; Tue, 12 Aug 2014 10:40:21 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com>
Date: Tue, 12 Aug 2014 10:40:19 +0200
X-Mao-Original-Outgoing-Id: 429525619.778124-1efd2775c48ffb70aab8faa6350b1af9
Content-Transfer-Encoding: quoted-printable
Message-Id: <C95BA1B7-A7B7-43BD-8E23-8FFDB2DD79ED@tzi.org>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/SzdpI-IDsFv6xuBHftuQM_KLpys
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Aug 2014 08:40:55 -0000

On 12 Aug 2014, at 09:15, Ines Robles <mariainesrobles@googlemail.com> =
wrote:

> This technique saves bytes

Again, the straw man at =
http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-00
saves the same number of bytes.  Actually, for common cases, it enables =
one additional optimization (saving one more byte) that is not available =
with the flow label hack.  (On the other hand, due to the way RFC 6282 =
works, the flow label hack saves one byte where both it and ECN are in =
use and the common case does not apply.)

The disadvantage of the RPL mesh header is that this approach is not =
available outside 6lo networks (i.e., networks employing adaptation =
layers that use RFC 6282).  I=92m not aware yet of a use case where that =
is a problem.

In either encoding (RPL mesh header or flow label), it is probably a =
good idea anyway to unpack the compressed information back into the RPL =
IPv6 option when leaving the 6lo networks.

Gr=FC=DFe, Carsten


From nobody Tue Aug 12 16:38:57 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A864A1A0AD2; Tue, 12 Aug 2014 16:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 IFRmJdn1jqBB; Tue, 12 Aug 2014 16:38:53 -0700 (PDT)
Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 157611A00E2; Tue, 12 Aug 2014 16:38:52 -0700 (PDT)
Received: by mail-ob0-f174.google.com with SMTP id vb8so7695464obc.5 for <multiple recipients>; Tue, 12 Aug 2014 16:38:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=hx0eOEFOsL1cjdWvPyKPQ+FEYL6bofpFZsADj0TCRZs=; b=gJzCaqs+LtiFge/Gn7PLxiL5AibdC9gIuVwBJDBrx2kIlbbHgUx2E7HnXwoG81tXlc buPfc4/JT+tKtHo1M2S2RQd9ouMVB/B2wZ11xMhE5OhA8Z7Gl97i3V/jqXC+RSpa6hFH mWLIFg/q/vUQnz92xafvn1Z2TnCUYKObMKloOE7DBEexvQj1FADOFECvXSqklXK/l1Nk UHRZghq1c2YqLD8zmqInFDuTTSqvD7Ohz8KMZgxwBUujKq8gj8Xsf/zeBE57g7rYkuRy Cd2LBWSmNDSTRhA5eGWyNAfvdXsQRnaQgkKZ26ntc3xcJfRnd/QlsWNZYWSOmMWOMpob 68rA==
X-Received: by 10.60.43.38 with SMTP id t6mr1146388oel.14.1407886731593; Tue, 12 Aug 2014 16:38:51 -0700 (PDT)
Received: from [172.24.60.8] (wireless-nat-21.auckland.ac.nz. [130.216.30.132]) by mx.google.com with ESMTPSA id s64sm544813oif.5.2014.08.12.16.38.49 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Aug 2014 16:38:51 -0700 (PDT)
Message-ID: <53EAA58D.4060401@gmail.com>
Date: Wed, 13 Aug 2014 11:38:53 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ines Robles <mariainesrobles@googlemail.com>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com>
In-Reply-To: <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/qQAD-5yFMgsv3nqlk4UYp73WzcI
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Aug 2014 23:38:54 -0000

Ines,

Can you perhaps clarify the exact question you are asking 6man?

(I'm thinking that 6man isn't being asked whether the number
of bits saved is a useful energy saving, or whether Carsten's
proposal is better.)

Regards
   Brian

On 12/08/2014 19:15, Ines Robles wrote:
> Hi,
> 
> On April, it was discussed and got consensus in ROLL [
> http://www.ietf.org/mail-archive/web/roll/current/msg08634.html].
> 
> This technique saves bytes, as was demonstrated by Xavier in his
> implementation [ start on Slide 41 -
> https://bytebucket.org/6tisch/meetings/raw/712902bb451d113494a7045e9730f1bb50335a79/140720_ietf90_plugfest_toronto/ietf90_toronto_plugfest_slides.pdf].
> Maybe we should enumerate the advantages and disadvantages of using it.
> (Some of these are tracked in ticket #5, #6 and #7).
> 
> 
> Anyway, demostratedIt needs the 6man approval to go forward.
> 
> Cheers,
> 
> Ines
> 
> 
> 2014-08-11 23:26 GMT+03:00 Brian E Carpenter <brian.e.carpenter@gmail.com>:
> 
>> On 12/08/2014 01:54, Ole Troan wrote:
>>>> I *really* don't think RFCs are algorithms to the point where we
>>>> need to do this. I see no reason why flow-label-for-rpl can't simply
>>>> declare itself an exception to this clause of RFC 6437.
>>> I must admit I'm uncomfortable with this draft and its approach. how can
>> we be sure that we aren't opening a Pandora's box?
>>> I'm worried that we set a precedence, and we'll see a new set of
>> creative proposals for the use of these 20 bits.
>>
>> Well, that has been the case for a long time: see RFC 6294.
>>
>> I see the concern. Actually that's why I don't want to see a formal
>> update to 6437, because the only rational update would be to allow
>> any closed domain to invent its own usage. We had that argument at
>> length during the development of 6437, and decided against it.
>> Therefore, treating RPL as a special case is the remaining option.
>> But does the ROLL community actually have consensus that they want
>> this special case?
>>
>>    Brian
>>
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
>>
> 
> 
> ------------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Tue Aug 12 18:19:39 2014
Return-Path: <cabo@tzi.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B391E1A6F87; Tue, 12 Aug 2014 18:19:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 GnPSxfmrmhZp; Tue, 12 Aug 2014 18:19:21 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5C41A6F86; Tue, 12 Aug 2014 18:19:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s7D1JEe9009134; Wed, 13 Aug 2014 03:19:14 +0200 (CEST)
Received: from [192.168.217.145] (p54890709.dip0.t-ipconnect.de [84.137.7.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 65C986F; Wed, 13 Aug 2014 03:19:13 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <53EAA58D.4060401@gmail.com>
Date: Wed, 13 Aug 2014 03:19:12 +0200
X-Mao-Original-Outgoing-Id: 429585552.308666-c9e5bc6724d010c898925a744d2346d9
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/rlmjrhiuqc-Z_e6QR2bOZBY9X6E
Cc: Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Aug 2014 01:19:23 -0000

On 13 Aug 2014, at 01:38, Brian E Carpenter =
<brian.e.carpenter@gmail.com> wrote:

> Can you perhaps clarify the exact question you are asking 6man?

Well, I=92m not Ines, but I=92m trying to find out why we are in this =
peculiar position of discussing this draft right now.

ROLL has a routing protocol that requires some data to be shipped around =
together with IP packets.
RFC 6553 and 6554 define ways to do this that are consistent with the IP =
architecture.
Unfortunately, the overhead (signal-to-fluff ratio) is relatively high, =
and in this area of application, that matters.

Normally, the next step would have been looking at ways to do header =
compression.
We did talk about compressing ROLL, but with a view to compressing the =
(control plane) ROLL messages, not so much about the (data plane) IP =
packets themselves.  GHC is trying to be a reasonably useful, but also =
reasonably general way to do the control plane messages.

For the data packets, the flow label (and its now predominant non-use) =
provides an attractive hole in the IPv6 packets to ship around the RFC =
6533 information, but not the RFC 6554 information.
In 6lo networks, normally RFC 6282 compresses away empty flow labels, =
but it is cheap to put them in, so a flow label really only costs 3 =
bytes (instead of 8 bytes RFC 6553 costs).  The most useful information =
from RFC 6553 can be stuffed into 19 bits, as demonstrated by the draft =
we are discussing here.

RFC 6282 has extension points (GHC uses one of them), but not really =
useful ones for the ROLL data plane.
So it appears it never occurred to us that the best way to handle these =
19 bits is to actually sidestep RFC 6282, and use the existing extension =
points of RFC 4944.  Until Laurent showed one way of doing this.  I just =
went from there and did a strawman using Laurent=92s idea for =
compressing the RFC 6553 option, in a way that is as efficient as (or, =
in most cases, actually more efficient than) using the flow label hole.

So to me it seems there no longer is a good technical argument to ask =
6man to liberate the flow label for carrying RFC 6553.
But that is maybe something that should now be discussed between 6lo and =
ROLL; I don=92t think that this is a 6man issue (unless the answer is a =
simple =93sure, go ahead, take it, we don=92t need it any more anyway=94, =
which is not what I have perceived RFC 6437 to say).
When 6lo and ROLL have generated consensus on the need to do this, we =
may or may not want to go back to 6man and actually pry that flow label =
hole out of your fingers.

Gr=FC=DFe, Carsten


From nobody Wed Aug 13 01:00:18 2014
Return-Path: <mariainesrobles@googlemail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4F51A702B; Wed, 13 Aug 2014 01:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 CYuYB6ZSjm1r; Wed, 13 Aug 2014 01:00:13 -0700 (PDT)
Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C461A08D1; Wed, 13 Aug 2014 01:00:13 -0700 (PDT)
Received: by mail-vc0-f182.google.com with SMTP id hy4so14831225vcb.27 for <multiple recipients>; Wed, 13 Aug 2014 01:00:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HWg2iR9QA75Mz2geZZ1ucbZ9sNX+CuR3KGhdegSzHDQ=; b=yy0GLPPfueRdjSiII+nH82JJ0XFLQgTvfyjiFrgTHx2CXW0QEZXtafv0sOyEnJCs2v UAYXRf88F6jDsN3DcTGsQstGfuWcfaYbiffVUAGTilxDC6sOchjke4oMljue2K5cPZ4L C2QY70dAK44FnfIu+kqgFmr1IcaXlVHyRLEq17xaMmFWI1EQH8gi83NmS3IuiNxCxg8i LWsVRonUthoJe5PYwxoeMA/BeklRmXmXV1cudPOHJ6rHAGxEmziNVaX2M5QD7r7YS5oO DWf2qawt74YHqNTUxkyCGWzKWLhypWCFbYxqXeIHeipXW4wNP49hSUtqybNqQ2g/X6WB 0MlA==
MIME-Version: 1.0
X-Received: by 10.220.163.69 with SMTP id z5mr2344006vcx.10.1407916812404; Wed, 13 Aug 2014 01:00:12 -0700 (PDT)
Received: by 10.220.58.69 with HTTP; Wed, 13 Aug 2014 01:00:12 -0700 (PDT)
In-Reply-To: <53EAA58D.4060401@gmail.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com>
Date: Wed, 13 Aug 2014 11:00:12 +0300
Message-ID: <CAP+sJUfRWDnDZZXhEP+ZjK-0HiTDt7WLsPorLhRUO9DWwnyG0g@mail.gmail.com>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Ines  Robles <mariainesrobles@googlemail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary=001a1133da247a0b7105007e2de5
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/xBYrdPBNyhX5nnm-Z-vvhXENe8w
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Aug 2014 08:00:15 -0000

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

Hi Brian,

Thanks for your comment.

Actually, I did not ask a question, I just wanted to say that the Pascal's
draft got consensus at ROLL in april, and the WGLC was done between 6man
and ROLL to know the 6man opinion about the use of flow-label (tickets #5,
#6 and #7). With the new Carsten proposal (6lo draft), we (constrained
environment WGs) should analyze this approach and decide the further steps
on Pascal draft related with that.

Thanks,

Ines


2014-08-13 2:38 GMT+03:00 Brian E Carpenter <brian.e.carpenter@gmail.com>:

> Ines,
>
> Can you perhaps clarify the exact question you are asking 6man?
>
> (I'm thinking that 6man isn't being asked whether the number
> of bits saved is a useful energy saving, or whether Carsten's
> proposal is better.)
>
> Regards
>    Brian
>
> On 12/08/2014 19:15, Ines Robles wrote:
> > Hi,
> >
> > On April, it was discussed and got consensus in ROLL [
> > http://www.ietf.org/mail-archive/web/roll/current/msg08634.html].
> >
> > This technique saves bytes, as was demonstrated by Xavier in his
> > implementation [ start on Slide 41 -
> >
> https://bytebucket.org/6tisch/meetings/raw/712902bb451d113494a7045e9730f1bb50335a79/140720_ietf90_plugfest_toronto/ietf90_toronto_plugfest_slides.pdf
> ].
> > Maybe we should enumerate the advantages and disadvantages of using it.
> > (Some of these are tracked in ticket #5, #6 and #7).
> >
> >
> > Anyway, demostratedIt needs the 6man approval to go forward.
> >
> > Cheers,
> >
> > Ines
> >
> >
> > 2014-08-11 23:26 GMT+03:00 Brian E Carpenter <
> brian.e.carpenter@gmail.com>:
> >
> >> On 12/08/2014 01:54, Ole Troan wrote:
> >>>> I *really* don't think RFCs are algorithms to the point where we
> >>>> need to do this. I see no reason why flow-label-for-rpl can't simply
> >>>> declare itself an exception to this clause of RFC 6437.
> >>> I must admit I'm uncomfortable with this draft and its approach. how
> can
> >> we be sure that we aren't opening a Pandora's box?
> >>> I'm worried that we set a precedence, and we'll see a new set of
> >> creative proposals for the use of these 20 bits.
> >>
> >> Well, that has been the case for a long time: see RFC 6294.
> >>
> >> I see the concern. Actually that's why I don't want to see a formal
> >> update to 6437, because the only rational update would be to allow
> >> any closed domain to invent its own usage. We had that argument at
> >> length during the development of 6437, and decided against it.
> >> Therefore, treating RPL as a special case is the remaining option.
> >> But does the ROLL community actually have consensus that they want
> >> this special case?
> >>
> >>    Brian
> >>
> >> _______________________________________________
> >> Roll mailing list
> >> Roll@ietf.org
> >> https://www.ietf.org/mailman/listinfo/roll
> >>
> >
> >
> > ------------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>

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

<div dir=3D"ltr">Hi Brian,<div><br></div><div>Thanks for your comment.<br><=
div><br></div><div>Actually, I did not ask a question, I just wanted to say=
 that the Pascal&#39;s draft got consensus at ROLL in april, and the WGLC w=
as done between 6man and ROLL to know the 6man opinion about the use of flo=
w-label (tickets #5, #6 and #7). With the new Carsten proposal (6lo draft),=
 we (constrained environment WGs) should analyze this approach and decide t=
he further steps on Pascal draft related with that.<br>
</div></div><div><br></div><div>Thanks,</div><div><br></div><div>Ines</div>=
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014-08=
-13 2:38 GMT+03:00 Brian E Carpenter <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:brian.e.carpenter@gmail.com" target=3D"_blank">brian.e.carpenter@gmail.co=
m</a>&gt;</span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Ines,<br>
<br>
Can you perhaps clarify the exact question you are asking 6man?<br>
<br>
(I&#39;m thinking that 6man isn&#39;t being asked whether the number<br>
of bits saved is a useful energy saving, or whether Carsten&#39;s<br>
proposal is better.)<br>
<br>
Regards<br>
<span class=3D"HOEnZb"><font color=3D"#888888">=C2=A0 =C2=A0Brian<br>
</font></span><div><div class=3D"h5"><br>
On 12/08/2014 19:15, Ines Robles wrote:<br>
&gt; Hi,<br>
&gt;<br>
&gt; On April, it was discussed and got consensus in ROLL [<br>
&gt; <a href=3D"http://www.ietf.org/mail-archive/web/roll/current/msg08634.=
html" target=3D"_blank">http://www.ietf.org/mail-archive/web/roll/current/m=
sg08634.html</a>].<br>
&gt;<br>
&gt; This technique saves bytes, as was demonstrated by Xavier in his<br>
&gt; implementation [ start on Slide 41 -<br>
&gt; <a href=3D"https://bytebucket.org/6tisch/meetings/raw/712902bb451d1134=
94a7045e9730f1bb50335a79/140720_ietf90_plugfest_toronto/ietf90_toronto_plug=
fest_slides.pdf" target=3D"_blank">https://bytebucket.org/6tisch/meetings/r=
aw/712902bb451d113494a7045e9730f1bb50335a79/140720_ietf90_plugfest_toronto/=
ietf90_toronto_plugfest_slides.pdf</a>].<br>

&gt; Maybe we should enumerate the advantages and disadvantages of using it=
.<br>
&gt; (Some of these are tracked in ticket #5, #6 and #7).<br>
&gt;<br>
&gt;<br>
&gt; Anyway, demostratedIt needs the 6man approval to go forward.<br>
&gt;<br>
&gt; Cheers,<br>
&gt;<br>
&gt; Ines<br>
&gt;<br>
&gt;<br>
&gt; 2014-08-11 23:26 GMT+03:00 Brian E Carpenter &lt;<a href=3D"mailto:bri=
an.e.carpenter@gmail.com">brian.e.carpenter@gmail.com</a>&gt;:<br>
&gt;<br>
&gt;&gt; On 12/08/2014 01:54, Ole Troan wrote:<br>
&gt;&gt;&gt;&gt; I *really* don&#39;t think RFCs are algorithms to the poin=
t where we<br>
&gt;&gt;&gt;&gt; need to do this. I see no reason why flow-label-for-rpl ca=
n&#39;t simply<br>
&gt;&gt;&gt;&gt; declare itself an exception to this clause of RFC 6437.<br=
>
&gt;&gt;&gt; I must admit I&#39;m uncomfortable with this draft and its app=
roach. how can<br>
&gt;&gt; we be sure that we aren&#39;t opening a Pandora&#39;s box?<br>
&gt;&gt;&gt; I&#39;m worried that we set a precedence, and we&#39;ll see a =
new set of<br>
&gt;&gt; creative proposals for the use of these 20 bits.<br>
&gt;&gt;<br>
&gt;&gt; Well, that has been the case for a long time: see RFC 6294.<br>
&gt;&gt;<br>
&gt;&gt; I see the concern. Actually that&#39;s why I don&#39;t want to see=
 a formal<br>
&gt;&gt; update to 6437, because the only rational update would be to allow=
<br>
&gt;&gt; any closed domain to invent its own usage. We had that argument at=
<br>
&gt;&gt; length during the development of 6437, and decided against it.<br>
&gt;&gt; Therefore, treating RPL as a special case is the remaining option.=
<br>
&gt;&gt; But does the ROLL community actually have consensus that they want=
<br>
&gt;&gt; this special case?<br>
&gt;&gt;<br>
&gt;&gt; =C2=A0 =C2=A0Brian<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; Roll mailing list<br>
&gt;&gt; <a href=3D"mailto:Roll@ietf.org">Roll@ietf.org</a><br>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/roll" target=3D"_=
blank">https://www.ietf.org/mailman/listinfo/roll</a><br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
</div></div>&gt; ----------------------------------------------------------=
--------------<br>
<div class=3D"HOEnZb"><div class=3D"h5">&gt;<br>
&gt; --------------------------------------------------------------------<b=
r>
&gt; IETF IPv6 working group mailing list<br>
&gt; <a href=3D"mailto:ipv6@ietf.org">ipv6@ietf.org</a><br>
&gt; Administrative Requests: <a href=3D"https://www.ietf.org/mailman/listi=
nfo/ipv6" target=3D"_blank">https://www.ietf.org/mailman/listinfo/ipv6</a><=
br>
&gt; --------------------------------------------------------------------<b=
r>
</div></div></blockquote></div><br></div>

--001a1133da247a0b7105007e2de5--


From nobody Wed Aug 13 02:54:12 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD8D1A07C0; Wed, 13 Aug 2014 02:54:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level: 
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 lOjyM-oGmHBV; Wed, 13 Aug 2014 02:54:06 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244F61A86E6; Wed, 13 Aug 2014 02:54:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3229; q=dns/txt; s=iport; t=1407923647; x=1409133247; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Wy0+wT8UH/s+sCZFCRT5OA/9ijdU+xj/U3zyQCViaoU=; b=Bfc8jVF7ipc1gOYjQRYL61FcgRRYqs6oO3X7j87jQSfqoxyoYt6RC8/F xlCAb1EyC5d6A9AZ1A35LOWyp/E7G582LaI4q8JXQfxDmynkYjkyBgzCf tFdt1B2ATX9gBG+s4I3LTCq0bgjLdKSaImza44mzrf1eR+Qv+VF2UWeUy A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFAJg061OtJV2c/2dsb2JhbABaDoJ/gSkE1G0BgRQWd4QDAQEBBHkMBAIBCA4DBAEBAQodByERFAkIAQEEDgUIiCYDEcA2DYVDF40fgVYJHTEHBoMpgR0FimOGOokOkFmGM4MaQmyBB0E
X-IronPort-AV: E=Sophos;i="5.01,856,1400025600"; d="scan'208";a="68847867"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP; 13 Aug 2014 09:54:05 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s7D9s4pl027789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 09:54:04 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 04:54:04 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Philip Levis <pal@cs.stanford.edu>
Subject: RE: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoAAAz3YlABynPRAAgwPkgAETF4SQ
Date: Wed, 13 Aug 2014 09:54:03 +0000
Deferred-Delivery: Wed, 13 Aug 2014 09:53:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D3A68F@xmb-rcd-x01.cisco.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <23EA0E40-A503-4F7E-A4A9-7A33D43A215D@cs.stanford.edu>
In-Reply-To: <23EA0E40-A503-4F7E-A4A9-7A33D43A215D@cs.stanford.edu>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.49.80.52]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/eQFrw6BbwBlHSEzsP4BKXiI3Y9o
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Aug 2014 09:54:08 -0000

Works for me,=20

thanks, Phil.

Pascal

> -----Original Message-----
> From: Philip Levis [mailto:pal@cs.stanford.edu]
> Sent: jeudi 7 ao=FBt 2014 19:35
> To: Pascal Thubert (pthubert)
> Cc: Ralph Droms; Michael Richardson; Routing Over Low power and Lossy
> networks; ipv6@ietf.org
> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
>=20
> Seems reasonable to me, although a bit cumbersome. I'd suggest
>=20
>   This document updates the IPv6
>   Flow Label Specification [RFC6437], which stipulates that once the Flow
>   Label is set, forwarding nodes do not update it unless there are compel=
ling
>   security reasons to do so. This document argues that saving energy in L=
LNs
>   is another sufficiently compelling reason to modify the Flow Label.
>=20
> Phil
>=20
> On Aug 5, 2014, at 1:11 AM, Pascal Thubert (pthubert)
> <pthubert@cisco.com> wrote:
>=20
> > I think I see what you are saying, Phil.
> >
> > I can split 1.3 to isolate the deviations to 6437.
> >
> > I also need to move the following text from section 3 in that new
> > section
> >
> >  This may seem contradictory with the IPv6
> >   Flow Label Specification [RFC6437] which stipulates that once it is
> >   set, the Flow Label is left unchanged; but the RFC also indicates a
> >   violation to the rule can be accepted for compelling reasons, and
> >   that security is a case justifying such a violation.  This
> >   specification suggests that energy-saving is another compelling
> >   reason for a violation to the aforementioned rule.
> >
> > Proposed update for that text:
> >
> >   This specification updates the IPv6
> >   Flow Label Specification [RFC6437], which stipulates that once it is
> >   set, the Flow Label is left unchanged. [RFC6437] also indicates that
> >   a violation to the rule can be accepted for compelling reasons,
> >   but limit those compelling reasons to security related issues.  This
> >   specification indicates that energy-saving is another compelling
> >   reason that justifies a violation to the aforementioned rule.
> >
> > What do you think?
> >
> > Cheers,
> >
> > Pascal
> >
> >
> >> -----Original Message-----
> >> From: Philip Levis [mailto:pal@cs.stanford.edu]
> >> Sent: lundi 4 ao=FBt 2014 20:23
> >> To: Ralph Droms
> >> Cc: Pascal Thubert (pthubert); Michael Richardson; Routing Over Low
> >> power and Lossy networks; ipv6@ietf.org
> >> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
> >>
> >>
> >> On Aug 4, 2014, at 11:10 AM, Ralph Droms <rdroms.ietf@gmail.com>
> wrote:
> >>
> >>>
> >>> On Aug 4, 2014, at 2:01 PM 8/4/14, Pascal Thubert (pthubert)
> >> <pthubert@cisco.com> wrote:
> >>>
> >>>> The change is now done, Ralph.
> >>>>
> >>>> The only difference between
> >>>> draft-thubert-6man-flow-label-for-rpl-03 and
> >> draft-thubert-6man-flow-label-for-rpl-04 is
> >>>>
> >>>> Updates: 6437 (if approved)
> >>>
> >>> I suggest adding a section to your doc that explains exactly what is
> >>> being
> >> updated in RFC 6437.
> >>>
> >>> - Ralph
> >>
> >>
> >> I agree. I think some of the text in 1.3 can be re-used for this purpo=
se.
> >>
> >> Phil


From nobody Wed Aug 13 09:37:42 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3361A0908; Wed, 13 Aug 2014 09:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level: 
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 5c38Gg58Kd9t; Wed, 13 Aug 2014 09:37:33 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBEDA1A091F; Wed, 13 Aug 2014 09:37:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3882; q=dns/txt; s=iport; t=1407947848; x=1409157448; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TB9WueMH+log7hj8wbs53uHcHxfd35qLRzPaSqPJn3A=; b=HJ4HwgcpuCelcWxSML2RwOW6Bw3z3ZN3mR1K5e+K+s6rh5lBinEAPvyA rVKYd3iy5/HbEddSXKA2OG/UPvadYXvNee9qLGf6M4eS/CdLqNnh15/DW c2oa0OXH6KZpy0vBc9+MP10fzqU7zyIKYMGuL9gqlPaHCn/Vh61jERzMO g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFAPuT61OtJV2U/2dsb2JhbABagw1SVwTNHgqHSAGBFBZ3hAMBAQEEAQEBawsMBAIBCBEEAQEBCh0HIQYLFAkIAQEEAQ0FCAELiBoDEQ3BEg2FRBeNH4FcAQEBCRQxAgUGgymBHQWGEIRThjqEJoRokFmGM4FjHYFcbAGBDjk
X-IronPort-AV: E=Sophos;i="5.01,857,1400025600"; d="scan'208";a="68959911"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP; 13 Aug 2014 16:37:27 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7DGbRaQ018587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 16:37:27 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 11:37:27 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Ines Robles <mariainesrobles@googlemail.com>
Subject: RE: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoAGeLZuUACNu7fA=
Date: Wed, 13 Aug 2014 16:37:27 +0000
Deferred-Delivery: Wed, 13 Aug 2014 16:37:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D3BE65@xmb-rcd-x01.cisco.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com>
In-Reply-To: <53EAA58D.4060401@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.49.80.52]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/-zXO7EYBCCvYxwTVYcoIlScA9oc
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Aug 2014 16:37:40 -0000

Hi Brian:

The question to 6MAN is really whether the use that the draft makes of the =
flow label within the RPL domain is acceptable or not. In particular Sectio=
n 1.3 does not force a particular usage of the flow label inside the LLN, i=
t simply updates the rules of what is allowed and what is not within that d=
omain, knowing that the root will set the label properly towards the Intern=
et and reset it from the Internet.

It is up to ROLL and other external standards adopting the work (ISA100, WC=
I) to decide of its usefulness.=20

Cheers,

Pascal


> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
> Sent: mercredi 13 ao=FBt 2014 01:39
> To: Ines Robles
> Cc: Routing Over Low power and Lossy networks; 6man WG
> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
>=20
> Ines,
>=20
> Can you perhaps clarify the exact question you are asking 6man?
>=20
> (I'm thinking that 6man isn't being asked whether the number of bits save=
d
> is a useful energy saving, or whether Carsten's proposal is better.)
>=20
> Regards
>    Brian
>=20
> On 12/08/2014 19:15, Ines Robles wrote:
> > Hi,
> >
> > On April, it was discussed and got consensus in ROLL [
> > http://www.ietf.org/mail-archive/web/roll/current/msg08634.html].
> >
> > This technique saves bytes, as was demonstrated by Xavier in his
> > implementation [ start on Slide 41 -
> >
> https://bytebucket.org/6tisch/meetings/raw/712902bb451d113494a7045e97
> 30f1bb50335a79/140720_ietf90_plugfest_toronto/ietf90_toronto_plugfest_s
> lides.pdf].
> > Maybe we should enumerate the advantages and disadvantages of using
> it.
> > (Some of these are tracked in ticket #5, #6 and #7).
> >
> >
> > Anyway, demostratedIt needs the 6man approval to go forward.
> >
> > Cheers,
> >
> > Ines
> >
> >
> > 2014-08-11 23:26 GMT+03:00 Brian E Carpenter
> <brian.e.carpenter@gmail.com>:
> >
> >> On 12/08/2014 01:54, Ole Troan wrote:
> >>>> I *really* don't think RFCs are algorithms to the point where we
> >>>> need to do this. I see no reason why flow-label-for-rpl can't
> >>>> simply declare itself an exception to this clause of RFC 6437.
> >>> I must admit I'm uncomfortable with this draft and its approach. how
> >>> can
> >> we be sure that we aren't opening a Pandora's box?
> >>> I'm worried that we set a precedence, and we'll see a new set of
> >> creative proposals for the use of these 20 bits.
> >>
> >> Well, that has been the case for a long time: see RFC 6294.
> >>
> >> I see the concern. Actually that's why I don't want to see a formal
> >> update to 6437, because the only rational update would be to allow
> >> any closed domain to invent its own usage. We had that argument at
> >> length during the development of 6437, and decided against it.
> >> Therefore, treating RPL as a special case is the remaining option.
> >> But does the ROLL community actually have consensus that they want
> >> this special case?
> >>
> >>    Brian
> >>
> >> _______________________________________________
> >> Roll mailing list
> >> Roll@ietf.org
> >> https://www.ietf.org/mailman/listinfo/roll
> >>
> >
> >
> > ----------------------------------------------------------------------
> > --
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Wed Aug 13 09:48:13 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EAE1A00F6; Wed, 13 Aug 2014 09:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level: 
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 8kNF8DdR09O1; Wed, 13 Aug 2014 09:48:09 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26E0E1A0028; Wed, 13 Aug 2014 09:48:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5548; q=dns/txt; s=iport; t=1407948489; x=1409158089; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+pTBLZOyVz7nKaCMMmxMD+YTWI+/yeJVClIMUKVMaYk=; b=jjDKIxrRta/j8N+qXjgy4g1LfaMgeEOPRYbcxsArGkIKdhbuNd4HyGXV t3Bw0TbaJ4iFBXj0xVSPkhTdEhWSNwbyRW7hDdNUu6vqyC9E5SNmg76u5 9BqguC9GoMz+6tK6kb5boeKwuoUt4ZJZ2rZBTE7YzYQPEUVeZdyWHWqxf o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhMFACaW61OtJV2Q/2dsb2JhbABagw1SVwTNHgqHSAGBFBZ3hAMBAQEEAQEBawsMBAIBCA4DAQMBAQEKHQchBgsUAwYIAQEEAQ0FCBOIEwMRDcEUDYVEEwSJf4MggV8dMQcGgymBHQWKY4Y6iQ6QWYYzgWMdgVxsAYFH
X-IronPort-AV: E=Sophos;i="5.01,857,1400025600"; d="scan'208";a="68961878"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP; 13 Aug 2014 16:48:07 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s7DGm7FN029265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 16:48:07 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 11:48:07 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Carsten Bormann <cabo@tzi.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: RE: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoAGeLZuUAA34HwAAE+G98A==
Date: Wed, 13 Aug 2014 16:48:06 +0000
Deferred-Delivery: Wed, 13 Aug 2014 16:47:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org>
In-Reply-To: <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.49.80.52]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/v25uFjX8IMZcQvRXbow7AaXAeQI
Cc: Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Aug 2014 16:48:11 -0000

Hello Carsten:

In my view, this work is not competing with 6lo: for the specific value of =
keeping the draft whatever 6lo decides to do:

- If this draft is not adopted, the flow label from LLN will probably stay =
all zeroes as it is today and the goal of 6437 will not be achieved. There =
is no way a device will waste 20 bits for a random that has no value inside=
 the LLN. The text tells the RPL root to set the flow label.

- If this draft is not adopted, the root of the LLN will have to forward th=
e flow label coming from the Internet down to the end destination device, d=
eep in the mesh, wasting 20 bits in each frame. These is a waste that 6lo c=
ompression will not be allowed to legally elide if today we decide that we =
do not allow it. Note: even if the correspondent sets the FL to zeroes to h=
elp the LLN, there is no way to guarantee that the flow label will not be s=
et on the way since that much is lawful.=20

- If the draft is not adopted, existing usages in shipping standards that i=
ncorporate IPv6 will stay borderline/unlawful. E.g. the draft legalizes the=
 way ISA100.11a uses the flow label for a stateful flow identification with=
in the ISA100 domain.

- If the draft is not adopted, we have no leverage over WCI that is definin=
g the backbone router for ISA100.11a devices. The draft indicates that the =
root should ensure that the flow label is correctly set when going outside,=
 which is a minor increment to WCI, if pushed in due time with a proper RFC=
 number that demands it.=20

The need for this work was agreed at ROLL. We need a better solution than a=
vailable, for application in RPL domains, that are often but not necessaril=
y congruent with 6LowPAN domains.

I'm fully supportive to have a 6lo compression that will improve the situat=
ion for a 6lowpan network, and at this point we have 3 proposals on the tab=
le, Laurent's, yours, and mine, which is to have a routing dispatch for rou=
te-over in parallel to the mesh dispatch that is mesh-under. I do hope we c=
reate a momentum there and converge. But there is no guarantee.

All in all, I will not drop something that works now, with running code and=
 all, and reached last call status, against the sirens of a compression tha=
t will not solve the issues above.

Cheers,

Pascal


> -----Original Message-----
> From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Carsten Bormann
> Sent: mercredi 13 ao=FBt 2014 03:19
> To: Routing Over Low power and Lossy networks
> Cc: Ines Robles; 6man WG; 6lo@ietf.org WG
> Subject: Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-=
03
>=20
> On 13 Aug 2014, at 01:38, Brian E Carpenter <brian.e.carpenter@gmail.com>
> wrote:
>=20
> > Can you perhaps clarify the exact question you are asking 6man?
>=20
> Well, I'm not Ines, but I'm trying to find out why we are in this peculia=
r
> position of discussing this draft right now.
>=20
> ROLL has a routing protocol that requires some data to be shipped around
> together with IP packets.
> RFC 6553 and 6554 define ways to do this that are consistent with the IP
> architecture.
> Unfortunately, the overhead (signal-to-fluff ratio) is relatively high, a=
nd in
> this area of application, that matters.
>=20
> Normally, the next step would have been looking at ways to do header
> compression.
> We did talk about compressing ROLL, but with a view to compressing the
> (control plane) ROLL messages, not so much about the (data plane) IP
> packets themselves.  GHC is trying to be a reasonably useful, but also
> reasonably general way to do the control plane messages.
>=20
> For the data packets, the flow label (and its now predominant non-use)
> provides an attractive hole in the IPv6 packets to ship around the RFC 65=
33
> information, but not the RFC 6554 information.
> In 6lo networks, normally RFC 6282 compresses away empty flow labels, but
> it is cheap to put them in, so a flow label really only costs 3 bytes (in=
stead of
> 8 bytes RFC 6553 costs).  The most useful information from RFC 6553 can b=
e
> stuffed into 19 bits, as demonstrated by the draft we are discussing here=
.
>=20
> RFC 6282 has extension points (GHC uses one of them), but not really usef=
ul
> ones for the ROLL data plane.
> So it appears it never occurred to us that the best way to handle these 1=
9
> bits is to actually sidestep RFC 6282, and use the existing extension poi=
nts of
> RFC 4944.  Until Laurent showed one way of doing this.  I just went from
> there and did a strawman using Laurent's idea for compressing the RFC 655=
3
> option, in a way that is as efficient as (or, in most cases, actually mor=
e
> efficient than) using the flow label hole.
>=20
> So to me it seems there no longer is a good technical argument to ask 6ma=
n
> to liberate the flow label for carrying RFC 6553.
> But that is maybe something that should now be discussed between 6lo and
> ROLL; I don't think that this is a 6man issue (unless the answer is a sim=
ple
> "sure, go ahead, take it, we don't need it any more anyway", which is not
> what I have perceived RFC 6437 to say).
> When 6lo and ROLL have generated consensus on the need to do this, we
> may or may not want to go back to 6man and actually pry that flow label
> hole out of your fingers.
>=20
> Gr=FC=DFe, Carsten
>=20
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo


From nobody Wed Aug 13 09:51:27 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453AC1A0936; Wed, 13 Aug 2014 09:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level: 
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 OxKR4SvenfMF; Wed, 13 Aug 2014 09:51:23 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51BBD1A0415; Wed, 13 Aug 2014 09:51:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1868; q=dns/txt; s=iport; t=1407948684; x=1409158284; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UAg8jz6yjyMjUYPdUDe+doeVg49RkBjAEPoQNaAXxvw=; b=IBATIewe1AGLBI9F1rCwGLdUfaSKo83oEH3lQvRtnJkjjXSoRvhKKH09 dI/4JMmxCEPKXkNKqnNJgIPnjI3gUOjiNtK3bHlQNh8A+OKg/swyELkqk sqe6OzmKdOF+4prY87aqx7rxUkpkQPsaCK5rW2zgiU1SR9SDKva1brNDU c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIFAESX61OtJA2K/2dsb2JhbABagw1SVwTNHgqHSAGBFBZ3hAMBAQEEAQEBawsMBAIBCA4DBAEBAQodBycLFAkIAgQBDQUIiCYDEQ3BCw2FRBeNH4FfHTEHBoMpgR0FhhCEU4Y6hCaITZMngWMdgVxsgUg
X-IronPort-AV: E=Sophos;i="5.01,857,1400025600"; d="scan'208";a="347231243"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-7.cisco.com with ESMTP; 13 Aug 2014 16:51:23 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s7DGpMhU031948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 16:51:22 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 11:51:22 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Carsten Bormann <cabo@tzi.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: RE: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoADOBvRXAAsYswAAiNKGgAANrl6AABapBoAAAvlzgAA40uRw
Date: Wed, 13 Aug 2014 16:51:21 +0000
Deferred-Delivery: Wed, 13 Aug 2014 16:51:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D3BF04@xmb-rcd-x01.cisco.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <C95BA1B7-A7B7-43BD-8E23-8FFDB2DD79ED@tzi.org>
In-Reply-To: <C95BA1B7-A7B7-43BD-8E23-8FFDB2DD79ED@tzi.org>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.49.80.52]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/MhXq8tsTqLnbOxlg5Ql1IwwV1S4
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Aug 2014 16:51:25 -0000

I disagree, Carsten.

To save all the bytes, we need to update the 6MAN rules and allow to change=
 a non-zero flow label, be it only to reset and elide it when coming from t=
he Internet.
More in my other answer to you today...

Pascal


> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Carsten Bormann
> Sent: mardi 12 ao=FBt 2014 10:40
> To: Routing Over Low power and Lossy networks
> Cc: Michael Richardson; 6man WG
> Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
>=20
> On 12 Aug 2014, at 09:15, Ines Robles <mariainesrobles@googlemail.com>
> wrote:
>=20
> > This technique saves bytes
>=20
> Again, the straw man at http://tools.ietf.org/html/draft-bormann-6lo-rpl-
> mesh-00
> saves the same number of bytes.  Actually, for common cases, it enables o=
ne
> additional optimization (saving one more byte) that is not available with=
 the
> flow label hack.  (On the other hand, due to the way RFC 6282 works, the
> flow label hack saves one byte where both it and ECN are in use and the
> common case does not apply.)
>=20
> The disadvantage of the RPL mesh header is that this approach is not
> available outside 6lo networks (i.e., networks employing adaptation layer=
s
> that use RFC 6282).  I'm not aware yet of a use case where that is a prob=
lem.
>=20
> In either encoding (RPL mesh header or flow label), it is probably a good=
 idea
> anyway to unpack the compressed information back into the RPL IPv6 option
> when leaving the 6lo networks.
>=20
> Gr=FC=DFe, Carsten
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Wed Aug 13 12:08:36 2014
Return-Path: <pal@cs.stanford.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159881A047D; Wed, 13 Aug 2014 12:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.868
X-Spam-Level: 
X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham
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 28Gaf_Yogfi9; Wed, 13 Aug 2014 12:08:15 -0700 (PDT)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 122791A0456; Wed, 13 Aug 2014 12:07:07 -0700 (PDT)
Received: from gapx8.stanford.edu ([171.64.70.57]:64636 helo=[10.171.216.192]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XHdt3-000517-IJ; Wed, 13 Aug 2014 12:07:06 -0700
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com>
Date: Wed, 13 Aug 2014 12:07:04 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 9c8d7c79e82d9ccd3af9a51b4d3246f3
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/KPuwCwVUOhfsxewXdNeO-bI0MGU
Cc: Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Aug 2014 19:08:19 -0000

On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) =
<pthubert@cisco.com> wrote:

> If this draft is not adopted, the flow label from LLN will probably =
stay all zeroes as it is today and the goal of 6437 will not be =
achieved.

Pascal, I'm trying to reconcile your claim that the goal of 6437 is to =
allow enclosed networks to use the flow label with Brian's statement

> Actually that's why I don't want to see a formal
> update to 6437, because the only rational update would be to allow
> any closed domain to invent its own usage. We had that argument at
> length during the development of 6437, and decided against it.

Phil



From nobody Wed Aug 13 12:12:04 2014
Return-Path: <pal@cs.stanford.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14EF71A0489; Wed, 13 Aug 2014 12:11:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.868
X-Spam-Level: 
X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham
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 lRJb3vwL0HaL; Wed, 13 Aug 2014 12:11:52 -0700 (PDT)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2031A047D; Wed, 13 Aug 2014 12:11:52 -0700 (PDT)
Received: from gapx8.stanford.edu ([171.64.70.57]:64640 helo=[10.171.216.192]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XHdxc-0005n6-GK; Wed, 13 Aug 2014 12:11:52 -0700
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com>
Date: Wed, 13 Aug 2014 12:11:48 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <E66DB157-B1C2-4BA4-B889-A15A6427DA3E@cs.stanford.edu>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 5fb79390a4aad79c01ba7e4883e5f1df
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/VfnBVXYN5S3bprJhcRCg_E2YwDY
Cc: Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Aug 2014 19:11:58 -0000

On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) =
<pthubert@cisco.com> wrote:

> The need for this work was agreed at ROLL. We need a better solution =
than available, for application in RPL domains, that are often but not =
necessarily congruent with 6LowPAN domains.

This seems to me to be the strong technical argument in favor of the =
draft. While Carsten's approach seems better technically, it only works =
for 6lowpan, and RPL should be independent of the underlying link layer.

Phil=


From nobody Wed Aug 13 12:50:03 2014
Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9321A0467; Wed, 13 Aug 2014 12:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 Pawfxn1FC44E; Wed, 13 Aug 2014 12:49:54 -0700 (PDT)
Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2971A039B; Wed, 13 Aug 2014 12:49:53 -0700 (PDT)
Received: by mail-qa0-f51.google.com with SMTP id k15so187149qaq.38 for <multiple recipients>; Wed, 13 Aug 2014 12:49:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n5qLDiMq4w1HINQl3Suub/E/OA70xC9ch92L2W73Io4=; b=qwTq6XiM4HCehhOLRjitw1hgDBuroxxmm62JlbN47ARD3vFTPKd9WE3GOhNNNeVUwM qI97+mOcQbwPuha/U7gOnwhGwutsMDx8duX9bJwdx4YRihLS6NEcyTQYZuPjxUbTRSa9 ue35QUNmWZOtgF3wtOxIE3rz43EDHqfpq5Is1JT5yShOg0qx3VjaV2goi+tjT0+Dtlcd Ec3/Yl+NhJxTN3hCeaYlfnCu5Cp0qsto8MeW6vG6cKXbCtZbiG04NP5mfA/apcODnnJF SIi5YASqBMk7mNvExvrN6UQ6lpLvWtj/PPHqxilKOfSO+Q2UgmCr6QVCamPK4r5sbEAd Uwrw==
X-Received: by 10.224.65.196 with SMTP id k4mr10501569qai.56.1407959392649; Wed, 13 Aug 2014 12:49:52 -0700 (PDT)
Received: from [10.86.254.61] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id u5sm4839422qae.18.2014.08.13.12.49.49 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Aug 2014 12:49:50 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <E66DB157-B1C2-4BA4-B889-A15A6427DA3E@cs.stanford.edu>
Date: Wed, 13 Aug 2014 15:49:45 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <E66DB157-B1C2-4BA4-B889-A15A6427DA3E@cs.stanford.edu>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Jtbi3Puzx4Dx9LEAwA4eJUdNXBE
Cc: Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Aug 2014 19:50:00 -0000

On Aug 13, 2014, at 3:11 PM 8/13/14, Philip Levis <pal@cs.stanford.edu> =
wrote:

> On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) =
<pthubert@cisco.com> wrote:
>=20
>> The need for this work was agreed at ROLL. We need a better solution =
than available, for application in RPL domains, that are often but not =
necessarily congruent with 6LowPAN domains.
>=20
> This seems to me to be the strong technical argument in favor of the =
draft. While Carsten's approach seems better technically, it only works =
for 6lowpan, and RPL should be independent of the underlying link layer.

Could we consider Carsten's approach a compression mechanism for the RPL =
information options, rather than a replacement, thereby allowing a =
one-to-one translation between compressed mode on 6lowpan networks and =
uncompressed mode in other networks?

- Ralph

>=20
> Phil
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll


From nobody Wed Aug 13 13:53:01 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69581A0113; Wed, 13 Aug 2014 13:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 szv7RmgRVe8s; Wed, 13 Aug 2014 13:52:55 -0700 (PDT)
Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBFD71A0087; Wed, 13 Aug 2014 13:52:54 -0700 (PDT)
Received: by mail-pd0-f171.google.com with SMTP id z10so322066pdj.30 for <multiple recipients>; Wed, 13 Aug 2014 13:52:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Zq13KrjxWEgsU/gEsK0K7I24Yu7AmKYu8Whd/3LQluI=; b=P5dVZO2yPUMgoq7rNcrYoW22KJDT282OBCB4+znGS3XAxfYOynoq8ky45dd4c+wODl +UZI+NmKuQ5CwYJDCtxPKiYP5iMNGi1KAhAdoVAlIHXKfAfDGE/YFRikK4wIWTR/E2+i ZYy6nxmpxcassPPdYg8jMm89ctWq/k9EDb77pmntJUEfu+6NEViEiEBQ03oCgeNJPTH7 lC1nUBSGO9WA0jP1MziwQrCGaL/9JiI7ZXKnAynZc44Nx/FeqE5rBxaumloUcbylMHNG 8m20FlwjjITsuZ2axglbF0k+MiQie5zQZlnshluH6aus3FCr+uiGUY3/3/HcMxfpGt2O glNw==
X-Received: by 10.70.61.162 with SMTP id q2mr6166813pdr.50.1407963174616; Wed, 13 Aug 2014 13:52:54 -0700 (PDT)
Received: from [192.168.178.23] (60.199.69.111.dynamic.snap.net.nz. [111.69.199.60]) by mx.google.com with ESMTPSA id dn3sm3025074pbc.79.2014.08.13.13.52.51 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Aug 2014 13:52:53 -0700 (PDT)
Message-ID: <53EBD028.30302@gmail.com>
Date: Thu, 14 Aug 2014 08:52:56 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Philip Levis <pal@cs.stanford.edu>
Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu>
In-Reply-To: <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/myi5YmQUIYsbVcgWdPP5IQrt_VQ
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Aug 2014 20:52:57 -0000

On 14/08/2014 07:07, Philip Levis wrote:
> On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> 
>> If this draft is not adopted, the flow label from LLN will probably stay all zeroes as it is today and the goal of 6437 will not be achieved.
> 
> Pascal, I'm trying to reconcile your claim that the goal of 6437 is to allow enclosed networks to use the flow label with Brian's statement
> 
>> Actually that's why I don't want to see a formal
>> update to 6437, because the only rational update would be to allow
>> any closed domain to invent its own usage. We had that argument at
>> length during the development of 6437, and decided against it.
> 
> Phil

Right. I'm drawing a very subtle line between (a) stating an exception
to 6437 for this particular usage and (b) opening the door to other
usages. Since 6man clearly didn't want (b) during the development of
6437 I think we do need to limit ourselves to (a).

    Brian


From nobody Wed Aug 13 14:02:40 2014
Return-Path: <cabo@tzi.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88FE1A024C; Wed, 13 Aug 2014 14:02:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.348
X-Spam-Level: **
X-Spam-Status: No, score=2.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 3-U63D7qrw_1; Wed, 13 Aug 2014 14:02:36 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB601A0240; Wed, 13 Aug 2014 14:02:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s7DL2WAY010151; Wed, 13 Aug 2014 23:02:32 +0200 (CEST)
Received: from [192.168.217.106] (p54890314.dip0.t-ipconnect.de [84.137.3.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id EECFB646; Wed, 13 Aug 2014 23:02:31 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com>
Date: Wed, 13 Aug 2014 23:02:30 +0200
X-Mao-Original-Outgoing-Id: 429656550.493394-0b0371c33024aed2238ba978ba9bb142
Content-Transfer-Encoding: quoted-printable
Message-Id: <C3D3692D-C6A6-4AD2-B5A7-3718E318055E@tzi.org>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <E66DB157-B1C2-4BA4-B889-A15A6427DA3E@cs.stanford.edu> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/cX_tQaN1vu3MlzrabjQBZTqFjro
Cc: 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Aug 2014 21:02:39 -0000

>> This seems to me to be the strong technical argument in favor of the =
draft. While Carsten's approach seems better technically, it only works =
for 6lowpan, and RPL should be independent of the underlying link layer.

The transport of RPL specific information for data plane packets already =
*is* independent of the underlying link layer, as specified in RFC 6553 =
and RFC 6554.  All we are talking about here is an optimization for =
those (for 6553, specifically; actually 6554 is probably the one even =
more in need).

> Could we consider Carsten's approach a compression mechanism for the =
RPL information options, rather than a replacement, thereby allowing a =
one-to-one translation between compressed mode on 6lowpan networks and =
uncompressed mode in other networks?

Indeed, that is probably the best way to view this approach.
(In the next version of the draft, I=92ll emphasize this.)

My assumption here is:
=97 Any subnet that could not live with transporting RFC 6553 as is, =
i.e. 8 bytes extra compared to the flow label approach (for uncompressed =
packets*), already needs (and, at this point, has) a header compression =
solution for the expansive IPv6 header anyway.
  So adding RFC 6553 compression to that solution is the natural =
approach.
=97 All subnets that can live with the IPv6 header as is, also can live =
with RFC 6553 as is.

This argument is on a technical level.
I=92m not talking about cognitive dissonance**) here, or political =
issues.
If there are important political issues (I have no idea what the =
ISA100/WCI talk is about), they probably need to be brought out in the =
open here.

Gr=FC=DFe, Carsten

*) less difference for header-compressed packets, e.g., 5 bytes for 6lo.
**) http://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf, =
section 2.6


From nobody Thu Aug 14 00:21:40 2014
Return-Path: <trac+6man@trac.tools.ietf.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C63E1A08F5; Thu, 14 Aug 2014 00:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level: 
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham
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 K7I603KIxgZk; Thu, 14 Aug 2014 00:21:34 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 629721A08E5; Thu, 14 Aug 2014 00:21:34 -0700 (PDT)
Received: from localhost ([::1]:57768 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <trac+6man@trac.tools.ietf.org>) id 1XHpLo-0006M4-OL; Thu, 14 Aug 2014 00:21:32 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "6man issue tracker" <trac+6man@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: pthubert@cisco.com, mariainesrobles@gmail.com
X-Trac-Project: 6man
Date: Thu, 14 Aug 2014 07:21:32 -0000
X-URL: http://tools.ietf.org/wg/6man/
Subject: [6man] #8 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 relation with draft-bormann-6lo-rpl-mesh-00
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/8
Message-ID: <067.39ff52585c7babe2e3fa02e2043cbad6@trac.tools.ietf.org>
X-Trac-Ticket-ID: 8
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org
X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/a6eJxdPg4gNmqbFvDwTNwyqB1A0
Cc: roll@ietf.org, 6man@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: 6man@ietf.org
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Aug 2014 07:21:37 -0000

#8: draft-thubert-6man-flow-label-for-rpl-03 relation with draft-bormann-6lo-
rpl-mesh-00

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08805.html

 From: Carsten Bormann <cabo at tzi.org>
 Date: Sun, 10 Aug 2014 18:29:01 +0200

 So far, we have mainly discussed the need for an optimization (it seems we
 now agree there is a need) and the interaction between the normative
 components of RFC 6437 and those of the draft at hand.

 I’d now like to bring up a different question:

 Is this the right approach?

 I have written up what appears to be a more natural approach in the
 strawman draft:
 http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-00

 Why are we doing the flow-label thing and not the more natural thing?

 [ ] because the flow label hack works on packets that leave the 6lo
 networks.
     • but do we really need to optimize this on the non-6lo networks?
 [ ] because the flow label hack has been around for a while and is now
 cast in stone.
     • is it?
 [ ] because there is a flaw with the way this has been integrated into the
 6lo framework.
     • ______ (fill in the flaw)
 [ ] because ______ (fill in the reason)

 Inquiring minds want to know.

 Grüße, Carsten

-- 
-------------------------------------------------+-------------------------
 Reporter:  mariainesrobles@gmail.com            |      Owner:
     Type:  defect                               |  pthubert@cisco.com
 Priority:  major                                |     Status:  new
Component:  draft-thubert-6man-flow-label-for-   |  Milestone:
  rpl                                            |    Version:
 Severity:  In WG Last Call                      |   Keywords:
-------------------------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6man/trac/ticket/8>
6man <http://tools.ietf.org/wg/6man/>


From nobody Thu Aug 14 00:23:54 2014
Return-Path: <trac+6man@trac.tools.ietf.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523F11A08FC; Thu, 14 Aug 2014 00:23:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.331
X-Spam-Level: *
X-Spam-Status: No, score=1.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, RP_MATCHES_RCVD=-0.668] autolearn=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 5ePIuIQSdZzK; Thu, 14 Aug 2014 00:23:44 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 72A741A08F5; Thu, 14 Aug 2014 00:23:44 -0700 (PDT)
Received: from localhost ([::1]:57842 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <trac+6man@trac.tools.ietf.org>) id 1XHpNv-0002o4-GP; Thu, 14 Aug 2014 00:23:43 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "6man issue tracker" <trac+6man@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: pthubert@cisco.com, mariainesrobles@gmail.com
X-Trac-Project: 6man
Date: Thu, 14 Aug 2014 07:23:43 -0000
X-URL: http://tools.ietf.org/wg/6man/
Subject: Re: [6man] #8 (draft-thubert-6man-flow-label-for-rpl): draft-thubert-6man-flow-label-for-rpl-03 relation with draft-bormann-6lo-rpl-mesh-00
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/6man/trac/ticket/8#comment:1
Message-ID: <082.779ea0cba3a3fda448c718ef6764041e@trac.tools.ietf.org>
References: <067.39ff52585c7babe2e3fa02e2043cbad6@trac.tools.ietf.org>
X-Trac-Ticket-ID: 8
In-Reply-To: <067.39ff52585c7babe2e3fa02e2043cbad6@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: pthubert@cisco.com, mariainesrobles@gmail.com, roll@ietf.org, 6man@ietf.org
X-SA-Exim-Mail-From: trac+6man@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/_VJNs4To8TzecNhbXM0POXcma_U
Cc: roll@ietf.org, 6man@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: 6man@ietf.org
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Aug 2014 07:23:51 -0000

#8: draft-thubert-6man-flow-label-for-rpl-03 relation with draft-bormann-6lo-
rpl-mesh-00


Comment (by mariainesrobles@gmail.com):

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08808.html


 From: "Pascal Thubert (pthubert)" <pthubert at cisco.com>
 Date: Sun, 10 Aug 2014 17:05:34 +0000

 Hi Carsten

 I think you jumped too quickly on my suggestion at 6lo.

 It makes a lot of sense to work on a 6lo routing dispatch and in
 particular enable the compression of all RPL artifacts.

 It will take some time to figure out what goes in there but my suggestion
 at 6lo includes routing header compression, RPL option, but also source
 destination if we decide to route fragments.

 I hope this happens and I'll see with Laurent if we use a respin of his
 draft or I start a new one.

 This work will be beneficial in the long run, but doubly fails to address
 the issues at stake here:

 - the draft proposes to update the rules in 6437 with stateful and with
 domain scoped operations. This is used by the draft itself but also by
 published and deployed standards that came up before 6437 (eg ISA100.11a)
 and we are now acknowledging and legalizing a de facto situation.

 - it will take a year or 2 at best to agree on the new routing dispatch
 and its operation. We need an improvement now. And btw we cannot
 necessarily assume 6lo together with RPL, I know of at least one RPL
 implementation that does not use that compression.

 Finally, Using a dispatch for the RPL option alone seems like a waste, but
 that is a discussion for 6lo. I'll publish there when I'm back from
 vacations.

 Cheers,

 Pascal

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08811.html

 From: Carsten Bormann <cabo at tzi.org>
 Date: Sun, 10 Aug 2014 21:07:04 +0200

 On 10 Aug 2014, at 19:05, Pascal Thubert (pthubert) <pthubert at
 cisco.com> wrote:

 > - it will take a year or 2 at best to agree on the new routing dispatch
 and its operation. We need an improvement now. And btw we cannot
 necessarily assume 6lo together with RPL, I know of at least one RPL
 implementation that does not use that compression.

 I don’t understand why we can’t do the saner equivalent of the flow label
 hack now and come up with a source routing header (which is not covered by
 the flow label hack) later.

 Please tell us more about how ISA100.11a uses the flow label; that is
 information that has been lacking from the discussion so far.

 Grüße, Carsten

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08817.html

 From: Carsten Bormann <cabo at tzi.org>
 Date: Tue, 12 Aug 2014 10:40:19 +0200

 On 12 Aug 2014, at 09:15, Ines Robles <mariainesrobles at googlemail.com>
 wrote:

 > This technique saves bytes

 Again, the straw man at http://tools.ietf.org/html/draft-bormann-6lo-rpl-
 mesh-00
 saves the same number of bytes.  Actually, for common cases, it enables
 one additional optimization (saving one more byte) that is not available
 with the flow label hack.  (On the other hand, due to the way RFC 6282
 works, the flow label hack saves one byte where both it and ECN are in use
 and the common case does not apply.)

 The disadvantage of the RPL mesh header is that this approach is not
 available outside 6lo networks (i.e., networks employing adaptation layers
 that use RFC 6282).  I’m not aware yet of a use case where that is a
 problem.

 In either encoding (RPL mesh header or flow label), it is probably a good
 idea anyway to unpack the compressed information back into the RPL IPv6
 option when leaving the 6lo networks.

 Grüße, Carsten

 -------------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08824.html

 From: "Pascal Thubert (pthubert)" <pthubert at cisco.com>
 Date: Wed, 13 Aug 2014 16:51:21 +0000

 I disagree, Carsten.

 To save all the bytes, we need to update the 6MAN rules and allow to
 change a non-zero flow label, be it only to reset and elide it when coming
 from the Internet.
 More in my other answer to you today...

 Pascal

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08818.html

 From: Brian E Carpenter <brian.e.carpenter at gmail.com>
 Date: Wed, 13 Aug 2014 11:38:53 +1200
 Ines,

 Can you perhaps clarify the exact question you are asking 6man?

 (I'm thinking that 6man isn't being asked whether the number
 of bits saved is a useful energy saving, or whether Carsten's
 proposal is better.)

 Regards
    Brian

 On 12/08/2014 19:15, Ines Robles wrote:
 > Hi,
 >
 > On April, it was discussed and got consensus in ROLL [
 > http://www.ietf.org/mail-archive/web/roll/current/msg08634.html].
 >
 > This technique saves bytes, as was demonstrated by Xavier in his
 > implementation [ start on Slide 41 -
 >
 https://bytebucket.org/6tisch/meetings/raw/712902bb451d113494a7045e9730f1bb50335a79/140720_ietf90_plugfest_toronto/ietf90_toronto_plugfest_slides.pdf].
 > Maybe we should enumerate the advantages and disadvantages of using it.
 > (Some of these are tracked in ticket #5, #6 and #7).
 >
 >
 > Anyway, demostratedIt needs the 6man approval to go forward.
 >
 > Cheers,
 >
 > Ines
 -------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08820.html

 From: Ines Robles <mariainesrobles at googlemail.com>
 Date: Wed, 13 Aug 2014 11:00:12 +0300

 Hi Brian,

 Thanks for your comment.

 Actually, I did not ask a question, I just wanted to say that the Pascal's
 draft got consensus at ROLL in april, and the WGLC was done between 6man
 and ROLL to know the 6man opinion about the use of flow-label (tickets #5,
 #6 and #7). With the new Carsten proposal (6lo draft), we (constrained
 environment WGs) should analyze this approach and decide the further steps
 on Pascal draft related with that.

 Thanks,

 Ines


 ---------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08822.html

 From: "Pascal Thubert (pthubert)" <pthubert at cisco.com>
 Date: Wed, 13 Aug 2014 16:37:27 +0000

 Hi Brian:

 The question to 6MAN is really whether the use that the draft makes of the
 flow label within the RPL domain is acceptable or not. In particular
 Section 1.3 does not force a particular usage of the flow label inside the
 LLN, it simply updates the rules of what is allowed and what is not within
 that domain, knowing that the root will set the label properly towards the
 Internet and reset it from the Internet.

 It is up to ROLL and other external standards adopting the work (ISA100,
 WCI) to decide of its usefulness.

 Cheers,

 Pascal


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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08819.html

 From: Carsten Bormann <cabo at tzi.org>
 Date: Wed, 13 Aug 2014 03:19:12 +0200

 On 13 Aug 2014, at 01:38, Brian E Carpenter <brian.e.carpenter at
 gmail.com> wrote:

 > Can you perhaps clarify the exact question you are asking 6man?

 Well, I’m not Ines, but I’m trying to find out why we are in this peculiar
 position of discussing this draft right now.

 ROLL has a routing protocol that requires some data to be shipped around
 together with IP packets.
 RFC 6553 and 6554 define ways to do this that are consistent with the IP
 architecture.
 Unfortunately, the overhead (signal-to-fluff ratio) is relatively high,
 and in this area of application, that matters.

 Normally, the next step would have been looking at ways to do header
 compression.
 We did talk about compressing ROLL, but with a view to compressing the
 (control plane) ROLL messages, not so much about the (data plane) IP
 packets themselves.  GHC is trying to be a reasonably useful, but also
 reasonably general way to do the control plane messages.

 For the data packets, the flow label (and its now predominant non-use)
 provides an attractive hole in the IPv6 packets to ship around the RFC
 6533 information, but not the RFC 6554 information.
 In 6lo networks, normally RFC 6282 compresses away empty flow labels, but
 it is cheap to put them in, so a flow label really only costs 3 bytes
 (instead of 8 bytes RFC 6553 costs).  The most useful information from RFC
 6553 can be stuffed into 19 bits, as demonstrated by the draft we are
 discussing here.

 RFC 6282 has extension points (GHC uses one of them), but not really
 useful ones for the ROLL data plane.
 So it appears it never occurred to us that the best way to handle these 19
 bits is to actually sidestep RFC 6282, and use the existing extension
 points of RFC 4944.  Until Laurent showed one way of doing this.  I just
 went from there and did a strawman using Laurent’s idea for compressing
 the RFC 6553 option, in a way that is as efficient as (or, in most cases,
 actually more efficient than) using the flow label hole.

 So to me it seems there no longer is a good technical argument to ask 6man
 to liberate the flow label for carrying RFC 6553.
 But that is maybe something that should now be discussed between 6lo and
 ROLL; I don’t think that this is a 6man issue (unless the answer is a
 simple “sure, go ahead, take it, we don’t need it any more anyway�, which
 is not what I have perceived RFC 6437 to say).
 When 6lo and ROLL have generated consensus on the need to do this, we may
 or may not want to go back to 6man and actually pry that flow label hole
 out of your fingers.

 Grüße, Carsten

 -------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08823.html

 From: "Pascal Thubert (pthubert)" <pthubert at cisco.com>
 Date: Wed, 13 Aug 2014 16:48:06 +0000

 Hello Carsten:

 In my view, this work is not competing with 6lo: for the specific value of
 keeping the draft whatever 6lo decides to do:

 - If this draft is not adopted, the flow label from LLN will probably stay
 all zeroes as it is today and the goal of 6437 will not be achieved. There
 is no way a device will waste 20 bits for a random that has no value
 inside the LLN. The text tells the RPL root to set the flow label.

 - If this draft is not adopted, the root of the LLN will have to forward
 the flow label coming from the Internet down to the end destination
 device, deep in the mesh, wasting 20 bits in each frame. These is a waste
 that 6lo compression will not be allowed to legally elide if today we
 decide that we do not allow it. Note: even if the correspondent sets the
 FL to zeroes to help the LLN, there is no way to guarantee that the flow
 label will not be set on the way since that much is lawful.

 - If the draft is not adopted, existing usages in shipping standards that
 incorporate IPv6 will stay borderline/unlawful. E.g. the draft legalizes
 the way ISA100.11a uses the flow label for a stateful flow identification
 within the ISA100 domain.

 - If the draft is not adopted, we have no leverage over WCI that is
 defining the backbone router for ISA100.11a devices. The draft indicates
 that the root should ensure that the flow label is correctly set when
 going outside, which is a minor increment to WCI, if pushed in due time
 with a proper RFC number that demands it.

 The need for this work was agreed at ROLL. We need a better solution than
 available, for application in RPL domains, that are often but not
 necessarily congruent with 6LowPAN domains.

 I'm fully supportive to have a 6lo compression that will improve the
 situation for a 6lowpan network, and at this point we have 3 proposals on
 the table, Laurent's, yours, and mine, which is to have a routing dispatch
 for route-over in parallel to the mesh dispatch that is mesh-under. I do
 hope we create a momentum there and converge. But there is no guarantee.

 All in all, I will not drop something that works now, with running code
 and all, and reached last call status, against the sirens of a compression
 that will not solve the issues above.

 Cheers,

 Pascal

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08826.html

 From: Philip Levis <pal at cs.stanford.edu>
 Date: Wed, 13 Aug 2014 12:07:04 -0700

 On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) <pthubert at
 cisco.com> wrote:

 > If this draft is not adopted, the flow label from LLN will probably stay
 all zeroes as it is today and the goal of 6437 will not be achieved.

 Pascal, I'm trying to reconcile your claim that the goal of 6437 is to
 allow enclosed networks to use the flow label with Brian's statement

 > Actually that's why I don't want to see a formal
 > update to 6437, because the only rational update would be to allow
 > any closed domain to invent its own usage. We had that argument at
 > length during the development of 6437, and decided against it.

 Phil

 --------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08830.html

 From: Brian E Carpenter <brian.e.carpenter at gmail.com>
 Date: Thu, 14 Aug 2014 08:52:56 +1200


 Right. I'm drawing a very subtle line between (a) stating an exception
 to 6437 for this particular usage and (b) opening the door to other
 usages. Since 6man clearly didn't want (b) during the development of
 6437 I think we do need to limit ourselves to (a).

     Brian
 --------------------------
 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08828.html

 From: Philip Levis <pal at cs.stanford.edu>
 Date: Wed, 13 Aug 2014 12:11:48 -0700

 On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) <pthubert at
 cisco.com> wrote:

 > The need for this work was agreed at ROLL. We need a better solution
 than available, for application in RPL domains, that are often but not
 necessarily congruent with 6LowPAN domains.

 This seems to me to be the strong technical argument in favor of the
 draft. While Carsten's approach seems better technically, it only works
 for 6lowpan, and RPL should be independent of the underlying link layer.

 Phil

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08829.html

 From: Ralph Droms <rdroms.ietf at gmail.com>
 Date: Wed, 13 Aug 2014 15:49:45 -0400

 On Aug 13, 2014, at 3:11 PM 8/13/14, Philip Levis <pal at cs.stanford.edu>
 wrote:

 > On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert) <pthubert at
 cisco.com> wrote:
 >
 >> The need for this work was agreed at ROLL. We need a better solution
 than available, for application in RPL domains, that are often but not
 necessarily congruent with 6LowPAN domains.
 >
 > This seems to me to be the strong technical argument in favor of the
 draft. While Carsten's approach seems better technically, it only works
 for 6lowpan, and RPL should be independent of the underlying link layer.

 Could we consider Carsten's approach a compression mechanism for the RPL
 information options, rather than a replacement, thereby allowing a one-to-
 one translation between compressed mode on 6lowpan networks and
 uncompressed mode in other networks?

 - Ralph

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

 Source: http://www.ietf.org/mail-archive/web/roll/current/msg08831.html

 From: Carsten Bormann <cabo at tzi.org>
 Date: Wed, 13 Aug 2014 23:02:30 +0200

 >> This seems to me to be the strong technical argument in favor of the
 draft. While Carsten's approach seems better technically, it only works
 for 6lowpan, and RPL should be independent of the underlying link layer.

 The transport of RPL specific information for data plane packets already
 *is* independent of the underlying link layer, as specified in RFC 6553
 and RFC 6554.  All we are talking about here is an optimization for those
 (for 6553, specifically; actually 6554 is probably the one even more in
 need).

 > Could we consider Carsten's approach a compression mechanism for the RPL
 information options, rather than a replacement, thereby allowing a one-to-
 one translation between compressed mode on 6lowpan networks and
 uncompressed mode in other networks?

 Indeed, that is probably the best way to view this approach.
 (In the next version of the draft, I’ll emphasize this.)

 My assumption here is:
 — Any subnet that could not live with transporting RFC 6553 as is, i.e. 8
 bytes extra compared to the flow label approach (for uncompressed
 packets*), already needs (and, at this point, has) a header compression
 solution for the expansive IPv6 header anyway.
   So adding RFC 6553 compression to that solution is the natural approach.
 — All subnets that can live with the IPv6 header as is, also can live with
 RFC 6553 as is.

 This argument is on a technical level.
 I’m not talking about cognitive dissonance**) here, or political issues.
 If there are important political issues (I have no idea what the
 ISA100/WCI talk is about), they probably need to be brought out in the
 open here.

 Grüße, Carsten

 *) less difference for header-compressed packets, e.g., 5 bytes for 6lo.
 **) http://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf, section
 2.6

-- 
-------------------------------------------------+-------------------------
 Reporter:  mariainesrobles@gmail.com            |       Owner:
     Type:  defect                               |  pthubert@cisco.com
 Priority:  major                                |      Status:  new
Component:  draft-thubert-6man-flow-label-for-   |   Milestone:
  rpl                                            |     Version:
 Severity:  In WG Last Call                      |  Resolution:
 Keywords:                                       |
-------------------------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6man/trac/ticket/8#comment:1>
6man <http://tools.ietf.org/wg/6man/>


From nobody Thu Aug 14 01:54:46 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED4F1A0998; Thu, 14 Aug 2014 01:54:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level: 
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 xLAAeJD6mhC2; Thu, 14 Aug 2014 01:54:37 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D571A0992; Thu, 14 Aug 2014 01:54:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2128; q=dns/txt; s=iport; t=1408006475; x=1409216075; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=o2qoFD+nZJBPHxj/SiAb5gvj8WcUNST3IF9UFp7IZV0=; b=NPiGWTq8Q8JIpmwkYaTow+KZKY9i7nA01f5pqQ3ZWPqWFxSPUPQicHgr +GWL6iWjWg3+R8UdM0FfEnzBb20k9i7RwBfZMsOX9jokp+HvcEDTw5oeB n8XtwBM/gwaSe2CfjaGbAmzFgKSfXiGwA9CHrjGV8b4yzLvpXnmCRjaRn U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnUFAIJ47FOtJA2M/2dsb2JhbABagw1SVwTNYQqHSAGBFRZ3hAMBAQEEAQEBawsMBAIBCA4DBAEBAQodBycLFAkIAgQOBQgTiCcNxXwTBI5+HTEHBoMpgR0FimOGOqAag1xsgUg
X-IronPort-AV: E=Sophos;i="5.01,862,1400025600"; d="scan'208";a="69171339"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-2.cisco.com with ESMTP; 14 Aug 2014 08:54:34 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s7E8sYmP005199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Aug 2014 08:54:34 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Thu, 14 Aug 2014 03:54:33 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Ralph Droms <rdroms.ietf@gmail.com>, "Routing Over Low power and Lossy networks" <roll@ietf.org>
Subject: RE: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPty/HkIDTIP3DQEeJJU36r1KfRZvPyktw
Date: Thu, 14 Aug 2014 08:54:33 +0000
Deferred-Delivery: Thu, 14 Aug 2014 08:54:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D3E1E4@xmb-rcd-x01.cisco.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <E66DB157-B1C2-4BA4-B889-A15A6427DA3E@cs.stanford.edu> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com>
In-Reply-To: <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.22.2]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/oUKu9ZtE8xhuEIuaHICWiGZSwCc
Cc: Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Aug 2014 08:54:43 -0000

Agreed, Ralph.

The work at 6lo would result in a one-to-one equivalence between a compress=
ed and an uncompressed packet, including the case where the packet has a RP=
L option, or a RH. The flow label draft makes equivalent a packet with a 0 =
flow label and a RPL option, and a packet with a flow label set as indicate=
d, so it is effectively another form of compression that is applicable in a=
ny RPL domain, but only compresses the RPL option.

If the 6lo work concludes as an RFC, it should recommend to prefer the 6lo =
way against the flow label way.

Cheers,

Pascal


> -----Original Message-----
> From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Ralph Droms
> Sent: mercredi 13 ao=FBt 2014 21:50
> To: Routing Over Low power and Lossy networks
> Cc: Ines Robles; 6man WG; 6lo@ietf.org WG
> Subject: Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-=
03
>=20
>=20
> On Aug 13, 2014, at 3:11 PM 8/13/14, Philip Levis <pal@cs.stanford.edu>
> wrote:
>=20
> > On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert)
> <pthubert@cisco.com> wrote:
> >
> >> The need for this work was agreed at ROLL. We need a better solution
> than available, for application in RPL domains, that are often but not
> necessarily congruent with 6LowPAN domains.
> >
> > This seems to me to be the strong technical argument in favor of the dr=
aft.
> While Carsten's approach seems better technically, it only works for
> 6lowpan, and RPL should be independent of the underlying link layer.
>=20
> Could we consider Carsten's approach a compression mechanism for the RPL
> information options, rather than a replacement, thereby allowing a one-to=
-
> one translation between compressed mode on 6lowpan networks and
> uncompressed mode in other networks?
>=20
> - Ralph
>=20
> >
> > Phil
> > _______________________________________________
> > Roll mailing list
> > Roll@ietf.org
> > https://www.ietf.org/mailman/listinfo/roll
>=20
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo


From nobody Thu Aug 14 02:05:29 2014
Return-Path: <cabo@tzi.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563751A09AC; Thu, 14 Aug 2014 02:05:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 T-brZBoibDia; Thu, 14 Aug 2014 02:05:26 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 787EA1A09A2; Thu, 14 Aug 2014 02:05:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s7E95FZ0015502; Thu, 14 Aug 2014 11:05:15 +0200 (CEST)
Received: from [192.168.217.145] (p54890314.dip0.t-ipconnect.de [84.137.3.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1A41D858; Thu, 14 Aug 2014 11:05:13 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD842D3E1E4@xmb-rcd-x01.cisco.com>
Date: Thu, 14 Aug 2014 11:05:12 +0200
X-Mao-Original-Outgoing-Id: 429699912.398908-3583409ce4c12fd784d40291f31fbb34
Content-Transfer-Encoding: quoted-printable
Message-Id: <CE11CC16-DEBD-426D-BF52-CEFF927B127A@tzi.org>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <E66DB157-B1C2-4BA4-B889-A15A6427DA3E@cs.stanford.edu> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> <E045AECD98228444A58C61C200AE1BD842D3E1E4@xmb-rcd-x01.cisco.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/54WoQyuv77FHsFGF-uVoz4ndqKU
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Aug 2014 09:05:28 -0000

On 14 Aug 2014, at 10:54, Pascal Thubert (pthubert) <pthubert@cisco.com> =
wrote:

> If the 6lo work concludes as an RFC, it should recommend to prefer the =
6lo way against the flow label way.

It is a bit more complicated.

If both representations of the RFC 6553 information are in use:
A compressor may need to decide whether a flow label present in an =
uncompressed packet is an RFC 3697 flow label or one of these.
A decompressor may need to decide whether the information is to be =
represented in canonical RFC 6553 form or making use of the flow label =
hack.

In any case, I=92m not a big fan of providing two different ways of =
doing the same thing, at different layers.
In particular not in the constrained environment.

I really would like to hear a technical argument why the flow label hack =
is needed.
(Or a political one, if that is the reason.)

Gr=FC=DFe, Carsten


From nobody Thu Aug 14 03:07:20 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B571A09D2; Thu, 14 Aug 2014 03:07:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level: 
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 ENvdtvLcENSR; Thu, 14 Aug 2014 03:07:07 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754E21A09C5; Thu, 14 Aug 2014 03:07:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5263; q=dns/txt; s=iport; t=1408010826; x=1409220426; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RNg38Eg5JNCEkmYIuYcGjF95xx47XC6PnXyV6dBcl/s=; b=MlD09D7fZVpPC0vcoJ+RZXiRPRSg8OeVOokS+mUtHpQQ+Kw429ju/NJs 5+jLr4nOx/5UXkgqhwlRy7/XGYVzL9ZrLr1NmUwLMaT1yuZNONfI6Kdej Ip02orrYUvtX8kS0DPV/ge026jtvauPWiLMgsQ4tU6z1qn72ipJz+/rG/ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnEFAJiJ7FOtJA2B/2dsb2JhbABagw2BKQTVNQGBFRZ3hAMBAQEDAWUUBQcEAgEIDgMEAQEBCgsSBzIUCQgBAQQOBQiIMgjGHReOewEBAR0xBwYEgyWBHQWKY4Y6oBqDXGyBDzk
X-IronPort-AV: E=Sophos;i="5.01,862,1400025600"; d="scan'208";a="347484258"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP; 14 Aug 2014 10:07:05 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7EA74Gq028321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Aug 2014 10:07:04 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 14 Aug 2014 05:07:04 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Carsten Bormann <cabo@tzi.org>
Subject: RE: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoAHkPgwFAAB9osA=
Date: Thu, 14 Aug 2014 10:07:03 +0000
Deferred-Delivery: Thu, 14 Aug 2014 10:06:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D3E3D8@xmb-rcd-x01.cisco.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <E66DB157-B1C2-4BA4-B889-A15A6427DA3E@cs.stanford.edu> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> <E045AECD98228444A58C61C200AE1BD842D3E1E4@xmb-rcd-x01.cisco.com> <CE11CC16-DEBD-426D-BF52-CEFF927B127A@tzi.org>
In-Reply-To: <CE11CC16-DEBD-426D-BF52-CEFF927B127A@tzi.org>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.22.2]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/heCMZuuRPYig_D5Hq-P7GtHEb24
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Aug 2014 10:07:11 -0000

Hello Carsten:

> I really would like to hear a technical argument why the flow label hack =
is needed.

? Then you probably missed most of my mail from yesterday ?
? The sentence is a rhetorical abuse - like "our just cause" as opposed to =
"our cause is just" which can be argued -, and there is no consensus that t=
he flow label technique is a hack ?
=20
Answering both pending mails from you; I'll rephrase, but please give a sec=
ond glance at my previous mail where I made 4 points and you responded to o=
nly one.

In short, a 6lo compression draft will not achieve all the purposes of the =
draft, it will not achieve the same compression, and the use case will not =
be fully congruent.

For instance, the draft is asking 6MAN the right to reset a flow label at t=
he ingress RPL domain. Without this right, a flow label coming from the Int=
ernet will be transported in the RPL domain or (more probably) implementati=
on will voluntarily fail to conform 6437, and elide them regardless. I'd ra=
ther have a realistic rule that sets the expectations right.

We disagree on the argument that both approaches save the same bits and alw=
ays result in frames of a same size is technically incorrect. In the scenar=
io above, the flow label draft saves 20 bits that a 6lo compression cannot =
save without the blessing that is being asked here, and the 6lo approach wi=
ll need signaling bits that are implicit in the flow label, thus consuming =
extra space. OTOH, the 6lo approach could compress the instanceID and save =
bits there - not sure I'd play more with the rank as your version suggests.=
=20

Another disagreement is on your assumption that compression is the only rea=
son for preferring the flow label technique. We have an IOS implementation =
that is not for use in 6LoWPAN networks, and relies on the (stateful) stori=
ng mode. HbH has known issues in classical routers, makes the header chain =
longer and requires silicon processing or punt, so there are reasons not to=
 use it there either. OTOH making a routing decision that takes the flow la=
bel into account is quite natural, this is what load balancers will do at t=
he core. We have prototyped indexing the VRF with the RPL instance in the f=
low label, and it works like a charm.

And even if compression is the reason why the flow label is used, RPL is a =
rather new routing protocol and we do not know what the world will make of =
it. For all I know it may be deployed in RoHC environments to aggregate fem=
tocell traffic for instance. Assuming that the compression will always be 6=
LoWPAN is short sighted.

And there is no "politics", but external SDOs that base their work on our R=
FCs and that we need to treat with all respect. Facts:
- ISA100.11a ships with IPv6, 6LoWPAN, and an IPv6 flow label that is a sta=
teful indicator of the flow (called a contract ID). We need to be clear on =
how we position this WRT 6437 now that we shipped it. The draft makes that =
legal, as long as we extend the RPL domain to an ISA100 domain as well.
- We can promote behaviors in WCI (e.g. reset the flow label to something v=
aluable to the Internet at large at the backbone router) but then we need t=
o document them in an RFC that they can reference.

I agree that multiple techniques is not a good idea, mostly in LLNs. Sadly =
the HbH is already there, uncompressed, and implemented in shipping devices=
. So the argument would stall the situation and we cannot have that. What I=
'd rather do is have the 6lo proposal converge the format with the FL, so t=
he logic to parse is common. Finding it in the packet is not the complex pi=
ece anyway.

If we still disagree then we can talk one-to-one, the lists are probably ov=
erwhelmed with this thread, and come back when we reach an agreement. We ca=
n also talk about the compression logic if you like. I can setup a webex.

Cheers,

Pascal


> -----Original Message-----
> From: Carsten Bormann [mailto:cabo@tzi.org]
> Sent: jeudi 14 ao=FBt 2014 11:05
> To: Pascal Thubert (pthubert)
> Cc: Ralph Droms; Routing Over Low power and Lossy networks; Ines Robles;
> 6man WG; 6lo@ietf.org WG
> Subject: Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-=
03
>=20
> On 14 Aug 2014, at 10:54, Pascal Thubert (pthubert) <pthubert@cisco.com>
> wrote:
>=20
> > If the 6lo work concludes as an RFC, it should recommend to prefer the =
6lo
> way against the flow label way.
>=20
> It is a bit more complicated.
>=20
> If both representations of the RFC 6553 information are in use:
> A compressor may need to decide whether a flow label present in an
> uncompressed packet is an RFC 3697 flow label or one of these.
> A decompressor may need to decide whether the information is to be
> represented in canonical RFC 6553 form or making use of the flow label ha=
ck.
>=20
> In any case, I'm not a big fan of providing two different ways of doing t=
he
> same thing, at different layers.
> In particular not in the constrained environment.
>=20
> I really would like to hear a technical argument why the flow label hack =
is
> needed.
> (Or a political one, if that is the reason.)
>=20
> Gr=FC=DFe, Carsten


From nobody Thu Aug 14 03:28:46 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2751A09D8; Thu, 14 Aug 2014 03:28:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level: 
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 EZhHvnS92bwD; Thu, 14 Aug 2014 03:28:38 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398731A09DD; Thu, 14 Aug 2014 03:28:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2399; q=dns/txt; s=iport; t=1408012119; x=1409221719; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ahv4vpnJwd2RZZY9mMG7UR9qhvvqEfk+ovHeJ+Z5LJk=; b=JSfKgqPzp78VOHSQ33/WthxsHZdQroiHy4LkhlFRStxrEaTPElHU5aFD jhrtxq9pl769z8ehLF8ewuK+6kYpVg+Za2Fh8QRAU8Ym6waChjQKyrd1l MtE71P4j8iJDoT1P9Bf3gAcoaYkS9XX4qngdHaeDJl2EbUzD8uqF1IlZM U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnUFAE6O7FOtJV2R/2dsb2JhbABaDoJ/UlcEzWMKh0gBgRUWd4QDAQEBBAEBAWQHCwwEAgEIEQQBAQEKHQcnCxQJCAIEAQ0FCIg6DcYWEwSOaQwJHTEHBoMpgR0FhhCEU4Y6oBqDGkJsgQdB
X-IronPort-AV: E=Sophos;i="5.01,862,1400025600"; d="scan'208";a="347488279"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP; 14 Aug 2014 10:28:38 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7EASbLu024628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Aug 2014 10:28:37 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Thu, 14 Aug 2014 05:28:37 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Philip Levis <pal@cs.stanford.edu>
Subject: RE: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPtyoH9NpmEOvPPUCuS34Wv0nHR5vPVpsAgACNI8A=
Date: Thu, 14 Aug 2014 10:28:36 +0000
Deferred-Delivery: Thu, 14 Aug 2014 10:28:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D3E4EF@xmb-rcd-x01.cisco.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu> <53EBD028.30302@gmail.com>
In-Reply-To: <53EBD028.30302@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.22.2]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/I0JMEN1UNVwEV8U7STKZVylgdIw
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Aug 2014 10:28:44 -0000

We can live with this Brian,=20

but then I can we add at least an ISA100.11a network? ISA100.11a was design=
ed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow label to ind=
icate which flow a packet belongs to. In more details, devices are provisio=
ned with per-flow behavior (including routing) and settings in what is call=
ed a contract. The contractID is carried in the IPv6 flow label.

If so should we name ISA100 specifically or use a more vague description li=
ke a "RPL or similar LLN domain"=20
We'll note that resetting an flow label that comes from the Internet is a g=
eneric need is that flow label was set according to 6437, cannot be trusted=
 to be untempered with,=20

Cheers,

Pascal


> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpenter
> Sent: mercredi 13 ao=FBt 2014 22:53
> To: Philip Levis
> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man WG;
> 6lo@ietf.org WG
> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-=
03
>=20
> On 14/08/2014 07:07, Philip Levis wrote:
> > On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert)
> <pthubert@cisco.com> wrote:
> >
> >> If this draft is not adopted, the flow label from LLN will probably st=
ay all
> zeroes as it is today and the goal of 6437 will not be achieved.
> >
> > Pascal, I'm trying to reconcile your claim that the goal of 6437 is to
> > allow enclosed networks to use the flow label with Brian's statement
> >
> >> Actually that's why I don't want to see a formal update to 6437,
> >> because the only rational update would be to allow any closed domain
> >> to invent its own usage. We had that argument at length during the
> >> development of 6437, and decided against it.
> >
> > Phil
>=20
> Right. I'm drawing a very subtle line between (a) stating an exception to=
 6437
> for this particular usage and (b) opening the door to other usages. Since
> 6man clearly didn't want (b) during the development of
> 6437 I think we do need to limit ourselves to (a).
>=20
>     Brian
>=20
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Thu Aug 14 04:29:43 2014
Return-Path: <cabo@tzi.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46891A0A76; Thu, 14 Aug 2014 04:29:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 OyFTuiGtKncu; Thu, 14 Aug 2014 04:29:35 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2826B1A0A7E; Thu, 14 Aug 2014 04:29:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s7EBTNRL026812; Thu, 14 Aug 2014 13:29:23 +0200 (CEST)
Received: from [192.168.217.145] (p54890314.dip0.t-ipconnect.de [84.137.3.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 098D9952; Thu, 14 Aug 2014 13:29:21 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD842D3E3D8@xmb-rcd-x01.cisco.com>
Date: Thu, 14 Aug 2014 13:29:20 +0200
X-Mao-Original-Outgoing-Id: 429708560.40719-59d134129f8d411f3519afd44c8fa26e
Content-Transfer-Encoding: quoted-printable
Message-Id: <9051878F-04DC-4FAD-BE53-056826FD1070@tzi.org>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <E66DB157-B1C2-4BA4-B889-A15A6427DA3E@cs.stanford.edu> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> <E045AECD98228444A58C61C200AE1BD842D3E1E4@xmb-rcd-x01.cisco.com> <CE11CC16-DEBD-426D-BF52-CEFF927B127A@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3E3D8@xmb-rcd-x01.cisco.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/iCvT4ZuKlaWV20prhOrX0r4K5MM
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Aug 2014 11:29:37 -0000

>> I really would like to hear a technical argument why the flow label =
hack is needed.
>=20
> ? Then you probably missed most of my mail from yesterday ?
> ? The sentence is a rhetorical abuse - like "our just cause" as =
opposed to "our cause is just" which can be argued -, and there is no =
consensus that the flow label technique is a hack ?

Oh, OK, I was using this as a technical term.  The Internet works =
because of a set of hacks piled on hacks.
Generally, most people would agree that an instance of =93there are some =
bits that aren=92t used very much =97 lets put our stuff there=94 is a =
hack.
But we don=92t need consensus on that word, in particular if you =
perceive it as pejorative.

> For instance, the draft is asking 6MAN the right to reset a flow label =
at the ingress RPL domain. Without this right, a flow label coming from =
the Internet will be transported in the RPL domain or (more probably) =
implementation will voluntarily fail to conform 6437, and elide them =
regardless. I'd rather have a realistic rule that sets the expectations =
right.

OK.  That is a completely different thing.
I certainly would support a =93license to drop=94 draft that says =93a =
highly constrained network can discard the information in flow labels=94.
(Maybe with some more context.  Just as RFC 6282 allows discarding UDP =
checksums in certain well-defined cases.)

But that is not an argument at all for storing anything different in =
those 20 bits.

> Another disagreement is on your assumption that compression is the =
only reason for preferring the flow label technique. We have an IOS =
implementation that is not for use in 6LoWPAN networks, and relies on =
the (stateful) storing mode. HbH has known issues in classical routers, =
makes the header chain longer and requires silicon processing or punt, =
so there are reasons not to use it there either. OTOH making a routing =
decision that takes the flow label into account is quite natural, this =
is what load balancers will do at the core. We have prototyped indexing =
the VRF with the RPL instance in the flow label, and it works like a =
charm.

Now it gets interesting.
I have another draft whose main content could be summarized as =
=93hop-by-hop options don=92t seem to work, now what=94.
So why did we do RFC 6553?  That was a big mistake, no?
We need to do the things hop-by-hop options were defined for, for a =
number of purposes. =20
This is not being helped by usurping the last free 20 bits in the header =
for one, and only one, of those purposes.

> And even if compression is the reason why the flow label is used, RPL =
is a rather new routing protocol and we do not know what the world will =
make of it. For all I know it may be deployed in RoHC environments to =
aggregate femtocell traffic for instance. Assuming that the compression =
will always be 6LoWPAN is short sighted.

Since ROHC is all about flows, it indeed is very good in completely =
compressing away static flow labels.
ROHC also is very good in completely compressing away static extension =
headers.
I haven=92t done the math, but I don=92t see a winning argument here.
In any case, my argument was that the header compression scheme should =
handle this, and, either way, ROHC already does!

More importantly, if RPL becomes applicable outside the constrained =
environment, the arguments that are being made about the requirements of =
(stubby) constrained environments no longer apply.

In any case: YAGNI.

> And there is no "politics", but external SDOs that base their work on =
our RFCs and that we need to treat with all respect. Facts:
> - ISA100.11a ships with IPv6, 6LoWPAN, and an IPv6 flow label that is =
a stateful indicator of the flow (called a contract ID). We need to be =
clear on how we position this WRT 6437 now that we shipped it. The draft =
makes that legal, as long as we extend the RPL domain to an ISA100 =
domain as well.

I don=92t know that a ISA100.11a contract ID is compatible with the =
proposed flow-label encoding of RFC 6553.
But support for this usage could go with =93license to drop=94 into a =
draft about constrained node network usage of flow labels.
(In any case, draft-thubert-6man-flow-label-for-rpl-04.txt does nothing =
here; it mentions ISA100.11a only in the introduction.)

> - We can promote behaviors in WCI (e.g. reset the flow label to =
something valuable to the Internet at large at the backbone router) but =
then we need to document them in an RFC that they can reference.

That seems to be the above argument about =93license to drop", which is =
again completely independent from the desire to compress RFC 6553.

                                  .oOo.

I won=92t continue belaboring this on the three mailing lists here.
(One reason being that I=92m going on vacation.)

My main point for 6man was that going down the =93let=92s appropriate =
the flow label for this=94 route is not at all inevitable.
(There also are some good contributions from this discussion for the =
ongoing quest for a good, deployable use for flow labels.)

For 6lo, the observation is that there is a place for header compression =
beyond RFC 6282, and that it is easy to get even better compression for =
RFC 6553 in the RFC 4944 framework.

For ROLL, my advice would be to take another look at RFC 6554, and see =
how that would be compressed in a 6lo context.  Most importantly, is =
there really a need for the =93segments left" construction, or can the =
waypoints be discarded once visited.

Gr=FC=DFe, Carsten


From nobody Thu Aug 14 05:21:22 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE591A0ACF; Thu, 14 Aug 2014 05:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level: 
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 BCpVDEJcFvZL; Thu, 14 Aug 2014 05:21:05 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11801A0AC7; Thu, 14 Aug 2014 05:21:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6875; q=dns/txt; s=iport; t=1408018865; x=1409228465; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=j9xz9IDcJFCDSTaYyIfwrmgYQi4KQS4IDBzikfTQYL8=; b=Ob/ubk/oFYYcrIf7coF15xkoS0h9ZVrFoNftMqkhWwsitAFqaiIIDOZ1 w/aJS+dTMhHUf8HObRnCssHLBCMhyzpRs2WwAykRDfkW5WK2dAbqqaOKx rHv+Vb1vMAHFFT5qrj6fMqcdR6j1VMD8J9Cag2LUXBNxh+fi/CgAA1rbC U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnEFAAep7FOtJV2U/2dsb2JhbABagw2BKQTVNQGBFhZ3hAMBAQEEZQkLDAQCAQgOAwQBAQsLEgcyFAkIAQEEDgUIiDrGHxeOfh0xBwYEgyWBHQWKY4Y6oBqDXGyBSA
X-IronPort-AV: E=Sophos;i="5.01,863,1400025600"; d="scan'208";a="347493019"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP; 14 Aug 2014 12:21:04 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7ECL4kx008236 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Aug 2014 12:21:04 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Thu, 14 Aug 2014 07:21:03 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Carsten Bormann <cabo@tzi.org>
Subject: RE: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: Ac+wDejPSf6MzwEzQpSdG5woHqaOoAHpRpGMAAFvTaA=
Date: Thu, 14 Aug 2014 12:20:54 +0000
Deferred-Delivery: Thu, 14 Aug 2014 12:20:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D3E864@xmb-rcd-x01.cisco.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <E66DB157-B1C2-4BA4-B889-A15A6427DA3E@cs.stanford.edu> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> <E045AECD98228444A58C61C200AE1BD842D3E1E4@xmb-rcd-x01.cisco.com> <CE11CC16-DEBD-426D-BF52-CEFF927B127A@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3E3D8@xmb-rcd-x01.cisco.com> <9051878F-04DC-4FAD-BE53-056826FD1070@tzi.org>
In-Reply-To: <9051878F-04DC-4FAD-BE53-056826FD1070@tzi.org>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.22.2]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/JqNsQPzeEBzG-g1J1OMjuXlmOaE
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Aug 2014 12:21:09 -0000

And my conclusion to 6MAN is that the changes of rules that are requested i=
n the draft are useful whether or not people are willing to use the flow la=
bel as the transport for the RPL option inside the RPL domain. Since this i=
s the question on the table for 6MAN, I think that the answer is now clearl=
y a yes.
 =20
Left will be the conclusion on whether the use of the flow label to carry t=
he RPL option is a good idea or not. I guess the answer belongs to ROLL and=
 the last call there.
If Carsten's arguments prevail, I can extract the 6553 compression from the=
 draft to keep the new rules separate from the particular usage of transpor=
ting 6553 flow information.=20

Cheers,

Pascal


> -----Original Message-----
> From: Carsten Bormann [mailto:cabo@tzi.org]
> Sent: jeudi 14 ao=FBt 2014 13:29
> To: Pascal Thubert (pthubert)
> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man WG;
> 6lo@ietf.org WG
> Subject: Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-=
03
>=20
> >> I really would like to hear a technical argument why the flow label ha=
ck is
> needed.
> >
> > ? Then you probably missed most of my mail from yesterday ?
> > ? The sentence is a rhetorical abuse - like "our just cause" as opposed=
 to
> "our cause is just" which can be argued -, and there is no consensus that=
 the
> flow label technique is a hack ?
>=20
> Oh, OK, I was using this as a technical term.  The Internet works because=
 of a
> set of hacks piled on hacks.
> Generally, most people would agree that an instance of "there are some bi=
ts
> that aren't used very much - lets put our stuff there" is a hack.
> But we don't need consensus on that word, in particular if you perceive i=
t as
> pejorative.
>=20
> > For instance, the draft is asking 6MAN the right to reset a flow label =
at the
> ingress RPL domain. Without this right, a flow label coming from the Inte=
rnet
> will be transported in the RPL domain or (more probably) implementation
> will voluntarily fail to conform 6437, and elide them regardless. I'd rat=
her
> have a realistic rule that sets the expectations right.
>=20
> OK.  That is a completely different thing.
> I certainly would support a "license to drop" draft that says "a highly
> constrained network can discard the information in flow labels".
> (Maybe with some more context.  Just as RFC 6282 allows discarding UDP
> checksums in certain well-defined cases.)
>=20
> But that is not an argument at all for storing anything different in thos=
e 20
> bits.
>=20
> > Another disagreement is on your assumption that compression is the only
> reason for preferring the flow label technique. We have an IOS
> implementation that is not for use in 6LoWPAN networks, and relies on the
> (stateful) storing mode. HbH has known issues in classical routers, makes=
 the
> header chain longer and requires silicon processing or punt, so there are
> reasons not to use it there either. OTOH making a routing decision that t=
akes
> the flow label into account is quite natural, this is what load balancers=
 will
> do at the core. We have prototyped indexing the VRF with the RPL instance
> in the flow label, and it works like a charm.
>=20
> Now it gets interesting.
> I have another draft whose main content could be summarized as "hop-by-
> hop options don't seem to work, now what".
> So why did we do RFC 6553?  That was a big mistake, no?
> We need to do the things hop-by-hop options were defined for, for a
> number of purposes.
> This is not being helped by usurping the last free 20 bits in the header =
for
> one, and only one, of those purposes.
>=20
> > And even if compression is the reason why the flow label is used, RPL i=
s a
> rather new routing protocol and we do not know what the world will make
> of it. For all I know it may be deployed in RoHC environments to aggregat=
e
> femtocell traffic for instance. Assuming that the compression will always=
 be
> 6LoWPAN is short sighted.
>=20
> Since ROHC is all about flows, it indeed is very good in completely
> compressing away static flow labels.
> ROHC also is very good in completely compressing away static extension
> headers.
> I haven't done the math, but I don't see a winning argument here.
> In any case, my argument was that the header compression scheme should
> handle this, and, either way, ROHC already does!
>=20
> More importantly, if RPL becomes applicable outside the constrained
> environment, the arguments that are being made about the requirements of
> (stubby) constrained environments no longer apply.
>=20
> In any case: YAGNI.
>=20
> > And there is no "politics", but external SDOs that base their work on o=
ur
> RFCs and that we need to treat with all respect. Facts:
> > - ISA100.11a ships with IPv6, 6LoWPAN, and an IPv6 flow label that is a
> stateful indicator of the flow (called a contract ID). We need to be clea=
r on
> how we position this WRT 6437 now that we shipped it. The draft makes
> that legal, as long as we extend the RPL domain to an ISA100 domain as we=
ll.
>=20
> I don't know that a ISA100.11a contract ID is compatible with the propose=
d
> flow-label encoding of RFC 6553.
> But support for this usage could go with "license to drop" into a draft a=
bout
> constrained node network usage of flow labels.
> (In any case, draft-thubert-6man-flow-label-for-rpl-04.txt does nothing h=
ere;
> it mentions ISA100.11a only in the introduction.)
>=20
> > - We can promote behaviors in WCI (e.g. reset the flow label to somethi=
ng
> valuable to the Internet at large at the backbone router) but then we nee=
d
> to document them in an RFC that they can reference.
>=20
> That seems to be the above argument about "license to drop", which is
> again completely independent from the desire to compress RFC 6553.
>=20
>                                   .oOo.
>=20
> I won't continue belaboring this on the three mailing lists here.
> (One reason being that I'm going on vacation.)
>=20
> My main point for 6man was that going down the "let's appropriate the flo=
w
> label for this" route is not at all inevitable.
> (There also are some good contributions from this discussion for the ongo=
ing
> quest for a good, deployable use for flow labels.)
>=20
> For 6lo, the observation is that there is a place for header compression
> beyond RFC 6282, and that it is easy to get even better compression for R=
FC
> 6553 in the RFC 4944 framework.
>=20
> For ROLL, my advice would be to take another look at RFC 6554, and see ho=
w
> that would be compressed in a 6lo context.  Most importantly, is there re=
ally
> a need for the "segments left" construction, or can the waypoints be
> discarded once visited.
>=20
> Gr=FC=DFe, Carsten


From nobody Thu Aug 14 07:17:07 2014
Return-Path: <mcr@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1FF1A0BEC; Thu, 14 Aug 2014 07:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level: 
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
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 dil1YK_kDMY4; Thu, 14 Aug 2014 07:16:54 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9963F1A0B7E; Thu, 14 Aug 2014 07:16:54 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A815C20012; Thu, 14 Aug 2014 10:19:49 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 0A9A863AC9; Thu, 14 Aug 2014 10:16:52 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EB08E638D6; Thu, 14 Aug 2014 10:16:52 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Carsten Bormann <cabo@tzi.org>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
In-Reply-To: <C95BA1B7-A7B7-43BD-8E23-8FFDB2DD79ED@tzi.org>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <C95BA1B7-A7B7-43BD-8E23-8FFDB2DD79ED@tzi.org>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Thu, 14 Aug 2014 10:16:52 -0400
Message-ID: <17279.1408025812@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/r7Cxt7rGo9886z8fyn0tXTNcD2g
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Aug 2014 14:17:00 -0000

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


Carsten Bormann <cabo@tzi.org> wrote:
    > Again, the straw man at
    > http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-00 saves the sa=
me
    > number of bytes.  Actually, for common cases, it enables one addition=
al
    > optimization (saving one more byte) that is not available with the fl=
ow
    > label hack.  (On the other hand, due to the way RFC 6282 works, the
    > flow label hack saves one byte where both it and ECN are in use and t=
he
    > common case does not apply.)

I read it, but I didn't understand it.
Is this something that fits into the 6lowpan adaptation header?

    > The disadvantage of the RPL mesh header is that this approach is not
    > available outside 6lo networks (i.e., networks employing adaptation
    > layers that use RFC 6282).  I=E2=80=99m not aware yet of a use case w=
here that
    > is a problem.

    > In either encoding (RPL mesh header or flow label), it is probably a
    > good idea anyway to unpack the compressed information back into the R=
PL
    > IPv6 option when leaving the 6lo networks.

A good point, I think.

=2D-
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBU+zE0oCLcPvd0N1lAQK22wgAmPGDjbFmvz/Mbql8qkA/kP99CXWh9DfW
9/VYNn9ZQP0o/XE2BeaEJInwKlYqNvxvKY3S4ixd4FRB5Bb29zdhwEZ9RSYh3ZAl
k6TgIT4FJVlR0l1m/b4JTLGHc10PgjRH5jH0FNC/TS2MsDQF/phGDzQVp8E2AruU
NfSURltlHCCMmn32xfCjqsXmH7GNjDgcnGyijyBHHr+WhjSRJdwaFZ5VRBmlhST1
NU812ozZGUWOqMXp1Wn6nfV48WvRZw/evPErmFqXSuvJxQ0BdraJQRUy8+B9Wvdj
M+v1fVNOwLlMY2FxIOOxfM/Z7zLWTA4c7RSgW22ijvCG5wBQOlTjOQ==
=UE9H
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Thu Aug 14 07:34:05 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A20C1A019C for <ipv6@ietfa.amsl.com>; Thu, 14 Aug 2014 07:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 9TklgVHxHl4s for <ipv6@ietfa.amsl.com>; Thu, 14 Aug 2014 07:34:01 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13DB1A0198 for <6man@ietf.org>; Thu, 14 Aug 2014 07:34:00 -0700 (PDT)
Received: from [2001:1291:2e6:1:284d:5f51:bffa:b9ab] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XHw6I-0008PM-Bj; Thu, 14 Aug 2014 16:33:58 +0200
Message-ID: <53ECC8CB.8010604@si6networks.com>
Date: Thu, 14 Aug 2014 10:33:47 -0400
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "6man@ietf.org" <6man@ietf.org>
Subject: Fwd: New I-D: IPv6 Extension Headers in the Real World
References: <53E44C55.9020306@si6networks.com>
In-Reply-To: <53E44C55.9020306@si6networks.com>
X-Forwarded-Message-Id: <53E44C55.9020306@si6networks.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/EVba2J0wJFQcNuEMrXWhTp39ZJA
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Aug 2014 14:34:03 -0000

Folks,

FYI. Discussion is meant to happen on the v6ops mailing-list... but I
thought this I-D might nevertheless be of your interest..

Thanks!
Fernando




-------- Forwarded Message --------
Subject: New I-D: IPv6 Extension Headers in the Real World
Date: Fri, 08 Aug 2014 00:04:37 -0400
From: Fernando Gont <fgont@si6networks.com>
To: IPv6 Operations <v6ops@ietf.org>

Folks,

We have published a new I-D on the topic of IPv6 Extension Headers
(EHs). The I-D is available at:
<http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt>.

Abstract:
   IPv6 Extension Headers allow for the extension of the IPv6 protocol,
   and provide support for some core functionality such as IPv6
   fragmentation.  However, IPv6 Extension Headers are deemed to present
   a challenge to IPv6 implementations and networks, and are known to be
   intentionally filtered in some existing IPv6 deployments.  This
   summarizes the issues associated with IPv6 extension headers, and
   presents real-world data regarding the extent to which packets with
   IPv6 extension headers are filtered in the public Internet, and where
   in the network such filtering occurs.  Additionally, it provides some
   guidance to operators in troubleshooting IPv6 blackholes resulting
   from the use of IPv6 extension headers.  Finally, this document
   provides some advice to protocol designers, and discusses areas where
   further work might be needed.

Comments and suggestions are welcome.

Thanks!

Best regards,
Fernando




-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt
Date: Thu, 07 Aug 2014 20:57:17 -0700
From: internet-drafts@ietf.org
To: J. Linkova <furry@google.com>, Shucheng LIU (Will)
<liushucheng@huawei.com>, Tim Chown <tjc@ecs.soton.ac.uk>, Tim Chown
<tjc@ecs.soton.ac.uk>, Fernando Gont <fgont@si6networks.com>, Fernando
Gont <fgont@si6networks.com>, Will (Shucheng) Liu
<liushucheng@huawei.com>, J. Linkova <furry@google.com>


A new version of I-D, draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-v6ops-ipv6-ehs-in-real-world
Revision:	00
Title:		IPv6 Extension Headers in the Real World
Document date:	2014-08-07
Group:		Individual Submission
Pages:		15
URL:
http://www.ietf.org/internet-drafts/draft-gont-v6ops-ipv6-ehs-in-real-world-00.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-in-real-world/
Htmlized:
http://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-in-real-world-00


Abstract:
   IPv6 Extension Headers allow for the extension of the IPv6 protocol,
   and provide support for some core functionality such as IPv6
   fragmentation.  However, IPv6 Extension Headers are deemed to present
   a challenge to IPv6 implementations and networks, and are known to be
   intentionally filtered in some existing IPv6 deployments.  This
   summarizes the issues associated with IPv6 extension headers, and
   presents real-world data regarding the extent to which packets with
   IPv6 extension headers are filtered in the public Internet, and where
   in the network such filtering occurs.  Additionally, it provides some
   guidance to operators in troubleshooting IPv6 blackholes resulting
   from the use of IPv6 extension headers.  Finally, this document
   provides some advice to protocol designers, and discusses areas where
   further work might be needed.





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

The IETF Secretariat







From nobody Thu Aug 14 07:44:46 2014
Return-Path: <cabo@tzi.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB13B1A02DE; Thu, 14 Aug 2014 07:44:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 tIZJv_XQxYv6; Thu, 14 Aug 2014 07:44:44 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C8A01A019C; Thu, 14 Aug 2014 07:44:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s7EEiX31029395; Thu, 14 Aug 2014 16:44:34 +0200 (CEST)
Received: from [192.168.217.106] (p54890314.dip0.t-ipconnect.de [84.137.3.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id BE3E0ABC; Thu, 14 Aug 2014 16:44:32 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <17279.1408025812@sandelman.ca>
Date: Thu, 14 Aug 2014 16:44:31 +0200
X-Mao-Original-Outgoing-Id: 429720271.234956-2fc503f092895771aedbebfc3f6f0f15
Content-Transfer-Encoding: quoted-printable
Message-Id: <137E1FA2-4AFB-4E1F-99CC-84724C2D6B52@tzi.org>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <C95BA1B7-A7B7-43BD-8E23-8FFDB2DD79ED@tzi.org> <17279.1408025812@sandelman.ca>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/4hXxBduMliL8NundErErlLVebV0
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Aug 2014 14:44:45 -0000

> Is this something that fits into the 6lowpan adaptation header?

Yes.
The idea is that, instead of sending a dispatch [RFC4944 term] of =
011X.XXXX with an RFC 6282 header followed by the hop-by-hop extension =
header containing an RFC 6553 option, you send
0100.01S0, one (S=3D0) or two bytes (S=3D1) of RPL information, and then =
the RFC 6282 header with the 011 replaced by the ORF bits, followed by =
what would be behind the hop-by-hop extension header.
Similar for the frag1 header (0100.01S1 then).

Since RFC 4944 and RFC 6282 are now being used by quite a few adaptation =
layers, I collectively refer to them as =936lo=94.
So this will immediately be applicable to BTLE, Z-Wave, DECT ULE, =
6lobac, 1901.2, NFC, etc.

Gr=FC=DFe, Carsten


From nobody Thu Aug 14 13:00:30 2014
Return-Path: <cabo@tzi.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818CC1A872C; Thu, 14 Aug 2014 12:59:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 vJdMNgB57_VP; Thu, 14 Aug 2014 12:59:57 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76B71A871D; Thu, 14 Aug 2014 12:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s7EJxncx014254; Thu, 14 Aug 2014 21:59:49 +0200 (CEST)
Received: from [192.168.217.106] (p54890314.dip0.t-ipconnect.de [84.137.3.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 716A1C80; Thu, 14 Aug 2014 21:59:48 +0200 (CEST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: RPL Information Header for 6lo (Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03)
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <9051878F-04DC-4FAD-BE53-056826FD1070@tzi.org>
Date: Thu, 14 Aug 2014 21:59:46 +0200
X-Mao-Original-Outgoing-Id: 429739186.592732-927ac8edb4da6dc164db0ac516b644ba
Content-Transfer-Encoding: quoted-printable
Message-Id: <9322723A-842E-4C10-BFB7-63C88A968169@tzi.org>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <E66DB157-B1C2-4BA4-B889-A15A6427DA3E@cs.stanford.edu> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> <E045AECD98228444A58C61C200AE1BD842D3E1E4@xmb-rcd-x01.cisco.com> <CE11CC16-DEBD-426D-BF52-CEFF927B127A@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3E3D8@xmb-rcd-x01.cisco.com> <9051878F-04DC-4FAD-BE53-056826FD1070@tzi.org>
To: "6lo@ietf.org WG" <6lo@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/ko-AQJq5PME9Kz_L61txN5iIgfE
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Aug 2014 20:00:00 -0000

I have updated the RPL Information Header draft (new title, old draft =
name*):
Thank you all for a lot of helpful input.

Htmlized:       http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-01
Diff:           =
http://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-6lo-rpl-mesh-01

This now contains a lot more discussion and background information about =
what it is trying to do.
(There are no technical changes from the Aug 01 version -00, but there =
is a second page describing it in more detail.)

This draft is both intended as a response to the WGLC referenced in the =
subject and as a proposal to the 6lo working group to pick this up as a =
working group item.  (Clearly, if we do this, we=92ll want lots of input =
from ROLL whether we are doing the right thing, while it is 6lo=92s job =
to do the thing right.  No changes to the IP architecture are required, =
so there is no need to bother 6man with this work.)

Heads up: I=92ll have limited E-Mail access Aug 16 to Sep 3.

Gr=FC=DFe, Carsten

*) There is always so much confusion when a draft name is changed and =
the numbering starts at -00 again.
We can choose a better draft name for draft-ietf-6lo-___, if and when we =
get there=85


From nobody Thu Aug 14 13:18:25 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262311A0669; Thu, 14 Aug 2014 13:18:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 PKmL3VfYHoGq; Thu, 14 Aug 2014 13:18:22 -0700 (PDT)
Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8461A04F6; Thu, 14 Aug 2014 13:18:22 -0700 (PDT)
Received: by mail-pa0-f49.google.com with SMTP id hz1so2236839pad.22 for <multiple recipients>; Thu, 14 Aug 2014 13:18:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oZoafNr5dvMw+i6ytj/Ldm3HhBEb5Zcr1opC1Ez7pfw=; b=ncoSvn899pm2PK6RNT26mZKDvWoQQH2LSE9O5UPuhLQneQ/CW4YerHrZFF8ZwkqojR i8Dro0IwginHdzkTEcCurL1PoPQcQnTbUI+rBli7jRNy7EhDpnhhAhdbP0XSwLtJNdn/ wRfq5khxLpX2tNlZAi0I0rrFuoAfBIjftC3jUEAh0vj0nyCB7cbz0JiAXUMBGh2HAZJg GlgqHcDFkDzXbH0nDe9R/Kh/cC9noo0eHFW572mZLneMasiDjWtb0dOTqQ87PnOG8iGl sfCXeCL8UgU7NKH+R2WylljqnUaXcuOrlPu7RMA8o+YVpXVeYpd3W2vTVKG5brMpWx5s ADoQ==
X-Received: by 10.66.236.161 with SMTP id uv1mr6579078pac.85.1408047501951; Thu, 14 Aug 2014 13:18:21 -0700 (PDT)
Received: from [192.168.178.23] (254.198.69.111.dynamic.snap.net.nz. [111.69.198.254]) by mx.google.com with ESMTPSA id tu10sm6145136pbc.43.2014.08.14.13.18.18 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Aug 2014 13:18:21 -0700 (PDT)
Message-ID: <53ED1992.1010708@gmail.com>
Date: Fri, 15 Aug 2014 08:18:26 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu> <53EBD028.30302@gmail.com> <E045AECD98228444A58C61C200AE1BD842D3E4EF@xmb-rcd-x01.cisco.com>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD842D3E4EF@xmb-rcd-x01.cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/guZyMeemWA7kU6AgPyp3XFlwX_o
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Aug 2014 20:18:24 -0000

On 14/08/2014 22:28, Pascal Thubert (pthubert) wrote:
> We can live with this Brian,=20
>=20
> but then I can we add at least an ISA100.11a network? ISA100.11a was de=
signed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow label =
to indicate which flow a packet belongs to.=20

I have no idea what ISA100.11a is or which organisation developed
it, but it sounds like a violation of the flow label standard at that
time (RFC 3697). If I'd known about it, we would probably have included
it in the menagerie of RFC 6294.

There's not much the IETF can do about other organisations that
misuse our standards, although indeed we sometimes need to
document such cases.

   Brian


In more details, devices are provisioned with per-flow behavior (includin=
g routing) and settings in what is called a contract.
The contractID is carried in the IPv6 flow label.
>=20
> If so should we name ISA100 specifically or use a more vague descriptio=
n like a "RPL or similar LLN domain"=20
> We'll note that resetting an flow label that comes from the Internet is=
 a generic need is that flow label was set according to 6437, cannot be t=
rusted to be untempered with,=20
>=20
> Cheers,
>=20
> Pascal
>=20
>=20
>> -----Original Message-----
>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpent=
er
>> Sent: mercredi 13 ao=C3=BBt 2014 22:53
>> To: Philip Levis
>> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man WG;
>> 6lo@ietf.org WG
>> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-r=
pl-03
>>
>> On 14/08/2014 07:07, Philip Levis wrote:
>>> On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert)
>> <pthubert@cisco.com> wrote:
>>>> If this draft is not adopted, the flow label from LLN will probably =
stay all
>> zeroes as it is today and the goal of 6437 will not be achieved.
>>> Pascal, I'm trying to reconcile your claim that the goal of 6437 is t=
o
>>> allow enclosed networks to use the flow label with Brian's statement
>>>
>>>> Actually that's why I don't want to see a formal update to 6437,
>>>> because the only rational update would be to allow any closed domain=

>>>> to invent its own usage. We had that argument at length during the
>>>> development of 6437, and decided against it.
>>> Phil
>> Right. I'm drawing a very subtle line between (a) stating an exception=
 to 6437
>> for this particular usage and (b) opening the door to other usages. Si=
nce
>> 6man clearly didn't want (b) during the development of
>> 6437 I think we do need to limit ourselves to (a).
>>
>>     Brian
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>=20


From nobody Thu Aug 14 16:41:17 2014
Return-Path: <nordmark@acm.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480B91A898A for <ipv6@ietfa.amsl.com>; Thu, 14 Aug 2014 16:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=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 9X7JC-NjCvNe for <ipv6@ietfa.amsl.com>; Thu, 14 Aug 2014 16:41:12 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3EC1A8987 for <ipv6@ietf.org>; Thu, 14 Aug 2014 16:41:12 -0700 (PDT)
Received: from [172.22.229.45] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s7ENf4lQ023643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 Aug 2014 16:41:04 -0700
Message-ID: <53ED4910.7040104@acm.org>
Date: Thu, 14 Aug 2014 16:41:04 -0700
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Dmitry Anipko <Dmitry.Anipko@microsoft.com>, Ole Troan <otroan@employees.org>
Subject: Re: draft-ietf-6man-resilient-rs update
References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> <BA7546DE-AD9B-46BA-90DD-6E89836E2A2F@employees.org> <3dfb3ea73b5d450c923198ce06704f5a@SN2PR03MB077.namprd03.prod.outlook.com> <57CD62D4-0D87-4F23-A6AA-0AA9E4EFCD26@employees.org> <7613b4b345e2473fb48ef90e7dc5844f@SN2PR03MB077.namprd03.prod.outlook.com> <F795F34D-AC5F-4DB5-9B99-B7D2EA462839@employees.org> <8c9ccd4087ca4358862e773776bf67b5@SN2PR03MB077.namprd03.prod.outlook.com> <CB21E017-EB8A-449A-9EE9-0346C214DE24@employees.org> <d63acea236f64a22bd51b30cefad37b8@SN2PR03MB077.namprd03.prod.outlook.com>
In-Reply-To: <d63acea236f64a22bd51b30cefad37b8@SN2PR03MB077.namprd03.prod.outlook.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVaz3I1frZPPibeooeG+ZyfZzDe7yo8q5yGUJkVzwEKolsRnO8miHR8gJsNqrmZygl2TTj8MD6AbLJF0/v/+oKR/
X-Sonic-ID: C;5JuadAwk5BG1wt90oK8kYw== M;XnbSdAwk5BG1wt90oK8kYw==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/D9Ps4pu4iaI2B2MgRH6imqimYhE
Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" <draft-ietf-6man-resilient-rs@tools.ietf.org>, 6man WG <ipv6@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Aug 2014 23:41:14 -0000

[Delay in responding due to travel and vacation]

On 7/25/14, 5:21 PM, Dmitry Anipko wrote:
> Let's separate discussions on the substance and on what exact language we put in the draft.
>
> Substance wise - IMO, the change tries to reduce existing fragility of RD in some situations. We had very real real-world support cases with one of the top mobile operators in the US, where the network was not sending new RAs before expiring the info in the initial one. Yes, this was  a misconfiguration / bug on the network side. Yes, this is where it was eventually fixed, and yes perhaps the support teams should not have taken as much time to figure it out. But the end-users don't care about that part, and they would be better off in the meantime if the protocol had more resiliency against misconfiguration or packet loss. Speaking for myself only, this is the scenario I'm concerned about. I'm sure there are others who know the "no multicast RAs, period" scenario better than I do, and they can speak for that.

Dmitry,
I don't understand how we can make the protocol specification more 
robust against the above type of misconfiguration - at least not without 
resulting in a lot more chatty protocol.

For instance, suppose we say that hosts should send unicast a RS every 
10 seconds. That would be quite chatty and would still result in the 
same failures if the operator accidentally configures the router (and/or 
prefix) lifetime to be 5 seconds.
And having the hosts look at the remaining lifetimes and decide to 
unicast (or multicast) RSes closer and closer together as the 
lifetime(s) get closer to expiry might result in an explosion of RS 
messages during a network outage.

    Erik

>
> So I think it would be good to first understand, leaving specific RFC language aside, whether there is consensus to improve RD reliability when the host sees that previously received information has expired / about to expire. My impression from the discussion in London was that there was such consensus - but perhaps I misunderstood. Letting the host do additional rate-limited transmissions to solve that, to me looks like a simple and reasonable approach. If you agree with that, then what's the specific concern on putting that as MAY?
>
> I do disagree with the viewpoint, that because if ND use of multicast is inefficient, let's not make any improvements to ND until multicast issue is solved. Yes, the multicast-related issues in general do need to be addressed over long term. But addressing them will take time, and there are issues today which end-users are hitting, for which incremental limited fixes within existing framework are possible and reasonable.
>
>>> today, links without periodic RAs are not supported.
> Since this is a statement about today, it equally applies (or not applies), to the option 2 you suggested and the option I suggested, so it's not a differentiator. Furthermore, it basically is equivalent to option 1, which makes it not an independent argument, but re-iterating option 1, and can't be used as a differentiator there either.
>
> -----Original Message-----
> From: Ole Troan [mailto:otroan@employees.org]
> Sent: Thursday, July 24, 2014 8:25 PM
> To: Dmitry Anipko
> Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>; draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG
> Subject: Re: draft-ietf-6man-resilient-rs update
>
>>>> wouldn't those hosts initially do router discovery, then not ever send RS again, and would be left without a default router when the router lifetime expired?
>> Assuming there are no other events, such as media state change - correct, and that's the behavior they get today. As I understand it, this MAY is about a specific behavior improvement, compared to the today state, which a vendor may choose to implement.
> today, links without periodic RAs are not supported.
>
> cheers,
> Ole
>
>> -----Original Message-----
>> From: Ole Troan [mailto:otroan@employees.org]
>> Sent: Wednesday, July 23, 2014 8:01 PM
>> To: Dmitry Anipko
>> Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>;
>> draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG
>> Subject: Re: draft-ietf-6man-resilient-rs update
>>
>> Dmitry,
>>
>>>>> what would happen with the hosts that didn't implement the feature on links w/o periodic multicast RAs?
>>> It would not get this particular improvement in behavior compared to the pre-draft state. But since the answer seems to be trivial, I'm not sure I understood the question correctly?
>> wouldn't those hosts initially do router discovery, then not ever send RS again, and would be left without a default router when the router lifetime expired?
>>
>> cheers,
>> Ole
>>
>>
>>>
>>> -----Original Message-----
>>> From: Ole Troan [mailto:otroan@employees.org]
>>> Sent: Tuesday, July 22, 2014 7:15 PM
>>> To: Dmitry Anipko
>>> Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>;
>>> draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG
>>> Subject: Re: draft-ietf-6man-resilient-rs update
>>>
>>> Dmitry,
>>>
>>>> Given the definition of MAY in RFC 2119, why is the wording, which is currently in the text, not an option?
>>>>
>>>> <quote>
>>>> In the
>>>> same vein an implementation which does include a particular option
>>>> MUST be prepared to interoperate with another implementation which
>>>> does not include the option (except, of course, for the feature the
>>>> option provides.) </quote>
>>>>
>>>> Where "the feature" would be e.g. "supporting links w/o periodic multicast RAs"?
>>> what would happen with the hosts that didn't implement the feature on links w/o periodic multicast RAs?
>>>
>>> cheers,
>>> Ole
>>>
>>>> -----Original Message-----
>>>> From: Ole Troan [mailto:otroan@employees.org]
>>>> Sent: Tuesday, July 22, 2014 2:10 PM
>>>> To: Suresh Krishnan
>>>> Cc: Dmitry Anipko; <6man-chairs@tools.ietf.org>;
>>>> draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG
>>>> Subject: Re: draft-ietf-6man-resilient-rs update
>>>>
>>>> Suresh, et al,
>>>>
>>>> to pick up this after my holiday.
>>>>
>>>>>>> My impression from the discussion in London that the consensus was closer to (2) than (1) - that on such links the hosts should be allowed to restart transmissions in a reasonable / rate-limited manner, when connectivity parameters expire. And that we should add MAY text for that.
>>>>>> that's also fine with me. if there was a text proposal it would most likely be easier for the working group to come to a decision.
>>>>>> is that something the authors can take on?
>>>>> In my view, the text in the draft already reflects something akin to what Dmitry was talking about (but not exactly option 2 from your original mail on this thread). This is the relevant text from the draft.
>>>>> Hosts MAY continue retransmitting the RSs even after router discovery is successful.  If the host continues to retransmit RSs, it is RECOMMENDED that such retransmissions be rate-limited to one every MRT.
>>>> the current text states: hosts SHOULD stop, but MAY continue.
>>>> on a link where there are no periodic multicast RA, then all the hosts that doesn't implement the MAY will fail after the initial Router lifetime seconds.
>>>>
>>>> to me it appears we have two options.
>>>> 1) only solve the initial connection case.
>>>> remove any mention of links without periodic RAs (remove the last sentence of the abstract, and bullet 1b.).
>>>>   possibly remove the MAY in the "SHOULD stop, but MAY continue"
>>>>   advance the document to the IESG
>>>> 2) take the document back to the WG and solve the problems that Erik outlined in his mail.
>>>>
>>>> cheers,
>>>> Ole
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


From nobody Thu Aug 14 17:03:01 2014
Return-Path: <nordmark@acm.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A701A899D for <ipv6@ietfa.amsl.com>; Thu, 14 Aug 2014 17:03:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=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 UNcHUwelDX-d for <ipv6@ietfa.amsl.com>; Thu, 14 Aug 2014 17:02:58 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF721A899C for <ipv6@ietf.org>; Thu, 14 Aug 2014 17:02:57 -0700 (PDT)
Received: from [172.22.229.45] ([162.210.130.3]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s7F01nRW008182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 Aug 2014 17:01:49 -0700
Message-ID: <53ED4DED.8030608@acm.org>
Date: Thu, 14 Aug 2014 17:01:49 -0700
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ole Troan <otroan@employees.org>, Dmitry Anipko <Dmitry.Anipko@microsoft.com>
Subject: Re: draft-ietf-6man-resilient-rs update
References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> <BA7546DE-AD9B-46BA-90DD-6E89836E2A2F@employees.org> <3dfb3ea73b5d450c923198ce06704f5a@SN2PR03MB077.namprd03.prod.outlook.com> <57CD62D4-0D87-4F23-A6AA-0AA9E4EFCD26@employees.org> <7613b4b345e2473fb48ef90e7dc5844f@SN2PR03MB077.namprd03.prod.outlook.com> <F795F34D-AC5F-4DB5-9B99-B7D2EA462839@employees.org> <8c9ccd4087ca4358862e773776bf67b5@SN2PR03MB077.namprd03.prod.outlook.com> <CB21E017-EB8A-449A-9EE9-0346C214DE24@employees.org> <d63acea236f64a22bd51b30cefad37b8@SN2PR03MB077.namprd03.prod.outlook.com> <004AD154-0D65-4F7F-A198-61382562550A@employees.org>
In-Reply-To: <004AD154-0D65-4F7F-A198-61382562550A@employees.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVZEG548s3suTfvuPlKKVWK0c+GgbsBIE25Apr0uboJWdq12OXAACgWCaYTmuL454MWa5ELz1bTeP7ZO9F+zILIH
X-Sonic-ID: C;YoSqWg8k5BGqUN90oK8kYw== M;bum7Wg8k5BGqUN90oK8kYw==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/jpIT-7DvE7_D0eN-IxcxN2P5Yxw
Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" <draft-ietf-6man-resilient-rs@tools.ietf.org>, 6man WG <ipv6@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Aug 2014 00:03:00 -0000

On 7/29/14, 1:48 AM, Ole Troan wrote:
>> Let's separate discussions on the substance and on what exact language we put in the draft.
>>
>> Substance wise - IMO, the change tries to reduce existing fragility of RD in some situations. We had very real real-world support cases with one of the top mobile operators in the US, where the network was not sending new RAs before expiring the info in the initial one. Yes, this was  a misconfiguration / bug on the network side. Yes, this is where it was eventually fixed, and yes perhaps the support teams should not have taken as much time to figure it out. But the end-users don't care about that part, and they would be better off in the meantime if the protocol had more resiliency against misconfiguration or packet loss. Speaking for myself only, this is the scenario I'm concerned about. I'm sure there are others who know the "no multicast RAs, period" scenario better than I do, and they can speak for that.
>>
>> So I think it would be good to first understand, leaving specific RFC language aside, whether there is consensus to improve RD reliability when the host sees that previously received information has expired / about to expire. My impression from the discussion in London was that there was such consensus - but perhaps I misunderstood. Letting the host do additional rate-limited transmissions to solve that, to me looks like a simple and reasonable approach. If you agree with that, then what's the specific concern on putting that as MAY?
> I do agree with that. the specific concern with the MAY, is that we'll end up with inconsistent behaviour on the link. I'd much rather that we specified behaviour in detail.
>
>> I do disagree with the viewpoint, that because if ND use of multicast is inefficient, let's not make any improvements to ND until multicast issue is solved. Yes, the multicast-related issues in general do need to be addressed over long term. But addressing them will take time, and there are issues today which end-users are hitting, for which incremental limited fixes within existing framework are possible and reasonable.
> I think the argument made is that the issues are somewhat tangled together.
>
>>>> today, links without periodic RAs are not supported.
>> Since this is a statement about today, it equally applies (or not applies), to the option 2 you suggested and the option I suggested, so it's not a differentiator. Furthermore, it basically is equivalent to option 1, which makes it not an independent argument, but re-iterating option 1, and can't be used as a differentiator there either.
> if you made RD more resilient against packet loss, then you may end up solving the "no periodic multicast" case as a side effect.
>
> so for the question of what to do with the resilient RS draft. there seems to be at least three problems:
> 1) the initial connection problem
> 2) not robust enough in case of packet drop / what to do when (last) router lifetime expires / last address expires

I thought Dmitry's case was different - not sufficiently robust against 
misconfiguration.
That sounds more like and implementation and operational issue and not a 
protocol issue.

The default values in RFC 4861 makes the periodic multicast RAs robust 
against packet loss by having the router lifetime be 3x times the 
advertisement interval. And on lossy links the routers can be configured 
with a higher ratio.

When the periodic multicast works there isn't an issue when the last 
router lifetime or address expires; that would only happen when either 
the connectivity was completely lost (i.e. packet loss large relative to 
the above chosen ratio), or the administrator intended to expire a 
router and/or a prefix.
Doing something extra in that case seems counterproductive.
Thus I don't think there is a #2 problem.

> 3) links without periodic RAs

I think the line should include "multicast".

There are links where periodic multicast RAs can be used, but are quite 
resource intensive. Not only the wifi links we've talked about but also 
for cellular networks where paging etc considerations come into play. 
(E.g.,


  draft-garneij-6man-nd-m2m-issues-00


)



> solving 2 may inadvertently solve 3.
>
> before posing the questions to the working group, let's agree on the questions.
> can we ask the working group to choose between the following two options:
> i) only solve problem 1 in the resilient-rs draft. which implies remove text about no periodic RAs
> ii) solve both problem 1 and 2. which implies taking the document back to the working group

While I don't think the problem 2 exists in any interesting and useful 
form, I think the choices for the WG are as you specified.
FWIW I'd be willing to work on the problem, whether the WG wants to hold 
back resilent-rs or put this in a separate document.

Regards,
    Erik

>
> cheers,
> Ole
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


From nobody Thu Aug 14 17:13:29 2014
Return-Path: <Dmitry.Anipko@microsoft.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42B01A89B8 for <ipv6@ietfa.amsl.com>; Thu, 14 Aug 2014 17:13:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 X1NHlmNlciWr for <ipv6@ietfa.amsl.com>; Thu, 14 Aug 2014 17:13:24 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0182.outbound.protection.outlook.com [207.46.163.182]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88FFB1A0451 for <ipv6@ietf.org>; Thu, 14 Aug 2014 17:13:24 -0700 (PDT)
Received: from BLUPR03MB066.namprd03.prod.outlook.com (10.255.209.154) by BLUPR03MB066.namprd03.prod.outlook.com (10.255.209.154) with Microsoft SMTP Server (TLS) id 15.0.1010.11; Fri, 15 Aug 2014 00:13:21 +0000
Received: from BLUPR03MB066.namprd03.prod.outlook.com ([169.254.10.115]) by BLUPR03MB066.namprd03.prod.outlook.com ([169.254.10.79]) with mapi id 15.00.1010.011; Fri, 15 Aug 2014 00:13:21 +0000
From: Dmitry Anipko <Dmitry.Anipko@microsoft.com>
To: Erik Nordmark <nordmark@acm.org>, Ole Troan <otroan@employees.org>
Subject: RE: draft-ietf-6man-resilient-rs update
Thread-Topic: draft-ietf-6man-resilient-rs update
Thread-Index: AQHPi7cqsEyuayzG7U2u4m7hjIGf2Zt4m40ygAFYPwCAAJnFgIAyPXiAgABHBZCAAA48gIABC23QgACT74CAAW614IAAKiQAgAFZbSCAH2kSAIAAB51A
Date: Fri, 15 Aug 2014 00:13:21 +0000
Message-ID: <9c69785532244f2aa3db4d752f384b9c@BLUPR03MB066.namprd03.prod.outlook.com>
References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> <BA7546DE-AD9B-46BA-90DD-6E89836E2A2F@employees.org> <3dfb3ea73b5d450c923198ce06704f5a@SN2PR03MB077.namprd03.prod.outlook.com> <57CD62D4-0D87-4F23-A6AA-0AA9E4EFCD26@employees.org> <7613b4b345e2473fb48ef90e7dc5844f@SN2PR03MB077.namprd03.prod.outlook.com> <F795F34D-AC5F-4DB5-9B99-B7D2EA462839@employees.org> <8c9ccd4087ca4358862e773776bf67b5@SN2PR03MB077.namprd03.prod.outlook.com> <CB21E017-EB8A-449A-9EE9-0346C214DE24@employees.org> <d63acea236f64a22bd51b30cefad37b8@SN2PR03MB077.namprd03.prod.outlook.com> <53ED4910.7040104@acm.org>
In-Reply-To: <53ED4910.7040104@acm.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ed31::3]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;
x-forefront-prvs: 0304E36CA3
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(13464003)(51704005)(24454002)(199003)(479174003)(189002)(377454003)(15202345003)(81542001)(105586002)(54356999)(76482001)(93886004)(19580405001)(83072002)(79102001)(108616004)(99396002)(85852003)(106356001)(4396001)(107046002)(2656002)(80022001)(87936001)(77982001)(15975445006)(50986999)(83322001)(106116001)(76176999)(92566001)(19580395003)(81342001)(74316001)(31966008)(64706001)(21056001)(74662001)(20776003)(99286002)(76576001)(561944003)(74502001)(101416001)(95666004)(86362001)(33646002)(77096002)(46102001)(85306004)(86612001)(24736002)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB066; H:BLUPR03MB066.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/XA6Z9thxnhfIbd1Yq9Z_zv6Y1zU
Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" <draft-ietf-6man-resilient-rs@tools.ietf.org>, 6man WG <ipv6@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Aug 2014 00:13:27 -0000

Hi Erik,

After some offline discussion, here is the adjustment of the text we'd like=
 to propose. Please let me know if this sufficiently mitigates your concern=
.

Replace the first paragraph of the section 2.1 of http://tools.ietf.org/id/=
draft-ietf-6man-resilient-rs-03.txt  with the following:

<text>
On multicast-capable links, the hosts following this specification=20
SHOULD stop retransmitting the RSs when Router Discovery is successful=20
(i.e. an RA with a non-zero Router Lifetime that results in a default=20
route is received).

When and if all of the following conditions are met:
1. The host received an RA with non-zero Router Lifetime since the=20
last attachment of the interface to the link, and has not received=20
later an RA with zero Router Lifetime from the same router.
2. Less than N seconds (where N is randomly chosen by the host at the=20
interface initialization time to be IRT < N <=3D 2*IRT) remain till the=20
expiration of all of the known default routers on the interface.

the host MAY re-start sending of the RSs following the Proposed=20
algorithm, described in the section 2.
</text>

-Dmitry


-----Original Message-----
From: Erik Nordmark [mailto:nordmark@acm.org]=20
Sent: Thursday, August 14, 2014 4:41 PM
To: Dmitry Anipko; Ole Troan
Cc: <6man-chairs@tools.ietf.org>; draft-ietf-6man-resilient-rs@tools.ietf.o=
rg; 6man WG; Suresh Krishnan
Subject: Re: draft-ietf-6man-resilient-rs update


[Delay in responding due to travel and vacation]

On 7/25/14, 5:21 PM, Dmitry Anipko wrote:
> Let's separate discussions on the substance and on what exact language we=
 put in the draft.
>
> Substance wise - IMO, the change tries to reduce existing fragility of RD=
 in some situations. We had very real real-world support cases with one of =
the top mobile operators in the US, where the network was not sending new R=
As before expiring the info in the initial one. Yes, this was  a misconfigu=
ration / bug on the network side. Yes, this is where it was eventually fixe=
d, and yes perhaps the support teams should not have taken as much time to =
figure it out. But the end-users don't care about that part, and they would=
 be better off in the meantime if the protocol had more resiliency against =
misconfiguration or packet loss. Speaking for myself only, this is the scen=
ario I'm concerned about. I'm sure there are others who know the "no multic=
ast RAs, period" scenario better than I do, and they can speak for that.

Dmitry,
I don't understand how we can make the protocol specification more robust a=
gainst the above type of misconfiguration - at least not without resulting =
in a lot more chatty protocol.

For instance, suppose we say that hosts should send unicast a RS every
10 seconds. That would be quite chatty and would still result in the same f=
ailures if the operator accidentally configures the router (and/or
prefix) lifetime to be 5 seconds.
And having the hosts look at the remaining lifetimes and decide to unicast =
(or multicast) RSes closer and closer together as the
lifetime(s) get closer to expiry might result in an explosion of RS message=
s during a network outage.

    Erik

>
> So I think it would be good to first understand, leaving specific RFC lan=
guage aside, whether there is consensus to improve RD reliability when the =
host sees that previously received information has expired / about to expir=
e. My impression from the discussion in London was that there was such cons=
ensus - but perhaps I misunderstood. Letting the host do additional rate-li=
mited transmissions to solve that, to me looks like a simple and reasonable=
 approach. If you agree with that, then what's the specific concern on putt=
ing that as MAY?
>
> I do disagree with the viewpoint, that because if ND use of multicast is =
inefficient, let's not make any improvements to ND until multicast issue is=
 solved. Yes, the multicast-related issues in general do need to be address=
ed over long term. But addressing them will take time, and there are issues=
 today which end-users are hitting, for which incremental limited fixes wit=
hin existing framework are possible and reasonable.
>
>>> today, links without periodic RAs are not supported.
> Since this is a statement about today, it equally applies (or not applies=
), to the option 2 you suggested and the option I suggested, so it's not a =
differentiator. Furthermore, it basically is equivalent to option 1, which =
makes it not an independent argument, but re-iterating option 1, and can't =
be used as a differentiator there either.
>
> -----Original Message-----
> From: Ole Troan [mailto:otroan@employees.org]
> Sent: Thursday, July 24, 2014 8:25 PM
> To: Dmitry Anipko
> Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>;=20
> draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG
> Subject: Re: draft-ietf-6man-resilient-rs update
>
>>>> wouldn't those hosts initially do router discovery, then not ever send=
 RS again, and would be left without a default router when the router lifet=
ime expired?
>> Assuming there are no other events, such as media state change - correct=
, and that's the behavior they get today. As I understand it, this MAY is a=
bout a specific behavior improvement, compared to the today state, which a =
vendor may choose to implement.
> today, links without periodic RAs are not supported.
>
> cheers,
> Ole
>
>> -----Original Message-----
>> From: Ole Troan [mailto:otroan@employees.org]
>> Sent: Wednesday, July 23, 2014 8:01 PM
>> To: Dmitry Anipko
>> Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>;=20
>> draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG
>> Subject: Re: draft-ietf-6man-resilient-rs update
>>
>> Dmitry,
>>
>>>>> what would happen with the hosts that didn't implement the feature on=
 links w/o periodic multicast RAs?
>>> It would not get this particular improvement in behavior compared to th=
e pre-draft state. But since the answer seems to be trivial, I'm not sure I=
 understood the question correctly?
>> wouldn't those hosts initially do router discovery, then not ever send R=
S again, and would be left without a default router when the router lifetim=
e expired?
>>
>> cheers,
>> Ole
>>
>>
>>>
>>> -----Original Message-----
>>> From: Ole Troan [mailto:otroan@employees.org]
>>> Sent: Tuesday, July 22, 2014 7:15 PM
>>> To: Dmitry Anipko
>>> Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>;=20
>>> draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG
>>> Subject: Re: draft-ietf-6man-resilient-rs update
>>>
>>> Dmitry,
>>>
>>>> Given the definition of MAY in RFC 2119, why is the wording, which is =
currently in the text, not an option?
>>>>
>>>> <quote>
>>>> In the
>>>> same vein an implementation which does include a particular option=20
>>>> MUST be prepared to interoperate with another implementation which=20
>>>> does not include the option (except, of course, for the feature the=20
>>>> option provides.) </quote>
>>>>
>>>> Where "the feature" would be e.g. "supporting links w/o periodic multi=
cast RAs"?
>>> what would happen with the hosts that didn't implement the feature on l=
inks w/o periodic multicast RAs?
>>>
>>> cheers,
>>> Ole
>>>
>>>> -----Original Message-----
>>>> From: Ole Troan [mailto:otroan@employees.org]
>>>> Sent: Tuesday, July 22, 2014 2:10 PM
>>>> To: Suresh Krishnan
>>>> Cc: Dmitry Anipko; <6man-chairs@tools.ietf.org>;=20
>>>> draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG
>>>> Subject: Re: draft-ietf-6man-resilient-rs update
>>>>
>>>> Suresh, et al,
>>>>
>>>> to pick up this after my holiday.
>>>>
>>>>>>> My impression from the discussion in London that the consensus was =
closer to (2) than (1) - that on such links the hosts should be allowed to =
restart transmissions in a reasonable / rate-limited manner, when connectiv=
ity parameters expire. And that we should add MAY text for that.
>>>>>> that's also fine with me. if there was a text proposal it would most=
 likely be easier for the working group to come to a decision.
>>>>>> is that something the authors can take on?
>>>>> In my view, the text in the draft already reflects something akin to =
what Dmitry was talking about (but not exactly option 2 from your original =
mail on this thread). This is the relevant text from the draft.
>>>>> Hosts MAY continue retransmitting the RSs even after router discovery=
 is successful.  If the host continues to retransmit RSs, it is RECOMMENDED=
 that such retransmissions be rate-limited to one every MRT.
>>>> the current text states: hosts SHOULD stop, but MAY continue.
>>>> on a link where there are no periodic multicast RA, then all the hosts=
 that doesn't implement the MAY will fail after the initial Router lifetime=
 seconds.
>>>>
>>>> to me it appears we have two options.
>>>> 1) only solve the initial connection case.
>>>> remove any mention of links without periodic RAs (remove the last sent=
ence of the abstract, and bullet 1b.).
>>>>   possibly remove the MAY in the "SHOULD stop, but MAY continue"
>>>>   advance the document to the IESG
>>>> 2) take the document back to the WG and solve the problems that Erik o=
utlined in his mail.
>>>>
>>>> cheers,
>>>> Ole
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


From nobody Fri Aug 15 01:51:46 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29E61A0938; Fri, 15 Aug 2014 01:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level: 
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 0El0Jofa6nt7; Fri, 15 Aug 2014 01:51:41 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFDAF1A0947; Fri, 15 Aug 2014 01:51:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4113; q=dns/txt; s=iport; t=1408092702; x=1409302302; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=l0bGHmFOQ7yQlw6ygVPdSPJFxNrIukv8yy1k0sa7bsQ=; b=G1UrsprkK5DZId/2xK5xshpVa1kBqjLDvu3Qeemvm7RGWy20Fni9GuJr s2hk9tIdag28X3FlF172taLB+cqrRY/1EVO6nBEnav1oDsLKbHLoiW6NO C/Kp3Cjd3FOKQFvIJH020Qkzabcldqvg+96UgSWvxkNu0Fyw8JwFVAG5N g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApEFABLJ7VOtJA2G/2dsb2JhbABZgw1TV81/CodJAYETFneEAwEBAQMBAQEBZAcLBQcEAgEIEQQBAQEnByEGCxQJCAIEDgWILgMJCA2+VQ2FNxMEjR+BSgwJGzMHBoMpgR0FhhCEU4Y6iQ6CD45LhjODXGyBB4FIAQEB
X-IronPort-AV: E=Sophos;i="5.01,868,1400025600"; d="scan'208";a="69490934"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-3.cisco.com with ESMTP; 15 Aug 2014 08:51:41 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7F8peDS011648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Aug 2014 08:51:40 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Fri, 15 Aug 2014 03:51:39 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPt/zmHp7q4q9DoEKOFDPz7vG+hJvRXEca
Date: Fri, 15 Aug 2014 08:51:38 +0000
Message-ID: <755F123A-A93F-4146-BD4C-4022CD8CE13E@cisco.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu> <53EBD028.30302@gmail.com> <E045AECD98228444A58C61C200AE1BD842D3E4EF@xmb-rcd-x01.cisco.com>, <53ED1992.1010708@gmail.com>
In-Reply-To: <53ED1992.1010708@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/bpkBdCfKAtLCMyBRe-K8vwYebVk
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Aug 2014 08:51:44 -0000

Hello Brian

I do not think that ISA10011.a violates RFC 3697. What exactly made you bel=
ieve so?

For all I know ISA100 does everything by the book. Note that ISA100 does no=
t update a non zero FL on the fly since it is not set by a source outside t=
he LLN if that is your concern.

OTOH It may violate RFC 6437 in that the flow is not a random but a value a=
ttributed by a PCE called system manager (along rules in section 4). As thi=
ngs stand, we'd certainly want the backbone router at LLN egress to rewrite=
 the FL in packets towards the Internet with a randomized per flow value.

It will violate RFC 6437 because if the flow label is set by a router in th=
e Internet - or an updated source that complies to 6437-, the backbone rout=
er at LLN Ingress will rewrite it.

Both issues are addressed in my draft for a RPL domain. An RFC will also hi=
nt a revision of the backbone router that it should rewrite the FL on outgo=
ing packets.

What do you think?

Pascal

> Le 14 ao=FBt 2014 =E0 22:18, "Brian E Carpenter" <brian.e.carpenter@gmail=
.com> a =E9crit :
>=20
>> On 14/08/2014 22:28, Pascal Thubert (pthubert) wrote:
>> We can live with this Brian,=20
>>=20
>> but then I can we add at least an ISA100.11a network? ISA100.11a was des=
igned in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow label to =
indicate which flow a packet belongs to.
>=20
> I have no idea what ISA100.11a is or which organisation developed
> it, but it sounds like a violation of the flow label standard at that
> time (RFC 3697). If I'd known about it, we would probably have included
> it in the menagerie of RFC 6294.
>=20
> There's not much the IETF can do about other organisations that
> misuse our standards, although indeed we sometimes need to
> document such cases.
>=20
>   Brian
>=20
>=20
> In more details, devices are provisioned with per-flow behavior (includin=
g routing) and settings in what is called a contract.
> The contractID is carried in the IPv6 flow label.
>>=20
>> If so should we name ISA100 specifically or use a more vague description=
 like a "RPL or similar LLN domain"=20
>> We'll note that resetting an flow label that comes from the Internet is =
a generic need is that flow label was set according to 6437, cannot be trus=
ted to be untempered with,=20
>>=20
>> Cheers,
>>=20
>> Pascal
>>=20
>>=20
>>> -----Original Message-----
>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpente=
r
>>> Sent: mercredi 13 ao=FBt 2014 22:53
>>> To: Philip Levis
>>> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man WG;
>>> 6lo@ietf.org WG
>>> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rp=
l-03
>>>=20
>>>> On 14/08/2014 07:07, Philip Levis wrote:
>>>> On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert)
>>> <pthubert@cisco.com> wrote:
>>>>> If this draft is not adopted, the flow label from LLN will probably s=
tay all
>>> zeroes as it is today and the goal of 6437 will not be achieved.
>>>> Pascal, I'm trying to reconcile your claim that the goal of 6437 is to
>>>> allow enclosed networks to use the flow label with Brian's statement
>>>>=20
>>>>> Actually that's why I don't want to see a formal update to 6437,
>>>>> because the only rational update would be to allow any closed domain
>>>>> to invent its own usage. We had that argument at length during the
>>>>> development of 6437, and decided against it.
>>>> Phil
>>> Right. I'm drawing a very subtle line between (a) stating an exception =
to 6437
>>> for this particular usage and (b) opening the door to other usages. Sin=
ce
>>> 6man clearly didn't want (b) during the development of
>>> 6437 I think we do need to limit ourselves to (a).
>>>=20
>>>    Brian
>>>=20
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>=20


From nobody Fri Aug 15 12:49:54 2014
Return-Path: <v6ops@globis.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958C01A0406; Fri, 15 Aug 2014 12:49:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.67
X-Spam-Level: 
X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
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 oS3lrnMJ7-Uq; Fri, 15 Aug 2014 12:49:51 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id AC6861A0404; Fri, 15 Aug 2014 12:49:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 96E8787153A; Fri, 15 Aug 2014 21:49:49 +0200 (CEST)
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL1gd1XAlV1i; Fri, 15 Aug 2014 21:49:49 +0200 (CEST)
Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:b577:54cb:5162:9077]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 3F5F9871519; Fri, 15 Aug 2014 21:49:49 +0200 (CEST)
Message-ID: <53EE6441.1000908@globis.net>
Date: Fri, 15 Aug 2014 21:49:21 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Carsten Bormann <cabo@tzi.org>
Subject: Re: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org>
In-Reply-To: <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/hXFFfrrmkleeqJRbUbL-ufjuoOk
Cc: roll <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Aug 2014 19:49:52 -0000

Carsten Bormann wrote:
> On 01 Aug 2014, at 10:50, Xavier Vilajosana<xvilajosana@eecs.berkeley.edu>  wrote:
>
>> Let's look at what IPHC does at the LBR when a flow label is elided and has to be inflated to be forwarded to the IPv6 network, this standardized behaviour is somehow interfering the end to end notion of the flow label as the content is being populated at the border of the LLN.
>
> No.  With IPHC, the flow label has always been there, it just was transmitted in a very compressed form.
>
> I think the visceral reaction that most of us have in using the flow label as a mesh routing header is that this blurs the layer boundaries.  So much for O, R, F, and rank.  Putting the VLAN (“instance ID�) into the packet is a significantly larger change, because it essentially extends the IP service interface by a VLAN ID.  We normally try to hide IDs of this kind below IP.
>
> Now, I’m not saying any of this new architecture is wrong.  I just think what we need to do is discuss this as the architectural change that it is, not as a simple optimization.  (The need for some kind of optimization of IP-in-IP mesh routing for small-packet IoT applications is pretty obvious to me.)
>
> The other story is that we are retracting RFC 6437 and turning the flow label into the “field you may trample on in your lower layers if you have a good reason�.  Cynically, one could say this is proper payback for designing this field without a compelling purpose and no protocol evolution story attached to it.  So the evolution just eats it.  Teachable moment.
>
> Grüße, Carsten
>
>
+1

Apologies for tardy response (holidays)

After reading the draft it seems to me that what is being attempted is
1) to add some stuff to the IPv6 header that is RPL domain specific
2) to reduce the overall packet length to reduce active radio time and 
thus save energy
by
3) overloading an existing well-defined and used IPv6 header field

My simple logic tells me that
1) could be best solved at an architecture level via an extension header 
http://tools.ietf.org/html/rfc2460#page-11 + 
http://tools.ietf.org/html/rfc7045
2) could be best solved at an architecture level via IP header 
compression http://tools.ietf.org/html/rfc2507.html with or without 
additional tweaks
and that overloading an opaque field in 3) by incorporating values with 
low entropy (as per the RPL flow label) gives additional security risks 
to http://tools.ietf.org/html/rfc7098

So what's wrong with my simple logic?

"But if we consider the whole RPL domain as a large virtual host from 
the standpoint of the rest of the Internet" would suggest to me that the 
cost of stripping out the additional IPv6 hop by hop extension header at 
the edge of the domain is a bogus argument, as you'll anyway have to 
provide some adaption and security at the root of each RPL domain to 
detect and bounce spoofed RPL Information from entering, or private RPL 
Information leaking out of each domain. Whether this domain-specificRPL 
Information is encoded in an explicit hop by hop option or an overloaded 
flow label would seem largely irrelevant to that operation at the RPL 
root (especially since the RPL root anyway has to be a high power node 
to be able communicate with the rest of the Internet).

IMHO If you overload the flow label you're looking at creating an 
incompatible walled garden, with competing IETF standards that are 
mutually exclusive.

-- 
Regards,
RayH


From nobody Fri Aug 15 17:33:42 2014
Return-Path: <pal@cs.stanford.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2F41A08FD; Fri, 15 Aug 2014 17:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.268
X-Spam-Level: 
X-Spam-Status: No, score=-4.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham
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 SB6vNeuh8FL9; Fri, 15 Aug 2014 17:33:39 -0700 (PDT)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E901A08F7; Fri, 15 Aug 2014 17:33:39 -0700 (PDT)
Received: from [76.14.66.110] (port=61003 helo=[192.168.0.106]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XIRw8-0002NS-Bh; Fri, 15 Aug 2014 17:33:37 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <53EE6441.1000908@globis.net>
Date: Fri, 15 Aug 2014 17:33:35 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53EE6441.1000908@globis.net>
To: Ray Hunter <v6ops@globis.net>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: 8e086a056c9d4443aaf3b84243aabc30
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/cAR8462_CGxsakbaE6101gJse3c
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, roll <roll@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Aug 2014 00:33:40 -0000

On Aug 15, 2014, at 12:49 PM, Ray Hunter <v6ops@globis.net> wrote:

> After reading the draft it seems to me that what is being attempted is
> 1) to add some stuff to the IPv6 header that is RPL domain specific
> 2) to reduce the overall packet length to reduce active radio time and =
thus save energy
> by
> 3) overloading an existing well-defined and used IPv6 header field
>=20
> My simple logic tells me that
> 1) could be best solved at an architecture level via an extension =
header http://tools.ietf.org/html/rfc2460#page-11 + =
http://tools.ietf.org/html/rfc7045
> 2) could be best solved at an architecture level via IP header =
compression http://tools.ietf.org/html/rfc2507.html with or without =
additional tweaks
> and that overloading an opaque field in 3) by incorporating values =
with low entropy (as per the RPL flow label) gives additional security =
risks to http://tools.ietf.org/html/rfc7098
>=20
> So what's wrong with my simple logic?

1) There is an extension header already; the problem is that it can =
introduce a significant (ballpark estimates are, in well engineered =
networks, up to 5-10%) cost. The proposal is to replace the extension =
header with using the flow label.

2) There'a already significant IP header compression in the cases we're =
talking about.

Phil=


From nobody Fri Aug 15 17:41:45 2014
Return-Path: <pal@cs.stanford.edu>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FAE1A0911; Fri, 15 Aug 2014 17:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.868
X-Spam-Level: 
X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham
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 5hYcEJA9C8vM; Fri, 15 Aug 2014 17:41:41 -0700 (PDT)
Received: from smtp1.cs.Stanford.EDU (smtp1.cs.Stanford.EDU [171.64.64.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B6B1A0910; Fri, 15 Aug 2014 17:41:41 -0700 (PDT)
Received: from [76.14.66.110] (port=61066 helo=[192.168.0.106]) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <pal@cs.stanford.edu>) id 1XIS3w-0003uj-1t; Fri, 15 Aug 2014 17:41:40 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <53E926EB.9000505@gmail.com>
Date: Fri, 15 Aug 2014 17:41:38 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <200645F3-ACEA-4F88-AD30-35998803FB54@cs.stanford.edu>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1510)
X-Scan-Signature: b64bce576883819501cf77c9371f4538
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/j49Uelh1pOqveN-eA9d55jlzzZc
Cc: "Pascal Thubert \(pthubert\)" <pthubert@cisco.com>, 6man WG <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Aug 2014 00:41:42 -0000

On Aug 11, 2014, at 1:26 PM, Brian E Carpenter =
<brian.e.carpenter@gmail.com> wrote:

> Therefore, treating RPL as a special case is the remaining option.
> But does the ROLL community actually have consensus that they want
> this special case?

I'd argue that if you look at the 15+ so years of work into mesh routing =
on low power and lossy networks, data path validation is a common =
technique to almost every approach. That is, there is absolutely =
consensus in the people engineering these protocols that data packets =
need to carry information about the route so the network can quickly =
discover and adapt to changes in the topology. The reason is that the =
topology can change very quickly, on the order of a few tens to hundreds =
of packets.=20

It turns out that this is very difficult to do efficiently in the IP =
architecture if you have small packets. HbH headers aren't tiny, and =
IP-in-IP encapsulation is significant.

In the broader scope of running IP over LLNs, I think that the ability =
to encode data path information into IPv6 headers without introducing =
significant overhead is critical. I therefore think this special case is =
worth it and important enough. But I also think it's important to very =
explicitly state that it is an additional special case, e.g., through an =
Updates:.

Phil=


From nobody Fri Aug 15 18:12:56 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2488A1A094B; Fri, 15 Aug 2014 18:12:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 FDqmh8Tg_DKh; Fri, 15 Aug 2014 18:12:46 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3351A092E; Fri, 15 Aug 2014 18:12:46 -0700 (PDT)
Received: by mail-pa0-f46.google.com with SMTP id lj1so4335166pab.5 for <multiple recipients>; Fri, 15 Aug 2014 18:12:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=JrIp4y27SDoItWowBuataiu428Kxkk2xVyAlG6WnWlQ=; b=FZ+l5llCpml8eltPQWSP1VkQ2RaKiQNcoInVw2EkJTu7NHh8IX3I4lPdvL9qzGhOEN tFFMV8yxniecy4uX2lIHOi77a9Sx10sciemQ0kJASy02fTQ/kg6F2Hzi0MOI1dNTTfgW nTBO9HT5mSF7hvcDZsboGvGTILEU5RU7bXSe3SBW1AUnHGAq7SyoXsZTfJHrMj+yoUe1 fbeEiESY1e+YAlkFoyTSxvknz1BtuHTTfpKmHUUd9hks5fWdhZtVDZBvvtjCphnxcU7Z raP5nvzq45+tpjkA+2Q6wXmsNPM4ne8cbcT0tbVAgmKhQ8wGBzlQkpZj8Qu9+fH7hjLk zwPA==
X-Received: by 10.70.62.5 with SMTP id u5mr22595483pdr.100.1408151566197; Fri, 15 Aug 2014 18:12:46 -0700 (PDT)
Received: from [192.168.178.23] (7.199.69.111.dynamic.snap.net.nz. [111.69.199.7]) by mx.google.com with ESMTPSA id ss5sm9157837pbc.27.2014.08.15.18.12.43 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Aug 2014 18:12:45 -0700 (PDT)
Message-ID: <53EEB016.4030105@gmail.com>
Date: Sat, 16 Aug 2014 13:12:54 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu> <53EBD028.30302@gmail.com> <E045AECD98228444A58C61C200AE1BD842D3E4EF@xmb-rcd-x01.cisco.com>, <53ED1992.1010708@gmail.com> <755F123A-A93F-4146-BD4C-4022CD8CE13E@cisco.com>
In-Reply-To: <755F123A-A93F-4146-BD4C-4022CD8CE13E@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/IGQMFAA5HSSew-CJYH0bAN6c8QE
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Aug 2014 01:12:48 -0000

On 15/08/2014 20:51, Pascal Thubert (pthubert) wrote:
> Hello Brian
>=20
> I do not think that ISA10011.a violates RFC 3697. What exactly made you=
 believe so?

I was over-interpreting what you wrote, I guess. It's true that 3697 was =
rather
vague about what it called "flow state establishment methods" and permitt=
ed
both sequential and pseudo-random flow label values. Is the ISA10011.a
on line somewhere?

> For all I know ISA100 does everything by the book. Note that ISA100 doe=
s not update a non zero FL on the fly since it is not set by a source out=
side the LLN if that is your concern.
>=20
> OTOH It may violate RFC 6437 in that the flow is not a random but a val=
ue attributed by a PCE called system manager (along rules in section 4). =
As things stand, we'd certainly want the backbone router at LLN egress to=
 rewrite the FL in packets towards the Internet with a randomized per flo=
w value.
>=20
> It will violate RFC 6437 because if the flow label is set by a router i=
n the Internet - or an updated source that complies to 6437-, the backbon=
e router at LLN Ingress will rewrite it.
>=20
> Both issues are addressed in my draft for a RPL domain. An RFC will als=
o hint a revision of the backbone router that it should rewrite the FL on=
 outgoing packets.
>
> What do you think?

I think that Phil's last message frames the question to 6man correctly,
so I will respond to him...

Regards
    Brian
>=20
> Pascal
>=20
>> Le 14 ao=C3=BBt 2014 =C3=A0 22:18, "Brian E Carpenter" <brian.e.carpen=
ter@gmail.com> a =C3=A9crit :
>>
>>> On 14/08/2014 22:28, Pascal Thubert (pthubert) wrote:
>>> We can live with this Brian,=20
>>>
>>> but then I can we add at least an ISA100.11a network? ISA100.11a was =
designed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow labe=
l to indicate which flow a packet belongs to.
>> I have no idea what ISA100.11a is or which organisation developed
>> it, but it sounds like a violation of the flow label standard at that
>> time (RFC 3697). If I'd known about it, we would probably have include=
d
>> it in the menagerie of RFC 6294.
>>
>> There's not much the IETF can do about other organisations that
>> misuse our standards, although indeed we sometimes need to
>> document such cases.
>>
>>   Brian
>>
>>
>> In more details, devices are provisioned with per-flow behavior (inclu=
ding routing) and settings in what is called a contract.
>> The contractID is carried in the IPv6 flow label.
>>> If so should we name ISA100 specifically or use a more vague descript=
ion like a "RPL or similar LLN domain"=20
>>> We'll note that resetting an flow label that comes from the Internet =
is a generic need is that flow label was set according to 6437, cannot be=
 trusted to be untempered with,=20
>>>
>>> Cheers,
>>>
>>> Pascal
>>>
>>>
>>>> -----Original Message-----
>>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E Carpe=
nter
>>>> Sent: mercredi 13 ao=C3=BBt 2014 22:53
>>>> To: Philip Levis
>>>> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man WG;=

>>>> 6lo@ietf.org WG
>>>> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for=
-rpl-03
>>>>
>>>>> On 14/08/2014 07:07, Philip Levis wrote:
>>>>> On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert)
>>>> <pthubert@cisco.com> wrote:
>>>>>> If this draft is not adopted, the flow label from LLN will probabl=
y stay all
>>>> zeroes as it is today and the goal of 6437 will not be achieved.
>>>>> Pascal, I'm trying to reconcile your claim that the goal of 6437 is=
 to
>>>>> allow enclosed networks to use the flow label with Brian's statemen=
t
>>>>>
>>>>>> Actually that's why I don't want to see a formal update to 6437,
>>>>>> because the only rational update would be to allow any closed doma=
in
>>>>>> to invent its own usage. We had that argument at length during the=

>>>>>> development of 6437, and decided against it.
>>>>> Phil
>>>> Right. I'm drawing a very subtle line between (a) stating an excepti=
on to 6437
>>>> for this particular usage and (b) opening the door to other usages. =
Since
>>>> 6man clearly didn't want (b) during the development of
>>>> 6437 I think we do need to limit ourselves to (a).
>>>>
>>>>    Brian
>>>>
>>>> --------------------------------------------------------------------=

>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------=

>=20


From nobody Fri Aug 15 18:21:06 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D76B1A0959; Fri, 15 Aug 2014 18:21:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 5xHOdagvKJen; Fri, 15 Aug 2014 18:21:02 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E95E1A0953; Fri, 15 Aug 2014 18:21:02 -0700 (PDT)
Received: by mail-pa0-f51.google.com with SMTP id ey11so4270332pad.24 for <multiple recipients>; Fri, 15 Aug 2014 18:21:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8JFOC1ieICmhwUeYDHL0ZqqXtOsGSNsBGL+Cnt4sI/U=; b=N1Feyn3iwKQqiBPa4Jzyk89gaaktuP6cSeY4UR/HGwi1Kk3Tzg48QkLpfczYotfi1V nblmXf9fZUcWD+PMrYeE13Ft0nlYPmJIpi9799YayjtZHbWqrQB51O3w5J1TeYxIa3fe 6o/KiEl3oEJ7Qhri4NLlQhAiM//34CfUX3R71TXGng5DUyOJwttw6DKpHBl7H+QE78uv XYslj6el8Zp8wO5oKZhg6zqp4nfDQqAnakDqfYKAa0tXkwyAcBm9mVE62JWCQH+0jrT8 Q3Hslrqqjg5hTCprRmmObFWp0rVNDsujY6h/ACVPbEI45VH8Qj7/OBreXijDOlA8ueBn 3aqQ==
X-Received: by 10.69.17.230 with SMTP id gh6mr16865368pbd.0.1408152062199; Fri, 15 Aug 2014 18:21:02 -0700 (PDT)
Received: from [192.168.178.23] (7.199.69.111.dynamic.snap.net.nz. [111.69.199.7]) by mx.google.com with ESMTPSA id ib5sm9163033pbb.55.2014.08.15.18.20.59 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Aug 2014 18:21:01 -0700 (PDT)
Message-ID: <53EEB205.3040205@gmail.com>
Date: Sat, 16 Aug 2014 13:21:09 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Philip Levis <pal@cs.stanford.edu>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <200645F3-ACEA-4F88-AD30-35998803FB54@cs.stanford.edu>
In-Reply-To: <200645F3-ACEA-4F88-AD30-35998803FB54@cs.stanford.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/8Ia8oDmrVpnmxqhbw9fUAv2Fk8Q
Cc: "Pascal Thubert \(pthubert\)" <pthubert@cisco.com>, 6man WG <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Aug 2014 01:21:04 -0000

On 16/08/2014 12:41, Philip Levis wrote:
> On Aug 11, 2014, at 1:26 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
>> Therefore, treating RPL as a special case is the remaining option.
>> But does the ROLL community actually have consensus that they want
>> this special case?
> 
> I'd argue that if you look at the 15+ so years of work into mesh routing on low power and lossy networks, data path validation is a common technique to almost every approach. That is, there is absolutely consensus in the people engineering these protocols that data packets need to carry information about the route so the network can quickly discover and adapt to changes in the topology. The reason is that the topology can change very quickly, on the order of a few tens to hundreds of packets. 
> 
> It turns out that this is very difficult to do efficiently in the IP architecture if you have small packets. HbH headers aren't tiny, and IP-in-IP encapsulation is significant.
> 
> In the broader scope of running IP over LLNs, I think that the ability to encode data path information into IPv6 headers without introducing significant overhead is critical. I therefore think this special case is worth it and important enough. But I also think it's important to very explicitly state that it is an additional special case, e.g., through an Updates:.

Firstly, I think that captures the 6man question: is this special-case
walled-garden exception to RFC 6437 acceptable? My personal answer is
yes; we're here to make things work, not to enforce dogma.

Secondly, here is my reasoning why a formal Updates: 6437 is *not* needed:

A reader of flow-label-for-rpl needs to read RFC 6437 in order to correctly
understand and implement flow-label-for-rpl. So RFC 6437 is correctly a
normative reference.  However, a reader of RFC 6437 has no need to be aware
of flow-label-for-rpl in order to correctly implement RFC 6437 in any non-RPL
node. So I see no logic in saying that flow-label-for-rpl updates 6437.

    Brian


From nobody Fri Aug 15 18:48:52 2014
Return-Path: <internet-drafts@ietf.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A3C1A09B6; Fri, 15 Aug 2014 18:48:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 gz0Qu7rwSy8f; Fri, 15 Aug 2014 18:48:49 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 736971A09A1; Fri, 15 Aug 2014 18:48:49 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action: draft-ietf-6man-why64-02.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p5
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140816014849.1968.50526.idtracker@ietfa.amsl.com>
Date: Fri, 15 Aug 2014 18:48:49 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/nDtTq-L5-Qj6ddhL3_8t-InfkdY
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Aug 2014 01:48:51 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

        Title           : Analysis of the 64-bit Boundary in IPv6 Addressing
        Authors         : Brian Carpenter
                          Tim Chown
                          Fernando Gont
                          Sheng Jiang
                          Alexandru Petrescu
                          Andrew Yourtchenko
	Filename        : draft-ietf-6man-why64-02.txt
	Pages           : 24
	Date            : 2014-08-15

Abstract:
   The IPv6 unicast addressing format includes a separation between the
   prefix used to route packets to a subnet and the interface identifier
   used to specify a given interface connected to that subnet.
   Currently the interface identifier is defined as 64 bits long for
   almost every case, leaving 64 bits for the subnet prefix.  This
   document describes the advantages of this fixed boundary and analyses
   the issues that would be involved in treating it as a variable
   boundary.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-why64/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-why64-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-why64-02


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

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


From nobody Fri Aug 15 18:50:56 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2371A09CB for <ipv6@ietfa.amsl.com>; Fri, 15 Aug 2014 18:50:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 LspRxqTFXl_a for <ipv6@ietfa.amsl.com>; Fri, 15 Aug 2014 18:50:53 -0700 (PDT)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A711A09C5 for <ipv6@ietf.org>; Fri, 15 Aug 2014 18:50:52 -0700 (PDT)
Received: by mail-pa0-f53.google.com with SMTP id rd3so4398595pab.40 for <ipv6@ietf.org>; Fri, 15 Aug 2014 18:50:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=BGZFNtl+VdBrlRzwaZls/nzEetDqzk8jK4zRzcTCJR0=; b=vwrOjNOteF1foYLZWbvq02XLt63YBpm90vXp2F4nG25EC4dT0L5xI7dP4Yg3kv+3Ml EjKRArKbiWSPnjqY+NsZbkmQKwkPPLSr5rnJH+2SJbskhr4PHuVVYEFSdE3vzqFPHGgk RJnDGlBS8i9jWb92v6ZE5oPLPzXZODRGSde0wCavOD3NG41wCpjyCTIRGN8ji87oec6a TG56rM0spkVgajO16PWuedDytF8xS4bwYPQjY9CluLMsMCpt1nU6QkUIzKKKTCv6a6ri sLOfj9AW4hiRLcO+/t06CyWxKs2oeIYKKZF6AgTRCeO6mDio9+um8oP7dQsX9F4NRIcX 3dSQ==
X-Received: by 10.68.65.9 with SMTP id t9mr17038302pbs.77.1408153852308; Fri, 15 Aug 2014 18:50:52 -0700 (PDT)
Received: from [192.168.178.23] (7.199.69.111.dynamic.snap.net.nz. [111.69.199.7]) by mx.google.com with ESMTPSA id fy1sm13992388pdb.66.2014.08.15.18.50.50 for <ipv6@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Aug 2014 18:50:51 -0700 (PDT)
Message-ID: <53EEB906.20206@gmail.com>
Date: Sat, 16 Aug 2014 13:51:02 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: 6man <ipv6@ietf.org>
Subject: [Fwd: I-D Action: draft-ietf-6man-why64-02.txt]
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/gwi5GGwQ_dSfq22689TVCU4jzWQ
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Aug 2014 01:50:55 -0000

This version is intended to respond to all the WG last call
comments and reviews. Here are the changes:

- numerous editorial improvements
- numerous small technical clarifications
- added reference to HD ratio
- expanded MLD text
- added text on duplicate address issue

Comments welcome.

  Brian + co-authors

-------- Original Message --------
Subject: I-D Action: draft-ietf-6man-why64-02.txt
Date: Fri, 15 Aug 2014 18:48:49 -0700
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
CC: ipv6@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

        Title           : Analysis of the 64-bit Boundary in IPv6 Addressing
        Authors         : Brian Carpenter
                          Tim Chown
                          Fernando Gont
                          Sheng Jiang
                          Alexandru Petrescu
                          Andrew Yourtchenko
	Filename        : draft-ietf-6man-why64-02.txt
	Pages           : 24
	Date            : 2014-08-15

Abstract:
   The IPv6 unicast addressing format includes a separation between the
   prefix used to route packets to a subnet and the interface identifier
   used to specify a given interface connected to that subnet.
   Currently the interface identifier is defined as 64 bits long for
   almost every case, leaving 64 bits for the subnet prefix.  This
   document describes the advantages of this fixed boundary and analyses
   the issues that would be involved in treating it as a variable
   boundary.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-why64/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-why64-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-why64-02


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

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


From nobody Fri Aug 15 23:49:52 2014
Return-Path: <v6ops@globis.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15691A702C; Fri, 15 Aug 2014 23:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.969
X-Spam-Level: 
X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
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 XwfX6C6_oUnF; Fri, 15 Aug 2014 23:49:48 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9995A1A0830; Fri, 15 Aug 2014 23:49:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 9584F87153A; Sat, 16 Aug 2014 08:49:47 +0200 (CEST)
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceeOCizm1C5a; Sat, 16 Aug 2014 08:49:47 +0200 (CEST)
Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:2c3d:d324:45ec:29d7]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 4041C870025; Sat, 16 Aug 2014 08:49:47 +0200 (CEST)
Message-ID: <53EEFEEE.8020505@globis.net>
Date: Sat, 16 Aug 2014 08:49:18 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Philip Levis <pal@cs.stanford.edu>
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53EE6441.1000908@globis.net> <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu>
In-Reply-To: <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/CvpalDzBJmtv82wpsD90dvBnfRI
Cc: "ipv6@ietf.org" <ipv6@ietf.org>, roll <roll@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Aug 2014 06:49:50 -0000

> Philip Levis <mailto:pal@cs.stanford.edu>
> 16 August 2014 02:33
>
> 1) There is an extension header already; the problem is that it can 
> introduce a significant (ballpark estimates are, in well engineered 
> networks, up to 5-10%) cost. The proposal is to replace the extension 
> header with using the flow label.
>
> 2) There'a already significant IP header compression in the cases 
> we're talking about.
>
> Phil

I'm sympathetic to the needs of low power devices.

However, to be clear, we are reengineering a standards track document 
that is around 2 years old (http://tools.ietf.org/html/rfc6553), and 
which works technically, and we are proposing an additional encoding of 
exactly the same information to achieve theoretical efficiency gains 
that are still only rough estimates?

Where's the experimental proof that this will really pay off in 
increased battery life?

You write "replace". Will 6553 now be deprecated?

If not we'll have:

6553 to carry RPL information as an option header.

draft-thubert-6man-flow-label-for-rpl-03 to carry RPL information as a 
flow label

flow label information used to select patch and load balancing in 
multi-path networks. e.g.
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5349203&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5349203
http://tools.ietf.org/html/rfc6438
http://tools.ietf.org/html/rfc7098

I do not see that these applications for this one field are mutually 
compatible, and worse still, the only way to decode the semantics of the 
overloaded field is by applying some unknown external context ("within 
RPL domain"/ "on the Internet").

The hidden "cost" here is that we will have 3 different overlapping 
solutions = code bloat and potentially a lot of additional processing to 
locate the correct information and then process it, which is also a hit 
on energy efficiency.

IMHO the bar should be pretty high for accepting this proposal, as it is 
not actually solving a tangible issue.

Also my prediction of the next request for field overloading will be:
My ISP only delegates one /64 with PD
I have multiple links in my Homenet
All my media is EUI48 based. No one really uses EUI64.
I want to rewrite the 16 spare bits in SLAAC ("FF:FE") and use this for 
routing in Homenet by encoding a (V)LAN ID in it.
It's OK though. Homenet is a walled garden and I'll rewrite the field at 
the exit so no one will ever know.


As an alternative: if this information is really RPL specific, why not 
just add the RPL Information as a tag to the front of the packet e.g. 
via an MPLS label?

MPLS labels are only 4 octets, and are designed to be very efficient and 
fast.
You can easily strip them at egress, and munge it/set it on ingress.
It's clear where an MPLS domain ends and starts: no chance of RPL 
information leaking onto the Internet, or entering from the Internet.
The MPLS label also transports the 20 bits of information you need.
MPLS labels are at a clear fixed position in the packet and are easy and 
efficient to parse.
You could also then nest RPL domains if you ever wanted to do that.
It's also extensible, as you can push more labels on the stack in the 
future if you ever want to extend the RPL Information transported, 
whereas the flow label is a single fixed field.
It does not require any new standard, except maybe an informational RFC 
on how to encode the RPL Information into MPLS labels.
And it doesn't overload anything.

regards,

> Ray Hunter <mailto:v6ops@globis.net>
> 15 August 2014 21:49
>
>
>
> +1
>
> Apologies for tardy response (holidays)
>
> After reading the draft it seems to me that what is being attempted is
> 1) to add some stuff to the IPv6 header that is RPL domain specific
> 2) to reduce the overall packet length to reduce active radio time and 
> thus save energy
> by
> 3) overloading an existing well-defined and used IPv6 header field
>
> My simple logic tells me that
> 1) could be best solved at an architecture level via an extension 
> header http://tools.ietf.org/html/rfc2460#page-11 + 
> http://tools.ietf.org/html/rfc7045
> 2) could be best solved at an architecture level via IP header 
> compression http://tools.ietf.org/html/rfc2507.html with or without 
> additional tweaks
> and that overloading an opaque field in 3) by incorporating values 
> with low entropy (as per the RPL flow label) gives additional security 
> risks to http://tools.ietf.org/html/rfc7098
>
> So what's wrong with my simple logic?
>
> "But if we consider the whole RPL domain as a large virtual host from 
> the standpoint of the rest of the Internet" would suggest to me that 
> the cost of stripping out the additional IPv6 hop by hop extension 
> header at the edge of the domain is a bogus argument, as you'll anyway 
> have to provide some adaption and security at the root of each RPL 
> domain to detect and bounce spoofed RPL Information from entering, or 
> private RPL Information leaking out of each domain. Whether this 
> domain-specificRPL Information is encoded in an explicit hop by hop 
> option or an overloaded flow label would seem largely irrelevant to 
> that operation at the RPL root (especially since the RPL root anyway 
> has to be a high power node to be able communicate with the rest of 
> the Internet).
>
> IMHO If you overload the flow label you're looking at creating an 
> incompatible walled garden, with competing IETF standards that are 
> mutually exclusive.
>
> ------------------------------------------------------------------------


-- 
Regards,
RayH


From nobody Sat Aug 16 12:55:10 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168BA1A01FF; Sat, 16 Aug 2014 12:55:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_51=0.6, SPF_PASS=-0.001] autolearn=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 4bwwnHugpsFl; Sat, 16 Aug 2014 12:55:03 -0700 (PDT)
Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94EF01A01E5; Sat, 16 Aug 2014 12:55:03 -0700 (PDT)
Received: by mail-pd0-f175.google.com with SMTP id r10so5085267pdi.6 for <multiple recipients>; Sat, 16 Aug 2014 12:55:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yqkvNql2yfGUXXQZLiuv3+oqHvdPB7VTDCG0TY3B+w0=; b=cYyPAUGU9mrXSerCfVAC+7Dju7eJj+L46wzla6QvYJD/q6JDdDHWLa9jCqeMUibunR sHx6HM00pLNuofi1imtW+85cmSgz/FpghaDciTpREx2pjazY4Y90qGXp78x0YzV41AgA iH8lsb1kKbPuK8hjarYgeCh2yFhIBJCHtDUlIpHbm9uezezrlCymCnq0wlmg90HNEqQy SmRLvAGS5Z0WO0s1RaS8Kb4P5WwVYBeKcT4opNiPcr0sIjOc0h6TYZxh2sBMIiv5XGE9 poNP0l1qVqDixrj5HZ4nYQ96BQS9DjnzBOWXk+xB8GRfRq1lucKqUrYJDDU/lOqjI2bI XQJg==
X-Received: by 10.66.159.8 with SMTP id wy8mr22606819pab.17.1408218901413; Sat, 16 Aug 2014 12:55:01 -0700 (PDT)
Received: from [192.168.178.23] (128.198.69.111.dynamic.snap.net.nz. [111.69.198.128]) by mx.google.com with ESMTPSA id h5sm1153264pdn.83.2014.08.16.12.54.58 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Aug 2014 12:55:00 -0700 (PDT)
Message-ID: <53EFB719.70508@gmail.com>
Date: Sun, 17 Aug 2014 07:55:05 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ray Hunter <v6ops@globis.net>
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53EE6441.1000908@globis.net> <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu> <53EEFEEE.8020505@globis.net>
In-Reply-To: <53EEFEEE.8020505@globis.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Ier_nLEedvAw3mA7e45DJutV-UM
Cc: roll <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Aug 2014 19:55:05 -0000

Ray,

On 16/08/2014 18:49, Ray Hunter wrote:
>> Philip Levis <mailto:pal@cs.stanford.edu>
>> 16 August 2014 02:33
>>
>> 1) There is an extension header already; the problem is that it can
>> introduce a significant (ballpark estimates are, in well engineered
>> networks, up to 5-10%) cost. The proposal is to replace the extension
>> header with using the flow label.
>>
>> 2) There'a already significant IP header compression in the cases
>> we're talking about.
>>
>> Phil
> 
> I'm sympathetic to the needs of low power devices.
> 
> However, to be clear, we are reengineering a standards track document
> that is around 2 years old (http://tools.ietf.org/html/rfc6553), and
> which works technically, and we are proposing an additional encoding of
> exactly the same information to achieve theoretical efficiency gains
> that are still only rough estimates?
> 
> Where's the experimental proof that this will really pay off in
> increased battery life?
> 
> You write "replace". Will 6553 now be deprecated?
> 
> If not we'll have:
> 
> 6553 to carry RPL information as an option header.
> 
> draft-thubert-6man-flow-label-for-rpl-03 to carry RPL information as a
> flow label
> 
> flow label information used to select patch and load balancing in
> multi-path networks. e.g.
> http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5349203&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5349203
> 
> http://tools.ietf.org/html/rfc6438
> http://tools.ietf.org/html/rfc7098
> 
> I do not see that these applications for this one field are mutually
> compatible, and worse still, the only way to decode the semantics of the
> overloaded field is by applying some unknown external context ("within
> RPL domain"/ "on the Internet").

No, I don't see a problem there. The boundary of a RPL domain is
very well defined and flow-label-for-rpl clearly specifies that
outside that boundary, RFC 6437 applies (which enables RFC 6438
and 7098).

> The hidden "cost" here is that we will have 3 different overlapping
> solutions = code bloat and potentially a lot of additional processing to
> locate the correct information and then process it, which is also a hit
> on energy efficiency.
> 
> IMHO the bar should be pretty high for accepting this proposal, as it is
> not actually solving a tangible issue.

Whether ROLL wants to endorse alternative methods within RPL
domains is not a 6man question.
> 
> Also my prediction of the next request for field overloading will be:
> My ISP only delegates one /64 with PD
> I have multiple links in my Homenet
> All my media is EUI48 based. No one really uses EUI64.
> I want to rewrite the 16 spare bits in SLAAC ("FF:FE") and use this for
> routing in Homenet by encoding a (V)LAN ID in it.
> It's OK though. Homenet is a walled garden and I'll rewrite the field at
> the exit so no one will ever know.

Nice strawman, but why is it relevant? There's no need to rewrite
the bits, BTW. As RFC 7136 says:
"However, the method of generating IIDs for specific link types MAY
define some local significance for certain bits... the whole IID value
MUST be viewed as an opaque bit string by third parties, except possibly
in the local context."

   Brian

> As an alternative: if this information is really RPL specific, why not
> just add the RPL Information as a tag to the front of the packet e.g.
> via an MPLS label?
> 
> MPLS labels are only 4 octets, and are designed to be very efficient and
> fast.
> You can easily strip them at egress, and munge it/set it on ingress.
> It's clear where an MPLS domain ends and starts: no chance of RPL
> information leaking onto the Internet, or entering from the Internet.
> The MPLS label also transports the 20 bits of information you need.
> MPLS labels are at a clear fixed position in the packet and are easy and
> efficient to parse.
> You could also then nest RPL domains if you ever wanted to do that.
> It's also extensible, as you can push more labels on the stack in the
> future if you ever want to extend the RPL Information transported,
> whereas the flow label is a single fixed field.
> It does not require any new standard, except maybe an informational RFC
> on how to encode the RPL Information into MPLS labels.
> And it doesn't overload anything.
> 
> regards,
> 
>> Ray Hunter <mailto:v6ops@globis.net>
>> 15 August 2014 21:49
>>
>>
>>
>> +1
>>
>> Apologies for tardy response (holidays)
>>
>> After reading the draft it seems to me that what is being attempted is
>> 1) to add some stuff to the IPv6 header that is RPL domain specific
>> 2) to reduce the overall packet length to reduce active radio time and
>> thus save energy
>> by
>> 3) overloading an existing well-defined and used IPv6 header field
>>
>> My simple logic tells me that
>> 1) could be best solved at an architecture level via an extension
>> header http://tools.ietf.org/html/rfc2460#page-11 +
>> http://tools.ietf.org/html/rfc7045
>> 2) could be best solved at an architecture level via IP header
>> compression http://tools.ietf.org/html/rfc2507.html with or without
>> additional tweaks
>> and that overloading an opaque field in 3) by incorporating values
>> with low entropy (as per the RPL flow label) gives additional security
>> risks to http://tools.ietf.org/html/rfc7098
>>
>> So what's wrong with my simple logic?
>>
>> "But if we consider the whole RPL domain as a large virtual host from
>> the standpoint of the rest of the Internet" would suggest to me that
>> the cost of stripping out the additional IPv6 hop by hop extension
>> header at the edge of the domain is a bogus argument, as you'll anyway
>> have to provide some adaption and security at the root of each RPL
>> domain to detect and bounce spoofed RPL Information from entering, or
>> private RPL Information leaking out of each domain. Whether this
>> domain-specificRPL Information is encoded in an explicit hop by hop
>> option or an overloaded flow label would seem largely irrelevant to
>> that operation at the RPL root (especially since the RPL root anyway
>> has to be a high power node to be able communicate with the rest of
>> the Internet).
>>
>> IMHO If you overload the flow label you're looking at creating an
>> incompatible walled garden, with competing IETF standards that are
>> mutually exclusive.
>>
>> ------------------------------------------------------------------------
> 
> 


From nobody Sat Aug 16 14:03:11 2014
Return-Path: <mcr@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D88D1A036F; Sat, 16 Aug 2014 14:03:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level: 
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
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 qdjtyNjrVr1r; Sat, 16 Aug 2014 14:03:00 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D011A036D; Sat, 16 Aug 2014 14:03:00 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 57DE72002B; Sat, 16 Aug 2014 17:06:03 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id EEEDF63AC9; Sat, 16 Aug 2014 17:02:58 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DB71C638D6; Sat, 16 Aug 2014 17:02:58 -0400 (EDT)
From: Michael Richardson <mcr@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>, 6man WG <ipv6@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
In-Reply-To: <53EEB205.3040205@gmail.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <200645F3-ACEA-4F88-AD30-35998803FB54@cs.stanford.edu> <53EEB205.3040205@gmail.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
Date: Sat, 16 Aug 2014 17:02:58 -0400
Message-ID: <3278.1408222978@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/SwLnIuCaQGXz8VjXJeWiMqIg3LU
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Aug 2014 21:03:03 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    > A reader of flow-label-for-rpl needs to read RFC 6437 in order to
    > correctly
    > understand and implement flow-label-for-rpl. So RFC 6437 is correctly a
    > normative reference.  However, a reader of RFC 6437 has no need to be
    > aware
    > of flow-label-for-rpl in order to correctly implement RFC 6437 in any
    > non-RPL
    > node. So I see no logic in saying that flow-label-for-rpl updates 6437.

So, if 6437 was revised, when you would not see a reason to pull any of
the text from flow-label-for-rpl into a 6437bis?
(that's my logic for Updates:... )

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [



From nobody Sat Aug 16 15:07:52 2014
Return-Path: <mcr@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B441A0406; Sat, 16 Aug 2014 15:07:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.959
X-Spam-Level: 
X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
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 ONpAKBMD8SwU; Sat, 16 Aug 2014 15:07:48 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F3721A0404; Sat, 16 Aug 2014 15:07:48 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F39E320029; Sat, 16 Aug 2014 18:10:51 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 75DA763AC9; Sat, 16 Aug 2014 18:07:47 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5F9A6638D6; Sat, 16 Aug 2014 18:07:47 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
In-Reply-To: <E045AECD98228444A58C61C200AE1BD842D3E864@xmb-rcd-x01.cisco.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <E66DB157-B1C2-4BA4-B889-A15A6427DA3E@cs.stanford.edu> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> <E045AECD98228444A58C61C200AE1BD842D3E1E4@xmb-rcd-x01.cisco.com> <CE11CC16-DEBD-426D-BF52-CEFF927B127A@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3E3D8@xmb-rcd-x01.cisco.com> <9051878F-04DC-4FAD-BE53-056826FD1070@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3E864@xmb-rcd-x01 .cisco.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Sat, 16 Aug 2014 18:07:47 -0400
Message-ID: <18424.1408226867@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/N5XW6mM8zpO27bM5Sp-r3kEk6E4
Cc: 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Aug 2014 22:07:50 -0000

--=-=-=


Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
    > And my conclusion to 6MAN is that the changes of rules that are
    > requested in the draft are useful whether or not people are willing to
    > use the flow label as the transport for the RPL option inside the RPL
    > domain. Since this is the question on the table for 6MAN, I think that
    > the answer is now clearly a yes.

Should we split the issue up?
1) blessing/permission/exception to reset flow label within an LLN,
   (which would include simply setting it to zero so it can be compressed
   out)

2) a document on how to compress 6553 HbH into ?flow-label vs ?6lo-HC.

   I am not enthusiastic about multiple ways.
   We will have an existing problem of figuring out 6553 vs new-way,
   and also noting that some nodes will needed to continue to speak 6553
   on some links anyway (backhaul ethernet).


    >> it mentions ISA100.11a only in the introduction.)

My understanding is that ISA100.11a uses the flow label to pick a path,
but not in a way that involves rewritting it on each hop in the LLN.
Please correct me if I'm wrong; it seems that document (1) is needed to
retro-actively bless ISA100.11a usage :-)

[I'm writing this on a rainy Saturday afternoon, at a friend's house,
playing 1st Ed AD&D, and my two characters are unconcious... so when I use
the term "bless"... you'll understand the context]

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBU+/WL4CLcPvd0N1lAQIFwgf9HSEQB5AhWfoJYn9bmmw7h8j1Y3S+nDfi
oHAW7r4xBRLG32IB7R91yt4DOzHBpsOD2uU3PTycgNhqWXNbCxnAhEBqsgAVuqBs
SWfd4JABP2DH0EXFkTBYKI2DCYBIemgWSBCQ1ct6zsKrVeqrJUibcIXmRK84Q2+c
ly2ZEsdIR0Jt4dtPH/55Z+O9zCJCsPaiYQC2JogQht8/ZY5whQ2kj6j32ryHjqk5
M3xjGXMeyUeLlISdL9/mNitCBvRex3juYJEbwPME6gRLYjBsjVN/budJE/4vPsHM
9eFzUGGiHNm2MbpFuC2L/36qrga+EgGaF0RDswnTYecLcqnSx1tk7g==
=qjIU
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Sat Aug 16 15:12:13 2014
Return-Path: <mcr@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35831A0479; Sat, 16 Aug 2014 15:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level: 
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
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 id0X9nBsY-rK; Sat, 16 Aug 2014 15:12:10 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8E11A0478; Sat, 16 Aug 2014 15:12:09 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AEA8520029; Sat, 16 Aug 2014 18:15:13 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 206E863AC9; Sat, 16 Aug 2014 18:12:09 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 08045638D6; Sat, 16 Aug 2014 18:12:09 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] RPL Information Header for 6lo (Re: [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03)
In-Reply-To: <9322723A-842E-4C10-BFB7-63C88A968169@tzi.org>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <E66DB157-B1C2-4BA4-B889-A15A6427DA3E@cs.stanford.edu> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> <E045AECD98228444A58C61C200AE1BD842D3E1E4@xmb-rcd-x01.cisco.com> <CE11CC16-DEBD-426D-BF52-CEFF927B127A@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3E3D8@xmb-rcd-x01.cisco.com> <9051878F-04DC-4FAD-BE53-056826FD1070@tzi.org> <9322723A-842E-4C10-BFB7-63C88A968169@tzi.org>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Sat, 16 Aug 2014 18:12:09 -0400
Message-ID: <19406.1408227129@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/DP2Uyuhh1uEDYgGBX0DaYdhml8g
Cc: 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Aug 2014 22:12:11 -0000

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


Carsten Bormann <cabo@tzi.org> wrote:
    > This draft is both intended as a response to the WGLC referenced in t=
he
    > subject and as a proposal to the 6lo working group to pick this up as=
 a
    > working group item.  (Clearly, if we do this, we=E2=80=99ll want lots=
 of input
    > from ROLL whether we are doing the right thing, while it is 6lo=E2=80=
=99s job
    > to do the thing right.  No changes to the IP architecture are require=
d,
    > so there is no need to bother 6man with this work.)

I think that we still need a blessing to reset the flow label to zero upon
entering the LLN, so that it can be nicely compressed out.  I think that we
have that blessing.   Please see my other email suggesting a split.

    > Heads up: I=E2=80=99ll have limited E-Mail access Aug 16 to Sep 3.

In your absense I am interested to hear from others about any preference
about technical solutions.  Please speak up.

=2D-
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -=3D IPv6 IoT consulting =3D-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBU+/XNoCLcPvd0N1lAQJaTgf/aCiLMi6ZJ04I54AGDEy9F4pLsELaZUar
ldC4uB5335Ml/JDWUbl0o4sgFwfedFjAXw8/wgv3J4Z2xH+WFknO4n4LlAHCFuNZ
5Ol2/OyfQijyweMwPhp3u5YNxVmsf8fQeWmjcNoJyKwmlmnqMK9jOtxvLTWhvJef
eiGEgTpPEwoUXPHxILodyx/EhcNP3PB+E0QmMeHmirLjCbeO4ty6oDf/7JY2vzW6
SR3Ec6OM1Wv4lQQYQLOeRBjRD0M4WRVE9sI56dU+JhWjnhiuCJUu23salHAbP9Eh
oz4krqFUq/z5EhAtn0qzw5tGVDH/JxyltpQF5qxJsLt1PKDHpWPVcg==
=sj9n
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Sat Aug 16 15:33:02 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECCB1A0489; Sat, 16 Aug 2014 15:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 Ug5SdD1BZS8i; Sat, 16 Aug 2014 15:32:59 -0700 (PDT)
Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EABB31A0487; Sat, 16 Aug 2014 15:32:58 -0700 (PDT)
Received: by mail-pa0-f45.google.com with SMTP id eu11so5432404pac.32 for <multiple recipients>; Sat, 16 Aug 2014 15:32:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Mcus3dMyu/W08/fwUBYxpixiK/1cX3W5voNQd9erCdw=; b=oM3uz1W+0ZzsF3cv4bD6EDh7YlrM58DRUEPj1VyysAVNKaX5jFbTfPi0eqjNwLD+nl KtCQTTBMtu8BH/yI86CwoTx6myJt/XyujfjRsbOOhAyjc/WJVZy6Q8sAuPirSmgnucFv +50TWCiddW7+M7wOcOBfZ0VncJejDQcLbOxma3QCOWgvAEA0TZXd86dzRDAACmU8aDXN hYw6qMHCRCxAFZ7w6vqQy0WHD3X5mAeIV86EHPsdnqbqFp0iKLnumlQRIiqI48Qm5WRA rj1Nkwh7kCXL66H0gfYm/Bc35b2q8vEmciWZHXey6sHJs73h550wiRg/pjdDPzsvPJ/z JpFg==
X-Received: by 10.68.163.100 with SMTP id yh4mr23158900pbb.122.1408228378552;  Sat, 16 Aug 2014 15:32:58 -0700 (PDT)
Received: from [192.168.178.23] (128.198.69.111.dynamic.snap.net.nz. [111.69.198.128]) by mx.google.com with ESMTPSA id zf5sm41985113pac.41.2014.08.16.15.32.56 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Aug 2014 15:32:57 -0700 (PDT)
Message-ID: <53EFDC26.1010706@gmail.com>
Date: Sun, 17 Aug 2014 10:33:10 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Michael Richardson <mcr@sandelman.ca>
Subject: Re: [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <200645F3-ACEA-4F88-AD30-35998803FB54@cs.stanford.edu> <53EEB205.3040205@gmail.com> <3278.1408222978@sandelman.ca>
In-Reply-To: <3278.1408222978@sandelman.ca>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/jMhSbXy8NQ0XE-MPNLOlBRm6XYo
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, 6man WG <ipv6@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Aug 2014 22:33:00 -0000

On 17/08/2014 09:02, Michael Richardson wrote:
> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>     > A reader of flow-label-for-rpl needs to read RFC 6437 in order to
>     > correctly
>     > understand and implement flow-label-for-rpl. So RFC 6437 is correctly a
>     > normative reference.  However, a reader of RFC 6437 has no need to be
>     > aware
>     > of flow-label-for-rpl in order to correctly implement RFC 6437 in any
>     > non-RPL
>     > node. So I see no logic in saying that flow-label-for-rpl updates 6437.
> 
> So, if 6437 was revised, when you would not see a reason to pull any of
> the text from flow-label-for-rpl into a 6437bis?
> (that's my logic for Updates:... )

Well, it's a matter of taste. I'd say not: I see no reason why an implementer
of a normal (non-RPL-aware) node should be sent off to read a bunch of
RPL documents, which is what such an update would imply.

    Brian


From nobody Sun Aug 17 02:52:51 2014
Return-Path: <v6ops@globis.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A852B1A081B; Sun, 17 Aug 2014 02:52:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.969
X-Spam-Level: 
X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
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 SeQDP-mdF1F9; Sun, 17 Aug 2014 02:52:47 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id C40ED1A081E; Sun, 17 Aug 2014 02:52:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 8943787153F; Sun, 17 Aug 2014 11:52:45 +0200 (CEST)
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8cVLh72qPyl; Sun, 17 Aug 2014 11:52:45 +0200 (CEST)
Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:71e5:ffdb:956c:66e1]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 3B43687005C; Sun, 17 Aug 2014 11:52:45 +0200 (CEST)
Message-ID: <53F07B55.7050708@globis.net>
Date: Sun, 17 Aug 2014 11:52:21 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53EE6441.1000908@globis.net> <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu> <53EEFEEE.8020505@globis.net> <53EFB719.70508@gmail.com>
In-Reply-To: <53EFB719.70508@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/1n-qIxp0pBIwjVY00vI2Xj5gnrc
Cc: roll <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Aug 2014 09:52:49 -0000

> Brian E Carpenter <mailto:brian.e.carpenter@gmail.com>
> 16 August 2014 21:55
> Ray,
>
> On 16/08/2014 18:49, Ray Hunter wrote:
>>> Philip Levis<mailto:pal@cs.stanford.edu>
>>> 16 August 2014 02:33
>>>
>>> 1) There is an extension header already; the problem is that it can
>>> introduce a significant (ballpark estimates are, in well engineered
>>> networks, up to 5-10%) cost. The proposal is to replace the extension
>>> header with using the flow label.
>>>
>>> 2) There'a already significant IP header compression in the cases
>>> we're talking about.
>>>
>>> Phil
>> I'm sympathetic to the needs of low power devices.
>>
>> However, to be clear, we are reengineering a standards track document
>> that is around 2 years old (http://tools.ietf.org/html/rfc6553), and
>> which works technically, and we are proposing an additional encoding of
>> exactly the same information to achieve theoretical efficiency gains
>> that are still only rough estimates?
>>
>> Where's the experimental proof that this will really pay off in
>> increased battery life?
>>
>> You write "replace". Will 6553 now be deprecated?
>>
>> If not we'll have:
>>
>> 6553 to carry RPL information as an option header.
>>
>> draft-thubert-6man-flow-label-for-rpl-03 to carry RPL information as a
>> flow label
>>
>> flow label information used to select patch and load balancing in
>> multi-path networks. e.g.
>> http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5349203&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5349203
>>
>> http://tools.ietf.org/html/rfc6438
>> http://tools.ietf.org/html/rfc7098
>>
>> I do not see that these applications for this one field are mutually
>> compatible, and worse still, the only way to decode the semantics of the
>> overloaded field is by applying some unknown external context ("within
>> RPL domain"/ "on the Internet").
>
> No, I don't see a problem there. The boundary of a RPL domain is
> very well defined and flow-label-for-rpl clearly specifies that
> outside that boundary, RFC 6437 applies (which enables RFC 6438
> and 7098).
But inside an RPL domain, you cannot use any RFC's that reference the 
flow label as per 6437, because all of the entropy has gone.

And what happened to our end to end architecture?

I just do not like the concept of parsing a packet, and then having to 
determine the semantics of the contents of a particular field based on a 
"domain" that is not carried anywhere in the packet.
e.g. think about decoding offline captures
>> The hidden "cost" here is that we will have 3 different overlapping
>> solutions = code bloat and potentially a lot of additional processing to
>> locate the correct information and then process it, which is also a hit
>> on energy efficiency.
>>
>> IMHO the bar should be pretty high for accepting this proposal, as it is
>> not actually solving a tangible issue.
>
> Whether ROLL wants to endorse alternative methods within RPL
> domains is not a 6man question.
>> Also my prediction of the next request for field overloading will be:
>> My ISP only delegates one /64 with PD
>> I have multiple links in my Homenet
>> All my media is EUI48 based. No one really uses EUI64.
>> I want to rewrite the 16 spare bits in SLAAC ("FF:FE") and use this for
>> routing in Homenet by encoding a (V)LAN ID in it.
>> It's OK though. Homenet is a walled garden and I'll rewrite the field at
>> the exit so no one will ever know.
>
> Nice strawman, but why is it relevant? There's no need to rewrite
> the bits, BTW. As RFC 7136 says:
> "However, the method of generating IIDs for specific link types MAY
> define some local significance for certain bits... the whole IID value
> MUST be viewed as an opaque bit string by third parties, except possibly
> in the local context."
>
>     Brian
>
>> As an alternative: if this information is really RPL specific, why not
>> just add the RPL Information as a tag to the front of the packet e.g.
>> via an MPLS label?
>>
>> MPLS labels are only 4 octets, and are designed to be very efficient and
>> fast.
>> You can easily strip them at egress, and munge it/set it on ingress.
>> It's clear where an MPLS domain ends and starts: no chance of RPL
>> information leaking onto the Internet, or entering from the Internet.
>> The MPLS label also transports the 20 bits of information you need.
>> MPLS labels are at a clear fixed position in the packet and are easy and
>> efficient to parse.
>> You could also then nest RPL domains if you ever wanted to do that.
>> It's also extensible, as you can push more labels on the stack in the
>> future if you ever want to extend the RPL Information transported,
>> whereas the flow label is a single fixed field.
>> It does not require any new standard, except maybe an informational RFC
>> on how to encode the RPL Information into MPLS labels.
>> And it doesn't overload anything.
>>
>> regards,
>>
>>> Ray Hunter<mailto:v6ops@globis.net>
>>> 15 August 2014 21:49
>>>
>>>
>>>
>>> +1
>>>
>>> Apologies for tardy response (holidays)
>>>
>>> After reading the draft it seems to me that what is being attempted is
>>> 1) to add some stuff to the IPv6 header that is RPL domain specific
>>> 2) to reduce the overall packet length to reduce active radio time and
>>> thus save energy
>>> by
>>> 3) overloading an existing well-defined and used IPv6 header field
>>>
>>> My simple logic tells me that
>>> 1) could be best solved at an architecture level via an extension
>>> header http://tools.ietf.org/html/rfc2460#page-11 +
>>> http://tools.ietf.org/html/rfc7045
>>> 2) could be best solved at an architecture level via IP header
>>> compression http://tools.ietf.org/html/rfc2507.html with or without
>>> additional tweaks
>>> and that overloading an opaque field in 3) by incorporating values
>>> with low entropy (as per the RPL flow label) gives additional security
>>> risks to http://tools.ietf.org/html/rfc7098
>>>
>>> So what's wrong with my simple logic?
>>>
>>> "But if we consider the whole RPL domain as a large virtual host from
>>> the standpoint of the rest of the Internet" would suggest to me that
>>> the cost of stripping out the additional IPv6 hop by hop extension
>>> header at the edge of the domain is a bogus argument, as you'll anyway
>>> have to provide some adaption and security at the root of each RPL
>>> domain to detect and bounce spoofed RPL Information from entering, or
>>> private RPL Information leaking out of each domain. Whether this
>>> domain-specificRPL Information is encoded in an explicit hop by hop
>>> option or an overloaded flow label would seem largely irrelevant to
>>> that operation at the RPL root (especially since the RPL root anyway
>>> has to be a high power node to be able communicate with the rest of
>>> the Internet).
>>>
>>> IMHO If you overload the flow label you're looking at creating an
>>> incompatible walled garden, with competing IETF standards that are
>>> mutually exclusive.
>>>
>>> ------------------------------------------------------------------------
> ------------------------------------------------------------------------


-- 
Regards,
RayH


From nobody Sun Aug 17 12:58:15 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9711A6FCF; Sun, 17 Aug 2014 12:58:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_51=0.6, SPF_PASS=-0.001] autolearn=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 xP3WD53madc4; Sun, 17 Aug 2014 12:58:10 -0700 (PDT)
Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77731A0AA3; Sun, 17 Aug 2014 12:58:10 -0700 (PDT)
Received: by mail-pd0-f169.google.com with SMTP id y10so6241236pdj.28 for <multiple recipients>; Sun, 17 Aug 2014 12:58:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=NpWmIR4H2InPyhtgEmo2FAQzRlXEVF03ACMf4v0NNTQ=; b=0InAO5GLB0+m2lgPSmCf7/VorbkQyZVcq2bT8a/5lUnqMTDbMOcaRxqGnYAeraOKM2 cGcGETCCoMuNsK1wjrCYzFP6ABkjIF5Tc/XgitPjuxbOMAGjCbLdu6NPASGHgTe4a6Ts Q6njxudkfpj9z8y02W+v/C3WITM6Cl50LspcjbYSS0wjYDmmu57ehFhWF08/Fy1X5Hww Dt09gIvUcDTBIlZMBQgiWTxY3j+zpPCre5JTWzUDjdR9OcuKvf7hzLvog8qIUKFoN8z5 IoiHY73f3bhsnNSEIbTxCJffG0lj0GTiA7ZD4e9Pwe41465QzH7lG42KtHZb3Ksq/e50 UQig==
X-Received: by 10.69.20.11 with SMTP id gy11mr29540063pbd.28.1408305490215; Sun, 17 Aug 2014 12:58:10 -0700 (PDT)
Received: from [192.168.178.23] (58.199.69.111.dynamic.snap.net.nz. [111.69.199.58]) by mx.google.com with ESMTPSA id qb2sm14094392pbb.0.2014.08.17.12.58.06 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Aug 2014 12:58:09 -0700 (PDT)
Message-ID: <53F10959.2000102@gmail.com>
Date: Mon, 18 Aug 2014 07:58:17 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ray Hunter <v6ops@globis.net>
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53EE6441.1000908@globis.net> <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu> <53EEFEEE.8020505@globis.net> <53EFB719.70508@gmail.com> <53F07B55.7050708@globis.net>
In-Reply-To: <53F07B55.7050708@globis.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/8-YZsVU_qPrhGrwG3bTBOZwCXoA
Cc: roll <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Aug 2014 19:58:13 -0000

On 17/08/2014 21:52, Ray Hunter wrote:
>> Brian E Carpenter <mailto:brian.e.carpenter@gmail.com>
>> 16 August 2014 21:55
>> Ray,
>>
>> On 16/08/2014 18:49, Ray Hunter wrote:
>>>> Philip Levis<mailto:pal@cs.stanford.edu>
>>>> 16 August 2014 02:33
>>>>
>>>> 1) There is an extension header already; the problem is that it can
>>>> introduce a significant (ballpark estimates are, in well engineered
>>>> networks, up to 5-10%) cost. The proposal is to replace the extension
>>>> header with using the flow label.
>>>>
>>>> 2) There'a already significant IP header compression in the cases
>>>> we're talking about.
>>>>
>>>> Phil
>>> I'm sympathetic to the needs of low power devices.
>>>
>>> However, to be clear, we are reengineering a standards track document
>>> that is around 2 years old (http://tools.ietf.org/html/rfc6553), and
>>> which works technically, and we are proposing an additional encoding of
>>> exactly the same information to achieve theoretical efficiency gains
>>> that are still only rough estimates?
>>>
>>> Where's the experimental proof that this will really pay off in
>>> increased battery life?
>>>
>>> You write "replace". Will 6553 now be deprecated?
>>>
>>> If not we'll have:
>>>
>>> 6553 to carry RPL information as an option header.
>>>
>>> draft-thubert-6man-flow-label-for-rpl-03 to carry RPL information as a
>>> flow label
>>>
>>> flow label information used to select patch and load balancing in
>>> multi-path networks. e.g.
>>> http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5349203&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5349203
>>>
>>>
>>> http://tools.ietf.org/html/rfc6438
>>> http://tools.ietf.org/html/rfc7098
>>>
>>> I do not see that these applications for this one field are mutually
>>> compatible, and worse still, the only way to decode the semantics of the
>>> overloaded field is by applying some unknown external context ("within
>>> RPL domain"/ "on the Internet").
>>
>> No, I don't see a problem there. The boundary of a RPL domain is
>> very well defined and flow-label-for-rpl clearly specifies that
>> outside that boundary, RFC 6437 applies (which enables RFC 6438
>> and 7098).
> But inside an RPL domain, you cannot use any RFC's that reference the
> flow label as per 6437, because all of the entropy has gone.

Correct. But isn't that a trade-off that might be reasonable in
the low-power lossy environment? (That's not intended as a rhetorical
question - I just don't have enough knowledge of that environment
to answer it.)

> 
> And what happened to our end to end architecture?

There are various views of what e2e means, but I still like the
phrase "certain required end-to-end functions can only be performed
correctly by the end-systems themselves". Load balancing and adaptive
routing are not actually e2e functions in that sense.

> I just do not like the concept of parsing a packet, and then having to
> determine the semantics of the contents of a particular field based on a
> "domain" that is not carried anywhere in the packet.

I see the objection, but we've been doing it for years; diffserv does
it by definition.

   Brian

> e.g. think about decoding offline captures

>>> The hidden "cost" here is that we will have 3 different overlapping
>>> solutions = code bloat and potentially a lot of additional processing to
>>> locate the correct information and then process it, which is also a hit
>>> on energy efficiency.
>>>
>>> IMHO the bar should be pretty high for accepting this proposal, as it is
>>> not actually solving a tangible issue.
>>
>> Whether ROLL wants to endorse alternative methods within RPL
>> domains is not a 6man question.
>>> Also my prediction of the next request for field overloading will be:
>>> My ISP only delegates one /64 with PD
>>> I have multiple links in my Homenet
>>> All my media is EUI48 based. No one really uses EUI64.
>>> I want to rewrite the 16 spare bits in SLAAC ("FF:FE") and use this for
>>> routing in Homenet by encoding a (V)LAN ID in it.
>>> It's OK though. Homenet is a walled garden and I'll rewrite the field at
>>> the exit so no one will ever know.
>>
>> Nice strawman, but why is it relevant? There's no need to rewrite
>> the bits, BTW. As RFC 7136 says:
>> "However, the method of generating IIDs for specific link types MAY
>> define some local significance for certain bits... the whole IID value
>> MUST be viewed as an opaque bit string by third parties, except possibly
>> in the local context."
>>
>>     Brian
>>
>>> As an alternative: if this information is really RPL specific, why not
>>> just add the RPL Information as a tag to the front of the packet e.g.
>>> via an MPLS label?
>>>
>>> MPLS labels are only 4 octets, and are designed to be very efficient and
>>> fast.
>>> You can easily strip them at egress, and munge it/set it on ingress.
>>> It's clear where an MPLS domain ends and starts: no chance of RPL
>>> information leaking onto the Internet, or entering from the Internet.
>>> The MPLS label also transports the 20 bits of information you need.
>>> MPLS labels are at a clear fixed position in the packet and are easy and
>>> efficient to parse.
>>> You could also then nest RPL domains if you ever wanted to do that.
>>> It's also extensible, as you can push more labels on the stack in the
>>> future if you ever want to extend the RPL Information transported,
>>> whereas the flow label is a single fixed field.
>>> It does not require any new standard, except maybe an informational RFC
>>> on how to encode the RPL Information into MPLS labels.
>>> And it doesn't overload anything.
>>>
>>> regards,
>>>
>>>> Ray Hunter<mailto:v6ops@globis.net>
>>>> 15 August 2014 21:49
>>>>
>>>>
>>>>
>>>> +1
>>>>
>>>> Apologies for tardy response (holidays)
>>>>
>>>> After reading the draft it seems to me that what is being attempted is
>>>> 1) to add some stuff to the IPv6 header that is RPL domain specific
>>>> 2) to reduce the overall packet length to reduce active radio time and
>>>> thus save energy
>>>> by
>>>> 3) overloading an existing well-defined and used IPv6 header field
>>>>
>>>> My simple logic tells me that
>>>> 1) could be best solved at an architecture level via an extension
>>>> header http://tools.ietf.org/html/rfc2460#page-11 +
>>>> http://tools.ietf.org/html/rfc7045
>>>> 2) could be best solved at an architecture level via IP header
>>>> compression http://tools.ietf.org/html/rfc2507.html with or without
>>>> additional tweaks
>>>> and that overloading an opaque field in 3) by incorporating values
>>>> with low entropy (as per the RPL flow label) gives additional security
>>>> risks to http://tools.ietf.org/html/rfc7098
>>>>
>>>> So what's wrong with my simple logic?
>>>>
>>>> "But if we consider the whole RPL domain as a large virtual host from
>>>> the standpoint of the rest of the Internet" would suggest to me that
>>>> the cost of stripping out the additional IPv6 hop by hop extension
>>>> header at the edge of the domain is a bogus argument, as you'll anyway
>>>> have to provide some adaption and security at the root of each RPL
>>>> domain to detect and bounce spoofed RPL Information from entering, or
>>>> private RPL Information leaking out of each domain. Whether this
>>>> domain-specificRPL Information is encoded in an explicit hop by hop
>>>> option or an overloaded flow label would seem largely irrelevant to
>>>> that operation at the RPL root (especially since the RPL root anyway
>>>> has to be a high power node to be able communicate with the rest of
>>>> the Internet).
>>>>
>>>> IMHO If you overload the flow label you're looking at creating an
>>>> incompatible walled garden, with competing IETF standards that are
>>>> mutually exclusive.
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>> ------------------------------------------------------------------------
> 
> 


From nobody Mon Aug 18 03:06:21 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19881A03A7; Mon, 18 Aug 2014 03:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.569
X-Spam-Level: 
X-Spam-Status: No, score=-14.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 wGfMG2m53rdu; Mon, 18 Aug 2014 03:06:15 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDA611A03A6; Mon, 18 Aug 2014 03:06:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3633; q=dns/txt; s=iport; t=1408356376; x=1409565976; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sBLDQrNzuw5RnVjBaLMW5qHxdD0jl6tnDGod3YtooL8=; b=TdTw+1cO2UafMqjBVz/+PUGubZhbZxKahwsaaRZ/U+qxoj7CVDTGp4pB kav3CqtF+ya/RCrnFIXGSq6GBrr3QGOjPg6KGiWZZMFMTdwM3XjwwzLua x6zEgm2g3yrB41GUT4hqxI+Erw3Y/LvKlcvkVWFOl51ndHSZLJfQwd7WA A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmQFAP7O8VOtJA2N/2dsb2JhbABZgw2BKgTURwGBGhZ3hAMBAQEEeQwEAgEIEQQBAQEKHQcyFAkIAgQOBQiIOsECF45+HTEHBoMpgR0FimaGP6Agg11sgUiBBwEBAQ
X-IronPort-AV: E=Sophos;i="5.01,885,1400025600"; d="scan'208";a="348273976"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP; 18 Aug 2014 10:06:15 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s7IA6DfQ021839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 10:06:13 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Mon, 18 Aug 2014 05:06:13 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "Routing Over Low power and Lossy networks" <roll@ietf.org>
Subject: RE: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPuswKNbfwRx2Yk0qsf2NSaa5I/A==
Date: Mon, 18 Aug 2014 10:06:12 +0000
Deferred-Delivery: Mon, 18 Aug 2014 10:06:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D462E9@xmb-rcd-x01.cisco.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <E66DB157-B1C2-4BA4-B889-A15A6427DA3E@cs.stanford.edu> <0B8D48F9-8AAE-49F7-A2FA-A58963088814@gmail.com> <E045AECD98228444A58C61C200AE1BD842D3E1E4@xmb-rcd-x01.cisco.com> <CE11CC16-DEBD-426D-BF52-CEFF927B127A@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3E3D8@xmb-rcd-x01.cisco.com> <9051878F-04DC-4FAD-BE53-056826FD1070@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3E864@xmb-rcd-x01 .cisco.com> <18424.1408226867@sandelman.ca>
In-Reply-To: <18424.1408226867@sandelman.ca>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.49.80.27]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/uXz5sPSQh_UZSDCXgltdXe3n_rM
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Aug 2014 10:06:16 -0000

Hello Michael;

The discussion was difficult enough with 2 WGs (just keeping clear on which=
 WG was asked what question).
Now Carsten has broadened the discussion to 6lo and thus the complexity.=20
In practice the discussion also impacts 6TiSCH because 6TiSCH will ship the=
 minimal RPL over TSCH to IESG this year (draft-ietf-6tisch-minimal).

I'm not fan of 2 ways either. But we have to face that unless we keep the H=
BH-based approach only (which is doubtlessly the worst possible outcome), t=
hen we are already in that situation for some implementation(s).

For the lack of any other (pending) RFC, the 6TiSCH minimal draft will have=
 point on the HbH-based approach and that approach will spread to 6TiSCH as=
 well, where it hurts the most due to the very small frame size. And then t=
here will have to be a deprecation and a migration to whatever ROLL and 6lo=
 decide to do. I'd rather have the starting point be the flow label and the=
n decide if we really want something else for 6TiSCH, what that something e=
lse is and if that something else is actually beneficial, which is not a do=
ne deal yet.

In any fashion, I think that we all agree that we need 6MAN to allow the bo=
rder router (RPL root) to update the Flow Label. So I'm in full agreement w=
ith you that the complexity we are now facing can be better addressed by sp=
litting the draft. One 6MAN-only draft that allows ROLL to do what the curr=
ent draft does, and one ROLL draft that does it. At that point it will be u=
p to ROLL (only) to standardize the second draft immediately or to wait and=
 see whatever progress happens at 6lo.

Cheers,

Pascal

> -----Original Message-----
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Michael Richardson
> Sent: dimanche 17 ao=FBt 2014 00:08
> To: Routing Over Low power and Lossy networks
> Cc: 6man WG; 6lo@ietf.org WG
> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-=
03
>=20
>=20
> Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
>     > And my conclusion to 6MAN is that the changes of rules that are
>     > requested in the draft are useful whether or not people are willing=
 to
>     > use the flow label as the transport for the RPL option inside the R=
PL
>     > domain. Since this is the question on the table for 6MAN, I think t=
hat
>     > the answer is now clearly a yes.
>=20
> Should we split the issue up?
> 1) blessing/permission/exception to reset flow label within an LLN,
>    (which would include simply setting it to zero so it can be compressed
>    out)
>=20
> 2) a document on how to compress 6553 HbH into ?flow-label vs ?6lo-HC.
>=20
>    I am not enthusiastic about multiple ways.
>    We will have an existing problem of figuring out 6553 vs new-way,
>    and also noting that some nodes will needed to continue to speak 6553
>    on some links anyway (backhaul ethernet).
>=20
>=20
>     >> it mentions ISA100.11a only in the introduction.)
>=20
> My understanding is that ISA100.11a uses the flow label to pick a path, b=
ut
> not in a way that involves rewritting it on each hop in the LLN.
> Please correct me if I'm wrong; it seems that document (1) is needed to
> retro-actively bless ISA100.11a usage :-)
>=20
> [I'm writing this on a rainy Saturday afternoon, at a friend's house, pla=
ying
> 1st Ed AD&D, and my two characters are unconcious... so when I use the
> term "bless"... you'll understand the context]
>=20
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> -=3D IPv6 IoT consulting =3D-
>=20
>=20


From nobody Mon Aug 18 05:51:48 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AFC81A024F; Mon, 18 Aug 2014 05:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level: 
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 WHn7577gj1oQ; Mon, 18 Aug 2014 05:51:43 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829471A01BD; Mon, 18 Aug 2014 05:51:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9398; q=dns/txt; s=iport; t=1408366304; x=1409575904; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OrnELmPzcPxGrIlAcbEtLy8zy5/sClgkLs5GP8ErCkI=; b=RTLtjg24o4t/ad2BJfD6aERh892Qd03PEd4KBKoVIV69l/0RdnehHl4V V6fA52LONT88hglZT+/QMtssJxOcTHscSjQ3xAbdcRCH6ZGIirvedI41f rTvtGd3oBx3umb4zgseVbKmnaO1FwgpzAzmtF61lUKy8a36iqnAAhhT35 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmwFAA328VOtJA2G/2dsb2JhbABZgw1TVwSCeMlyDodUARmBAhZ3hAMBAQECAgEBASARMwcLDAQCAQgRAQMBAQECAgYdAwICAh8GCxQBAgYIAgQBDQUIiCYDEQ2rf486DYUzF4Esi3OBSgwJHRYbBwaCczaBHQWGEYsUhl+CL5BfhjODXWwBAYEFQYEHAQEB
X-IronPort-AV: E=Sophos;i="5.01,885,1400025600"; d="scan'208";a="70148401"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP; 18 Aug 2014 12:51:42 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s7ICpgWT008194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Aug 2014 12:51:42 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Mon, 18 Aug 2014 07:51:41 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca>
Subject: RE: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPt/zmHp7q4q9DoEKOFDPz7vG+hJvRXEcagAFl+gCAA4xFwA==
Date: Mon, 18 Aug 2014 12:51:41 +0000
Deferred-Delivery: Mon, 18 Aug 2014 12:51:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D4671C@xmb-rcd-x01.cisco.com>
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu> <53EBD028.30302@gmail.com> <E045AECD98228444A58C61C200AE1BD842D3E4EF@xmb-rcd-x01.cisco.com>, <53ED1992.1010708@gmail.com> <755F123A-A93F-4146-BD4C-4022CD8CE13E@cisco.com> <53EEB016.4030105@gmail.com>
In-Reply-To: <53EEB016.4030105@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.49.80.27]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Y4zRpp7hF_Tv61LnYkTT6yMY_EM
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Aug 2014 12:51:45 -0000

SGVsbG8gQnJpYW46DQoNCkkgZG8gbm90IHRoaW5rIHRoYXQgeW91IGNhbiBmcmVlbHkgZG93bmxv
YWQgdGhlIHNwZWNpZmljYXRpb24uIFlvdSBwcm9iYWJseSBuZWVkIG1lbWJlcnNoaXAgZmlyc3Qu
IFRoZSBsaW5rcyBleGlzdCBmcm9tIHRoZSBXaWtpcGVkaWEgcGFnZSBidXQgdGhleSBhcmUgYnJv
a2VuLiBTYW1lIGdvZXMgZm9yIHRoZSBJRUMgdmVyc2lvbiB3aGljaCBpcyBJRUMgNjI3MzQsIGJ1
dCBpZiB5b3UgaGF2ZSBhY2Nlc3MgdG8gdGhlIElFQyB0aGVuIHRoZSBjdXJyZW50IHdvcmsgaXMg
aGVyZSBodHRwOi8vd3d3LmllYy5jaC9jZ2ktYmluL3Jlc3RyaWN0ZWQvZ2V0ZmlsZS5wbC82NUNf
NzM1ZWFfQ0RWLnBkZj9kaXI9NjVDJmZvcm1hdD1wZGYmdHlwZT1fQ0RWJmZpbGU9NzM1ZWEucGRm
DQoNClF1b3RlczogDQoNCiJUaGUgQ29udHJhY3RJRCBpcyBhc3NvY2lhdGVkIHdpdGggYSBwYXJ0
aWN1bGFyIEQtcm91dGUuIFRoaXMgbWF5IGJlIHVzZWQgd2hlbiBhIHBhcnRpY3VsYXIgZ3JhcGgg
b3Igc291cmNlIEQtcm91dGUgaXMgaW50ZW5kZWQgdG8gcHJvdmlkZSBhIGRlZmluZWQgbGV2ZWwg
b2Ygc2VydmljZSINCg0KIkZsb3dMYWJlbDogVGhlIGxvd2VyIG9yZGVyIDE2IGJpdHMgb2YgdGhl
IEZsb3dMYWJlbCBzaGFsbCBiZSBzZXQgdG8gQ29udHJhY3RJRC4gVGhlIGhpZ2hlciBvcmRlciA0
IGJpdHMgc2hhbGwgYmUgYWxsIHplcm9zLiBUaGlzIGZpZWxkIHNoYWxsIG9ubHkgYmUgcHJlc2Vu
dCBpZiBvY3RldHMgMyB0aHJvdWdoIDUgYXJlIHByZXNlbnQsIGFzIGluZGljYXRlZCBieSBMT1dQ
QU5fSVBIQyBlbmNvZGluZy4iDQoNCk5vdGUgdGhhdCB0aGUgNlRpU0NIIGFyY2hpdGVjdHVyZSBl
Y2hvZXMgdGhpcyBkZXNpZ24sIGFuZCBhIGQtcm91dGUgaXMgdmVyeSBzaW1pbGFyIHRvIGEgNlRp
U0NIIHRyYWNrLg0KDQpGb3IgdGhlIHNha2Ugb2YgaGlzdG9yeSBhbmQgdG8gbXkgYmVzdCBrbm93
bGVkZ2UsIElTQTEwMC4xMWEgd2FzIHRoZSBmaXJzdCBpbmR1c3RyaWFsIHN0YW5kYXJkIHRvIGFk
b3B0IElQdjYgZm9yIHByb2Nlc3MgY29udHJvbCBhcHBsaWNhdGlvbnMgKGNvbnRyb2wgbG9vcHMg
YW5kIG1vbml0b3JpbmcpLiANCkl0IGlzIGVmZmVjdGl2ZWx5IGVuYWJsaW5nIElQIGluIHRoZSBj
b250cm9sIG5ldHdvcmssIHdoaWNoIGlzIGFuIGhpc3RvcmljYWwgc3RlcCB0b3dhcmQgdGhlIElU
L09UIGNvbnZlcmdlbmNlLCB0aGF0IGlzIHRoZSBJbmR1c3RyaWFsIGVxdWl2YWxlbnQgb2Ygdm9p
Y2UgYW5kIHZpZGVvIGNvbnZlcmdlbmNlIG92ZXIgSVAuDQoNCkFuZCBhbHNvIHRvIG15IGJlc3Qg
a25vd2xlZGdlIGFuZCBjb25mb3JtaW5nIFJGQyAzNjk3LCBJU0ExMDAuMTFhIGRvZXMgbm90IG11
dGUgdGhlIEZsb3cgTGFiZWwgaW5zaWRlIHRoZSBuZXR3b3JrLCBhcyBNaWNoYWVsIHBvaW50cyBv
dXQuIE9ubHkgd2hlbiB0aGUgYWRkaXRpb25hbCBiYWNrYm9uZSBSb3V0ZXIgZnVuY3Rpb25hbGl0
eSBpcyBkZWZpbmVkIGRvZXMgdGhlIHByb2JsZW0gb2YgcmV3cml0aW5nIGNvbWUgaW50byBwbGF5
IGF0IHRoZSBCYWNrYm9uZSBSb3V0ZXIgKHNhbWUgcG9zaXRpb24gYXMgUlBMIHJvb3QpLiBGb3Ig
YWxsIEkga25vdyB0aGlzIHdvcmsgaXMgdGFraW5nIHBsYWNlIGF0IHRoZSBXaXJlbGVzcyBDb21w
bGlhbmNlIEluc3RpdHV0ZSwgV0NJLCBidXQgSSBkbyBub3QgaGF2ZSB0aGUgbGF0ZXN0Lg0KDQpD
aGVlcnMsDQoNClBhc2NhbA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv
bTogQnJpYW4gRSBDYXJwZW50ZXIgW21haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb21d
DQo+IFNlbnQ6IHNhbWVkaSAxNiBhb8O7dCAyMDE0IDAzOjEzDQo+IFRvOiBQYXNjYWwgVGh1YmVy
dCAocHRodWJlcnQpDQo+IENjOiBQaGlsaXAgTGV2aXM7IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIg
YW5kIExvc3N5IG5ldHdvcmtzOyBJbmVzIFJvYmxlczsNCj4gNm1hbiBXRzsgNmxvQGlldGYub3Jn
IFdHDQo+IFN1YmplY3Q6IFJlOiBbUm9sbF0gWzZsb10gV0dMQyBmb3IgZHJhZnQtdGh1YmVydC02
bWFuLWZsb3ctbGFiZWwtZm9yLXJwbC0wMw0KPiANCj4gT24gMTUvMDgvMjAxNCAyMDo1MSwgUGFz
Y2FsIFRodWJlcnQgKHB0aHViZXJ0KSB3cm90ZToNCj4gPiBIZWxsbyBCcmlhbg0KPiA+DQo+ID4g
SSBkbyBub3QgdGhpbmsgdGhhdCBJU0ExMDAxMS5hIHZpb2xhdGVzIFJGQyAzNjk3LiBXaGF0IGV4
YWN0bHkgbWFkZSB5b3UNCj4gYmVsaWV2ZSBzbz8NCj4gDQo+IEkgd2FzIG92ZXItaW50ZXJwcmV0
aW5nIHdoYXQgeW91IHdyb3RlLCBJIGd1ZXNzLiBJdCdzIHRydWUgdGhhdCAzNjk3IHdhcyByYXRo
ZXINCj4gdmFndWUgYWJvdXQgd2hhdCBpdCBjYWxsZWQgImZsb3cgc3RhdGUgZXN0YWJsaXNobWVu
dCBtZXRob2RzIiBhbmQNCj4gcGVybWl0dGVkIGJvdGggc2VxdWVudGlhbCBhbmQgcHNldWRvLXJh
bmRvbSBmbG93IGxhYmVsIHZhbHVlcy4gSXMgdGhlDQo+IElTQTEwMDExLmEgb24gbGluZSBzb21l
d2hlcmU/DQo+IA0KPiA+IEZvciBhbGwgSSBrbm93IElTQTEwMCBkb2VzIGV2ZXJ5dGhpbmcgYnkg
dGhlIGJvb2suIE5vdGUgdGhhdCBJU0ExMDAgZG9lcw0KPiBub3QgdXBkYXRlIGEgbm9uIHplcm8g
Rkwgb24gdGhlIGZseSBzaW5jZSBpdCBpcyBub3Qgc2V0IGJ5IGEgc291cmNlIG91dHNpZGUgdGhl
DQo+IExMTiBpZiB0aGF0IGlzIHlvdXIgY29uY2Vybi4NCj4gPg0KPiA+IE9UT0ggSXQgbWF5IHZp
b2xhdGUgUkZDIDY0MzcgaW4gdGhhdCB0aGUgZmxvdyBpcyBub3QgYSByYW5kb20gYnV0IGEgdmFs
dWUNCj4gYXR0cmlidXRlZCBieSBhIFBDRSBjYWxsZWQgc3lzdGVtIG1hbmFnZXIgKGFsb25nIHJ1
bGVzIGluIHNlY3Rpb24gNCkuIEFzDQo+IHRoaW5ncyBzdGFuZCwgd2UnZCBjZXJ0YWlubHkgd2Fu
dCB0aGUgYmFja2JvbmUgcm91dGVyIGF0IExMTiBlZ3Jlc3MgdG8NCj4gcmV3cml0ZSB0aGUgRkwg
aW4gcGFja2V0cyB0b3dhcmRzIHRoZSBJbnRlcm5ldCB3aXRoIGEgcmFuZG9taXplZCBwZXIgZmxv
dw0KPiB2YWx1ZS4NCj4gPg0KPiA+IEl0IHdpbGwgdmlvbGF0ZSBSRkMgNjQzNyBiZWNhdXNlIGlm
IHRoZSBmbG93IGxhYmVsIGlzIHNldCBieSBhIHJvdXRlciBpbiB0aGUNCj4gSW50ZXJuZXQgLSBv
ciBhbiB1cGRhdGVkIHNvdXJjZSB0aGF0IGNvbXBsaWVzIHRvIDY0MzctLCB0aGUgYmFja2JvbmUg
cm91dGVyDQo+IGF0IExMTiBJbmdyZXNzIHdpbGwgcmV3cml0ZSBpdC4NCj4gPg0KPiA+IEJvdGgg
aXNzdWVzIGFyZSBhZGRyZXNzZWQgaW4gbXkgZHJhZnQgZm9yIGEgUlBMIGRvbWFpbi4gQW4gUkZD
IHdpbGwgYWxzbw0KPiBoaW50IGEgcmV2aXNpb24gb2YgdGhlIGJhY2tib25lIHJvdXRlciB0aGF0
IGl0IHNob3VsZCByZXdyaXRlIHRoZSBGTCBvbg0KPiBvdXRnb2luZyBwYWNrZXRzLg0KPiA+DQo+
ID4gV2hhdCBkbyB5b3UgdGhpbms/DQo+IA0KPiBJIHRoaW5rIHRoYXQgUGhpbCdzIGxhc3QgbWVz
c2FnZSBmcmFtZXMgdGhlIHF1ZXN0aW9uIHRvIDZtYW4gY29ycmVjdGx5LCBzbyBJDQo+IHdpbGwg
cmVzcG9uZCB0byBoaW0uLi4NCj4gDQo+IFJlZ2FyZHMNCj4gICAgIEJyaWFuDQo+ID4NCj4gPiBQ
YXNjYWwNCj4gPg0KPiA+PiBMZSAxNCBhb8O7dCAyMDE0IMOgIDIyOjE4LCAiQnJpYW4gRSBDYXJw
ZW50ZXIiDQo+IDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IGEgw6ljcml0IDoNCj4gPj4N
Cj4gPj4+IE9uIDE0LzA4LzIwMTQgMjI6MjgsIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgd3Jv
dGU6DQo+ID4+PiBXZSBjYW4gbGl2ZSB3aXRoIHRoaXMgQnJpYW4sDQo+ID4+Pg0KPiA+Pj4gYnV0
IHRoZW4gSSBjYW4gd2UgYWRkIGF0IGxlYXN0IGFuIElTQTEwMC4xMWEgbmV0d29yaz8gSVNBMTAw
LjExYSB3YXMNCj4gZGVzaWduZWQgaW4gMjAwNy84LCBhZG9wdGVkIElQdjYgYW5kIDZMb1dQQU4s
IGFuZCB1c2VzIHRoZSBJUHY2IGZsb3cgbGFiZWwNCj4gdG8gaW5kaWNhdGUgd2hpY2ggZmxvdyBh
IHBhY2tldCBiZWxvbmdzIHRvLg0KPiA+PiBJIGhhdmUgbm8gaWRlYSB3aGF0IElTQTEwMC4xMWEg
aXMgb3Igd2hpY2ggb3JnYW5pc2F0aW9uIGRldmVsb3BlZCBpdCwNCj4gPj4gYnV0IGl0IHNvdW5k
cyBsaWtlIGEgdmlvbGF0aW9uIG9mIHRoZSBmbG93IGxhYmVsIHN0YW5kYXJkIGF0IHRoYXQNCj4g
Pj4gdGltZSAoUkZDIDM2OTcpLiBJZiBJJ2Qga25vd24gYWJvdXQgaXQsIHdlIHdvdWxkIHByb2Jh
Ymx5IGhhdmUNCj4gPj4gaW5jbHVkZWQgaXQgaW4gdGhlIG1lbmFnZXJpZSBvZiBSRkMgNjI5NC4N
Cj4gPj4NCj4gPj4gVGhlcmUncyBub3QgbXVjaCB0aGUgSUVURiBjYW4gZG8gYWJvdXQgb3RoZXIg
b3JnYW5pc2F0aW9ucyB0aGF0DQo+ID4+IG1pc3VzZSBvdXIgc3RhbmRhcmRzLCBhbHRob3VnaCBp
bmRlZWQgd2Ugc29tZXRpbWVzIG5lZWQgdG8gZG9jdW1lbnQNCj4gPj4gc3VjaCBjYXNlcy4NCj4g
Pj4NCj4gPj4gICBCcmlhbg0KPiA+Pg0KPiA+Pg0KPiA+PiBJbiBtb3JlIGRldGFpbHMsIGRldmlj
ZXMgYXJlIHByb3Zpc2lvbmVkIHdpdGggcGVyLWZsb3cgYmVoYXZpb3IgKGluY2x1ZGluZw0KPiBy
b3V0aW5nKSBhbmQgc2V0dGluZ3MgaW4gd2hhdCBpcyBjYWxsZWQgYSBjb250cmFjdC4NCj4gPj4g
VGhlIGNvbnRyYWN0SUQgaXMgY2FycmllZCBpbiB0aGUgSVB2NiBmbG93IGxhYmVsLg0KPiA+Pj4g
SWYgc28gc2hvdWxkIHdlIG5hbWUgSVNBMTAwIHNwZWNpZmljYWxseSBvciB1c2UgYSBtb3JlIHZh
Z3VlIGRlc2NyaXB0aW9uDQo+IGxpa2UgYSAiUlBMIG9yIHNpbWlsYXIgTExOIGRvbWFpbiINCj4g
Pj4+IFdlJ2xsIG5vdGUgdGhhdCByZXNldHRpbmcgYW4gZmxvdyBsYWJlbCB0aGF0IGNvbWVzIGZy
b20gdGhlIEludGVybmV0DQo+ID4+PiBpcyBhIGdlbmVyaWMgbmVlZCBpcyB0aGF0IGZsb3cgbGFi
ZWwgd2FzIHNldCBhY2NvcmRpbmcgdG8gNjQzNywNCj4gPj4+IGNhbm5vdCBiZSB0cnVzdGVkIHRv
IGJlIHVudGVtcGVyZWQgd2l0aCwNCj4gPj4+DQo+ID4+PiBDaGVlcnMsDQo+ID4+Pg0KPiA+Pj4g
UGFzY2FsDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
PiA+Pj4+IEZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs
ZiBPZiBCcmlhbiBFDQo+ID4+Pj4gQ2FycGVudGVyDQo+ID4+Pj4gU2VudDogbWVyY3JlZGkgMTMg
YW/Du3QgMjAxNCAyMjo1Mw0KPiA+Pj4+IFRvOiBQaGlsaXAgTGV2aXMNCj4gPj4+PiBDYzogUm91
dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3M7IEluZXMgUm9ibGVzOyA2bWFu
DQo+ID4+Pj4gV0c7IDZsb0BpZXRmLm9yZyBXRw0KPiA+Pj4+IFN1YmplY3Q6IFJlOiBbUm9sbF0g
WzZsb10gV0dMQyBmb3INCj4gPj4+PiBkcmFmdC10aHViZXJ0LTZtYW4tZmxvdy1sYWJlbC1mb3It
cnBsLTAzDQo+ID4+Pj4NCj4gPj4+Pj4gT24gMTQvMDgvMjAxNCAwNzowNywgUGhpbGlwIExldmlz
IHdyb3RlOg0KPiA+Pj4+PiBPbiBBdWcgMTMsIDIwMTQsIGF0IDk6NDggQU0sIFBhc2NhbCBUaHVi
ZXJ0IChwdGh1YmVydCkNCj4gPj4+PiA8cHRodWJlcnRAY2lzY28uY29tPiB3cm90ZToNCj4gPj4+
Pj4+IElmIHRoaXMgZHJhZnQgaXMgbm90IGFkb3B0ZWQsIHRoZSBmbG93IGxhYmVsIGZyb20gTExO
IHdpbGwNCj4gPj4+Pj4+IHByb2JhYmx5IHN0YXkgYWxsDQo+ID4+Pj4gemVyb2VzIGFzIGl0IGlz
IHRvZGF5IGFuZCB0aGUgZ29hbCBvZiA2NDM3IHdpbGwgbm90IGJlIGFjaGlldmVkLg0KPiA+Pj4+
PiBQYXNjYWwsIEknbSB0cnlpbmcgdG8gcmVjb25jaWxlIHlvdXIgY2xhaW0gdGhhdCB0aGUgZ29h
bCBvZiA2NDM3DQo+ID4+Pj4+IGlzIHRvIGFsbG93IGVuY2xvc2VkIG5ldHdvcmtzIHRvIHVzZSB0
aGUgZmxvdyBsYWJlbCB3aXRoIEJyaWFuJ3MNCj4gPj4+Pj4gc3RhdGVtZW50DQo+ID4+Pj4+DQo+
ID4+Pj4+PiBBY3R1YWxseSB0aGF0J3Mgd2h5IEkgZG9uJ3Qgd2FudCB0byBzZWUgYSBmb3JtYWwg
dXBkYXRlIHRvIDY0MzcsDQo+ID4+Pj4+PiBiZWNhdXNlIHRoZSBvbmx5IHJhdGlvbmFsIHVwZGF0
ZSB3b3VsZCBiZSB0byBhbGxvdyBhbnkgY2xvc2VkDQo+ID4+Pj4+PiBkb21haW4gdG8gaW52ZW50
IGl0cyBvd24gdXNhZ2UuIFdlIGhhZCB0aGF0IGFyZ3VtZW50IGF0IGxlbmd0aA0KPiA+Pj4+Pj4g
ZHVyaW5nIHRoZSBkZXZlbG9wbWVudCBvZiA2NDM3LCBhbmQgZGVjaWRlZCBhZ2FpbnN0IGl0Lg0K
PiA+Pj4+PiBQaGlsDQo+ID4+Pj4gUmlnaHQuIEknbSBkcmF3aW5nIGEgdmVyeSBzdWJ0bGUgbGlu
ZSBiZXR3ZWVuIChhKSBzdGF0aW5nIGFuDQo+ID4+Pj4gZXhjZXB0aW9uIHRvIDY0MzcgZm9yIHRo
aXMgcGFydGljdWxhciB1c2FnZSBhbmQgKGIpIG9wZW5pbmcgdGhlDQo+ID4+Pj4gZG9vciB0byBv
dGhlciB1c2FnZXMuIFNpbmNlIDZtYW4gY2xlYXJseSBkaWRuJ3Qgd2FudCAoYikgZHVyaW5nIHRo
ZQ0KPiA+Pj4+IGRldmVsb3BtZW50IG9mDQo+ID4+Pj4gNjQzNyBJIHRoaW5rIHdlIGRvIG5lZWQg
dG8gbGltaXQgb3Vyc2VsdmVzIHRvIChhKS4NCj4gPj4+Pg0KPiA+Pj4+ICAgIEJyaWFuDQo+ID4+
Pj4NCj4gPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pj4gLSBJRVRGIElQdjYgd29ya2luZyBncm91cCBt
YWlsaW5nIGxpc3QgaXB2NkBpZXRmLm9yZyBBZG1pbmlzdHJhdGl2ZQ0KPiA+Pj4+IFJlcXVlc3Rz
OiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gPj4+PiAtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQo+ID4+Pj4gLQ0KPiA+DQoNCg==


From nobody Mon Aug 18 10:27:34 2014
Return-Path: <v6ops@globis.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0F01A0702; Mon, 18 Aug 2014 10:27:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.969
X-Spam-Level: 
X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_51=0.6, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
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 j5rf4Ij21BiF; Mon, 18 Aug 2014 10:27:23 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA2C1A06FE; Mon, 18 Aug 2014 10:27:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 24F5D87153A; Mon, 18 Aug 2014 19:27:22 +0200 (CEST)
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8cOLHoESt9b; Mon, 18 Aug 2014 19:27:22 +0200 (CEST)
Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:d08:e91:f56:fe00]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id D2989871519; Mon, 18 Aug 2014 19:27:21 +0200 (CEST)
Message-ID: <53F2375E.6000501@globis.net>
Date: Mon, 18 Aug 2014 19:26:54 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53EE6441.1000908@globis.net> <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu> <53EEFEEE.8020505@globis.net> <53EFB719.70508@gmail.com> <53F07B55.7050708@globis.net> <53F10959.2000102@gmail.com>
In-Reply-To: <53F10959.2000102@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/T1Xkdotheprx7t9at-Kjh0r436E
Cc: roll <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Aug 2014 17:27:29 -0000

> Brian E Carpenter <mailto:brian.e.carpenter@gmail.com>
> 17 August 2014 21:58
> On 17/08/2014 21:52, Ray Hunter wrote:
>>> Brian E Carpenter<mailto:brian.e.carpenter@gmail.com>
>>> 16 August 2014 21:55
>>> Ray,
>>>
>>> On 16/08/2014 18:49, Ray Hunter wrote:
>>>>> Philip Levis<mailto:pal@cs.stanford.edu>
>>>>> 16 August 2014 02:33
>>>>>
>>>>> 1) There is an extension header already; the problem is that it can
>>>>> introduce a significant (ballpark estimates are, in well engineered
>>>>> networks, up to 5-10%) cost. The proposal is to replace the extension
>>>>> header with using the flow label.
>>>>>
>>>>> 2) There'a already significant IP header compression in the cases
>>>>> we're talking about.
>>>>>
>>>>> Phil
>>>> I'm sympathetic to the needs of low power devices.
>>>>
>>>> However, to be clear, we are reengineering a standards track document
>>>> that is around 2 years old (http://tools.ietf.org/html/rfc6553), and
>>>> which works technically, and we are proposing an additional encoding of
>>>> exactly the same information to achieve theoretical efficiency gains
>>>> that are still only rough estimates?
>>>>
>>>> Where's the experimental proof that this will really pay off in
>>>> increased battery life?
>>>>
>>>> You write "replace". Will 6553 now be deprecated?
>>>>
>>>> If not we'll have:
>>>>
>>>> 6553 to carry RPL information as an option header.
>>>>
>>>> draft-thubert-6man-flow-label-for-rpl-03 to carry RPL information as a
>>>> flow label
>>>>
>>>> flow label information used to select patch and load balancing in
>>>> multi-path networks. e.g.
>>>> http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5349203&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5349203
>>>>
>>>>
>>>> http://tools.ietf.org/html/rfc6438
>>>> http://tools.ietf.org/html/rfc7098
>>>>
>>>> I do not see that these applications for this one field are mutually
>>>> compatible, and worse still, the only way to decode the semantics of the
>>>> overloaded field is by applying some unknown external context ("within
>>>> RPL domain"/ "on the Internet").
>>> No, I don't see a problem there. The boundary of a RPL domain is
>>> very well defined and flow-label-for-rpl clearly specifies that
>>> outside that boundary, RFC 6437 applies (which enables RFC 6438
>>> and 7098).
>> But inside an RPL domain, you cannot use any RFC's that reference the
>> flow label as per 6437, because all of the entropy has gone.
>
> Correct. But isn't that a trade-off that might be reasonable in
> the low-power lossy environment? (That's not intended as a rhetorical
> question - I just don't have enough knowledge of that environment
> to answer it.)
I would prefer to avoid making the trade off if we don't have to. Who 
knows what future application will use the flow label?

I'm no RPL expert, but 
http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-01 seems more 
elegant and avoids all of this discussion.
>> And what happened to our end to end architecture?
>
> There are various views of what e2e means, but I still like the
> phrase "certain required end-to-end functions can only be performed
> correctly by the end-systems themselves". Load balancing and adaptive
> routing are not actually e2e functions in that sense.
>
>> I just do not like the concept of parsing a packet, and then having to
>> determine the semantics of the contents of a particular field based on a
>> "domain" that is not carried anywhere in the packet.
>
> I see the objection, but we've been doing it for years; diffserv does
> it by definition.
>
>     Brian
Agreed. But that is also largely being overtaken by MPLS Traffic 
Engineering, precisely so you can have an extensible label stack, or 
nest QoS domains, whilst still easily accessing the required label info 
at all points along the forwarding path.
>> e.g. think about decoding offline captures
>
>>>> The hidden "cost" here is that we will have 3 different overlapping
>>>> solutions = code bloat and potentially a lot of additional processing to
>>>> locate the correct information and then process it, which is also a hit
>>>> on energy efficiency.
>>>>
>>>> IMHO the bar should be pretty high for accepting this proposal, as it is
>>>> not actually solving a tangible issue.
>>> Whether ROLL wants to endorse alternative methods within RPL
>>> domains is not a 6man question.
>>>> Also my prediction of the next request for field overloading will be:
>>>> My ISP only delegates one /64 with PD
>>>> I have multiple links in my Homenet
>>>> All my media is EUI48 based. No one really uses EUI64.
>>>> I want to rewrite the 16 spare bits in SLAAC ("FF:FE") and use this for
>>>> routing in Homenet by encoding a (V)LAN ID in it.
>>>> It's OK though. Homenet is a walled garden and I'll rewrite the field at
>>>> the exit so no one will ever know.
>>> Nice strawman, but why is it relevant? There's no need to rewrite
>>> the bits, BTW. As RFC 7136 says:
>>> "However, the method of generating IIDs for specific link types MAY
>>> define some local significance for certain bits... the whole IID value
>>> MUST be viewed as an opaque bit string by third parties, except possibly
>>> in the local context."
>>>
>>>      Brian
>>>
>>>> As an alternative: if this information is really RPL specific, why not
>>>> just add the RPL Information as a tag to the front of the packet e.g.
>>>> via an MPLS label?
>>>>
>>>> MPLS labels are only 4 octets, and are designed to be very efficient and
>>>> fast.
>>>> You can easily strip them at egress, and munge it/set it on ingress.
>>>> It's clear where an MPLS domain ends and starts: no chance of RPL
>>>> information leaking onto the Internet, or entering from the Internet.
>>>> The MPLS label also transports the 20 bits of information you need.
>>>> MPLS labels are at a clear fixed position in the packet and are easy and
>>>> efficient to parse.
>>>> You could also then nest RPL domains if you ever wanted to do that.
>>>> It's also extensible, as you can push more labels on the stack in the
>>>> future if you ever want to extend the RPL Information transported,
>>>> whereas the flow label is a single fixed field.
>>>> It does not require any new standard, except maybe an informational RFC
>>>> on how to encode the RPL Information into MPLS labels.
>>>> And it doesn't overload anything.
>>>>
>>>> regards,
>>>>
>>>>> Ray Hunter<mailto:v6ops@globis.net>
>>>>> 15 August 2014 21:49
>>>>>
>>>>>
>>>>>
>>>>> +1
>>>>>
>>>>> Apologies for tardy response (holidays)
>>>>>
>>>>> After reading the draft it seems to me that what is being attempted is
>>>>> 1) to add some stuff to the IPv6 header that is RPL domain specific
>>>>> 2) to reduce the overall packet length to reduce active radio time and
>>>>> thus save energy
>>>>> by
>>>>> 3) overloading an existing well-defined and used IPv6 header field
>>>>>
>>>>> My simple logic tells me that
>>>>> 1) could be best solved at an architecture level via an extension
>>>>> header http://tools.ietf.org/html/rfc2460#page-11 +
>>>>> http://tools.ietf.org/html/rfc7045
>>>>> 2) could be best solved at an architecture level via IP header
>>>>> compression http://tools.ietf.org/html/rfc2507.html with or without
>>>>> additional tweaks
>>>>> and that overloading an opaque field in 3) by incorporating values
>>>>> with low entropy (as per the RPL flow label) gives additional security
>>>>> risks to http://tools.ietf.org/html/rfc7098
>>>>>
>>>>> So what's wrong with my simple logic?
>>>>>
>>>>> "But if we consider the whole RPL domain as a large virtual host from
>>>>> the standpoint of the rest of the Internet" would suggest to me that
>>>>> the cost of stripping out the additional IPv6 hop by hop extension
>>>>> header at the edge of the domain is a bogus argument, as you'll anyway
>>>>> have to provide some adaption and security at the root of each RPL
>>>>> domain to detect and bounce spoofed RPL Information from entering, or
>>>>> private RPL Information leaking out of each domain. Whether this
>>>>> domain-specificRPL Information is encoded in an explicit hop by hop
>>>>> option or an overloaded flow label would seem largely irrelevant to
>>>>> that operation at the RPL root (especially since the RPL root anyway
>>>>> has to be a high power node to be able communicate with the rest of
>>>>> the Internet).
>>>>>
>>>>> IMHO If you overload the flow label you're looking at creating an
>>>>> incompatible walled garden, with competing IETF standards that are
>>>>> mutually exclusive.
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>> ------------------------------------------------------------------------
>

-- 
Regards,
RayH


From nobody Mon Aug 18 14:20:23 2014
Return-Path: <mcr@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D36F1A6F96; Mon, 18 Aug 2014 14:20:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.559
X-Spam-Level: 
X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
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 CrqT3rY-qxeM; Mon, 18 Aug 2014 14:20:18 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1811A6F9A; Mon, 18 Aug 2014 14:20:18 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B260020028; Mon, 18 Aug 2014 17:23:27 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 6FFC463AC9; Mon, 18 Aug 2014 17:20:16 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 59695638D7; Mon, 18 Aug 2014 17:20:16 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Ray Hunter <v6ops@globis.net>
Subject: Re: WGLC for draft-thubert-6man-flow-label-for-rpl-03
In-Reply-To: <53F2375E.6000501@globis.net>
References: <CAP+sJUeLa9r2otVv41ezg1Om--XzM84w3MOvCyn7bawDA7Oqgw@mail.gmail.com> <69656203-C009-4ABE-BCAD-17622058FEB9@cs.stanford.edu> <53D84C2C.9050709@gmail.com> <140F7EAF-B3B2-4F39-B676-5901457BF494@cs.stanford.edu> <CAMsDxWQTMBWS6GY7q5cT9FVds-obdE45PiLWVEqbV8HMpjbSsA@mail.gmail.com> <47417131-2393-4083-B904-E1983D6AAAA6@tzi.org> <53EE6441.1000908@globis.net> <6ECB70BE-13A7-4C23-B182-C4F0AC2B73D1@cs.stanford.edu> <53EEFEEE.8020505@globis.net> <53EFB719.70508@gmail.com> <53F07B55.7050708@globis.net> <53F10959.2000102@gmail.com> <53F2375E.6000501@globis.net>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Mon, 18 Aug 2014 17:20:16 -0400
Message-ID: <7414.1408396816@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/aC2offo6Cm5qX3HVJRfHVbYg2OI
Cc: roll <roll@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Aug 2014 21:20:20 -0000

--=-=-=


I just want to point out that the RPL Instance ID isn't used for routing
like the MPLS label. RPL nodes still do longest prefix match routing
on IPv6 destination address.

If you had to make an analogy to other technology, it's more like a VLAN
tag being used to pick a virtual router/routing table.

> I would prefer to avoid making the trade off if we don't have to. Who knows
> what future application will use the flow label?

Yes, my response is: "hi, we are the future. Do you mind if we use that
     thing you reserved for us?"

> I'm no RPL expert, but
> http://tools.ietf.org/html/draft-bormann-6lo-rpl-mesh-01 seems more elegant
> and avoids all of this discussion.

6lo-rpl-mesh is certainly merits discussion.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-




--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEVAwUBU/JuDoCLcPvd0N1lAQLk5Qf/TfASntPM7m7Cwx3WXGnDGdVrVEm5CZIn
fSN65SynSQrOWJiV5TYYErt1KU0LzLGrrHLe4d3D2lvi5esm9zd8eunY2enFnMS8
btyxs1UH/NlbPc8hs9tb6xAq5XYg90sq8P/k1abyY7LoLax8m9jqIgdJaFs8XpTQ
waKIpeEX/WKTPlyYx65/O6l8fNCvKKB58c/9E4iKZQBQEBYQxkPTDMsi7X5AU/ny
g+ImUKGB2TmS2ktwjsmeBmKiuFRPtAXgAf/3bNkN5r1KpN8+5Bgl9KxG6pjDo8tW
vSYFsVCKm/lCnvWv1nc9/29zWZl+gfiPZYaAV40tC0T3XY2ElWmHUA==
=aZPW
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Mon Aug 18 17:54:22 2014
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2FC1A8725; Mon, 18 Aug 2014 17:54:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 4Kh3JRqYAfHn; Mon, 18 Aug 2014 17:54:20 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFC41A874D; Mon, 18 Aug 2014 17:54:18 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'Updates to the IPv6 Multicast Addressing Architecture' to Proposed Standard (draft-ietf-6man-multicast-addr-arch-update-08.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p5
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140819005418.4387.68098.idtracker@ietfa.amsl.com>
Date: Mon, 18 Aug 2014 17:54:18 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/XCBCq0xWjlPqipQ3H1MlZi1GETA
Cc: 6man chair <6man-chairs@tools.ietf.org>, 6man mailing list <ipv6@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 00:54:21 -0000

The IESG has approved the following document:
- 'Updates to the IPv6 Multicast Addressing Architecture'
  (draft-ietf-6man-multicast-addr-arch-update-08.txt) as Proposed
Standard

This document is the product of the IPv6 Maintenance Working Group.

The IESG contact persons are Brian Haberman and Ted Lemon.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-6man-multicast-addr-arch-update/




Technical Summary

  This document updates the IPv6 multicast addressing architecture by
  defining the 17-20 reserved bits as generic flag bits.  The document
  provides also some clarifications related to the use of these flag
  bits.

Working Group Summary

  This work was taken over by 6MAN since it changes the IPv6
  addressing architecture, after initially starting out in MBONED.
  See
  https://datatracker.ietf.org/doc/draft-ietf-mboned-64-multicast-address-format/writeup/

Document Quality

  The 6man working group appoints reviewers for all documents being
  advanced to the IESG. This document has been reviewed in detail by
  Jinmei Tetsuya. In addition to the chair's and shepherd's review.

Personnel

  Document Shepherd: Ole Troan
  Responsible Area Director: Brian Haberman


From nobody Tue Aug 19 07:51:47 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDB51A891F; Tue, 19 Aug 2014 07:51:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 g900IMSb-OL1; Tue, 19 Aug 2014 07:51:43 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3971A03AC; Tue, 19 Aug 2014 07:51:43 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XJkkq-0004e3-Kw; Tue, 19 Aug 2014 16:51:41 +0200
Message-ID: <53F36432.8090108@si6networks.com>
Date: Tue, 19 Aug 2014 11:50:26 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "6man@ietf.org" <6man@ietf.org>
Subject: Deprecating the Generation of IPv6 Atomic Fragments (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-00.txt)
References: <20140819144703.13248.62145.idtracker@ietfa.amsl.com>
In-Reply-To: <20140819144703.13248.62145.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20140819144703.13248.62145.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/FuCxPl1wkJjqmsLBIYcLItsaszY
Cc: IPv6 Operations <v6ops@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 14:51:45 -0000

Folks,

FYI, this is
<http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-00.txt>
our Std-track "patch" to fix this:
<http://www.ietf.org/mail-archive/web/v6ops/current/msg19746.html>

Comments welcome ;-)

Thanks!
Fernando




-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-6man-deprecate-atomfrag-generation-00.txt
Date: Tue, 19 Aug 2014 07:47:03 -0700
From: internet-drafts@ietf.org
To: Fernando Gont <fgont@si6networks.com>, Will(Shucheng) Liu
<liushucheng@huawei.com>, Fernando Gont <fgont@si6networks.com>,
Shucheng LIU (Will) <liushucheng@huawei.com>


A new version of I-D, draft-gont-6man-deprecate-atomfrag-generation-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-6man-deprecate-atomfrag-generation
Revision:	00
Title:		Deprecating the Generation of IPv6 Atomic Fragments
Document date:	2014-08-19
Group:		Individual Submission
Pages:		7
URL:
http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-00.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-6man-deprecate-atomfrag-generation/
Htmlized:
http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00


Abstract:
   The core IPv6 specification requires that when a host receives an
   ICMPv6 "Packet Too Big" message reporting a "Next-Hop MTU" smaller
   than 1280, the host includes a Fragment Header in all subsequent
   packets sent to that destination, without reducing the assumed Path-
   MTU.  The simplicity with which ICMPv6 "Packet Too Big" messages can
   be forged, coupled with the widespread filtering of IPv6 fragments,
   results in an attack vector that can be leveraged for Denial of
   Service purposes.  This document briefly discusses the aforementioned
   attack vector, and formally deprecates the generation of IPv6 atomic
   fragments, such that the aforementioned attack vector is eliminated.





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

The IETF Secretariat





From nobody Tue Aug 19 08:14:47 2014
Return-Path: <antonios.atlasis@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E3A1A03DF; Tue, 19 Aug 2014 08:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 D0Z3AjqAXyEd; Tue, 19 Aug 2014 08:14:44 -0700 (PDT)
Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147391A03BD; Tue, 19 Aug 2014 08:14:44 -0700 (PDT)
Received: by mail-oi0-f46.google.com with SMTP id i138so4663130oig.5 for <multiple recipients>; Tue, 19 Aug 2014 08:14:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BqeXDf8B8BqNYbKcYmPhdZbXvTtjL7dxbNCJIHF1+VE=; b=Hye3VOmDA03BH3mbAX3NMbuhDANc4aZvCJrDl9ENOO6C2UTM6CH5clTbVK8Z8QrWTR Fu1mXOmlU07Dcdh++okQ9etXms6KYdk8cBs5tMjnXHUTOZL++Lekull90OLQOupHZxor rYT1A8aqA0ChtTQqCj/U74NNDdWfc4QJA6zcfmhdd0U2PUiw5GmLfcZg5VuiX1cxWP2i KRlDb7fm3HlWMyLFMyFLr5OfZdKvjqxUo6GPhRejFGRqcT89qp3vCidstuI3RgQjR87I is9dol5H+YiikQ7QrNHq6yd9FwXF97uRsy/E65sqCgNP2GZeX97qZeGvnnYOif3BOE8J 7c6w==
MIME-Version: 1.0
X-Received: by 10.182.112.134 with SMTP id iq6mr42751248obb.34.1408461283451;  Tue, 19 Aug 2014 08:14:43 -0700 (PDT)
Received: by 10.202.206.212 with HTTP; Tue, 19 Aug 2014 08:14:43 -0700 (PDT)
In-Reply-To: <53F36432.8090108@si6networks.com>
References: <20140819144703.13248.62145.idtracker@ietfa.amsl.com> <53F36432.8090108@si6networks.com>
Date: Tue, 19 Aug 2014 18:14:43 +0300
Message-ID: <CADoTVZ+LYOO1qH57eWdfQ7w7ASX-ycS__GNqquWgDnxS7O8Bvg@mail.gmail.com>
Subject: Re: Deprecating the Generation of IPv6 Atomic Fragments (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-00.txt)
From: Antonios Atlasis <antonios.atlasis@gmail.com>
To: Fernando Gont <fgont@si6networks.com>, 6man@ietf.org
Content-Type: multipart/alternative; boundary=089e0149cf607aec600500fcf270
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/mqtGiffyYvFKh2gfcSZb7_6jjjY
Cc: v6ops@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 15:14:46 -0000

--089e0149cf607aec600500fcf270
Content-Type: text/plain; charset=UTF-8

Hi,

regarding the second paragraph of section 5, I thought that the fragment
ID, included both in the IPv6 atomic fragments (the half of the ID
actually) and in the IPv4 header was necessary to track the end-to-end
connection. If a fragment ID is used only in the IPv4 part of the
end-to-end path, how does IPv6-to-IPv4 translation node is going to track
the end-to-end connection? Unless I miss sthg here.

Best

Antonios


2014-08-19 17:50 GMT+03:00 Fernando Gont <fgont@si6networks.com>:

> Folks,
>
> FYI, this is
> <
> http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-00.txt
> >
> our Std-track "patch" to fix this:
> <http://www.ietf.org/mail-archive/web/v6ops/current/msg19746.html>
>
> Comments welcome ;-)
>
> Thanks!
> Fernando
>
>
>
>
> -------- Forwarded Message --------
> Subject: New Version Notification for
> draft-gont-6man-deprecate-atomfrag-generation-00.txt
> Date: Tue, 19 Aug 2014 07:47:03 -0700
> From: internet-drafts@ietf.org
> To: Fernando Gont <fgont@si6networks.com>, Will(Shucheng) Liu
> <liushucheng@huawei.com>, Fernando Gont <fgont@si6networks.com>,
> Shucheng LIU (Will) <liushucheng@huawei.com>
>
>
> A new version of I-D, draft-gont-6man-deprecate-atomfrag-generation-00.txt
> has been successfully submitted by Fernando Gont and posted to the
> IETF repository.
>
> Name:           draft-gont-6man-deprecate-atomfrag-generation
> Revision:       00
> Title:          Deprecating the Generation of IPv6 Atomic Fragments
> Document date:  2014-08-19
> Group:          Individual Submission
> Pages:          7
> URL:
>
> http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-00.txt
> Status:
>
> https://datatracker.ietf.org/doc/draft-gont-6man-deprecate-atomfrag-generation/
> Htmlized:
> http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-00
>
>
> Abstract:
>    The core IPv6 specification requires that when a host receives an
>    ICMPv6 "Packet Too Big" message reporting a "Next-Hop MTU" smaller
>    than 1280, the host includes a Fragment Header in all subsequent
>    packets sent to that destination, without reducing the assumed Path-
>    MTU.  The simplicity with which ICMPv6 "Packet Too Big" messages can
>    be forged, coupled with the widespread filtering of IPv6 fragments,
>    results in an attack vector that can be leveraged for Denial of
>    Service purposes.  This document briefly discusses the aforementioned
>    attack vector, and formally deprecates the generation of IPv6 atomic
>    fragments, such that the aforementioned attack vector is eliminated.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



-- 
=====================
Antonios Atlasis, PhD, MPhil
GXPN, GREM, GPEN, GWAPT, CCIH, GCIA

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

<div dir=3D"ltr"><div><div><div>Hi, <br><br></div>regarding the second para=
graph of section 5, I thought that the fragment ID, included both in the IP=
v6 atomic fragments (the half of the ID actually) and in the IPv4 header wa=
s necessary to track the end-to-end connection. If a fragment ID is used on=
ly in the IPv4 part of the end-to-end path, how does IPv6-to-IPv4 translati=
on node is going to track the end-to-end connection? Unless I miss sthg her=
e.<br>
<br></div></div>Best<br><br>Antonios<br></div><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">2014-08-19 17:50 GMT+03:00 Fernando Gont <=
span dir=3D"ltr">&lt;<a href=3D"mailto:fgont@si6networks.com" target=3D"_bl=
ank">fgont@si6networks.com</a>&gt;</span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Folks,<br>
<br>
FYI, this is<br>
&lt;<a href=3D"http://www.ietf.org/internet-drafts/draft-gont-6man-deprecat=
e-atomfrag-generation-00.txt" target=3D"_blank">http://www.ietf.org/interne=
t-drafts/draft-gont-6man-deprecate-atomfrag-generation-00.txt</a>&gt;<br>
our Std-track &quot;patch&quot; to fix this:<br>
&lt;<a href=3D"http://www.ietf.org/mail-archive/web/v6ops/current/msg19746.=
html" target=3D"_blank">http://www.ietf.org/mail-archive/web/v6ops/current/=
msg19746.html</a>&gt;<br>
<br>
Comments welcome ;-)<br>
<br>
Thanks!<br>
Fernando<br>
<br>
<br>
<br>
<br>
-------- Forwarded Message --------<br>
Subject: New Version Notification for<br>
draft-gont-6man-deprecate-atomfrag-generation-00.txt<br>
Date: Tue, 19 Aug 2014 07:47:03 -0700<br>
From: <a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org<=
/a><br>
To: Fernando Gont &lt;<a href=3D"mailto:fgont@si6networks.com">fgont@si6net=
works.com</a>&gt;, Will(Shucheng) Liu<br>
&lt;<a href=3D"mailto:liushucheng@huawei.com">liushucheng@huawei.com</a>&gt=
;, Fernando Gont &lt;<a href=3D"mailto:fgont@si6networks.com">fgont@si6netw=
orks.com</a>&gt;,<br>
Shucheng LIU (Will) &lt;<a href=3D"mailto:liushucheng@huawei.com">liushuche=
ng@huawei.com</a>&gt;<br>
<br>
<br>
A new version of I-D, draft-gont-6man-deprecate-atomfrag-generation-00.txt<=
br>
has been successfully submitted by Fernando Gont and posted to the<br>
IETF repository.<br>
<br>
Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-gont-6man-deprecate-ato=
mfrag-generation<br>
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000<br>
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Deprecating the Generation of IPv6=
 Atomic Fragments<br>
Document date:=C2=A0 2014-08-19<br>
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission<br>
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7<br>
URL:<br>
<a href=3D"http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-at=
omfrag-generation-00.txt" target=3D"_blank">http://www.ietf.org/internet-dr=
afts/draft-gont-6man-deprecate-atomfrag-generation-00.txt</a><br>
Status:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-gont-6man-deprecate-atomf=
rag-generation/" target=3D"_blank">https://datatracker.ietf.org/doc/draft-g=
ont-6man-deprecate-atomfrag-generation/</a><br>
Htmlized:<br>
<a href=3D"http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-ge=
neration-00" target=3D"_blank">http://tools.ietf.org/html/draft-gont-6man-d=
eprecate-atomfrag-generation-00</a><br>
<br>
<br>
Abstract:<br>
=C2=A0 =C2=A0The core IPv6 specification requires that when a host receives=
 an<br>
=C2=A0 =C2=A0ICMPv6 &quot;Packet Too Big&quot; message reporting a &quot;Ne=
xt-Hop MTU&quot; smaller<br>
=C2=A0 =C2=A0than 1280, the host includes a Fragment Header in all subseque=
nt<br>
=C2=A0 =C2=A0packets sent to that destination, without reducing the assumed=
 Path-<br>
=C2=A0 =C2=A0MTU.=C2=A0 The simplicity with which ICMPv6 &quot;Packet Too B=
ig&quot; messages can<br>
=C2=A0 =C2=A0be forged, coupled with the widespread filtering of IPv6 fragm=
ents,<br>
=C2=A0 =C2=A0results in an attack vector that can be leveraged for Denial o=
f<br>
=C2=A0 =C2=A0Service purposes.=C2=A0 This document briefly discusses the af=
orementioned<br>
=C2=A0 =C2=A0attack vector, and formally deprecates the generation of IPv6 =
atomic<br>
=C2=A0 =C2=A0fragments, such that the aforementioned attack vector is elimi=
nated.<br>
<br>
<br>
<br>
<br>
<br>
Please note that it may take a couple of minutes from the time of submissio=
n<br>
until the htmlized version and diff are available at <a href=3D"http://tool=
s.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br>
<br>
The IETF Secretariat<br>
<br>
<br>
<br>
<br>
--------------------------------------------------------------------<br>
IETF IPv6 working group mailing list<br>
<a href=3D"mailto:ipv6@ietf.org">ipv6@ietf.org</a><br>
Administrative Requests: <a href=3D"https://www.ietf.org/mailman/listinfo/i=
pv6" target=3D"_blank">https://www.ietf.org/mailman/listinfo/ipv6</a><br>
--------------------------------------------------------------------<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Antonios Atlasis, PhD, MPhil<=
br>
GXPN, GREM, GPEN, GWAPT, CCIH, GCIA
</div>

--089e0149cf607aec600500fcf270--


From nobody Tue Aug 19 08:19:31 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C211A03E3 for <ipv6@ietfa.amsl.com>; Tue, 19 Aug 2014 08:19:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 7m2ZzhGJ0CeJ for <ipv6@ietfa.amsl.com>; Tue, 19 Aug 2014 08:19:27 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6E6D1A03DF for <6man@ietf.org>; Tue, 19 Aug 2014 08:19:27 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XJlC2-0004oz-6a; Tue, 19 Aug 2014 17:19:26 +0200
Message-ID: <53F36AAB.9030700@si6networks.com>
Date: Tue, 19 Aug 2014 12:18:03 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Antonios Atlasis <antonios.atlasis@gmail.com>, 6man@ietf.org
Subject: Re: Deprecating the Generation of IPv6 Atomic Fragments (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-00.txt)
References: <20140819144703.13248.62145.idtracker@ietfa.amsl.com>	<53F36432.8090108@si6networks.com> <CADoTVZ+LYOO1qH57eWdfQ7w7ASX-ycS__GNqquWgDnxS7O8Bvg@mail.gmail.com>
In-Reply-To: <CADoTVZ+LYOO1qH57eWdfQ7w7ASX-ycS__GNqquWgDnxS7O8Bvg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/O2dwWtNRg2zVVfBnI17O1e3E1Do
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 15:19:29 -0000

Hi, Antonios, (v6ops removed)

On 08/19/2014 12:14 PM, Antonios Atlasis wrote:
> 
> regarding the second paragraph of section 5, I thought that the fragment
> ID, included both in the IPv6 atomic fragments (the half of the ID
> actually) and in the IPv4 header was necessary to track the end-to-end
> connection.

Never heard of that.

> If a fragment ID is used only in the IPv4 part of the
> end-to-end path, how does IPv6-to-IPv4 translation node is going to
> track the end-to-end connection? Unless I miss sthg here.

Same way as a NAT44 box does, if needed?  -- but not sure what you mean
by "track the end-to-end connection".

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Tue Aug 19 08:36:22 2014
Return-Path: <antonios.atlasis@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7AE1A0478 for <ipv6@ietfa.amsl.com>; Tue, 19 Aug 2014 08:36:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 tvKZ7UG1E9VI for <ipv6@ietfa.amsl.com>; Tue, 19 Aug 2014 08:36:16 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B891A04B7 for <6man@ietf.org>; Tue, 19 Aug 2014 08:35:48 -0700 (PDT)
Received: by mail-oi0-f50.google.com with SMTP id a141so4695927oig.37 for <6man@ietf.org>; Tue, 19 Aug 2014 08:35:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Met0YBkAIa84fzLcpvNEKUfywLsGtivbdZmznT0393Y=; b=Ei41mzU387rTC9fbQA3w92dj/29RwygMH1mW2niQzG5PImHrXR2SGC0ZL08+qIMD59 565jQPvoj0me39kmhtoCOFZrhcpt5OMybUFTMi26sYrx7wT/h1yzqB5b9M3CHEdb6xXY Ru6j+bmMUCY0GVifIB3Q2xY1lNxLq4iBU39u075GRHzTCkLTJMc+La+ejquztcIUavu3 dIOHcbOn3ye14+emMdtkMLb9+qwpwSuPpevVEVpDte59y18fKwaloNIUNI8Hb8b2+ccg PikYRBhtU1hO7NiXil536t6NiSs+fAkDLDO1RGJyW1mHViKQnTqtKYlzUuFJq4+fDSqu mngg==
MIME-Version: 1.0
X-Received: by 10.60.68.41 with SMTP id s9mr28138484oet.30.1408462548264; Tue, 19 Aug 2014 08:35:48 -0700 (PDT)
Received: by 10.202.206.212 with HTTP; Tue, 19 Aug 2014 08:35:48 -0700 (PDT)
In-Reply-To: <53F36AAB.9030700@si6networks.com>
References: <20140819144703.13248.62145.idtracker@ietfa.amsl.com> <53F36432.8090108@si6networks.com> <CADoTVZ+LYOO1qH57eWdfQ7w7ASX-ycS__GNqquWgDnxS7O8Bvg@mail.gmail.com> <53F36AAB.9030700@si6networks.com>
Date: Tue, 19 Aug 2014 18:35:48 +0300
Message-ID: <CADoTVZKt1z2RNBttxWq+hAZOzBmKYK+5OW-_AokCK3HtrEkXrA@mail.gmail.com>
Subject: Re: Deprecating the Generation of IPv6 Atomic Fragments (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-00.txt)
From: Antonios Atlasis <antonios.atlasis@gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary=001a11333570de6f030500fd3de6
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/8w8Sl6UKV2wcbQHmD7UfKCv_D48
Cc: 6man@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 15:36:18 -0000

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

I meant that based on the Fragment ID value, the translator can correspond,
if needed, the IPv6 unfragmented (but including an Atomic Fragment)
datagram to the fragmented IPv4 one, and vice versa, without needing any
other information or mechanism.


2014-08-19 18:18 GMT+03:00 Fernando Gont <fgont@si6networks.com>:

> Hi, Antonios, (v6ops removed)
>
> On 08/19/2014 12:14 PM, Antonios Atlasis wrote:
> >
> > regarding the second paragraph of section 5, I thought that the fragment
> > ID, included both in the IPv6 atomic fragments (the half of the ID
> > actually) and in the IPv4 header was necessary to track the end-to-end
> > connection.
>
> Never heard of that.
>
> > If a fragment ID is used only in the IPv4 part of the
> > end-to-end path, how does IPv6-to-IPv4 translation node is going to
> > track the end-to-end connection? Unless I miss sthg here.
>
> Same way as a NAT44 box does, if needed?  -- but not sure what you mean
> by "track the end-to-end connection".
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>


-- 
=====================
Antonios Atlasis, PhD, MPhil
GXPN, GREM, GPEN, GWAPT, CCIH, GCIA

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

<div dir=3D"ltr">I meant that based on the Fragment ID value, the translato=
r can correspond, if needed, the IPv6 unfragmented (but including an Atomic=
 Fragment) datagram to the fragmented IPv4 one, and vice versa, without nee=
ding any other information or mechanism.<br>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014-08-19 18=
:18 GMT+03:00 Fernando Gont <span dir=3D"ltr">&lt;<a href=3D"mailto:fgont@s=
i6networks.com" target=3D"_blank">fgont@si6networks.com</a>&gt;</span>:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hi, Antonios, (v6ops removed)<br>
<div class=3D""><br>
On 08/19/2014 12:14 PM, Antonios Atlasis wrote:<br>
&gt;<br>
&gt; regarding the second paragraph of section 5, I thought that the fragme=
nt<br>
&gt; ID, included both in the IPv6 atomic fragments (the half of the ID<br>
&gt; actually) and in the IPv4 header was necessary to track the end-to-end=
<br>
&gt; connection.<br>
<br>
</div>Never heard of that.<br>
<div class=3D""><br>
&gt; If a fragment ID is used only in the IPv4 part of the<br>
&gt; end-to-end path, how does IPv6-to-IPv4 translation node is going to<br=
>
&gt; track the end-to-end connection? Unless I miss sthg here.<br>
<br>
</div>Same way as a NAT44 box does, if needed?=C2=A0 -- but not sure what y=
ou mean<br>
by &quot;track the end-to-end connection&quot;.<br>
<br>
Thanks,<br>
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
Fernando Gont<br>
SI6 Networks<br>
e-mail: <a href=3D"mailto:fgont@si6networks.com">fgont@si6networks.com</a><=
br>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492<br>
<br>
<br>
<br>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br>=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Antonios Atlasis,=
 PhD, MPhil<br>
GXPN, GREM, GPEN, GWAPT, CCIH, GCIA
</div></div>

--001a11333570de6f030500fd3de6--


From nobody Tue Aug 19 13:09:09 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0037F1A0AFC for <ipv6@ietfa.amsl.com>; Tue, 19 Aug 2014 13:08:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 bBVc8O-VSOqN for <ipv6@ietfa.amsl.com>; Tue, 19 Aug 2014 13:08:40 -0700 (PDT)
Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D6471A0ADC for <ipv6@ietf.org>; Tue, 19 Aug 2014 13:08:40 -0700 (PDT)
Received: by mail-pd0-f172.google.com with SMTP id y13so10380633pdi.17 for <ipv6@ietf.org>; Tue, 19 Aug 2014 13:08:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Qw7sYh/QG15COWdNrnmhPqwINGcrOvL9YAAFf7RGP1k=; b=OaYV00uyh5Mx3mIbt2XWro1JJASP2H1FBK1P4Z2oolpExx2YcNtaa1yu3/aw4HcSsq d60lRI/2aKaKK9x6P7mn7QUcsqWdg0qLjwPkTc/ekICJpRZwJTEJhRFLYouonProyG6g xvNpKAscXVpxk/ZIPeUyzEQShT5b49togL2eRvmac1CDfcLOeayxtfF5OBEIFdfRmhqw isL5FZoqAr8ccZ/wsjJHL5ncCwIAWTZefZa/6bbBj48LDv5gV7FW2PXeWCCDVJJh2Ioj 6o1KYrfs35pjhNI5gSyy18AiL5/86fzS+iTl7NrQzQsELmhODPs3bp777ygBrs71y/BI FsSA==
X-Received: by 10.68.106.132 with SMTP id gu4mr47542847pbb.26.1408478919846; Tue, 19 Aug 2014 13:08:39 -0700 (PDT)
Received: from [192.168.178.23] (182.199.69.111.dynamic.snap.net.nz. [111.69.199.182]) by mx.google.com with ESMTPSA id xr3sm20116531pbb.51.2014.08.19.13.08.38 for <ipv6@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 13:08:39 -0700 (PDT)
Message-ID: <53F3AEC9.9010307@gmail.com>
Date: Wed, 20 Aug 2014 08:08:41 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: 6man <ipv6@ietf.org>
Subject: Re: I-D Action: draft-gont-6man-deprecate-atomfrag-generation-00.txt
References: <20140819144703.13248.27719.idtracker@ietfa.amsl.com>
In-Reply-To: <20140819144703.13248.27719.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/UVqt0MUpRq2IJV4mdUanp-I3-qg
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 20:08:45 -0000

Hi,

Quoting RFC 6145:

  "Path MTU discovery across
   a translator relies on ICMP Packet Too Big messages being received
   and processed by IPv6 hosts, including an ICMP Packet Too Big that
   indicates the MTU is less than the IPv6 minimum MTU."

  "...the translator can rely on IPv6
   hosts sending subsequent packets to the same IPv6 destination with
   IPv6 Fragment Headers.  In such an environment, when the translator
   receives an IPv6 packet with a Fragment Header, the translator SHOULD
   generate the IPv4 packet with a cleared Don't Fragment bit, and with
   its identification value from the IPv6 Fragment Header, for all of
   the IPv6 fragments (MF=0 or MF=1).

   In an environment where an ICMPv4 Packet Too Big message is filtered
   (by a network firewall or by the host itself) or not correctly
   processed by the IPv6 hosts, the IPv6 host will never generate an
   IPv6 packet with the IPv6 Fragment Header.  In such an environment,
   the translator SHOULD set the IPv4 Don't Fragment bit."

In other words, this proposal simply breaks SIIT for IPv4 MTUs below 1260
octets.

    Brian


From nobody Tue Aug 19 13:31:51 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575781A6EF6; Tue, 19 Aug 2014 13:31:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 cuMhiHYjI6Mp; Tue, 19 Aug 2014 13:31:47 -0700 (PDT)
Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B06D11A016B; Tue, 19 Aug 2014 13:31:47 -0700 (PDT)
Received: by mail-pa0-f48.google.com with SMTP id et14so10516385pad.35 for <multiple recipients>; Tue, 19 Aug 2014 13:31:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4OnGCL2FsypqTrAu4nkvHDbi9nh/tbN/FXoUM5RvEDA=; b=W8sWL5ZyXuTGMvY9Z4ezTNJUhJqiN9Q90jiaD7RxlPuaMAEOxJqoxQq2NUeMCGdoNR kj+PA9Gt11/m0xX5AswYOZ9dVUko4640WlutgHWjp4UkRi58b9DE/WYyxt+B/YxtvpuX TAhG2UOdKX0H1MgYbrq1mkS1Ye51EJHuQoERGExshycY1/gbDML/9YNNRsPVUzFKjWtj 9IQGEyzCX/ul4S6dMvlg8Qo0ZIWguwhXTqcUbSybKseTBFA94TFokDhUhLUgMACKo99O nJH2mAeuv6iFYuLBJFXOuGooQWr6RjVkim1aDPBp6LrZbiWttR6mCRUN+4Y4JThFd+Ed 8vWA==
X-Received: by 10.66.222.132 with SMTP id qm4mr23358367pac.140.1408480305184;  Tue, 19 Aug 2014 13:31:45 -0700 (PDT)
Received: from [192.168.178.23] (182.199.69.111.dynamic.snap.net.nz. [111.69.199.182]) by mx.google.com with ESMTPSA id ob14sm30763457pdb.40.2014.08.19.13.31.41 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 13:31:44 -0700 (PDT)
Message-ID: <53F3B431.7060703@gmail.com>
Date: Wed, 20 Aug 2014 08:31:45 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <E045AECD98228444A58C61C200AE1BD842D189A1@xmb-rcd-x01.cisco.com> <406B5D64-4F0E-4E71-BC60-A113FB367652@gmail.com> <46112F69-05F0-4E50-A808-287B06AE8E5F@cs.stanford.edu> <E045AECD98228444A58C61C200AE1BD842D1A9FA@xmb-rcd-x01.cisco.com> <057EC9C6-07FF-409B-A3BC-3348A5F43AB3@gmail.com> <53E534E8.4050304@gmail.com> <F7618DE0-7217-46C2-93A1-CE050085E7AB@employees.org> <53E926EB.9000505@gmail.com> <CAP+sJUfDyNa=t=+C=QXy8MmvG9rAUxA0mTsXL7xSWAeLUR1qcQ@mail.gmail.com> <53EAA58D.4060401@gmail.com> <4C8FA2D5-7FD5-40A0-9D98-081BEC6A0480@tzi.org> <E045AECD98228444A58C61C200AE1BD842D3BED8@xmb-rcd-x01.cisco.com> <6454DDD1-9A3F-4F46-9493-7307BEC01F4D@cs.stanford.edu> <53EBD028.30302@gmail.com> <E045AECD98228444A58C61C200AE1BD842D3E4EF@xmb-rcd-x01.cisco.com>, <53ED1992.1010708@gmail.com> <755F123A-A93F-4146-BD4C-4022CD8CE13E@cisco.com> <53EEB016.4030105@gmail.com> <E045AECD98228444A58C61C200AE1BD842D4671C@xmb-rcd-x01.cisco.com>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD842D4671C@xmb-rcd-x01.cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/3dWyJp8kTVqWEa_k8g8jZ5CQkl4
Cc: 6man WG <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 20:31:50 -0000

Hi Pascal,

If we're really going to discuss this, we need the IAB to establish
liaison and get the right to let us all see the specification. I'm not
going to spend my time speculating about a secret document. However,
the bit you quote: "FlowLabel: The lower order 16 bits of the FlowLabel
shall be set to ContractID. The higher order 4 bits shall be all zeros."
certainly seems to violate RFC 6437. Whether it violated the somewhat
confused situation left by RFC 2460 and RFC 3697 is less clear. I have
no recollection of anybody from ISA or IEC talking to the IETF about
this issue.

Regards
   Brian

On 19/08/2014 00:51, Pascal Thubert (pthubert) wrote:
> Hello Brian:
>=20
> I do not think that you can freely download the specification. You prob=
ably need membership first. The links exist from the Wikipedia page but t=
hey are broken. Same goes for the IEC version which is IEC 62734, but if =
you have access to the IEC then the current work is here http://www.iec.c=
h/cgi-bin/restricted/getfile.pl/65C_735ea_CDV.pdf?dir=3D65C&format=3Dpdf&=
type=3D_CDV&file=3D735ea.pdf
>=20
> Quotes:=20
>=20
> "The ContractID is associated with a particular D-route. This may be us=
ed when a particular graph or source D-route is intended to provide a def=
ined level of service"
>=20
> "FlowLabel: The lower order 16 bits of the FlowLabel shall be set to Co=
ntractID. The higher order 4 bits shall be all zeros. This field shall on=
ly be present if octets 3 through 5 are present, as indicated by LOWPAN_I=
PHC encoding."
>=20
> Note that the 6TiSCH architecture echoes this design, and a d-route is =
very similar to a 6TiSCH track.
>=20
> For the sake of history and to my best knowledge, ISA100.11a was the fi=
rst industrial standard to adopt IPv6 for process control applications (c=
ontrol loops and monitoring).=20
> It is effectively enabling IP in the control network, which is an histo=
rical step toward the IT/OT convergence, that is the Industrial equivalen=
t of voice and video convergence over IP.
>=20
> And also to my best knowledge and conforming RFC 3697, ISA100.11a does =
not mute the Flow Label inside the network, as Michael points out. Only w=
hen the additional backbone Router functionality is defined does the prob=
lem of rewriting come into play at the Backbone Router (same position as =
RPL root). For all I know this work is taking place at the Wireless Compl=
iance Institute, WCI, but I do not have the latest.
>=20
> Cheers,
>=20
> Pascal
>=20
>=20
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>> Sent: samedi 16 ao=C3=BBt 2014 03:13
>> To: Pascal Thubert (pthubert)
>> Cc: Philip Levis; Routing Over Low power and Lossy networks; Ines Robl=
es;
>> 6man WG; 6lo@ietf.org WG
>> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-r=
pl-03
>>
>> On 15/08/2014 20:51, Pascal Thubert (pthubert) wrote:
>>> Hello Brian
>>>
>>> I do not think that ISA10011.a violates RFC 3697. What exactly made y=
ou
>> believe so?
>>
>> I was over-interpreting what you wrote, I guess. It's true that 3697 w=
as rather
>> vague about what it called "flow state establishment methods" and
>> permitted both sequential and pseudo-random flow label values. Is the
>> ISA10011.a on line somewhere?
>>
>>> For all I know ISA100 does everything by the book. Note that ISA100 d=
oes
>> not update a non zero FL on the fly since it is not set by a source ou=
tside the
>> LLN if that is your concern.
>>> OTOH It may violate RFC 6437 in that the flow is not a random but a v=
alue
>> attributed by a PCE called system manager (along rules in section 4). =
As
>> things stand, we'd certainly want the backbone router at LLN egress to=

>> rewrite the FL in packets towards the Internet with a randomized per f=
low
>> value.
>>> It will violate RFC 6437 because if the flow label is set by a router=
 in the
>> Internet - or an updated source that complies to 6437-, the backbone r=
outer
>> at LLN Ingress will rewrite it.
>>> Both issues are addressed in my draft for a RPL domain. An RFC will a=
lso
>> hint a revision of the backbone router that it should rewrite the FL o=
n
>> outgoing packets.
>>> What do you think?
>> I think that Phil's last message frames the question to 6man correctly=
, so I
>> will respond to him...
>>
>> Regards
>>     Brian
>>> Pascal
>>>
>>>> Le 14 ao=C3=BBt 2014 =C3=A0 22:18, "Brian E Carpenter"
>> <brian.e.carpenter@gmail.com> a =C3=A9crit :
>>>>> On 14/08/2014 22:28, Pascal Thubert (pthubert) wrote:
>>>>> We can live with this Brian,
>>>>>
>>>>> but then I can we add at least an ISA100.11a network? ISA100.11a wa=
s
>> designed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow l=
abel
>> to indicate which flow a packet belongs to.
>>>> I have no idea what ISA100.11a is or which organisation developed it=
,
>>>> but it sounds like a violation of the flow label standard at that
>>>> time (RFC 3697). If I'd known about it, we would probably have
>>>> included it in the menagerie of RFC 6294.
>>>>
>>>> There's not much the IETF can do about other organisations that
>>>> misuse our standards, although indeed we sometimes need to document
>>>> such cases.
>>>>
>>>>   Brian
>>>>
>>>>
>>>> In more details, devices are provisioned with per-flow behavior (inc=
luding
>> routing) and settings in what is called a contract.
>>>> The contractID is carried in the IPv6 flow label.
>>>>> If so should we name ISA100 specifically or use a more vague descri=
ption
>> like a "RPL or similar LLN domain"
>>>>> We'll note that resetting an flow label that comes from the Interne=
t
>>>>> is a generic need is that flow label was set according to 6437,
>>>>> cannot be trusted to be untempered with,
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Pascal
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E
>>>>>> Carpenter
>>>>>> Sent: mercredi 13 ao=C3=BBt 2014 22:53
>>>>>> To: Philip Levis
>>>>>> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man
>>>>>> WG; 6lo@ietf.org WG
>>>>>> Subject: Re: [Roll] [6lo] WGLC for
>>>>>> draft-thubert-6man-flow-label-for-rpl-03
>>>>>>
>>>>>>> On 14/08/2014 07:07, Philip Levis wrote:
>>>>>>> On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert)
>>>>>> <pthubert@cisco.com> wrote:
>>>>>>>> If this draft is not adopted, the flow label from LLN will
>>>>>>>> probably stay all
>>>>>> zeroes as it is today and the goal of 6437 will not be achieved.
>>>>>>> Pascal, I'm trying to reconcile your claim that the goal of 6437
>>>>>>> is to allow enclosed networks to use the flow label with Brian's
>>>>>>> statement
>>>>>>>
>>>>>>>> Actually that's why I don't want to see a formal update to 6437,=

>>>>>>>> because the only rational update would be to allow any closed
>>>>>>>> domain to invent its own usage. We had that argument at length
>>>>>>>> during the development of 6437, and decided against it.
>>>>>>> Phil
>>>>>> Right. I'm drawing a very subtle line between (a) stating an
>>>>>> exception to 6437 for this particular usage and (b) opening the
>>>>>> door to other usages. Since 6man clearly didn't want (b) during th=
e
>>>>>> development of
>>>>>> 6437 I think we do need to limit ourselves to (a).
>>>>>>
>>>>>>    Brian
>>>>>>
>>>>>> ------------------------------------------------------------------=
-
>>>>>> - IETF IPv6 working group mailing list ipv6@ietf.org Administrativ=
e
>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> ------------------------------------------------------------------=
-
>>>>>> -
>=20


From nobody Tue Aug 19 13:37:02 2014
Return-Path: <fernando@gont.com.ar>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07C21A6EE6 for <ipv6@ietfa.amsl.com>; Tue, 19 Aug 2014 13:37:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 iakGmvkAyOC3 for <ipv6@ietfa.amsl.com>; Tue, 19 Aug 2014 13:36:59 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F9F01A016B for <ipv6@ietf.org>; Tue, 19 Aug 2014 13:36:59 -0700 (PDT)
Received: from [186.134.69.71] (helo=[192.168.123.127]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fernando@gont.com.ar>) id 1XJq9J-0005qS-Ii; Tue, 19 Aug 2014 22:36:57 +0200
Message-ID: <53F3B562.8090506@gont.com.ar>
Date: Tue, 19 Aug 2014 17:36:50 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man <ipv6@ietf.org>
Subject: Re: I-D Action: draft-gont-6man-deprecate-atomfrag-generation-00.txt
References: <20140819144703.13248.27719.idtracker@ietfa.amsl.com> <53F3AEC9.9010307@gmail.com>
In-Reply-To: <53F3AEC9.9010307@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/LK9dLcZq1FmYu-brXZ_nivCCHII
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 20:37:01 -0000

Hi, Brian,

On 08/19/2014 05:08 PM, Brian E Carpenter wrote:
> 
> Quoting RFC 6145:
> 
>   "Path MTU discovery across
>    a translator relies on ICMP Packet Too Big messages being received
>    and processed by IPv6 hosts, including an ICMP Packet Too Big that
>    indicates the MTU is less than the IPv6 minimum MTU."
> 
>   "...the translator can rely on IPv6
>    hosts sending subsequent packets to the same IPv6 destination with
>    IPv6 Fragment Headers.  In such an environment, when the translator
>    receives an IPv6 packet with a Fragment Header, the translator SHOULD
>    generate the IPv4 packet with a cleared Don't Fragment bit, and with
>    its identification value from the IPv6 Fragment Header, for all of
>    the IPv6 fragments (MF=0 or MF=1).
> 
>    In an environment where an ICMPv4 Packet Too Big message is filtered
>    (by a network firewall or by the host itself) or not correctly
>    processed by the IPv6 hosts, the IPv6 host will never generate an
>    IPv6 packet with the IPv6 Fragment Header.  In such an environment,
>    the translator SHOULD set the IPv4 Don't Fragment bit."
> 
> In other words, this proposal simply breaks SIIT for IPv4 MTUs below 1260
> octets.

Clearly, RFC6145 says what it says. Now, may I ask: what's the gain in
requiring the IPv6 source to generate atomic fragments? -- I can't see
any gain but just drawbacks:

* The translator is in a better position to generate a non-colliding
Fragment IDs

* Requiring the source to generate atomic fragments means there will be
more fragmented traffic than necessary -- which not unusually gets dropped.

* Native IPv6 hosts pay the price for the SIIT thing...

Right now, a device that wants to filter fragments, is subject to DoS
attacks just because of this little "feature" which, while present in
RFC 6145, seems rather unnecessary (unless I'm missing something).

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From nobody Tue Aug 19 13:55:17 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0433D1A8946 for <ipv6@ietfa.amsl.com>; Tue, 19 Aug 2014 13:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 ABfXUSAFP8Tu for <ipv6@ietfa.amsl.com>; Tue, 19 Aug 2014 13:55:13 -0700 (PDT)
Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 867EE1A891A for <ipv6@ietf.org>; Tue, 19 Aug 2014 13:55:13 -0700 (PDT)
Received: by mail-pd0-f174.google.com with SMTP id fp1so10361419pdb.33 for <ipv6@ietf.org>; Tue, 19 Aug 2014 13:55:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2Jia3o+uGJOWM1X6q6sR+yD6ffOjLUMP+g/f8XaX9UQ=; b=abhT4LChGKazGg/xP3Mv2L+p/fPgfXqUEnkoQJD7E89kp9f0WtUQ4JV8DXts3On9eG j6uCbaXwShzP3Co3N1OQnYY1U7k4OkVJifNDFDqnlM6a1NNEQ2Fxtbro71zvDdmgngWa iq7h2PETugmj0cSJi3Fqi5jKvuu2SX/rxuBvgsa4zZ/LPzKFdlnk+i8hjw3xatpZZHLx ugpXrY7BMm4EKiZxIeCWwgsBjQN3vv7PMzop71m1WwutJhI0b1ZuyedBkw92jmtfiEgf 7YbklRAXgVFgS1SkDEqDjkXdOLRPXeR9FWfSwPQLdsFaJScUbi/0ReLP8Qkd78uSl3nn jx/g==
X-Received: by 10.68.186.33 with SMTP id fh1mr47136425pbc.105.1408481713158; Tue, 19 Aug 2014 13:55:13 -0700 (PDT)
Received: from [192.168.178.23] (182.199.69.111.dynamic.snap.net.nz. [111.69.199.182]) by mx.google.com with ESMTPSA id wc3sm72720619pac.18.2014.08.19.13.55.11 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 13:55:12 -0700 (PDT)
Message-ID: <53F3B9B3.40308@gmail.com>
Date: Wed, 20 Aug 2014 08:55:15 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
Subject: Re: I-D Action: draft-gont-6man-deprecate-atomfrag-generation-00.txt
References: <20140819144703.13248.27719.idtracker@ietfa.amsl.com> <53F3AEC9.9010307@gmail.com> <53F3B562.8090506@gont.com.ar>
In-Reply-To: <53F3B562.8090506@gont.com.ar>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/1dOaVhJ1P_VX1Gig4QU6sGb03S0
Cc: 6man <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 20:55:15 -0000

On 20/08/2014 08:36, Fernando Gont wrote:
> Hi, Brian,
> 
> On 08/19/2014 05:08 PM, Brian E Carpenter wrote:
>> Quoting RFC 6145:
>>
>>   "Path MTU discovery across
>>    a translator relies on ICMP Packet Too Big messages being received
>>    and processed by IPv6 hosts, including an ICMP Packet Too Big that
>>    indicates the MTU is less than the IPv6 minimum MTU."
>>
>>   "...the translator can rely on IPv6
>>    hosts sending subsequent packets to the same IPv6 destination with
>>    IPv6 Fragment Headers.  In such an environment, when the translator
>>    receives an IPv6 packet with a Fragment Header, the translator SHOULD
>>    generate the IPv4 packet with a cleared Don't Fragment bit, and with
>>    its identification value from the IPv6 Fragment Header, for all of
>>    the IPv6 fragments (MF=0 or MF=1).
>>
>>    In an environment where an ICMPv4 Packet Too Big message is filtered
>>    (by a network firewall or by the host itself) or not correctly
>>    processed by the IPv6 hosts, the IPv6 host will never generate an
>>    IPv6 packet with the IPv6 Fragment Header.  In such an environment,
>>    the translator SHOULD set the IPv4 Don't Fragment bit."
>>
>> In other words, this proposal simply breaks SIIT for IPv4 MTUs below 1260
>> octets.
> 
> Clearly, RFC6145 says what it says. Now, may I ask: what's the gain in
> requiring the IPv6 source to generate atomic fragments? -- I can't see
> any gain but just drawbacks:
> 
> * The translator is in a better position to generate a non-colliding
> Fragment IDs
> 
> * Requiring the source to generate atomic fragments means there will be
> more fragmented traffic than necessary -- which not unusually gets dropped.
> 
> * Native IPv6 hosts pay the price for the SIIT thing...
> 
> Right now, a device that wants to filter fragments, is subject to DoS
> attacks just because of this little "feature" which, while present in
> RFC 6145, seems rather unnecessary (unless I'm missing something).

That's not my point. My point is that if you propose this change, you
need to make specific updates to RFC 6145 at the same time, and describe
the compatibility issues if hosts that support your proposed update
to 2460 meet SIIT translators that do not support your proposed updates
to 6145.

In other words there is an important section missing from your draft:
"Updates to the IP/ICMP Translation Algorithm."

   Brian


From nobody Tue Aug 19 14:17:46 2014
Return-Path: <fernando@gont.com.ar>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87261A6F24 for <ipv6@ietfa.amsl.com>; Tue, 19 Aug 2014 14:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 HMQiHnQXdHyS for <ipv6@ietfa.amsl.com>; Tue, 19 Aug 2014 14:17:43 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03F51A012D for <ipv6@ietf.org>; Tue, 19 Aug 2014 14:17:42 -0700 (PDT)
Received: from [186.134.69.71] (helo=[192.168.123.127]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fernando@gont.com.ar>) id 1XJqmi-0005zC-QG; Tue, 19 Aug 2014 23:17:41 +0200
Message-ID: <53F3BED7.9070504@gont.com.ar>
Date: Tue, 19 Aug 2014 18:17:11 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: I-D Action: draft-gont-6man-deprecate-atomfrag-generation-00.txt
References: <20140819144703.13248.27719.idtracker@ietfa.amsl.com> <53F3AEC9.9010307@gmail.com> <53F3B562.8090506@gont.com.ar> <53F3B9B3.40308@gmail.com>
In-Reply-To: <53F3B9B3.40308@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/c3Rbmwp29rmSOMGx0h3PRlPhPy0
Cc: 6man <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 21:17:45 -0000

On 08/19/2014 05:55 PM, Brian E Carpenter wrote:
>> Right now, a device that wants to filter fragments, is subject to DoS
>> attacks just because of this little "feature" which, while present in
>> RFC 6145, seems rather unnecessary (unless I'm missing something).
> 
> That's not my point. My point is that if you propose this change, you
> need to make specific updates to RFC 6145 at the same time, and describe
> the compatibility issues if hosts that support your proposed update
> to 2460 meet SIIT translators that do not support your proposed updates
> to 6145.
> 
> In other words there is an important section missing from your draft:
> "Updates to the IP/ICMP Translation Algorithm."

Absolutely. I was just double-cheking if there is anything I was missing
from the existing requirement/expectation to cause the sending node to
produce atomic fragments... IMO, it brings more trouble than anything
else...

But, yes: you raised a very important point. WIll fix this in the next rev.

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From nobody Tue Aug 19 16:00:13 2014
Return-Path: <fernando@gont.com.ar>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46E11A6FA9 for <ipv6@ietfa.amsl.com>; Tue, 19 Aug 2014 16:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.902
X-Spam-Level: 
X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 bOzzrv7g6oiL for <ipv6@ietfa.amsl.com>; Tue, 19 Aug 2014 16:00:08 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0451A6F9B for <ipv6@ietf.org>; Tue, 19 Aug 2014 16:00:08 -0700 (PDT)
Received: from [186.134.69.71] (helo=[192.168.123.127]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fernando@gont.com.ar>) id 1XJsNp-0007S1-Vy; Wed, 20 Aug 2014 01:00:06 +0200
Message-ID: <53F3D6E0.5010905@gont.com.ar>
Date: Tue, 19 Aug 2014 19:59:44 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Philip Homburg <pch-6man-1b@u-1.phicoh.com>
Subject: Re: I-D Action: draft-gont-6man-deprecate-atomfrag-generation-00.txt
References: <20140819144703.13248.27719.idtracker@ietfa.amsl.com> <53F3AEC9.9010307@gmail.com> <53F3B562.8090506@gont.com.ar> <m1XJrzr-0000R1C@stereo.hq.phicoh.net>
In-Reply-To: <m1XJrzr-0000R1C@stereo.hq.phicoh.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/hNFN3CGVq-k7jXm7er-EH0-8Vsw
Cc: 6man <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 23:00:11 -0000

On 08/19/2014 07:35 PM, Philip Homburg wrote:
> In your letter dated Tue, 19 Aug 2014 17:36:50 -0300 you wrote:
>> * The translator is in a better position to generate a non-colliding
>> Fragment IDs
> 
> There are people who want to run IPv6-only datacenters and then use stateless v4-to-v6
> translation to handle v4.
> 
> Obviously, if traffic goes to a v4 host that is on path mtu less than 1300, the v4
> packets needs to be fragmented.
> 
> The translator being stateless (and probably redundant) implies that at best the IPv4 
> packet ID can be chosen at random. Giving a 1 in 64k chance that two flows with the
> same source and destination addresses will have the same ID.

FWIW, there are stateless algorithms with a lower frequency reuse rate
... e.g., check OpenBSD's Frag ID, generator, or some of the algorithms
in <http://tools.ietf.org/html/draft-ietf-6man-predictable-fragment-id>



> One big question is how many v4 hosts would be affected by this, i.e. how 
> many v4 hosts are on a path mtu less than 1300.
> 
> Another question is whether taking 16 bits out of the 32-bit fragment ID in IPv6
> actually results in something better than random.

Certainly not, particularly if the nodes use something like
per-destination counter for the frag ID -- if you were unlucky, the Frag
IDs counters of two nodes could be "synchronized".

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From nobody Wed Aug 20 04:07:42 2014
Return-Path: <markzzzsmith@yahoo.com.au>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1971A01E4 for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 04:07:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.402
X-Spam-Level: 
X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 dmRJkO175Ss3 for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 04:07:38 -0700 (PDT)
Received: from nm32.bullet.mail.ne1.yahoo.com (nm32.bullet.mail.ne1.yahoo.com [98.138.229.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56221A01DC for <ipv6@ietf.org>; Wed, 20 Aug 2014 04:07:37 -0700 (PDT)
Received: from [127.0.0.1] by nm32.bullet.mail.ne1.yahoo.com with NNFMP; 20 Aug 2014 11:07:37 -0000
Received: from [98.138.100.112] by nm32.bullet.mail.ne1.yahoo.com with NNFMP;  20 Aug 2014 11:04:52 -0000
Received: from [66.196.81.174] by tm103.bullet.mail.ne1.yahoo.com with NNFMP;  20 Aug 2014 11:04:52 -0000
Received: from [98.139.212.194] by tm20.bullet.mail.bf1.yahoo.com with NNFMP;  20 Aug 2014 11:04:52 -0000
Received: from [127.0.0.1] by omp1003.mail.bf1.yahoo.com with NNFMP; 20 Aug 2014 11:04:52 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 97474.69174.bm@omp1003.mail.bf1.yahoo.com
Received: (qmail 14509 invoked by uid 60001); 20 Aug 2014 11:04:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024;  t=1408532691; bh=+02RjbLppMd4b4GizagEDTnf2aA9HARbYiO+9lfBqU0=;  h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YPpwhK+7z5qAHOGivk3lKWJcDNHf629AIusQbpxA9dkpWeuUrKcxneUg5BqQnRtV+xp/ppNaTeXcpW/top1nZ789u/G7ygyNlLfWfytQTcBucG3VpNZNIzQlik5dXEOGxnSND5cA16gvF0F/eW9Yu7g4YqRwm2KvReRvfqKStCU=
X-YMail-OSG: sIvsdc4VM1kZI0tR3RTYr7rviFZpJMTTKZtNaymSJ.MlKa8 XOGCEYBHAEhIIGAz.uFmwxeKfWbKSR65Mh8RZwFU648m15QDN1UF0.ja_5D8 l96huRjKelmNp0GLkXLzDmOo5V52ggWppERsEg_rDGqaMGQcUZm3sEYb9vva 3Fa8ly51VjaMNXkjj4VbKRAQ0msWhSjToYmWREaKfv1ufQHT2BmhOEUS7a6Y HCYIkNzZta6vc6jh6zlxbQLqkQSeuaYq5Mf8PiTBJ3ReZZ8HEL8zvd9fv9pj lpARHUX1TnOWOlf7e_XepBbpkzi6Fx2b_95h8kinX8VVYSgZTogEaKXPsE7c mdoAtkrd3AxJ3gSCallECCxsCoZw6yESi8nbEfQPqlR3gkCLmPwu5_qJ.VV8 EmWPDX1YQdhzcD5Cr.S.jpCO2VFVuqUEqVbZO4lRvQJj2hQ05Y_oLiA1fiQ9 BfDKUTHYt7UAZt0IsS0WZNe7fiwvHdS1kCP1ZIFp.pOlnaMBshlUdq5rZctE ZtThh9dfVt75lh9DES05cf4dokcODbdLymBXrI8rMCUXQHn8dbQGOSwUh3DJ ZCU_7ph9t
Received: from [150.101.221.237] by web162206.mail.bf1.yahoo.com via HTTP; Wed, 20 Aug 2014 04:04:51 PDT
X-Rocket-MIMEInfo: 002.001, SGksCgpJJ20gaGFwcHkgd2l0aCB0aGUgY2hhbmdlcy4KCk1pbm9yIG5pdCwgZHVwbGljYXRlICd0aGUnCgoiIEF0IHRoZSAqdGhlKiB0aW1lIG9mIHB1YmxpY2F0aW9uwqAKwqAgwqAgwqBvZiBSRkMgMjcxMCwgdGhlIElQdjYgYWRkcmVzc2luZyBhcmNoaXRlY3R1cmUgc3BlY2lmaWVkIGxpbmstbG9jYWzCoArCoCDCoCDCoGFkZHJlc3NlcyB3aXRoIDY0LWJpdCBpbnRlcmZhY2UgaWRlbnRpZmllcnMuICIKCgpSZWdhcmRzLApNYXJrLgoKCgotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogQnIBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.201.700
References: <53EEB906.20206@gmail.com>
Message-ID: <1408532691.50051.YahooMailNeo@web162206.mail.bf1.yahoo.com>
Date: Wed, 20 Aug 2014 04:04:51 -0700
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Subject: Re: [Fwd: I-D Action: draft-ietf-6man-why64-02.txt]
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man <ipv6@ietf.org>
In-Reply-To: <53EEB906.20206@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/ZlqpM_odmeuR4SUmVf6XNoVqo_I
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 11:07:40 -0000

Hi,=0A=0AI'm happy with the changes.=0A=0AMinor nit, duplicate 'the'=0A=0A"=
 At the *the* time of publication=A0=0A=A0 =A0 =A0of RFC 2710, the IPv6 add=
ressing architecture specified link-local=A0=0A=A0 =A0 =A0addresses with 64=
-bit interface identifiers. "=0A=0A=0ARegards,=0AMark.=0A=0A=0A=0A----- Ori=
ginal Message -----=0A> From: Brian E Carpenter <brian.e.carpenter@gmail.co=
m>=0A> To: 6man <ipv6@ietf.org>=0A> Cc: =0A> Sent: Saturday, 16 August 2014=
 11:51 AM=0A> Subject: [Fwd: I-D Action: draft-ietf-6man-why64-02.txt]=0A> =
=0A>T his version is intended to respond to all the WG last call=0A> commen=
ts and reviews. Here are the changes:=0A> =0A> - numerous editorial improve=
ments=0A> - numerous small technical clarifications=0A> - added reference t=
o HD ratio=0A> - expanded MLD text=0A> - added text on duplicate address is=
sue=0A> =0A> Comments welcome.=0A> =0A> =A0 Brian + co-authors=0A> =0A> ---=
----- Original Message --------=0A> Subject: I-D Action: draft-ietf-6man-wh=
y64-02.txt=0A> Date: Fri, 15 Aug 2014 18:48:49 -0700=0A> From: internet-dra=
fts@ietf.org=0A> To: i-d-announce@ietf.org=0A> CC: ipv6@ietf.org=0A> =0A> =
=0A> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.=0A> This draft is a work item of the IPv6 Maintenance Working Gro=
up of the IETF.=0A> =0A> =A0 =A0 =A0 =A0 Title=A0 =A0 =A0 =A0 =A0  : Analys=
is of the 64-bit Boundary in IPv6 Addressing=0A> =A0 =A0 =A0 =A0 Authors=A0=
 =A0 =A0 =A0  : Brian Carpenter=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 Tim Chown=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 Fernando Gont=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 S=
heng Jiang=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Alexandr=
u Petrescu=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Andrew Y=
ourtchenko=0A> =A0=A0=A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-6man-why64-02=
.txt=0A> =A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0  : 24=0A> =A0=A0=A0 Date=A0 =A0=
 =A0 =A0 =A0 =A0 : 2014-08-15=0A> =0A> Abstract:=0A> =A0  The IPv6 unicast =
addressing format includes a separation between the=0A> =A0  prefix used to=
 route packets to a subnet and the interface identifier=0A> =A0  used to sp=
ecify a given interface connected to that subnet.=0A> =A0  Currently the in=
terface identifier is defined as 64 bits long for=0A> =A0  almost every cas=
e, leaving 64 bits for the subnet prefix.=A0 This=0A> =A0  document describ=
es the advantages of this fixed boundary and analyses=0A> =A0  the issues t=
hat would be involved in treating it as a variable=0A> =A0  boundary.=0A> =
=0A> =0A> The IETF datatracker status page for this draft is:=0A> https://d=
atatracker.ietf.org/doc/draft-ietf-6man-why64/=0A> =0A> There's also a html=
ized version available at:=0A> http://tools.ietf.org/html/draft-ietf-6man-w=
hy64-02=0A> =0A> A diff from the previous version is available at:=0A> http=
://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-why64-02=0A> =0A> =0A> Pleas=
e note that it may take a couple of minutes from the time of submission=0A>=
 until the htmlized version and diff are available at tools.ietf.org.=0A> =
=0A> Internet-Drafts are also available by anonymous FTP at:=0A> ftp://ftp.=
ietf.org/internet-drafts/=0A> =0A> ----------------------------------------=
----------------------------=0A> IETF IPv6 working group mailing list=0A> i=
pv6@ietf.org=0A> Administrative Requests: https://www.ietf.org/mailman/list=
info/ipv6=0A> -------------------------------------------------------------=
-------=0A> =0A> ----------------------------------------------------------=
----------=0A> IETF IPv6 working group mailing list=0A> ipv6@ietf.org=0A> A=
dministrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=0A> ----=
----------------------------------------------------------------=0A> 


From nobody Wed Aug 20 04:28:13 2014
Return-Path: <markzzzsmith@yahoo.com.au>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363F11A0218 for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 04:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level: 
X-Spam-Status: No, score=-1.497 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 9tMFVAjQ-EER for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 04:28:10 -0700 (PDT)
Received: from nm44.bullet.mail.ne1.yahoo.com (nm44.bullet.mail.ne1.yahoo.com [98.138.120.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E191A0205 for <ipv6@ietf.org>; Wed, 20 Aug 2014 04:28:10 -0700 (PDT)
Received: from [127.0.0.1] by nm44.bullet.mail.ne1.yahoo.com with NNFMP; 20 Aug 2014 11:28:09 -0000
Received: from [98.138.100.112] by nm44.bullet.mail.ne1.yahoo.com with NNFMP;  20 Aug 2014 11:25:20 -0000
Received: from [98.139.215.142] by tm103.bullet.mail.ne1.yahoo.com with NNFMP;  20 Aug 2014 11:25:20 -0000
Received: from [98.139.212.227] by tm13.bullet.mail.bf1.yahoo.com with NNFMP;  20 Aug 2014 11:25:20 -0000
Received: from [127.0.0.1] by omp1036.mail.bf1.yahoo.com with NNFMP; 20 Aug 2014 11:25:20 -0000
X-Yahoo-Newman-Property: ymail-4
X-Yahoo-Newman-Id: 593858.76423.bm@omp1036.mail.bf1.yahoo.com
Received: (qmail 2979 invoked by uid 60001); 20 Aug 2014 11:25:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024;  t=1408533920; bh=bQSjn/GFUGsl5nZBn4VJhiPi+wbCUvKtrrBuWvDvU5Y=;  h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=cAV7y0+RlK5xjxsraagJvki+2srYlZ1HJLGQvW6pjMtGRc9fMIhLB1YDUizha5ybZT31lKOvEqev9HUHK/ZVYOk287REXsRfsp1nxb+N8M8pvLZL/CwkFDVSy0Egqk3dgxlT1fYI+W7Vui7ZfnmQOwBwlSykPRWgCLofhUUjZM8=
X-YMail-OSG: 7WFaGpMVM1nQ4.DRygmjXNDRHJZajzHt6fNrlWis31t5HKI qCSIFiQtSiN0EYznJ77jaPbxoG9vxh5emtxuOjsRCnOycr9lrIn9qdhg7wcY czymz0IuzQwD4kt.9IRHBGOEm.H_e8hv6pmjgbPX7nHyEegIzfmMYy4x7qsJ rKCtfLaQ8rs.LLa2aouRZDHbWbYV2gf1uflcgG9qr6K0lDjvnj1QCgPlhSfz 4SP622NZ.rSQo9xt4UQm40odnLcw.QnoGd1.rjBzhgVPP0Gd7V5s81xvdJHq FAglyzuYA1hsSwFkDKiH68tPgiIcAXNcNaUZeSdFDRgTk7ULCL36h9WZraHg jcNm5lWAxC2KPiPLF.1CTi1.I8SbPS_lUJM2BMe9RcK0u.Aet3TAzJ6WX4_x uBxn0WcAPiXC_E7hV4rJ4_6_UzxV3BQ2PJmzFYNQzwj4B5T1yNDHhDOOGCaF ZldBdHOZLWWw3F9DsHtBX1jXKCK7DAQEkC5PNxTBogLuRhTvieRjFefZ1FpZ fiU0O_gMKTeYC5JevOdGQYkfGSrpzEu4rjtztEiKIC1CsCG4OvcbFK8Kqqcy h4ZhZg8SO2Ys-
Received: from [150.101.221.237] by web162204.mail.bf1.yahoo.com via HTTP; Wed, 20 Aug 2014 04:25:20 PDT
X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBNYXJrIFpaWiBTbWl0aCA8bWFya3p6enNtaXRoQHlhaG9vLmNvbS5hdT4KPiBUbzogQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT47IDZtYW4gPGlwdjZAaWV0Zi5vcmc.Cj4gQ2M6IAo.IFNlbnQ6IFdlZG5lc2RheSwgMjAgQXVndXN0IDIwMTQgOTowNCBQTQo.IFN1YmplY3Q6IFJlOiBbRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLTZtYW4td2h5NjQtMDIudHh0XQo.IAo.IEhpLAo.IAo.IEknbSABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.201.700
References: <53EEB906.20206@gmail.com> <1408532691.50051.YahooMailNeo@web162206.mail.bf1.yahoo.com>
Message-ID: <1408533920.87649.YahooMailNeo@web162204.mail.bf1.yahoo.com>
Date: Wed, 20 Aug 2014 04:25:20 -0700
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Subject: Re: [Fwd: I-D Action: draft-ietf-6man-why64-02.txt]
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man <ipv6@ietf.org>
In-Reply-To: <1408532691.50051.YahooMailNeo@web162206.mail.bf1.yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/pFI3RkuIOC9TNdWJaV4z9id0KmI
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 11:28:12 -0000

=0A=0A=0A=0A----- Original Message -----=0A> From: Mark ZZZ Smith <markzzzs=
mith@yahoo.com.au>=0A> To: Brian E Carpenter <brian.e.carpenter@gmail.com>;=
 6man <ipv6@ietf.org>=0A> Cc: =0A> Sent: Wednesday, 20 August 2014 9:04 PM=
=0A> Subject: Re: [Fwd: I-D Action: draft-ietf-6man-why64-02.txt]=0A> =0A> =
Hi,=0A> =0A> I'm happy with the changes.=0A> =0A> Minor nit, duplicate 'the=
'=0A> =0A> " At the *the* time of publication=A0=0A> =A0 =A0 =A0of RFC 2710=
, the IPv6 addressing architecture specified link-local=A0=0A> =A0 =A0 =A0a=
ddresses with 64-bit interface identifiers. "=0A>=A0=0A=0A(And my original =
mistake. I'll have to start doing detailed reviews of my detailed reviews ;=
-) )=0A=0A> =0A> Regards,=0A> Mark.=0A> =0A> =0A> =0A> =0A> ----- Original =
Message -----=0A>>  From: Brian E Carpenter <brian.e.carpenter@gmail.com>=
=0A>>  To: 6man <ipv6@ietf.org>=0A>>  Cc: =0A>>  Sent: Saturday, 16 August =
2014 11:51 AM=0A>>  Subject: [Fwd: I-D Action: draft-ietf-6man-why64-02.txt=
]=0A>> =0A>> T his version is intended to respond to all the WG last call=
=0A>>  comments and reviews. Here are the changes:=0A>> =0A>>  - numerous e=
ditorial improvements=0A>>  - numerous small technical clarifications=0A>> =
 - added reference to HD ratio=0A>>  - expanded MLD text=0A>>  - added text=
 on duplicate address issue=0A>> =0A>>  Comments welcome.=0A>> =0A>>  =A0 B=
rian + co-authors=0A>> =0A>>  -------- Original Message --------=0A>>  Subj=
ect: I-D Action: draft-ietf-6man-why64-02.txt=0A>>  Date: Fri, 15 Aug 2014 =
18:48:49 -0700=0A>>  From: internet-drafts@ietf.org=0A>>  To: i-d-announce@=
ietf.org=0A>>  CC: ipv6@ietf.org=0A>> =0A>> =0A>>  A New Internet-Draft is =
available from the on-line Internet-Drafts =0A> directories.=0A>>  This dra=
ft is a work item of the IPv6 Maintenance Working Group of the =0A> IETF.=
=0A>> =0A>>  =A0 =A0 =A0 =A0 Title=A0 =A0 =A0 =A0 =A0=A0 : Analysis of the =
64-bit Boundary in IPv6 =0A> Addressing=0A>>  =A0 =A0 =A0 =A0 Authors=A0 =
=A0 =A0 =A0=A0 : Brian Carpenter=0A>>  =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 Tim Chown=0A>>  =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 Fernando Gont=0A>>  =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 Sheng Jiang=0A>>  =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 Alexandru Petrescu=0A>>  =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 Andrew Yourtchenko=0A>>  =A0=A0=A0 Filename=A0 =A0 =A0 =A0 : draft-=
ietf-6man-why64-02.txt=0A>>  =A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0=A0 : 24=0A>=
>  =A0=A0=A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2014-08-15=0A>> =0A>>  Abstract:=
=0A>>  =A0=A0 The IPv6 unicast addressing format includes a separation betw=
een the=0A>>  =A0=A0 prefix used to route packets to a subnet and the inter=
face identifier=0A>>  =A0=A0 used to specify a given interface connected to=
 that subnet.=0A>>  =A0=A0 Currently the interface identifier is defined as=
 64 bits long for=0A>>  =A0=A0 almost every case, leaving 64 bits for the s=
ubnet prefix.=A0 This=0A>>  =A0=A0 document describes the advantages of thi=
s fixed boundary and analyses=0A>>  =A0=A0 the issues that would be involve=
d in treating it as a variable=0A>>  =A0=A0 boundary.=0A>> =0A>> =0A>>  The=
 IETF datatracker status page for this draft is:=0A>>  https://datatracker.=
ietf.org/doc/draft-ietf-6man-why64/=0A>> =0A>>  There's also a htmlized ver=
sion available at:=0A>>  http://tools.ietf.org/html/draft-ietf-6man-why64-0=
2=0A>> =0A>>  A diff from the previous version is available at:=0A>>  http:=
//www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6man-why64-02=0A>> =0A>> =0A>>  Pl=
ease note that it may take a couple of minutes from the time of =0A> submis=
sion=0A>>  until the htmlized version and diff are available at tools.ietf.=
org.=0A>> =0A>>  Internet-Drafts are also available by anonymous FTP at:=0A=
>>  ftp://ftp.ietf.org/internet-drafts/=0A>> =0A>>  -----------------------=
---------------------------------------------=0A>>  IETF IPv6 working group=
 mailing list=0A>>  ipv6@ietf.org=0A>>  Administrative Requests: https://ww=
w.ietf.org/mailman/listinfo/ipv6=0A>>  ------------------------------------=
--------------------------------=0A>> =0A>>  ------------------------------=
--------------------------------------=0A>>  IETF IPv6 working group mailin=
g list=0A>>  ipv6@ietf.org=0A>>  Administrative Requests: https://www.ietf.=
org/mailman/listinfo/ipv6=0A>>  -------------------------------------------=
-------------------------=0A>> =0A> 


From nobody Wed Aug 20 07:27:24 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1581A03C5 for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 07:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 NRQeUd9sYUY6 for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 07:27:19 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413581A03C2 for <ipv6@ietf.org>; Wed, 20 Aug 2014 07:27:19 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XK6r5-0007V5-F0; Wed, 20 Aug 2014 16:27:15 +0200
Message-ID: <53F4B02B.3090607@si6networks.com>
Date: Wed, 20 Aug 2014 11:26:51 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Bob Briscoe <bob.briscoe@bt.com>,  draft-gont-6man-deprecate-atomfrag-generation@tools.ietf.org
Subject: Re: Relax draft-gont-6man-deprecate-atomfrag-generation-00
References: <201408201356.s7KDuYc5026764@bagheera.jungle.bt.co.uk>
In-Reply-To: <201408201356.s7KDuYc5026764@bagheera.jungle.bt.co.uk>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/OgB5UjMl8fenRBgqShDTG56BMPo
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 14:27:22 -0000

Hi, Bob,

Thanks so much for your feedback! -- Please find my comments in-line....

On 08/20/2014 10:56 AM, Bob Briscoe wrote:
> 
> [I've cc'd ipv6, but I'm not subscribed, so pls include me specifically
> in any response.]
> 
> S.4
> Agree The current 2460 rule creates a vulnerability, but don't agree
> with [sender] "MUST discard ICMPv6 Packet Too Big" as the remedy. I
> would prefer "MUST NOT include a Fragment header in subsequent packets",
> which is the minimum needed to address the actual attack.

Clarification on our side (since what we conveyed might be different
from what we meant): What we meant is that if a host receives an ICMPv6
< 1280, it MUST NOT start sending atomic fragments.

So I will apply your suggested change -- thanks!


> Reasoning: there is no danger in the sender being aware that its packets
> are being fragmented. 2460 says the sender "is not required to reduce
> the size of subsequent packets", but this only means it doesn't have to;
> it doesn't mean it MUST NOT. In many cases the sender will be able to
> help the v6/v4 gateway improve performance by using a smaller segment
> size (e.g. if using TCP), rather than merely sending atomic fragments.

The question here is this:
The semantics of an ICMPv6 PTB is "Your packet was discarded, and this
is the size you should use for further packets". So (at least in an
IPv6-only world), an ICMPv6 PTB<1280 does not really signal that the
packet is being fragmented (since IPv6 routers do not fragment packets).


While I agree that, at least in theory, one could receive ICMPv6
PTB<1280, do nothing at the network layer, but still report the received
message to the transport layer, I'd probably say that acting on such
message kind of eliminates the concept of "IPv6 minimum MTU" -- i.e.,
"if all IPv6 networks support an MTU>=1280 bytes, why am I receiving
this ICMPv6 PTB that claims an MTU smaller than 1280?".

Thoughts?


> One nit noticed:
> S.3:
> s/When server server B/When server B/

Yep. Fixed.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Wed Aug 20 07:30:52 2014
Return-Path: <pch-bBB316E3E@u-1.phicoh.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D8D1A0020 for <ipv6@ietfa.amsl.com>; Tue, 19 Aug 2014 15:35:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level: 
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham
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 lJNIZUQr6SZh for <ipv6@ietfa.amsl.com>; Tue, 19 Aug 2014 15:35:26 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE411A6F03 for <ipv6@ietf.org>; Tue, 19 Aug 2014 15:35:26 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XJrzr-0000R1C; Wed, 20 Aug 2014 00:35:19 +0200
Message-Id: <m1XJrzr-0000R1C@stereo.hq.phicoh.net>
To: Fernando Gont <fernando@gont.com.ar>
Subject: Re: I-D Action: draft-gont-6man-deprecate-atomfrag-generation-00.txt 
From: Philip Homburg <pch-6man-1b@u-1.phicoh.com>
Sender: pch-bBB316E3E@u-1.phicoh.com
References: <20140819144703.13248.27719.idtracker@ietfa.amsl.com> <53F3AEC9.9010307@gmail.com> <53F3B562.8090506@gont.com.ar> 
In-reply-to: Your message of "Tue, 19 Aug 2014 17:36:50 -0300 ." <53F3B562.8090506@gont.com.ar> 
Date: Wed, 20 Aug 2014 00:35:18 +0200
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Wm7vfbfBpSJlH7-rZkai9RrvhfQ
X-Mailman-Approved-At: Wed, 20 Aug 2014 07:30:51 -0700
Cc: 6man <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Aug 2014 22:35:28 -0000

In your letter dated Tue, 19 Aug 2014 17:36:50 -0300 you wrote:
>* The translator is in a better position to generate a non-colliding
>Fragment IDs

There are people who want to run IPv6-only datacenters and then use stateless v4-to-v6
translation to handle v4.

Obviously, if traffic goes to a v4 host that is on path mtu less than 1300, the v4
packets needs to be fragmented.

The translator being stateless (and probably redundant) implies that at best the IPv4 
packet ID can be chosen at random. Giving a 1 in 64k chance that two flows with the
same source and destination addresses will have the same ID.

One big question is how many v4 hosts would be affected by this, i.e. how 
many v4 hosts are on a path mtu less than 1300.

Another question is whether taking 16 bits out of the 32-bit fragment ID in IPv6
actually results in something better than random.

Of course, any IPv6 site that want to do DNSSEC has to be able to receive fragmented
traffic. In that sense, atomic fragments are just a easy subset of receiving 
fragmented traffic in general. 


From nobody Wed Aug 20 07:30:54 2014
Return-Path: <bob.briscoe@bt.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8786D1A03A9 for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 06:56:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.569
X-Spam-Level: 
X-Spam-Status: No, score=-0.569 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
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 JSr91NHpLO2y for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 06:56:42 -0700 (PDT)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FB1E1A03B3 for <ipv6@ietf.org>; Wed, 20 Aug 2014 06:56:42 -0700 (PDT)
Received: from EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 20 Aug 2014 14:56:36 +0100
Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR01-UKBR.domain1.systemhost.net (193.113.108.40) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 20 Aug 2014 14:56:39 +0100
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Wed, 20 Aug 2014 14:56:36 +0100
Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93])	by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s7KDuYc5026764;	Wed, 20 Aug 2014 14:56:34 +0100
Message-ID: <201408201356.s7KDuYc5026764@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 20 Aug 2014 14:56:32 +0100
To: <draft-gont-6man-deprecate-atomfrag-generation@tools.ietf.org>
From: Bob Briscoe <bob.briscoe@bt.com>
Subject: Relax draft-gont-6man-deprecate-atomfrag-generation-00
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/tS2art6rJ7X69flcN8A_HlHsBwE
X-Mailman-Approved-At: Wed, 20 Aug 2014 07:30:51 -0700
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 13:56:44 -0000

Fernando, Will,

[I've cc'd ipv6, but I'm not subscribed, so pls include me 
specifically in any response.]

S.4
Agree The current 2460 rule creates a vulnerability, but don't agree 
with [sender] "MUST discard ICMPv6 Packet Too Big" as the remedy. I 
would prefer "MUST NOT include a Fragment header in subsequent 
packets", which is the minimum needed to address the actual attack.

Reasoning: there is no danger in the sender being aware that its 
packets are being fragmented. 2460 says the sender "is not required 
to reduce the size of subsequent packets", but this only means it 
doesn't have to; it doesn't mean it MUST NOT. In many cases the 
sender will be able to help the v6/v4 gateway improve performance by 
using a smaller segment size (e.g. if using TCP), rather than merely 
sending atomic fragments.

Otherwise, with your proposed wording, the next thing we will see is 
(more) filtering of ICMPv6 Packet Too Big error messages, because it 
will be perceived that they are ignored anyway. Then perfectly 
harmless optimisations will become impossible.

One nit noticed:
S.3:
s/When server server B/When server B/



Bob


________________________________________________________________
Bob Briscoe,                                                  BT 


From nobody Wed Aug 20 07:50:49 2014
Return-Path: <fernando@gont.com.ar>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8FE1A045F for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 07:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level: 
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 LIzNFkZHfBAJ for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 07:50:43 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCA981A0442 for <ipv6@ietf.org>; Wed, 20 Aug 2014 07:50:42 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fernando@gont.com.ar>) id 1XK7Dk-0008BC-3s; Wed, 20 Aug 2014 16:50:40 +0200
Message-ID: <53F4B5AF.3060306@gont.com.ar>
Date: Wed, 20 Aug 2014 11:50:23 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Bob Briscoe <bob.briscoe@bt.com>,  draft-gont-6man-deprecate-atomfrag-generation@tools.ietf.org
Subject: Re: Relax draft-gont-6man-deprecate-atomfrag-generation-00
References: <201408201356.s7KDuYc5026764@bagheera.jungle.bt.co.uk>
In-Reply-To: <201408201356.s7KDuYc5026764@bagheera.jungle.bt.co.uk>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/s32szFMYWdScU_DqdY4y5BIzEw8
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 14:50:45 -0000

On 08/20/2014 10:56 AM, Bob Briscoe wrote:
> 
> [I've cc'd ipv6, but I'm not subscribed, so pls include me specifically
> in any response.]
> 
> S.4
> Agree The current 2460 rule creates a vulnerability, but don't agree
> with [sender] "MUST discard ICMPv6 Packet Too Big" as the remedy. I
> would prefer "MUST NOT include a Fragment header in subsequent packets",
> which is the minimum needed to address the actual attack.

BTW, how about replacing the existing:

 "IPv6 nodes MUST discard ICMPv6 Packet Too Big error messages that
 report a Next-Hop MTU smaller than 1280 bytes (the minimum IPv6
 MTU)."

with

"An IPv6 node that receives an ICMPv6 Packet Too Big error message that
reports a Next-Hop MTU smaller than 1280 bytes (the minimum IPv6 MTU)
MUST NOT include a Fragment header in subsequent packets sent to the
corresponding destination. That is, IPv6 nodes MUST NOT generate IPv6
atomic fragments."

?

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From nobody Wed Aug 20 10:38:16 2014
Return-Path: <tom.taylor.stds@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48F11A04B9 for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 10:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 4OjUwgooi-wk for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 10:38:12 -0700 (PDT)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC2C1A04A8 for <ipv6@ietf.org>; Wed, 20 Aug 2014 10:38:12 -0700 (PDT)
Received: by mail-ig0-f178.google.com with SMTP id uq10so11560868igb.11 for <ipv6@ietf.org>; Wed, 20 Aug 2014 10:38:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=oB9JYoDNulFAhMamMCwUsM8VhBsHrtKBBnjGiZ4TCmY=; b=XfPr5WxXGg2QbH3cXVxSXssx+urCqgJBswjbEzIM8R+VPeWfSpJWtbIUHUvTEEOY78 WLhhTa/zKmq2qqLbDWaPSAT3+x1UzYlatxRKmua0BDy44pePie4s0UdaYrg6YNBet2oQ 9sj4lxENG3xcW6e3AjPJAzUVsXX4K9/nXXLy0D7XDYECtlERwsGoI5v/Isn+EHjK7jpI Xb0ToVKsDzHajjHUx0Qg9GnfG20QVwBFtLLpxqG+ytoZ3Lhcr0K6enAxKcvYTmAwW69E G4B0ZjWV+lXGSm/CnUpp+6KHq/Ezoc6h6i02RJbqxF6IkNNhTbbF9r/dvZakCRUs1CqG priQ==
X-Received: by 10.43.70.205 with SMTP id yh13mr49261079icb.44.1408556292060; Wed, 20 Aug 2014 10:38:12 -0700 (PDT)
Received: from [192.168.97.246] ([67.210.160.130]) by mx.google.com with ESMTPSA id d10sm13369850igl.13.2014.08.20.10.38.10 for <ipv6@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Aug 2014 10:38:11 -0700 (PDT)
Message-ID: <53F4DCF0.9030501@gmail.com>
Date: Wed, 20 Aug 2014 13:37:52 -0400
From: Tom Taylor <tom.taylor.stds@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "ipv6@ietf.org" <ipv6@ietf.org>
Subject: Minimum valid prefix lengths
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/vhzHZwKBb6rpg75oS2ax23i6MY4
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 17:38:14 -0000

I've been chasing this around, but it would be nice to have definitive 
answers. draft-ietf-softwire-dslite-multicast-07 describes the use of 
ASM and SSM prefixes with embedded IPv4 addresses, so maximum valid 
lengths of the prefixes would be 96. Taking account of the just-approved 
updates to the multicast address architecture, what would be the minimum 
valid lengths for ASM and SSM respectively when used in this way?

Tom Taylor


From nobody Wed Aug 20 13:01:20 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1F01A06C5 for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 13:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 kGBurCWHRhGo for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 13:01:16 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0741A06A6 for <ipv6@ietf.org>; Wed, 20 Aug 2014 13:01:16 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from <fgont@si6networks.com>) id 1XKC4H-0007Rv-TE; Wed, 20 Aug 2014 22:01:14 +0200
Message-ID: <53F4F828.8080502@si6networks.com>
Date: Wed, 20 Aug 2014 16:34:00 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Bob Briscoe <bob.briscoe@bt.com>
Subject: Re: Relax draft-gont-6man-deprecate-atomfrag-generation-00
References: <201408201356.s7KDuYc5026764@bagheera.jungle.bt.co.uk> <53F4B02B.3090607@si6networks.com> <201408201851.s7KIpA3k027926@bagheera.jungle.bt.co.uk>
In-Reply-To: <201408201851.s7KIpA3k027926@bagheera.jungle.bt.co.uk>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/ZnrU_RTbN6yEZvv8Ikv36Ji3gqA
Cc: ipv6@ietf.org, draft-gont-6man-deprecate-atomfrag-generation@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 20:01:19 -0000

On 08/20/2014 03:51 PM, Bob Briscoe wrote:
>> The question here is this:
>> The semantics of an ICMPv6 PTB is "Your packet was discarded, and this
>> is the size you should use for further packets". So (at least in an
>> IPv6-only world), an ICMPv6 PTB<1280 does not really signal that the
>> packet is being fragmented (since IPv6 routers do not fragment packets).
>>
>>
>> While I agree that, at least in theory, one could receive ICMPv6
>> PTB<1280, do nothing at the network layer, but still report the received
>> message to the transport layer, I'd probably say that acting on such
>> message kind of eliminates the concept of "IPv6 minimum MTU" -- i.e.,
>> "if all IPv6 networks support an MTU>=1280 bytes, why am I receiving
>> this ICMPv6 PTB that claims an MTU smaller than 1280?".
> 
> The idea that IPv6 can declare that the min MTU will be 1280 stems from
> the idea that every link technology will have to implement an
> encapsulation of v6, so implementers should be able to ensure this new
> min MTU will always be honoured. However, that thinking overlooks the
> fact that IPv4 can also act as a 'link technology' for IPv6.

My understanding is that, when you employ IPv4 as a "link technology"
for IPv6, you need to offer IPv6 an MTU of at least 1280 bytes (e.g., by
relying on IPv4 fragmentation).

Note: I'm not arguing whether that's a good idea or not, but rather that
it's "doable".

-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Wed Aug 20 13:48:01 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B128E1A0395 for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 13:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 9hZNmimpPSVO for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 13:47:48 -0700 (PDT)
Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2786C1A0B00 for <ipv6@ietf.org>; Wed, 20 Aug 2014 13:47:48 -0700 (PDT)
Received: by mail-pd0-f181.google.com with SMTP id g10so12259466pdj.40 for <ipv6@ietf.org>; Wed, 20 Aug 2014 13:47:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6fCtb30hPKJ8aKCYYolyhTUn7l8YZuNeS0/vZC1EaW8=; b=W7Mmk49J/8x8cbdTRGx5dzm7wt6P66TRNJtu1bf17R5eCzMZQy3nEV4N+bRDWV0RKZ Btf+S0TLrqF2BXcHNuC9/Rvmn7PWOf8+YVyq3IXIyc+0cmnLYfN6SlR1u3wJnPQv5FSV 97WL3C/lrYSUhHC4haknTH6cwlYtO0ftRx1TyO1fz4v8VQSlVf4bXP4PN6tFgIa2j8g+ yp0Qx4oWaioItBtVD3s1e8ppOoZEr+zeqPCWex6X2s2O5t7qmwuT65fqmdrA32w2/cn/ bm7RjLIw+w1H2myVWkG9YE7eoqghnBwuiEj73pmeAkdpqAk6IkSCcoBnhatopv7sjGil OuCg==
X-Received: by 10.66.124.199 with SMTP id mk7mr56236604pab.89.1408567661321; Wed, 20 Aug 2014 13:47:41 -0700 (PDT)
Received: from [192.168.178.23] (37.199.69.111.dynamic.snap.net.nz. [111.69.199.37]) by mx.google.com with ESMTPSA id y4sm23248776pbt.60.2014.08.20.13.47.39 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Aug 2014 13:47:40 -0700 (PDT)
Message-ID: <53F5096B.7020604@gmail.com>
Date: Thu, 21 Aug 2014 08:47:39 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Fernando Gont <fgont@si6networks.com>
Subject: Re: Relax draft-gont-6man-deprecate-atomfrag-generation-00
References: <201408201356.s7KDuYc5026764@bagheera.jungle.bt.co.uk> <53F4B02B.3090607@si6networks.com> <201408201851.s7KIpA3k027926@bagheera.jungle.bt.co.uk> <53F4F828.8080502@si6networks.com>
In-Reply-To: <53F4F828.8080502@si6networks.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/e-Dhiwou4FRFBGcxZdsMIQp5SZc
Cc: ipv6@ietf.org, Bob Briscoe <bob.briscoe@bt.com>, draft-gont-6man-deprecate-atomfrag-generation@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 20:47:52 -0000

On 21/08/2014 07:34, Fernando Gont wrote:
> On 08/20/2014 03:51 PM, Bob Briscoe wrote:
>>> The question here is this:
>>> The semantics of an ICMPv6 PTB is "Your packet was discarded, and this
>>> is the size you should use for further packets". So (at least in an
>>> IPv6-only world), an ICMPv6 PTB<1280 does not really signal that the
>>> packet is being fragmented (since IPv6 routers do not fragment packets).
>>>
>>>
>>> While I agree that, at least in theory, one could receive ICMPv6
>>> PTB<1280, do nothing at the network layer, but still report the received
>>> message to the transport layer, I'd probably say that acting on such
>>> message kind of eliminates the concept of "IPv6 minimum MTU" -- i.e.,
>>> "if all IPv6 networks support an MTU>=1280 bytes, why am I receiving
>>> this ICMPv6 PTB that claims an MTU smaller than 1280?".
>> The idea that IPv6 can declare that the min MTU will be 1280 stems from
>> the idea that every link technology will have to implement an
>> encapsulation of v6, so implementers should be able to ensure this new
>> min MTU will always be honoured. However, that thinking overlooks the
>> fact that IPv4 can also act as a 'link technology' for IPv6.
> 
> My understanding is that, when you employ IPv4 as a "link technology"
> for IPv6, you need to offer IPv6 an MTU of at least 1280 bytes (e.g., by
> relying on IPv4 fragmentation).

That is an explicit requirement for v6-in-v4 tunnels in RFC 4213.
(See text and pseudo-code in section 3.2.2.) There is no get-out-of-jail
card for the 1280 MTU.

    Brian

> 
> Note: I'm not arguing whether that's a good idea or not, but rather that
> it's "doable".
> 


From nobody Wed Aug 20 13:50:02 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CFD1A0ADC for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 13:50:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 BOGUJSqAsoLy for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 13:49:59 -0700 (PDT)
Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217A11A0661 for <ipv6@ietf.org>; Wed, 20 Aug 2014 13:49:56 -0700 (PDT)
Received: by mail-pd0-f176.google.com with SMTP id y10so12283062pdj.35 for <ipv6@ietf.org>; Wed, 20 Aug 2014 13:49:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Nrt0AtYw37g0KP5zNOwSOfTLNciHCsJaAwx/5Lsv0ME=; b=EmkdcPX7Z9pVyTwU+iX4ooJBLKDKMb8G7E/h+8fp+3qLvrRUNvR8eUHcrXXztIDSif AV/jPUwBoMEpNQLoiGE1mwwWlMnY5Q7F/HaQUV5EX1xGi/6ItNt8HSiKDIlzQrh6svts dRPNhYQT95wouHphoXibyqaWoQsRkxUQh3IKy189Q1bM2y+Y7WnwVSF+9K8z94XxNC08 yHumBrbWemI3/Xq6yIkwbGzyQmKnpuPSh6PPVG95FzSTr6yzVE+XUo3rkZd7SB8vsRVN kyRUhi1M6CGFXsthh4Fu1ou/xYvgXG3xnpqpl+7rMVhRo4PZDZOyxZndT49011nX/8Az EUbg==
X-Received: by 10.66.124.168 with SMTP id mj8mr55883548pab.78.1408567795643; Wed, 20 Aug 2014 13:49:55 -0700 (PDT)
Received: from [192.168.178.23] (37.199.69.111.dynamic.snap.net.nz. [111.69.199.37]) by mx.google.com with ESMTPSA id j4sm9186142pda.36.2014.08.20.13.49.53 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Aug 2014 13:49:55 -0700 (PDT)
Message-ID: <53F509F7.4090500@gmail.com>
Date: Thu, 21 Aug 2014 08:49:59 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
Subject: Re: [Fwd: I-D Action: draft-ietf-6man-why64-02.txt]
References: <53EEB906.20206@gmail.com> <1408532691.50051.YahooMailNeo@web162206.mail.bf1.yahoo.com> <1408533920.87649.YahooMailNeo@web162204.mail.bf1.yahoo.com>
In-Reply-To: <1408533920.87649.YahooMailNeo@web162204.mail.bf1.yahoo.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/5b26YvDx2mNtUCcu-ITPqEq4qeQ
Cc: 6man <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 20:50:00 -0000

Thanks thanks Mark ;-)

   Brian

On 20/08/2014 23:25, Mark ZZZ Smith wrote:
> 
> 
> 
> ----- Original Message -----
>> From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
>> To: Brian E Carpenter <brian.e.carpenter@gmail.com>; 6man <ipv6@ietf.org>
>> Cc: 
>> Sent: Wednesday, 20 August 2014 9:04 PM
>> Subject: Re: [Fwd: I-D Action: draft-ietf-6man-why64-02.txt]
>>
>> Hi,
>>
>> I'm happy with the changes.
>>
>> Minor nit, duplicate 'the'
>>
>> " At the *the* time of publication 
>>      of RFC 2710, the IPv6 addressing architecture specified link-local 
>>      addresses with 64-bit interface identifiers. "
>>  
> 
> (And my original mistake. I'll have to start doing detailed reviews of my detailed reviews ;-) )
> 
>> Regards,
>> Mark.
>>
>>
>>
>>
>> ----- Original Message -----
>>>  From: Brian E Carpenter <brian.e.carpenter@gmail.com>
>>>  To: 6man <ipv6@ietf.org>
>>>  Cc: 
>>>  Sent: Saturday, 16 August 2014 11:51 AM
>>>  Subject: [Fwd: I-D Action: draft-ietf-6man-why64-02.txt]
>>>
>>> T his version is intended to respond to all the WG last call
>>>  comments and reviews. Here are the changes:
>>>
>>>  - numerous editorial improvements
>>>  - numerous small technical clarifications
>>>  - added reference to HD ratio
>>>  - expanded MLD text
>>>  - added text on duplicate address issue
>>>
>>>  Comments welcome.
>>>
>>>    Brian + co-authors
>>>
>>>  -------- Original Message --------
>>>  Subject: I-D Action: draft-ietf-6man-why64-02.txt
>>>  Date: Fri, 15 Aug 2014 18:48:49 -0700
>>>  From: internet-drafts@ietf.org
>>>  To: i-d-announce@ietf.org
>>>  CC: ipv6@ietf.org
>>>
>>>
>>>  A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>>>  This draft is a work item of the IPv6 Maintenance Working Group of the 
>> IETF.
>>>          Title           : Analysis of the 64-bit Boundary in IPv6 
>> Addressing
>>>          Authors         : Brian Carpenter
>>>                            Tim Chown
>>>                            Fernando Gont
>>>                            Sheng Jiang
>>>                            Alexandru Petrescu
>>>                            Andrew Yourtchenko
>>>      Filename        : draft-ietf-6man-why64-02.txt
>>>      Pages           : 24
>>>      Date            : 2014-08-15
>>>
>>>  Abstract:
>>>     The IPv6 unicast addressing format includes a separation between the
>>>     prefix used to route packets to a subnet and the interface identifier
>>>     used to specify a given interface connected to that subnet.
>>>     Currently the interface identifier is defined as 64 bits long for
>>>     almost every case, leaving 64 bits for the subnet prefix.  This
>>>     document describes the advantages of this fixed boundary and analyses
>>>     the issues that would be involved in treating it as a variable
>>>     boundary.
>>>
>>>
>>>  The IETF datatracker status page for this draft is:
>>>  https://datatracker.ietf.org/doc/draft-ietf-6man-why64/
>>>
>>>  There's also a htmlized version available at:
>>>  http://tools.ietf.org/html/draft-ietf-6man-why64-02
>>>
>>>  A diff from the previous version is available at:
>>>  http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-why64-02
>>>
>>>
>>>  Please note that it may take a couple of minutes from the time of 
>> submission
>>>  until the htmlized version and diff are available at tools.ietf.org.
>>>
>>>  Internet-Drafts are also available by anonymous FTP at:
>>>  ftp://ftp.ietf.org/internet-drafts/
>>>
>>>  --------------------------------------------------------------------
>>>  IETF IPv6 working group mailing list
>>>  ipv6@ietf.org
>>>  Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>  --------------------------------------------------------------------
>>>
>>>  --------------------------------------------------------------------
>>>  IETF IPv6 working group mailing list
>>>  ipv6@ietf.org
>>>  Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>  --------------------------------------------------------------------
>>>
> 


From nobody Wed Aug 20 23:50:17 2014
Return-Path: <bob.briscoe@bt.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3891A0694 for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 11:51:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.269
X-Spam-Level: 
X-Spam-Status: No, score=-1.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_36=1, J_BACKHAIR_37=1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=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 Qb3B1Nry9cRy for <ipv6@ietfa.amsl.com>; Wed, 20 Aug 2014 11:51:16 -0700 (PDT)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99CB21A0678 for <ipv6@ietf.org>; Wed, 20 Aug 2014 11:51:15 -0700 (PDT)
Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 20 Aug 2014 19:51:13 +0100
Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 20 Aug 2014 19:51:13 +0100
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Wed, 20 Aug 2014 19:51:12 +0100
Received: from BTP075694.jungle.bt.co.uk ([10.215.130.93])	by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s7KIpA3k027926;	Wed, 20 Aug 2014 19:51:10 +0100
Message-ID: <201408201851.s7KIpA3k027926@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Wed, 20 Aug 2014 19:51:09 +0100
To: Fernando Gont <fgont@si6networks.com>
From: Bob Briscoe <bob.briscoe@bt.com>
Subject: Re: Relax draft-gont-6man-deprecate-atomfrag-generation-00
In-Reply-To: <53F4B02B.3090607@si6networks.com>
References: <201408201356.s7KDuYc5026764@bagheera.jungle.bt.co.uk> <53F4B02B.3090607@si6networks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/l3KXG2rCHnVnBf0LpFFXQXSOu7w
X-Mailman-Approved-At: Wed, 20 Aug 2014 23:50:16 -0700
Cc: ipv6@ietf.org, draft-gont-6man-deprecate-atomfrag-generation@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Aug 2014 18:51:17 -0000

Fernando,

At 15:26 20/08/2014, Fernando Gont wrote:
>Hi, Bob,
>
>Thanks so much for your feedback! -- Please find my comments in-line....
>
>On 08/20/2014 10:56 AM, Bob Briscoe wrote:
> >
> > [I've cc'd ipv6, but I'm not subscribed, so pls include me specifically
> > in any response.]
> >
> > S.4
> > Agree The current 2460 rule creates a vulnerability, but don't agree
> > with [sender] "MUST discard ICMPv6 Packet Too Big" as the remedy. I
> > would prefer "MUST NOT include a Fragment header in subsequent packets",
> > which is the minimum needed to address the actual attack.
>
>Clarification on our side (since what we conveyed might be different
>from what we meant): What we meant is that if a host receives an ICMPv6
>< 1280, it MUST NOT start sending atomic fragments.
>
>So I will apply your suggested change -- thanks!
>
>
> > Reasoning: there is no danger in the sender being aware that its packets
> > are being fragmented. 2460 says the sender "is not required to reduce
> > the size of subsequent packets", but this only means it doesn't have to;
> > it doesn't mean it MUST NOT. In many cases the sender will be able to
> > help the v6/v4 gateway improve performance by using a smaller segment
> > size (e.g. if using TCP), rather than merely sending atomic fragments.
>
>The question here is this:
>The semantics of an ICMPv6 PTB is "Your packet was discarded, and this
>is the size you should use for further packets". So (at least in an
>IPv6-only world), an ICMPv6 PTB<1280 does not really signal that the
>packet is being fragmented (since IPv6 routers do not fragment packets).
>
>
>While I agree that, at least in theory, one could receive ICMPv6
>PTB<1280, do nothing at the network layer, but still report the received
>message to the transport layer, I'd probably say that acting on such
>message kind of eliminates the concept of "IPv6 minimum MTU" -- i.e.,
>"if all IPv6 networks support an MTU>=1280 bytes, why am I receiving
>this ICMPv6 PTB that claims an MTU smaller than 1280?".

The idea that IPv6 can declare that the min MTU will be 1280 stems 
from the idea that every link technology will have to implement an 
encapsulation of v6, so implementers should be able to ensure this 
new min MTU will always be honoured. However, that thinking overlooks 
the fact that IPv4 can also act as a 'link technology' for IPv6. And 
IPv4 doesn't enforce IPv6's min MTU for the link technologies over 
which it has already been implemented.

The designers of IPv6 might have wanted to pretend that v6 could make 
a clean break from IPv4 where MTU is concerned, but the IETF's prime 
objective is to ensure interworking (esp. between the two Internet 
protocols), which has to involve some compromises on the purity of v6.


Bob


>Thoughts?
>
>
> > One nit noticed:
> > S.3:
> > s/When server server B/When server B/
>
>Yep. Fixed.
>
>Thanks!
>
>Best regards,
>--
>Fernando Gont
>SI6 Networks
>e-mail: fgont@si6networks.com
>PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

________________________________________________________________
Bob Briscoe,                                                  BT 


From nobody Thu Aug 21 07:27:33 2014
Return-Path: <antonios.atlasis@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACFA1A031A for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 07:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 DjreeOdwYBrv for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 07:27:17 -0700 (PDT)
Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010511A036D for <ipv6@ietf.org>; Thu, 21 Aug 2014 07:27:16 -0700 (PDT)
Received: by mail-ob0-f182.google.com with SMTP id wm4so7439239obc.41 for <ipv6@ietf.org>; Thu, 21 Aug 2014 07:27:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jzHYrHz0FXuljSFejpSQNGuvi5c47an1WACKQYSWU5o=; b=SBNvtTw3klwIxRtIq4zGCVceG5R4BX/C17L/th9BspsUL72QjkOdXWIRW4gmHrpl4k Ch6mGNeUjCOF9g6G0tT/JfX20zz7cuoo8VCBOw64dkgifgb4cYtWZEcoGwhi1T/Yr62x 2wcWinD51zNV0u0QyBP2Y8euLsNzL+anXeERBBCwLdYao5JQ06UfSmsdNVK5rm0oq4Qx eqmLQpvqqP/4kmPf1Jkjt7zXeiWpenQN33ivCHoyj75efzmxdPqa4stMJZkZCJio+fjk 1RbbcAjPeJGlkcL95qmOMtkpXqZy+9thvQruYhrnnMwNTO8rMVbyuozIywWtibo/LGEe iO/Q==
MIME-Version: 1.0
X-Received: by 10.60.102.100 with SMTP id fn4mr9335591oeb.30.1408631235502; Thu, 21 Aug 2014 07:27:15 -0700 (PDT)
Received: by 10.202.206.212 with HTTP; Thu, 21 Aug 2014 07:27:15 -0700 (PDT)
In-Reply-To: <53F5096B.7020604@gmail.com>
References: <201408201356.s7KDuYc5026764@bagheera.jungle.bt.co.uk> <53F4B02B.3090607@si6networks.com> <201408201851.s7KIpA3k027926@bagheera.jungle.bt.co.uk> <53F4F828.8080502@si6networks.com> <53F5096B.7020604@gmail.com>
Date: Thu, 21 Aug 2014 17:27:15 +0300
Message-ID: <CADoTVZKK51n4aqwCA5MUkR6=OAn1gsps9YY=c=oNmwaH5tn_Ww@mail.gmail.com>
Subject: Re: Relax draft-gont-6man-deprecate-atomfrag-generation-00
From: Antonios Atlasis <antonios.atlasis@gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary=089e0111d84269cbfb0501248424
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/sa0b-tmN1qfJj2pjI-gtsS8cW94
Cc: ipv6@ietf.org, draft-gont-6man-deprecate-atomfrag-generation@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 14:27:20 -0000

--089e0111d84269cbfb0501248424
Content-Type: text/plain; charset=UTF-8

Hi,

please, allow me a comment from my side:

- If Atomic Fragments are/can be more or less useless (as I derived from
some parts of the proposed RFC and from some of the Fernando's comments),
then, no matter if there are security implications or not, please deprecate
them. That simple.

- However, if I did not understand correctly and, by any chance, you
believe that they serve some purpose, I believe that a) we should examine
carefully the scale of these security implications, b) we should check if
there are / can be some other mitigation techniques. For instance,
regarding TCP traffic at least, both end-hosts and (stateful) firewalls
keep track of the their connections. So, it can be easy for them to check
whether the incoming ICMPv6 Packet Too Big messages come as a response to a
corresponding outgoing TCP packet or not (since PTB messages contain at
least the header that triggered them).

Just some thoughts

Best

Antonios


2014-08-20 23:47 GMT+03:00 Brian E Carpenter <brian.e.carpenter@gmail.com>:

> On 21/08/2014 07:34, Fernando Gont wrote:
> > On 08/20/2014 03:51 PM, Bob Briscoe wrote:
> >>> The question here is this:
> >>> The semantics of an ICMPv6 PTB is "Your packet was discarded, and this
> >>> is the size you should use for further packets". So (at least in an
> >>> IPv6-only world), an ICMPv6 PTB<1280 does not really signal that the
> >>> packet is being fragmented (since IPv6 routers do not fragment
> packets).
> >>>
> >>>
> >>> While I agree that, at least in theory, one could receive ICMPv6
> >>> PTB<1280, do nothing at the network layer, but still report the
> received
> >>> message to the transport layer, I'd probably say that acting on such
> >>> message kind of eliminates the concept of "IPv6 minimum MTU" -- i.e.,
> >>> "if all IPv6 networks support an MTU>=1280 bytes, why am I receiving
> >>> this ICMPv6 PTB that claims an MTU smaller than 1280?".
> >> The idea that IPv6 can declare that the min MTU will be 1280 stems from
> >> the idea that every link technology will have to implement an
> >> encapsulation of v6, so implementers should be able to ensure this new
> >> min MTU will always be honoured. However, that thinking overlooks the
> >> fact that IPv4 can also act as a 'link technology' for IPv6.
> >
> > My understanding is that, when you employ IPv4 as a "link technology"
> > for IPv6, you need to offer IPv6 an MTU of at least 1280 bytes (e.g., by
> > relying on IPv4 fragmentation).
>
> That is an explicit requirement for v6-in-v4 tunnels in RFC 4213.
> (See text and pseudo-code in section 3.2.2.) There is no get-out-of-jail
> card for the 1280 MTU.
>
>     Brian
>
> >
> > Note: I'm not arguing whether that's a good idea or not, but rather that
> > it's "doable".
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



-- 
=====================
Antonios Atlasis, PhD, MPhil
GXPN, GREM, GPEN, GWAPT, CCIH, GCIA

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

<div dir=3D"ltr">Hi, <br><div class=3D"gmail_extra"><br></div><div class=3D=
"gmail_extra">please, allow me a comment from my side:<br><br></div><div cl=
ass=3D"gmail_extra">- If Atomic Fragments are/can be more or less useless (=
as I derived from some parts of the proposed RFC and from some of the Ferna=
ndo&#39;s comments), then, no matter if there are security implications or =
not, please deprecate them. That simple.<br>
<br></div><div class=3D"gmail_extra">- However, if I did not understand cor=
rectly and, by any chance, you believe that they serve some purpose, I beli=
eve that a) we should examine carefully the scale of these security implica=
tions, b) we should check if there are / can be some other mitigation techn=
iques. For instance, regarding TCP traffic at least, both end-hosts and (st=
ateful) firewalls keep track of the their connections. So, it can be easy f=
or them to check whether the incoming ICMPv6 Packet Too Big messages come a=
s a response to a corresponding outgoing TCP packet or not (since PTB messa=
ges contain at least the header that triggered them). <br>
<br></div><div class=3D"gmail_extra">Just some thoughts<br><br></div><div c=
lass=3D"gmail_extra">Best<br><br>Antonios<br></div><div class=3D"gmail_extr=
a">=C2=A0<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail=
_extra"><div class=3D"gmail_quote">
2014-08-20 23:47 GMT+03:00 Brian E Carpenter <span dir=3D"ltr">&lt;<a href=
=3D"mailto:brian.e.carpenter@gmail.com" target=3D"_blank">brian.e.carpenter=
@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"">On 21/08/2014 07:34, Fernando Gont wrote:<br>
&gt; On 08/20/2014 03:51 PM, Bob Briscoe wrote:<br>
&gt;&gt;&gt; The question here is this:<br>
&gt;&gt;&gt; The semantics of an ICMPv6 PTB is &quot;Your packet was discar=
ded, and this<br>
&gt;&gt;&gt; is the size you should use for further packets&quot;. So (at l=
east in an<br>
&gt;&gt;&gt; IPv6-only world), an ICMPv6 PTB&lt;1280 does not really signal=
 that the<br>
&gt;&gt;&gt; packet is being fragmented (since IPv6 routers do not fragment=
 packets).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; While I agree that, at least in theory, one could receive ICMP=
v6<br>
&gt;&gt;&gt; PTB&lt;1280, do nothing at the network layer, but still report=
 the received<br>
&gt;&gt;&gt; message to the transport layer, I&#39;d probably say that acti=
ng on such<br>
&gt;&gt;&gt; message kind of eliminates the concept of &quot;IPv6 minimum M=
TU&quot; -- i.e.,<br>
&gt;&gt;&gt; &quot;if all IPv6 networks support an MTU&gt;=3D1280 bytes, wh=
y am I receiving<br>
&gt;&gt;&gt; this ICMPv6 PTB that claims an MTU smaller than 1280?&quot;.<b=
r>
&gt;&gt; The idea that IPv6 can declare that the min MTU will be 1280 stems=
 from<br>
&gt;&gt; the idea that every link technology will have to implement an<br>
&gt;&gt; encapsulation of v6, so implementers should be able to ensure this=
 new<br>
&gt;&gt; min MTU will always be honoured. However, that thinking overlooks =
the<br>
&gt;&gt; fact that IPv4 can also act as a &#39;link technology&#39; for IPv=
6.<br>
&gt;<br>
&gt; My understanding is that, when you employ IPv4 as a &quot;link technol=
ogy&quot;<br>
&gt; for IPv6, you need to offer IPv6 an MTU of at least 1280 bytes (e.g., =
by<br>
&gt; relying on IPv4 fragmentation).<br>
<br>
</div>That is an explicit requirement for v6-in-v4 tunnels in RFC 4213.<br>
(See text and pseudo-code in section 3.2.2.) There is no get-out-of-jail<br=
>
card for the 1280 MTU.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
=C2=A0 =C2=A0 Brian<br>
</font></span><div class=3D"im HOEnZb"><br>
&gt;<br>
&gt; Note: I&#39;m not arguing whether that&#39;s a good idea or not, but r=
ather that<br>
&gt; it&#39;s &quot;doable&quot;.<br>
&gt;<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">-----------------------------=
---------------------------------------<br>
IETF IPv6 working group mailing list<br>
<a href=3D"mailto:ipv6@ietf.org">ipv6@ietf.org</a><br>
Administrative Requests: <a href=3D"https://www.ietf.org/mailman/listinfo/i=
pv6" target=3D"_blank">https://www.ietf.org/mailman/listinfo/ipv6</a><br>
--------------------------------------------------------------------<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Antonios Atlasis,=
 PhD, MPhil<br>
GXPN, GREM, GPEN, GWAPT, CCIH, GCIA
</div></div>

--089e0111d84269cbfb0501248424--


From nobody Thu Aug 21 07:48:58 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 361101A00DD for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 07:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 2fiC1zZd5E_L for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 07:48:54 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37EFF1A03AD for <ipv6@ietf.org>; Thu, 21 Aug 2014 07:48:54 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XKTfX-0006Jl-Ur; Thu, 21 Aug 2014 16:48:52 +0200
Message-ID: <53F606C5.9050603@si6networks.com>
Date: Thu, 21 Aug 2014 11:48:37 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "ipv6@ietf.org" <ipv6@ietf.org>
Subject: Atomic fragments (interoperability issues)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/zHAmGSxPZXDCJbfGIi-ko1wzX3I
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 14:48:57 -0000

Folks,

This is some text we've drafted regarding the interoperability
implications of relying on IPv6 atomic fragments for translators. --
comments welcome.

---- cut here ----
   Besides the security assessment provided in Section 3, it is
   interesting to evaluate the pros and cons of having IPv6-to-IPv4
   translating router rely on the generation of IPv6 atomic fragments.

   Relying on the generation of IPv6 atomic fragments implies a reliance
   on:

   1.  ICMPv6 packets arriving from the sending node to the destination
       node

   2.  Nodes receiving ICMPv6 PTB messages reporting an MTU smaller than
       1280 bytes actually producing atomic fragments

   3.  Support for IPv6 fragmentation on the IPv6 side of the translator

   Unfortunately,

   o  There exists a fair share of evidence of ICMPv6 Packet Too Big
      messages being dropped on the public Internet (for instance, that
      is one of the reasons for which the [RFC4821] was published).
      Therefore, relying on such messages being successfully delivered
      will affect the robustness of the protocol that relies on them.

   o  A number of IPv6 implementations have been known to fail to
      generate IPv6 atomic fragments in response to ICMPv6 PTB messages
      reporting an MTU smaller than 1280 bytes [RFC6946] [Morbitzer].
      Additionally, results included in Section 6 of [RFC6145] note that
      57% of the tested web servers failed to produce IPv6 atomic
      fragments in response to ICMPv6 PTB messages reporting an MTU
      smaller than 1280 bytes.  Thus, any protocol relying on IPv6
      atomic fragment generation for proper functioning will have
      interoperability problems with the aforementioned IPv6 stacks.

   o  IPv6 atomic fragment generation represents a case in which
      fragmented traffic is produced where otherwise it would not be
      needed.  Since there is widespread filtering of IPv6 fragments in
      the public Internet [I-D.gont-v6ops-ipv6-ehs-in-real-world], this
      would mean that the (unnecessary) use of IPv6 fragmentation might
      result, unnecessarily, in a Denial of Service situation even in
      legitimate cases.

   [RFC6145] is currently the only "consumer" of IPv6 atomic fragments,
   and it correctly and diligently notes (in Section 6) the possible
   interoperability problems of relying on IPv6 atomic fragments,
   proposing as a workaround something very similar to what we proposed
   in Section 6.  We believe that, by making the more robust behavior
   the default behavior of the "IP/ICMP Translation Algorithm",
   robustness is increased, and the corresponding code is simplified.
---- cut here ----

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Aug 21 07:53:33 2014
Return-Path: <pch-bBB316E3E@u-1.phicoh.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB041A0092 for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 02:13:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.9
X-Spam-Level: 
X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] autolearn=ham
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 h5dhj-KPTIMQ for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 02:13:14 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 68A541A0091 for <ipv6@ietf.org>; Thu, 21 Aug 2014 02:13:13 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1XKOQZ-0000DvC; Thu, 21 Aug 2014 11:13:03 +0200
Message-Id: <m1XKOQZ-0000DvC@stereo.hq.phicoh.net>
To: Bob Briscoe <bob.briscoe@bt.com>
Subject: Re: Relax draft-gont-6man-deprecate-atomfrag-generation-00 
From: Philip Homburg <pch-6man-1b@u-1.phicoh.com>
Sender: pch-bBB316E3E@u-1.phicoh.com
References: <201408201356.s7KDuYc5026764@bagheera.jungle.bt.co.uk> <53F4B02B.3090607@si6networks.com> <201408201851.s7KIpA3k027926@bagheera.jungle.bt.co.uk> 
In-reply-to: Your message of "Wed, 20 Aug 2014 19:51:09 +0100 ." <201408201851.s7KIpA3k027926@bagheera.jungle.bt.co.uk> 
Date: Thu, 21 Aug 2014 11:13:02 +0200
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/wmGVnNAq6h64J7l_JRlTyo-v-O4
X-Mailman-Approved-At: Thu, 21 Aug 2014 07:53:32 -0700
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 09:13:16 -0000

In your letter dated Wed, 20 Aug 2014 19:51:09 +0100 you wrote:
>The idea that IPv6 can declare that the min MTU will be 1280 stems 
>from the idea that every link technology will have to implement an 
>encapsulation of v6, so implementers should be able to ensure this 
>new min MTU will always be honoured. However, that thinking overlooks 
>the fact that IPv4 can also act as a 'link technology' for IPv6. And 
>IPv4 doesn't enforce IPv6's min MTU for the link technologies over 
>which it has already been implemented.

IPv6 over IPv4 works fine if you use IPv4 fragmentation.

The problem starts when the tunnel endpoint is not an IPv4 host but some
kind of stateless IPv6 to IPv4 translator. Then you need an IPv4 MTU of 1260.

Not a real problem, just limit stateless IPv6 to IPv4 translators to
situations where you know that the IPv4 path MTU is big enough.



From nobody Thu Aug 21 08:00:22 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8851A8764 for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 08:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 ZA5xk-jEg0_4 for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 08:00:06 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6FF1A0113 for <ipv6@ietf.org>; Thu, 21 Aug 2014 08:00:05 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XKTqN-0006LO-1V; Thu, 21 Aug 2014 17:00:03 +0200
Message-ID: <53F60968.4010903@si6networks.com>
Date: Thu, 21 Aug 2014 11:59:52 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Antonios Atlasis <antonios.atlasis@gmail.com>
Subject: Re: Relax draft-gont-6man-deprecate-atomfrag-generation-00
References: <201408201356.s7KDuYc5026764@bagheera.jungle.bt.co.uk>	<53F4B02B.3090607@si6networks.com>	<201408201851.s7KIpA3k027926@bagheera.jungle.bt.co.uk>	<53F4F828.8080502@si6networks.com>	<53F5096B.7020604@gmail.com> <CADoTVZKK51n4aqwCA5MUkR6=OAn1gsps9YY=c=oNmwaH5tn_Ww@mail.gmail.com>
In-Reply-To: <CADoTVZKK51n4aqwCA5MUkR6=OAn1gsps9YY=c=oNmwaH5tn_Ww@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/6R3D1-_cv3mN6lvWDK_P7o_3Cmg
Cc: ipv6@ietf.org, draft-gont-6man-deprecate-atomfrag-generation@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 15:00:08 -0000

Hi, Antonios,

Thanks so much for your feedback! -- Comments in-line...

On 08/21/2014 11:27 AM, Antonios Atlasis wrote:
> - If Atomic Fragments are/can be more or less useless (as I derived from
> some parts of the proposed RFC and from some of the Fernando's
> comments), then, no matter if there are security implications or not,
> please deprecate them. That simple.

Truth is that, besides the security implications, there are
interoperability problems. Please see the message with subject "Atomic
fragments (interoperability issues)" I've just posted to this list.


> - However, if I did not understand correctly and, by any chance, you
> believe that they serve some purpose, 

Well, they are certainly used for "something" (essentially signaling
between the IPv6 node and the translator whether the DF bit should be
set or not).


>I believe that a) we should examine carefully the scale of these security implications,

The scale is simple: It's trivial to trigger their use. And since IPv6
fragments are widely dropped, that can be exploited for DoS.

Let me give one concrete example:
Google filters IPv6 fragments. Now, if I now you're mailserver IPv6
address and the IPv6 addresses to which gmail.com will map to, I can
essentially prevent mail being delivered from your mailserver, to gmail.

Now let's replace "your mailserver" with, say, Yahoo.. and if they
happen to honor ICMPv6 PTB<1280, they are subject to the same sort of
attack.

Try the "recipe" I provided in one of my earlier emails about this topic
(employing the icmp6 tool), and see it for yourself.


> b) we should
> check if there are / can be some other mitigation techniques. For
> instance, regarding TCP traffic at least, both end-hosts and (stateful)
> firewalls keep track of the their connections. 

All the IPv6 implementations I recall checking do not enforce any kind
of validation on the embedded IPv6 packet.

And, in a sense, there's a reason for that: because of extension header
(yes) you are not guaranteed to get the upper-layer header of the
original apcket (the one that triggered the error) in the ICMPv6 payload.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Aug 21 08:19:44 2014
Return-Path: <antonios.atlasis@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEECA1A0B17 for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 08:19:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 ZPJRR516vOva for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 08:19:41 -0700 (PDT)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5DE1A02ED for <ipv6@ietf.org>; Thu, 21 Aug 2014 08:19:41 -0700 (PDT)
Received: by mail-oi0-f49.google.com with SMTP id u20so6794402oif.36 for <ipv6@ietf.org>; Thu, 21 Aug 2014 08:19:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M8tnTpCi8JkUDM4b/2lJYODTbe6xc28urRY4kRym9Ik=; b=AzYhuEgnVLLjZl57cchGA2PqfSGDTAuccAHHXn7Vk6DXlI5157f0Tse2l8+4us7qmg N9oK3L90Cb+JgR2hrIbAkKGtjFj/nCcvVPL0vdf2Wg8F10DLlyVZbDdbOyxi6ao4aZic wo1hryLOLaFVFpa65/+PVDPSeIR3hDHP+0AjXmiekEDRQRIHhDDbSKG60EoDTM5duVRj Abg8F8hp4e7UWZF9z3TjdpaYe7kGpmsL4pWp12cWErxtP6HKYahfT1EgywEAF7PIKlZE W0gWfgtkZhW1PsMAqmuPGJqDAcIdPcq9MuICpj4KJLhdtses6zUnmXdKq5X187V/m+Zi v3eQ==
MIME-Version: 1.0
X-Received: by 10.60.74.232 with SMTP id x8mr2344939oev.84.1408634380633; Thu, 21 Aug 2014 08:19:40 -0700 (PDT)
Received: by 10.202.206.212 with HTTP; Thu, 21 Aug 2014 08:19:40 -0700 (PDT)
In-Reply-To: <53F60968.4010903@si6networks.com>
References: <201408201356.s7KDuYc5026764@bagheera.jungle.bt.co.uk> <53F4B02B.3090607@si6networks.com> <201408201851.s7KIpA3k027926@bagheera.jungle.bt.co.uk> <53F4F828.8080502@si6networks.com> <53F5096B.7020604@gmail.com> <CADoTVZKK51n4aqwCA5MUkR6=OAn1gsps9YY=c=oNmwaH5tn_Ww@mail.gmail.com> <53F60968.4010903@si6networks.com>
Date: Thu, 21 Aug 2014 18:19:40 +0300
Message-ID: <CADoTVZKsPd1iCwBu9jkRiQmdrwRUMg3QMqiJ8a7d2FYCDNeqKg@mail.gmail.com>
Subject: Re: Relax draft-gont-6man-deprecate-atomfrag-generation-00
From: Antonios Atlasis <antonios.atlasis@gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary=001a113483b4e0b65c0501253f1c
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/FMSwhz8lHtu7iQEKUS0xM7q3tsI
Cc: ipv6@ietf.org, draft-gont-6man-deprecate-atomfrag-generation@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 15:19:43 -0000

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

Hi Fernando,

I appreciate your response. Going directly to my final point:


2014-08-21 17:59 GMT+03:00 Fernando Gont <fgont@si6networks.com>:

> ...

Well, they are certainly used for "something" (essentially signaling
> between the IPv6 node and the translator whether the DF bit should be
> set or not).
> ...
>
And, in a sense, there's a reason for that: because of extension header
> (yes) you are not guaranteed to get the upper-layer header of the
> original apcket (the one that triggered the error) in the ICMPv6 payload.
>


So, since they are used for sthg, as you said, why not focusing on
mitigation? You get the upper layer because you get the PTB messages
(that's the upper layer) - unless of course you filter them deliberately
(in which case, the filtering devices still gets it, in order to filter it)
and the header of the protocol that triggered the legitimate PRB messages
is the payload of this upper layer. So, you do not have to get yet another
upper layer.

A final rhetorical question to all: Should the "design" (or at least, the
update) of a protocol be driven from what is currently enforced, to
whatever extend, OR should it aim at optimizing features like
functionality, interoperability, etc. AND security, of course, and finally,
proper implementation has to follow?

I have posted some similar, more extended thoughts about this subjecy, as a
"Personal Comment" at this blogpost, for those who may be interested:
http://www.insinuator.net/2014/08/atomic-fragments-vs-fragmentation-in-the-ipv6-real-world/

Best

Antonios

-- 
=====================
Antonios Atlasis, PhD, MPhil
GXPN, GREM, GPEN, GWAPT, CCIH, GCIA

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

<div dir=3D"ltr"><div>Hi Fernando, <br><br></div>I appreciate your response=
. Going directly to my final point:<br><div class=3D"gmail_extra"><br><br><=
div class=3D"gmail_quote">2014-08-21 17:59 GMT+03:00 Fernando Gont <span di=
r=3D"ltr">&lt;<a href=3D"mailto:fgont@si6networks.com" target=3D"_blank">fg=
ont@si6networks.com</a>&gt;</span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">...=C2=A0</blockquote><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">
Well, they are certainly used for &quot;something&quot; (essentially signal=
ing<br>
between the IPv6 node and the translator whether the DF bit should be<br>
set or not).<br>...=C2=A0 <br></blockquote><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">
And, in a sense, there&#39;s a reason for that: because of extension header=
<br>
(yes) you are not guaranteed to get the upper-layer header of the<br>
original apcket (the one that triggered the error) in the ICMPv6 payload.<b=
r></blockquote></div><br><br></div><div class=3D"gmail_extra">So, since the=
y are used for sthg, as you said, why not focusing on mitigation? You get t=
he upper layer because you get the PTB messages (that&#39;s the upper layer=
) - unless of course you filter them deliberately (in which case, the filte=
ring devices still gets it, in order to filter it) and the header of the pr=
otocol that triggered the legitimate PRB messages is the payload of this up=
per layer. So, you do not have to get yet another upper layer.<br>
<br></div><div class=3D"gmail_extra">A final rhetorical question to all: Sh=
ould the &quot;design&quot; (or at least, the update) of a protocol be driv=
en from what is currently enforced, to whatever extend, OR should it aim at=
 optimizing features like functionality, interoperability, etc. AND securit=
y, of course, and finally, proper implementation has to follow?<br>
<br></div><div class=3D"gmail_extra">I have posted some similar, more exten=
ded thoughts about this subjecy, as a &quot;Personal Comment&quot; at this =
blogpost, for those who may be interested: <a href=3D"http://www.insinuator=
.net/2014/08/atomic-fragments-vs-fragmentation-in-the-ipv6-real-world/">htt=
p://www.insinuator.net/2014/08/atomic-fragments-vs-fragmentation-in-the-ipv=
6-real-world/</a><br>
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Best<=
br><br>Antonios<br></div><div class=3D"gmail_extra"><br>-- <br>=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Antonios Atlasis, Ph=
D, MPhil<br>
GXPN, GREM, GPEN, GWAPT, CCIH, GCIA
</div></div>

--001a113483b4e0b65c0501253f1c--


From nobody Thu Aug 21 08:42:15 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23961A06B1 for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 08:42:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 EYdkcR-qOa9a for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 08:42:12 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435761A03FE for <ipv6@ietf.org>; Thu, 21 Aug 2014 08:42:12 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XKUV7-0006VA-U7; Thu, 21 Aug 2014 17:42:10 +0200
Message-ID: <53F6133A.6070602@si6networks.com>
Date: Thu, 21 Aug 2014 12:41:46 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Antonios Atlasis <antonios.atlasis@gmail.com>
Subject: Re: Relax draft-gont-6man-deprecate-atomfrag-generation-00
References: <201408201356.s7KDuYc5026764@bagheera.jungle.bt.co.uk>	<53F4B02B.3090607@si6networks.com>	<201408201851.s7KIpA3k027926@bagheera.jungle.bt.co.uk>	<53F4F828.8080502@si6networks.com>	<53F5096B.7020604@gmail.com>	<CADoTVZKK51n4aqwCA5MUkR6=OAn1gsps9YY=c=oNmwaH5tn_Ww@mail.gmail.com>	<53F60968.4010903@si6networks.com> <CADoTVZKsPd1iCwBu9jkRiQmdrwRUMg3QMqiJ8a7d2FYCDNeqKg@mail.gmail.com>
In-Reply-To: <CADoTVZKsPd1iCwBu9jkRiQmdrwRUMg3QMqiJ8a7d2FYCDNeqKg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/lhP6q2a8UUmVMFltcg51mAbmJZg
Cc: ipv6@ietf.org, draft-gont-6man-deprecate-atomfrag-generation@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 15:42:15 -0000

On 08/21/2014 12:19 PM, Antonios Atlasis wrote:
> 
> So, since they are used for sthg, as you said, why not focusing on
> mitigation?

Well, the mitigation is not to use them, since they are not really
necessary, and they tend to break SIIT in many environments.

(*Everything* can be used for "something".. the question is whether that
makes sense or not)


> You get the upper layer because you get the PTB messages
> (that's the upper layer)

Nope. When you get an ICMPv6, you get a piece of the packet that
originated the error message. In IPv4, you're guaranteed to get the full
IPv4 header, plus the first 8 bytes of the payload (which means you have
e.g. src IP, dst IP, src port, dst port, and TCP seq).

IN v6 that cannot be guaranteed, because of the same reason that, not
that long ago you were not even guaranteed to have the upper layer
header in the first fragment of a packet -- the uper-layer protocol can
be "padded" by extension headers.

Hence, you could just get "IPv6 header + a bunch of extension headers",
and no transport protocol header).


> A final rhetorical question to all: Should the "design" (or at least,
> the update) of a protocol be driven from what is currently enforced, to
> whatever extend, OR should it aim at optimizing features like
> functionality, interoperability, etc. AND security, of course, and
> finally, proper implementation has to follow?

Not sure I've understood your question. But I'd say "a balance of both".



> I have posted some similar, more extended thoughts about this subjecy,
> as a "Personal Comment" at this blogpost, for those who may be
> interested:
> http://www.insinuator.net/2014/08/atomic-fragments-vs-fragmentation-in-the-ipv6-real-world/

Short answer:
A 15% failure rate is still horrible. -- Ask any company that e.g. makes
money out of visits whether they would deploy something with such a
failure rate.

Finally, one thing is IPv6 atomic fragments being accepted, and another
is atomic fragments being generated. Both things contribute their share
of failure to the use of IPv6 atomic fragments.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Aug 21 11:16:13 2014
Return-Path: <nordmark@acm.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 471A41A7032 for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 11:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=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 ZctieciztoDM for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 11:16:09 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0081A6FD3 for <ipv6@ietf.org>; Thu, 21 Aug 2014 11:16:07 -0700 (PDT)
Received: from [172.22.249.34] ([162.210.130.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s7LIFvm4031005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 21 Aug 2014 11:15:58 -0700
Message-ID: <53F6375D.1070907@acm.org>
Date: Thu, 21 Aug 2014 11:15:57 -0700
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Dmitry Anipko <Dmitry.Anipko@microsoft.com>, Erik Nordmark <nordmark@acm.org>, Ole Troan <otroan@employees.org>
Subject: Re: draft-ietf-6man-resilient-rs update
References: <103E7D11-3748-4EA9-B3A4-C5027766001F@employees.org> <1403194605449.87135@microsoft.com> <5ED66186-B218-4A2B-A47B-B467BA92A742@employees.org> <53A4AE11.5040900@ericsson.com> <BA7546DE-AD9B-46BA-90DD-6E89836E2A2F@employees.org> <3dfb3ea73b5d450c923198ce06704f5a@SN2PR03MB077.namprd03.prod.outlook.com> <57CD62D4-0D87-4F23-A6AA-0AA9E4EFCD26@employees.org> <7613b4b345e2473fb48ef90e7dc5844f@SN2PR03MB077.namprd03.prod.outlook.com> <F795F34D-AC5F-4DB5-9B99-B7D2EA462839@employees.org> <8c9ccd4087ca4358862e773776bf67b5@SN2PR03MB077.namprd03.prod.outlook.com> <CB21E017-EB8A-449A-9EE9-0346C214DE24@employees.org> <d63acea236f64a22bd51b30cefad37b8@SN2PR03MB077.namprd03.prod.outlook.com> <53ED4910.7040104@acm.org> <9c69785532244f2aa3db4d752f384b9c@BLUPR03MB066.namprd03.prod.outlook.com>
In-Reply-To: <9c69785532244f2aa3db4d752f384b9c@BLUPR03MB066.namprd03.prod.outlook.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVbR6W63rF5L7Yg2AbXOyZlTYFyrKfII+NrUXtJPn3992Y7CdCyLijlaWyRudLahpuBi7AtIDPD9j9A4ww6UW7C/
X-Sonic-ID: C;8njaMl8p5BGkofofoK8kYw== M;fuPyMl8p5BGkofofoK8kYw==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/g9nau2nFaixVuzcfkNGz3sH6KAA
Cc: "<6man-chairs@tools.ietf.org>" <6man-chairs@tools.ietf.org>, "draft-ietf-6man-resilient-rs@tools.ietf.org" <draft-ietf-6man-resilient-rs@tools.ietf.org>, 6man WG <ipv6@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 18:16:11 -0000

On 8/14/14, 5:13 PM, Dmitry Anipko wrote:
> Hi Erik,
>
> After some offline discussion, here is the adjustment of the text we'd like to propose. Please let me know if this sufficiently mitigates your concern.
>
> Replace the first paragraph of the section 2.1 of http://tools.ietf.org/id/draft-ietf-6man-resilient-rs-03.txt  with the following:
>
> <text>
> On multicast-capable links, the hosts following this specification
> SHOULD stop retransmitting the RSs when Router Discovery is successful
> (i.e. an RA with a non-zero Router Lifetime that results in a default
> route is received).
>
> When and if all of the following conditions are met:
> 1. The host received an RA with non-zero Router Lifetime since the
> last attachment of the interface to the link, and has not received
> later an RA with zero Router Lifetime from the same router.
> 2. Less than N seconds (where N is randomly chosen by the host at the
> interface initialization time to be IRT < N <= 2*IRT) remain till the
> expiration of all of the known default routers on the interface.
What is IRT?
> the host MAY re-start sending of the RSs following the Proposed
> algorithm, described in the section 2.
> </text>

This ensures that as long as there is no outage there would be no extra 
RS messages.

However, if there is some outage all the hosts are likely to flood the 
network with RS messages at the same time.
(For instance, if L2 is fine but some L3 breakage results in the router 
not getting the RAs out.)

The "at the same time" part would be quite bad in a large network e.g. 
10000 hosts on the link - whether WiFi or cellular.
One could try to address that by adding a random delay, but that is a 
bit hard because the host doesn't know whether there are 10 or 10,000 
hosts on the link.

Furthermore, the algorithm in section 2 is to send multicast RS. That is 
needed if the last router silently died and a replacement router (with a 
different MAC and IPv6 address) has been put in place instead. 10,000 
muticast RS as the same time seems bad.

But if the issue is instead that the link isn't very good at delivering 
the multicast RAs and the router is fine, then a unicast RS would suffice.

But I still don't understand (or I don't agree) with the problem you are 
trying to solve.

Is the problem you want to solve a misconfigured router (which sends 
periodic RAs less frequently than the default router lifetime)?
Is it links where multicast (RAs) are very unreliable, hence the host 
can miss the 3 that should appear before the default router lifetime 
expires?
Routers which get replaced (without VRRP or HSRP) *and* do not send an 
initial set of multicast RAs?

For links with unreliable (or no) multicast RAs there are much more 
robust ways to do this.

    Erik

>
> -Dmitry
>
>
> -----Original Message-----
> From: Erik Nordmark [mailto:nordmark@acm.org]
> Sent: Thursday, August 14, 2014 4:41 PM
> To: Dmitry Anipko; Ole Troan
> Cc: <6man-chairs@tools.ietf.org>; draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG; Suresh Krishnan
> Subject: Re: draft-ietf-6man-resilient-rs update
>
>
> [Delay in responding due to travel and vacation]
>
> On 7/25/14, 5:21 PM, Dmitry Anipko wrote:
>> Let's separate discussions on the substance and on what exact language we put in the draft.
>>
>> Substance wise - IMO, the change tries to reduce existing fragility of RD in some situations. We had very real real-world support cases with one of the top mobile operators in the US, where the network was not sending new RAs before expiring the info in the initial one. Yes, this was  a misconfiguration / bug on the network side. Yes, this is where it was eventually fixed, and yes perhaps the support teams should not have taken as much time to figure it out. But the end-users don't care about that part, and they would be better off in the meantime if the protocol had more resiliency against misconfiguration or packet loss. Speaking for myself only, this is the scenario I'm concerned about. I'm sure there are others who know the "no multicast RAs, period" scenario better than I do, and they can speak for that.
> Dmitry,
> I don't understand how we can make the protocol specification more robust against the above type of misconfiguration - at least not without resulting in a lot more chatty protocol.
>
> For instance, suppose we say that hosts should send unicast a RS every
> 10 seconds. That would be quite chatty and would still result in the same failures if the operator accidentally configures the router (and/or
> prefix) lifetime to be 5 seconds.
> And having the hosts look at the remaining lifetimes and decide to unicast (or multicast) RSes closer and closer together as the
> lifetime(s) get closer to expiry might result in an explosion of RS messages during a network outage.
>
>      Erik
>
>> So I think it would be good to first understand, leaving specific RFC language aside, whether there is consensus to improve RD reliability when the host sees that previously received information has expired / about to expire. My impression from the discussion in London was that there was such consensus - but perhaps I misunderstood. Letting the host do additional rate-limited transmissions to solve that, to me looks like a simple and reasonable approach. If you agree with that, then what's the specific concern on putting that as MAY?
>>
>> I do disagree with the viewpoint, that because if ND use of multicast is inefficient, let's not make any improvements to ND until multicast issue is solved. Yes, the multicast-related issues in general do need to be addressed over long term. But addressing them will take time, and there are issues today which end-users are hitting, for which incremental limited fixes within existing framework are possible and reasonable.
>>
>>>> today, links without periodic RAs are not supported.
>> Since this is a statement about today, it equally applies (or not applies), to the option 2 you suggested and the option I suggested, so it's not a differentiator. Furthermore, it basically is equivalent to option 1, which makes it not an independent argument, but re-iterating option 1, and can't be used as a differentiator there either.
>>
>> -----Original Message-----
>> From: Ole Troan [mailto:otroan@employees.org]
>> Sent: Thursday, July 24, 2014 8:25 PM
>> To: Dmitry Anipko
>> Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>;
>> draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG
>> Subject: Re: draft-ietf-6man-resilient-rs update
>>
>>>>> wouldn't those hosts initially do router discovery, then not ever send RS again, and would be left without a default router when the router lifetime expired?
>>> Assuming there are no other events, such as media state change - correct, and that's the behavior they get today. As I understand it, this MAY is about a specific behavior improvement, compared to the today state, which a vendor may choose to implement.
>> today, links without periodic RAs are not supported.
>>
>> cheers,
>> Ole
>>
>>> -----Original Message-----
>>> From: Ole Troan [mailto:otroan@employees.org]
>>> Sent: Wednesday, July 23, 2014 8:01 PM
>>> To: Dmitry Anipko
>>> Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>;
>>> draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG
>>> Subject: Re: draft-ietf-6man-resilient-rs update
>>>
>>> Dmitry,
>>>
>>>>>> what would happen with the hosts that didn't implement the feature on links w/o periodic multicast RAs?
>>>> It would not get this particular improvement in behavior compared to the pre-draft state. But since the answer seems to be trivial, I'm not sure I understood the question correctly?
>>> wouldn't those hosts initially do router discovery, then not ever send RS again, and would be left without a default router when the router lifetime expired?
>>>
>>> cheers,
>>> Ole
>>>
>>>
>>>> -----Original Message-----
>>>> From: Ole Troan [mailto:otroan@employees.org]
>>>> Sent: Tuesday, July 22, 2014 7:15 PM
>>>> To: Dmitry Anipko
>>>> Cc: Suresh Krishnan; <6man-chairs@tools.ietf.org>;
>>>> draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG
>>>> Subject: Re: draft-ietf-6man-resilient-rs update
>>>>
>>>> Dmitry,
>>>>
>>>>> Given the definition of MAY in RFC 2119, why is the wording, which is currently in the text, not an option?
>>>>>
>>>>> <quote>
>>>>> In the
>>>>> same vein an implementation which does include a particular option
>>>>> MUST be prepared to interoperate with another implementation which
>>>>> does not include the option (except, of course, for the feature the
>>>>> option provides.) </quote>
>>>>>
>>>>> Where "the feature" would be e.g. "supporting links w/o periodic multicast RAs"?
>>>> what would happen with the hosts that didn't implement the feature on links w/o periodic multicast RAs?
>>>>
>>>> cheers,
>>>> Ole
>>>>
>>>>> -----Original Message-----
>>>>> From: Ole Troan [mailto:otroan@employees.org]
>>>>> Sent: Tuesday, July 22, 2014 2:10 PM
>>>>> To: Suresh Krishnan
>>>>> Cc: Dmitry Anipko; <6man-chairs@tools.ietf.org>;
>>>>> draft-ietf-6man-resilient-rs@tools.ietf.org; 6man WG
>>>>> Subject: Re: draft-ietf-6man-resilient-rs update
>>>>>
>>>>> Suresh, et al,
>>>>>
>>>>> to pick up this after my holiday.
>>>>>
>>>>>>>> My impression from the discussion in London that the consensus was closer to (2) than (1) - that on such links the hosts should be allowed to restart transmissions in a reasonable / rate-limited manner, when connectivity parameters expire. And that we should add MAY text for that.
>>>>>>> that's also fine with me. if there was a text proposal it would most likely be easier for the working group to come to a decision.
>>>>>>> is that something the authors can take on?
>>>>>> In my view, the text in the draft already reflects something akin to what Dmitry was talking about (but not exactly option 2 from your original mail on this thread). This is the relevant text from the draft.
>>>>>> Hosts MAY continue retransmitting the RSs even after router discovery is successful.  If the host continues to retransmit RSs, it is RECOMMENDED that such retransmissions be rate-limited to one every MRT.
>>>>> the current text states: hosts SHOULD stop, but MAY continue.
>>>>> on a link where there are no periodic multicast RA, then all the hosts that doesn't implement the MAY will fail after the initial Router lifetime seconds.
>>>>>
>>>>> to me it appears we have two options.
>>>>> 1) only solve the initial connection case.
>>>>> remove any mention of links without periodic RAs (remove the last sentence of the abstract, and bullet 1b.).
>>>>>    possibly remove the MAY in the "SHOULD stop, but MAY continue"
>>>>>    advance the document to the IESG
>>>>> 2) take the document back to the WG and solve the problems that Erik outlined in his mail.
>>>>>
>>>>> cheers,
>>>>> Ole
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>


From nobody Thu Aug 21 11:41:15 2014
Return-Path: <rbonica@juniper.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3831A6FD3 for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 11:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.602
X-Spam-Level: 
X-Spam-Status: No, score=-102.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 LVxisvimniHC for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 11:41:12 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A774D1A0316 for <ipv6@ietf.org>; Thu, 21 Aug 2014 11:41:11 -0700 (PDT)
Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB506.namprd05.prod.outlook.com (10.141.71.142) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Thu, 21 Aug 2014 18:41:09 +0000
Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Thu, 21 Aug 2014 18:41:08 +0000
Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.216]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.216]) with mapi id 15.00.1010.016; Thu, 21 Aug 2014 18:41:07 +0000
From: Ronald Bonica <rbonica@juniper.net>
To: "ipv6@ietf.org" <ipv6@ietf.org>
Subject: draft-gont-6man-nd-opt- valdation-00
Thread-Topic: draft-gont-6man-nd-opt- valdation-00
Thread-Index: Ac+9b3M7T4XCoXb/T7aFRhCYHwe+6g==
Date: Thu, 21 Aug 2014 18:41:07 +0000
Message-ID: <f6619105b4094541a053b0f80b381d99@CO1PR05MB442.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.12]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:;
x-forefront-prvs: 0310C78181
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199003)(105586002)(83322001)(108616004)(99286002)(107046002)(110136001)(77982001)(31966008)(74662001)(87936001)(54356999)(86362001)(95666004)(92566001)(229853001)(77096002)(74502001)(33646002)(101416001)(106356001)(90102001)(2351001)(46102001)(74316001)(76482001)(81542001)(85306004)(76576001)(99396002)(4396001)(81342001)(2656002)(50986999)(21056001)(79102001)(107886001)(83072002)(85852003)(64706001)(66066001)(230783001)(20776003)(80022001)(2501001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB443; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/mvCEOI1pN_DP6fffuV-ACpZKCbo
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 18:41:13 -0000

Folks,

As instructed by the WG, Fernando and I have expanded the scope of draft- g=
ont-6man-lla-opt-validation to include validation rules for all options use=
d in all ND messages. The new document is called draft-gont-6man-nd-opt- va=
ldation-00.

Please take a look at the draft. Tell us if we have done what the WG reques=
ted.

Ron Bonica


From nobody Thu Aug 21 11:50:02 2014
Return-Path: <nordmark@acm.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CD31A8026 for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 11:49:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=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 aUP3eVzqHAaD for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 11:49:52 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A8A91A872A for <ipv6@ietf.org>; Thu, 21 Aug 2014 11:49:51 -0700 (PDT)
Received: from [172.22.249.34] ([162.210.130.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s7LInh20003244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 21 Aug 2014 11:49:45 -0700
Message-ID: <53F63F47.6050204@acm.org>
Date: Thu, 21 Aug 2014 11:49:43 -0700
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>, Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man <ipv6@ietf.org>
Subject: Re: I-D Action: draft-gont-6man-deprecate-atomfrag-generation-00.txt
References: <20140819144703.13248.27719.idtracker@ietfa.amsl.com> <53F3AEC9.9010307@gmail.com> <53F3B562.8090506@gont.com.ar>
In-Reply-To: <53F3B562.8090506@gont.com.ar>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVbFTioX6F8eH7nUqyIm1prgucuNYxPxALusRXrc8mtUDKdwoYjRf+LCG7ouO6sgEkGFr+x7AUy9PEm2pU4I8b4p
X-Sonic-ID: C;uPsR6mMp5BGCB/ofoK8kYw== M;LszK6mMp5BGCB/ofoK8kYw==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/Fpd_fPV4CO2n2_CkdfUIiD-XFrY
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 18:49:55 -0000

On 8/19/14, 1:36 PM, Fernando Gont wrote:
> Hi, Brian,
>
> On 08/19/2014 05:08 PM, Brian E Carpenter wrote:
>> Quoting RFC 6145:
>>
>>    "Path MTU discovery across
>>     a translator relies on ICMP Packet Too Big messages being received
>>     and processed by IPv6 hosts, including an ICMP Packet Too Big that
>>     indicates the MTU is less than the IPv6 minimum MTU."
>>
>>    "...the translator can rely on IPv6
>>     hosts sending subsequent packets to the same IPv6 destination with
>>     IPv6 Fragment Headers.  In such an environment, when the translator
>>     receives an IPv6 packet with a Fragment Header, the translator SHOULD
>>     generate the IPv4 packet with a cleared Don't Fragment bit, and with
>>     its identification value from the IPv6 Fragment Header, for all of
>>     the IPv6 fragments (MF=0 or MF=1).
>>
>>     In an environment where an ICMPv4 Packet Too Big message is filtered
>>     (by a network firewall or by the host itself) or not correctly
>>     processed by the IPv6 hosts, the IPv6 host will never generate an
>>     IPv6 packet with the IPv6 Fragment Header.  In such an environment,
>>     the translator SHOULD set the IPv4 Don't Fragment bit."
>>
>> In other words, this proposal simply breaks SIIT for IPv4 MTUs below 1260
>> octets.
> Clearly, RFC6145 says what it says. Now, may I ask: what's the gain in
> requiring the IPv6 source to generate atomic fragments? -- I can't see
> any gain but just drawbacks:
>
> * The translator is in a better position to generate a non-colliding
> Fragment IDs


Fernando,

The original motivation for this in SIIT was that since the translator 
is stateless, ECMP routing can take different fragments to different 
translators. When that happens it doesn't work to have the translator 
make up a fragment ID since different fragments of the same datagram 
would get the ID assigned by different translators.

Whether the complexity of handling that case is worth the cost is a 
separate matter.

In any case, it makes sense to document this in your draft.

    Erik

>
> * Requiring the source to generate atomic fragments means there will be
> more fragmented traffic than necessary -- which not unusually gets dropped.
>
> * Native IPv6 hosts pay the price for the SIIT thing...
>
> Right now, a device that wants to filter fragments, is subject to DoS
> attacks just because of this little "feature" which, while present in
> RFC 6145, seems rather unnecessary (unless I'm missing something).
>
> Thanks!
>
> Cheers,


From nobody Thu Aug 21 12:01:39 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4CB1A899E for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 12:01:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 9GMu2akbSAwa for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 12:01:34 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AE231A8982 for <ipv6@ietf.org>; Thu, 21 Aug 2014 12:01:33 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XKXc0-000778-Gi; Thu, 21 Aug 2014 21:01:28 +0200
Message-ID: <53F641F5.9030304@si6networks.com>
Date: Thu, 21 Aug 2014 16:01:09 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Erik Nordmark <nordmark@acm.org>, Fernando Gont <fernando@gont.com.ar>, Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man <ipv6@ietf.org>
Subject: Re: I-D Action: draft-gont-6man-deprecate-atomfrag-generation-00.txt
References: <20140819144703.13248.27719.idtracker@ietfa.amsl.com> <53F3AEC9.9010307@gmail.com> <53F3B562.8090506@gont.com.ar> <53F63F47.6050204@acm.org>
In-Reply-To: <53F63F47.6050204@acm.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/caMldEESR1wZW3BVCTzH9BPgU2Q
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 19:01:37 -0000

Hi, Erik,

On 08/21/2014 03:49 PM, Erik Nordmark wrote:
>> Clearly, RFC6145 says what it says. Now, may I ask: what's the gain in
>> requiring the IPv6 source to generate atomic fragments? -- I can't see
>> any gain but just drawbacks:
>>
>> * The translator is in a better position to generate a non-colliding
>> Fragment IDs
> 
> The original motivation for this in SIIT was that since the translator
> is stateless, ECMP routing can take different fragments to different
> translators. When that happens it doesn't work to have the translator
> make up a fragment ID since different fragments of the same datagram
> would get the ID assigned by different translators.

mm.. not sure I follow. At least acording to RFC6145 (I haven't checked
RFC2765), there are two cases in which the translator can receive a
packet with a FH:

1) An atomic fragment (triggered by ICMPv6 PTB<1280) -- in which case,
the translator is getting the whole thing, since the packet is not
fragmented. But the translator still uses the Frag ID from the IPv6 FH.

2) A normal fragmented traffic. In this case, the translator may or may
not receive all the fragment (due to ECMP). In this case, the translator
also uses the Frag ID from the IPv6 FH.


The case you describe seems to be "2)", which is fine to me. The one
that I don't think makes much sense is "1)"....



> In any case, it makes sense to document this in your draft.

Please do let me know if I got the above wrong...

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Aug 21 12:11:28 2014
Return-Path: <nordmark@acm.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78D51A89DE for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 12:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=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 lobxzqP0Te9n for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 12:11:25 -0700 (PDT)
Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801481A89D9 for <ipv6@ietf.org>; Thu, 21 Aug 2014 12:11:25 -0700 (PDT)
Received: from [172.22.249.34] ([162.210.130.4]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s7LJBJSD016533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 21 Aug 2014 12:11:19 -0700
Message-ID: <53F64457.7030104@acm.org>
Date: Thu, 21 Aug 2014 12:11:19 -0700
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Fernando Gont <fgont@si6networks.com>, Erik Nordmark <nordmark@acm.org>, Fernando Gont <fernando@gont.com.ar>, Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man <ipv6@ietf.org>
Subject: Re: I-D Action: draft-gont-6man-deprecate-atomfrag-generation-00.txt
References: <20140819144703.13248.27719.idtracker@ietfa.amsl.com> <53F3AEC9.9010307@gmail.com> <53F3B562.8090506@gont.com.ar> <53F63F47.6050204@acm.org> <53F641F5.9030304@si6networks.com>
In-Reply-To: <53F641F5.9030304@si6networks.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVYLd/upwO/dEI5e0q49xUf3Er9DBdxLdgjkAlx85etHrQNffQI0O/PTDqJYwwJ6jNrhhIDCyAeZRROyUrusQ7g8
X-Sonic-ID: C;toKZ7mYp5BG9+wvd54E5FQ== M;Lj3G7mYp5BG9+wvd54E5FQ==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/j3HuLQRBJ17jVqbNlK2r8SqaSg0
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 19:11:26 -0000

On 8/21/14, 12:01 PM, Fernando Gont wrote:
> Hi, Erik,
>
> On 08/21/2014 03:49 PM, Erik Nordmark wrote:
>>> Clearly, RFC6145 says what it says. Now, may I ask: what's the gain in
>>> requiring the IPv6 source to generate atomic fragments? -- I can't see
>>> any gain but just drawbacks:
>>>
>>> * The translator is in a better position to generate a non-colliding
>>> Fragment IDs
>> The original motivation for this in SIIT was that since the translator
>> is stateless, ECMP routing can take different fragments to different
>> translators. When that happens it doesn't work to have the translator
>> make up a fragment ID since different fragments of the same datagram
>> would get the ID assigned by different translators.
> mm.. not sure I follow. At least acording to RFC6145 (I haven't checked
> RFC2765), there are two cases in which the translator can receive a
> packet with a FH:
>
> 1) An atomic fragment (triggered by ICMPv6 PTB<1280) -- in which case,
> the translator is getting the whole thing, since the packet is not
> fragmented. But the translator still uses the Frag ID from the IPv6 FH.
>
> 2) A normal fragmented traffic. In this case, the translator may or may
> not receive all the fragment (due to ECMP). In this case, the translator
> also uses the Frag ID from the IPv6 FH.
>
>
> The case you describe seems to be "2)", which is fine to me. The one
> that I don't think makes much sense is "1)"....
>
>


Sure.

When you have a mixture of 1 and 2 traffic then with RFC6145 the host is 
picking the fragment IDs for all of them. Hence it can do a reasonable 
job of keeping the fragment IDs unique - limited by ending up with only 
16 bits after the translator.

If you remove the atomic fragments then for 2 the host will pick the 
fragment IDs and for 1 the translator will pick them. That might result 
in a higher probability of colliding fragment IDs.

    Erik


From nobody Thu Aug 21 12:32:44 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15AA1A0689 for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 12:32:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 CXVSt_CagvgY for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 12:32:40 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E3C1A067A for <ipv6@ietf.org>; Thu, 21 Aug 2014 12:32:40 -0700 (PDT)
Received: from 18-132-17-190.fibertel.com.ar ([190.17.132.18] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XKY68-0007CU-Lx; Thu, 21 Aug 2014 21:32:36 +0200
Message-ID: <53F64948.1060300@si6networks.com>
Date: Thu, 21 Aug 2014 16:32:24 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Erik Nordmark <nordmark@acm.org>, Fernando Gont <fernando@gont.com.ar>, Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man <ipv6@ietf.org>
Subject: Re: I-D Action: draft-gont-6man-deprecate-atomfrag-generation-00.txt
References: <20140819144703.13248.27719.idtracker@ietfa.amsl.com> <53F3AEC9.9010307@gmail.com> <53F3B562.8090506@gont.com.ar> <53F63F47.6050204@acm.org> <53F641F5.9030304@si6networks.com> <53F64457.7030104@acm.org>
In-Reply-To: <53F64457.7030104@acm.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/mUtt6dHZOABvKYMzsn8XkHWiPUs
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 19:32:43 -0000

On 08/21/2014 04:11 PM, Erik Nordmark wrote:
>> mm.. not sure I follow. At least acording to RFC6145 (I haven't checked
>> RFC2765), there are two cases in which the translator can receive a
>> packet with a FH:
>>
>> 1) An atomic fragment (triggered by ICMPv6 PTB<1280) -- in which case,
>> the translator is getting the whole thing, since the packet is not
>> fragmented. But the translator still uses the Frag ID from the IPv6 FH.
>>
>> 2) A normal fragmented traffic. In this case, the translator may or may
>> not receive all the fragment (due to ECMP). In this case, the translator
>> also uses the Frag ID from the IPv6 FH.
>>
>> The case you describe seems to be "2)", which is fine to me. The one
>> that I don't think makes much sense is "1)"....
> 
> Sure.
> 
> When you have a mixture of 1 and 2 traffic then with RFC6145 the host is
> picking the fragment IDs for all of them.

But if there are multiple IPv6 hosts and, say, a single IPv4 address at
the translator, it's way more likely that you'll get Frag ID collisions
if it's the hosts picking the IDs as opposed to the translator.

For case 2 above, you clearly have no other option, and have to live
with it. But for case "1)" above the translator is in a better position
to pick the Frag ID (after all, the translator is the only box that
"nows" which frag IDs have been used recently).


Trivial example: let's assume that both Host A and Host B are IPv6 nodes
connected to the translator, and that Host A, Host B, and the translator
all use a global counter for selecting Frag IDs.

Say Host A sends an atomic fragment with Frag ID: 0, and that
Say Host B sends an atomic fragment with Frag ID: 0.

If the translator honors the Frag ID in the IPv6 FH (as required), then
there will be a frag ID collision as both packets would be sent to the
IPv4 world with a frag ID of 0 (and, if everyone is using counters,
collisions are likely to repeat).

OTOH, if the translator were to select the frag IDs for the
aforementioned packets, the first one (from Host A) would be assigned,
say, Frag ID 0, and the second packet (from Host B) would be assigned
Frag ID 1.

i.e., in those cases where it's possible (atomic fragments), it seems
that it's better to pick the frag ID at the translator... but RFC6145
currently requires nodes to use whatever the nodes had selected (well,
the lower 16bits of that, of course).


> If you remove the atomic fragments then for 2 the host will pick the
> fragment IDs and for 1 the translator will pick them. That might result
> in a higher probability of colliding fragment IDs.

In the case of mixed traffic (1 and 2 above), since there's no
coordination between the nodes, isn't it, at the end of the day, the
same thing if the translator picks the ID?

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Aug 21 16:30:54 2014
Return-Path: <nordmark@acm.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D7D1A6F36 for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 16:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level: 
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=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 HzjE6-Gbo2af for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 16:30:52 -0700 (PDT)
Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED0C1A6EF8 for <ipv6@ietf.org>; Thu, 21 Aug 2014 16:30:52 -0700 (PDT)
Received: from [172.22.249.34] ([162.210.130.4]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s7LNUirR007417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 21 Aug 2014 16:30:45 -0700
Message-ID: <53F68124.4010807@acm.org>
Date: Thu, 21 Aug 2014 16:30:44 -0700
From: Erik Nordmark <nordmark@acm.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Fernando Gont <fgont@si6networks.com>, Erik Nordmark <nordmark@acm.org>, Fernando Gont <fernando@gont.com.ar>, Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man <ipv6@ietf.org>
Subject: Re: I-D Action: draft-gont-6man-deprecate-atomfrag-generation-00.txt
References: <20140819144703.13248.27719.idtracker@ietfa.amsl.com> <53F3AEC9.9010307@gmail.com> <53F3B562.8090506@gont.com.ar> <53F63F47.6050204@acm.org> <53F641F5.9030304@si6networks.com> <53F64457.7030104@acm.org> <53F64948.1060300@si6networks.com>
In-Reply-To: <53F64948.1060300@si6networks.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Sonic-CAuth: UmFuZG9tSVZ7jFUOC3HMksErVMMYnwTJZ4j120TxmhUkYHjDv8+hVMHi9qc1IqRbvebKKxl0Y8zs5R1KJYwSwN932oYDTi1M
X-Sonic-ID: C;Nv1QLIsp5BGINvofoK8kYw== M;SquOLIsp5BGINvofoK8kYw==
X-Sonic-Spam-Details: 0.0/5.0 by cerberusd
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/4mCgIHQvx5tg31dK7cimLj9tCUo
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 23:30:53 -0000

On 8/21/14, 12:32 PM, Fernando Gont wrote:
> On 08/21/2014 04:11 PM, Erik Nordmark wrote:
>>> mm.. not sure I follow. At least acording to RFC6145 (I haven't checked
>>> RFC2765), there are two cases in which the translator can receive a
>>> packet with a FH:
>>>
>>> 1) An atomic fragment (triggered by ICMPv6 PTB<1280) -- in which case,
>>> the translator is getting the whole thing, since the packet is not
>>> fragmented. But the translator still uses the Frag ID from the IPv6 FH.
>>>
>>> 2) A normal fragmented traffic. In this case, the translator may or may
>>> not receive all the fragment (due to ECMP). In this case, the translator
>>> also uses the Frag ID from the IPv6 FH.
>>>
>>> The case you describe seems to be "2)", which is fine to me. The one
>>> that I don't think makes much sense is "1)"....
>> Sure.
>>
>> When you have a mixture of 1 and 2 traffic then with RFC6145 the host is
>> picking the fragment IDs for all of them.
> But if there are multiple IPv6 hosts and, say, a single IPv4 address at
> the translator, it's way more likely that you'll get Frag ID collisions
> if it's the hosts picking the IDs as opposed to the translator.

If the IPv4 address is shared then the translator isn't stateless any 
more. Needs to translate TCP/UDP port numbers etc. Hence all bets are 
off ;-)

In such a case the translator can assume it is on the path for all the 
packets. Thus it can rewrite the fragment IDs as it pleases.

I was merely commenting on the case of stateless translators that are 
used in redundant ways using e.g. ECMP routing.

    Erik

>
> For case 2 above, you clearly have no other option, and have to live
> with it. But for case "1)" above the translator is in a better position
> to pick the Frag ID (after all, the translator is the only box that
> "nows" which frag IDs have been used recently).
>
>
> Trivial example: let's assume that both Host A and Host B are IPv6 nodes
> connected to the translator, and that Host A, Host B, and the translator
> all use a global counter for selecting Frag IDs.
>
> Say Host A sends an atomic fragment with Frag ID: 0, and that
> Say Host B sends an atomic fragment with Frag ID: 0.
>
> If the translator honors the Frag ID in the IPv6 FH (as required), then
> there will be a frag ID collision as both packets would be sent to the
> IPv4 world with a frag ID of 0 (and, if everyone is using counters,
> collisions are likely to repeat).
>
> OTOH, if the translator were to select the frag IDs for the
> aforementioned packets, the first one (from Host A) would be assigned,
> say, Frag ID 0, and the second packet (from Host B) would be assigned
> Frag ID 1.
>
> i.e., in those cases where it's possible (atomic fragments), it seems
> that it's better to pick the frag ID at the translator... but RFC6145
> currently requires nodes to use whatever the nodes had selected (well,
> the lower 16bits of that, of course).
>
>
>> If you remove the atomic fragments then for 2 the host will pick the
>> fragment IDs and for 1 the translator will pick them. That might result
>> in a higher probability of colliding fragment IDs.
> In the case of mixed traffic (1 and 2 above), since there's no
> coordination between the nodes, isn't it, at the end of the day, the
> same thing if the translator picks the ID?
>
> Cheers,


From nobody Thu Aug 21 16:34:37 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89201A6F62 for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 16:34:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 M1QzgYztY8oo for <ipv6@ietfa.amsl.com>; Thu, 21 Aug 2014 16:34:29 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB391A8735 for <ipv6@ietf.org>; Thu, 21 Aug 2014 16:34:29 -0700 (PDT)
Received: from [181.46.190.53] (helo=[172.16.5.159]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XKbsA-0000dA-P6; Fri, 22 Aug 2014 01:34:27 +0200
Message-ID: <53F681EE.9020702@si6networks.com>
Date: Thu, 21 Aug 2014 20:34:06 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Erik Nordmark <nordmark@acm.org>, Fernando Gont <fernando@gont.com.ar>, Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man <ipv6@ietf.org>
Subject: Re: I-D Action: draft-gont-6man-deprecate-atomfrag-generation-00.txt
References: <20140819144703.13248.27719.idtracker@ietfa.amsl.com> <53F3AEC9.9010307@gmail.com> <53F3B562.8090506@gont.com.ar> <53F63F47.6050204@acm.org> <53F641F5.9030304@si6networks.com> <53F64457.7030104@acm.org> <53F64948.1060300@si6networks.com> <53F68124.4010807@acm.org>
In-Reply-To: <53F68124.4010807@acm.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/drCinWK7ENZrjaLQweyum-SkFV8
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 23:34:34 -0000

On 08/21/2014 08:30 PM, Erik Nordmark wrote:
> On 8/21/14, 12:32 PM, Fernando Gont wrote:
>> On 08/21/2014 04:11 PM, Erik Nordmark wrote:
[....]
>>>
>>> When you have a mixture of 1 and 2 traffic then with RFC6145 the host is
>>> picking the fragment IDs for all of them.
>> But if there are multiple IPv6 hosts and, say, a single IPv4 address at
>> the translator, it's way more likely that you'll get Frag ID collisions
>> if it's the hosts picking the IDs as opposed to the translator.
> 
> If the IPv4 address is shared then the translator isn't stateless any
> more. Needs to translate TCP/UDP port numbers etc. Hence all bets are
> off ;-)
> 
> In such a case the translator can assume it is on the path for all the
> packets. Thus it can rewrite the fragment IDs as it pleases.
> 
> I was merely commenting on the case of stateless translators that are
> used in redundant ways using e.g. ECMP routing.

Ok, now I see what you meant. Thanks for the clarification!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Fri Aug 22 05:56:19 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215BC1A02DE; Fri, 22 Aug 2014 05:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level: 
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 Lx9Nwtpv6ofK; Fri, 22 Aug 2014 05:56:15 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EB3C1A02D7; Fri, 22 Aug 2014 05:56:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13200; q=dns/txt; s=iport; t=1408712175; x=1409921775; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=AsZPIuEfYTmQN7twmskU2h/6pGwI957g+GQtY6JlGsA=; b=Dsi3uYflokISIeq/hQIOglrW/CwOVT/ptF+lrZTXZKifpBvYNd9kBqD8 MLak3LEpERVsz1BZay4jjMc3XBQJpFGGjbNbp2heMsuHtG1Cokb+LxeCH KGuIKxem4+o9Uz1psbPYlhVVRd86TqNXz0qkxnQnXVZOB7F7DKwGkDDW4 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjgFAAs991OtJV2Y/2dsb2JhbABZgw1TVwSCeMlYCodMARl0FneEAwEBAQICAQEBIBEzBwsMBgEIEQEDAQEBAgIGHQMCBB8GCxQBAgYJAQQOBQiIJgMRDa8Lj3YNhRkXgSyLc4FKDAkdFhsNgnM2gR0FhhGLFYZjgjCQZ4Y1g15sAYEGQYEHAQEB
X-IronPort-AV: E=Sophos;i="5.04,380,1406592000"; d="scan'208";a="71453774"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP; 22 Aug 2014 12:56:13 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7MCuDG4027555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 12:56:13 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 07:56:13 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: RE: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: Ac++CEw2eULOCzQzTxOZUvA7hQn3Ew==
Date: Fri, 22 Aug 2014 12:56:13 +0000
Deferred-Delivery: Fri, 22 Aug 2014 12:56:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D503B7@xmb-rcd-x01.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.49.80.27]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/rbMf5EICwgU5n-IRrxs_dmr8snQ
Cc: 6man WG <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Aug 2014 12:56:18 -0000

SGVsbG8gQnJpYW46DQoNClRoZSBxdWVzdGlvbiBvZiBhIGxpYWlzb24gd2FzIGRpc2N1c3NlZCBh
dCBib3RoIElFQyBhbmQgSVNBMTAwLCBhbmQgdGhleSB3ZXJlIHZlcnkgcG9zaXRpdmUgYWJvdXQg
dGhlIGlkZWEuIFdlIGNhbiBjZXJ0YWlubHkgbWFrZSB0aGF0IGhhcHBlbi4NCkkgZG91YnQgdGhh
dCB0aGVyZSBpcyB2YWx1ZSBpbiBhbmFseXppbmcgZmluZWx5IElTQTEwMC4xMWEgdGhhdCBpcyBt
b3N0bHkgY2FzdCBpbiBzdG9uZSBub3cuIFdlIG1hZGUgdGhlIGFuYWx5c2lzIGF0IHRoZSB0aW1l
IGFuZCBjb25jbHVkZWQgdGhhdCBpdCB3YXMgY29uZm9ybWluZyBSRkMgMzY5NywgYW5kIHdlIGtu
b3cgbm93IHRoYXQgaXQgZG9lcyBub3QgY29uZm9ybSBSRkMgNjQzNy4NCldlIGNvdWxkIHN0aWxs
IHBhcnRpY2lwYXRlIHRvIHRoZSB3b3JrIG9uIHRoZSBiYWNrYm9uZSByb3V0ZXIgYnV0IHRoZSBy
dWxlcyBpbiBSRkMgNjQzNyB3aWxsIG5vdCBiZSBhY2NlcHRhYmxlIHRoZXJlIGZvciB0aGUgZXhh
Y3Qgc2FtZSByZWFzb25zIHRoYXQgdGhleSBhcmUgbm90IGFjY2VwdGFibGUgaW4gYSBSUEwgZG9t
YWluLCBhbmQgdGhlIExhdXJlbnQrQ2Fyc3RlbiBwcm9wb3NhbCB3aWxsIG5vdCBjaGFuZ2UgdGhh
dCBhIGlvdGEuDQoNClRoZSBtb3N0IGNvbnN0cnVjdGl2ZSB3b3VsZCBiZSAoSU1ITyk6DQotIGFk
b3B0IHRoZSBwcm9wb3NlZCBjaGFuZ2UgdG8gdGhlIDZNQU4gcnVsZXMgc2VwYXJhdGVseSBmcm9t
IHRoZSBwcm9wb3NlZCB1c2UgaW4gUlBMIGFuZCANCi0gZXh0ZW5kIHRoZSByaWdodHMgdGhhdCB3
ZSBhcmUgYXNraW5nIGZvciBhIFJQTCBkb21haW4gdG8gYW4gSVNBMTAwIHN1Ym5ldHdvcmsgYXMg
d2VsbCBzbyBhcyB0byBtYWtlIElTQTEwMCBjb21wbGlhbnQgYWdhaW4NCi0gdXBkYXRlIDYyODQg
dG8gcG9zaXRpb24gSVNBMTAwLjExYS9JRUM2MjczNCB2cy4gYm90aCBSRkNzIGFuZCB0aGUgNk1B
TiBSUEwgZmxvdyBsYWJlbCB3b3JrIChzcGxpdCBvciBub3QpIGFzIEluZXMgc3VnZ2VzdGVkDQot
IGdvIHRvIFdDSSBhbmQgZW5mb3JjZSB0aGUgYXBwbGljYXRpb24gb2YgdGhlIG5ldyBSRkMgc28g
dGhhdCBwYWNrZXRzIG91dGdvaW5nIHRoZSBJU0ExMDAgc3VibmV0d29yayBhcmUgbWFkZSBjb21w
bGlhbnQgdG8gUkZDIDY0MzcgKGJ5IHRoZSBiYWNrYm9uZSByb3V0ZXIpLg0KDQpXb3VsZCB3ZSBh
Z3JlZSBvbiB0aGlzIHBhdGg/IA0KDQpQYXNjYWwNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQo+IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50
ZXJAZ21haWwuY29tXQ0KPiBTZW50OiBtYXJkaSAxOSBhb8O7dCAyMDE0IDIyOjMyDQo+IFRvOiBQ
YXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQo+IENjOiBNaWNoYWVsIFJpY2hhcmRzb247IFBoaWxp
cCBMZXZpczsgUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kNCj4gbmV0d29ya3M7IElu
ZXMgUm9ibGVzOyA2bWFuIFdHOyA2bG9AaWV0Zi5vcmcgV0cNCj4gU3ViamVjdDogUmU6IFtSb2xs
XSBbNmxvXSBXR0xDIGZvciBkcmFmdC10aHViZXJ0LTZtYW4tZmxvdy1sYWJlbC1mb3ItcnBsLTAz
DQo+IA0KPiBIaSBQYXNjYWwsDQo+IA0KPiBJZiB3ZSdyZSByZWFsbHkgZ29pbmcgdG8gZGlzY3Vz
cyB0aGlzLCB3ZSBuZWVkIHRoZSBJQUIgdG8gZXN0YWJsaXNoIGxpYWlzb24gYW5kDQo+IGdldCB0
aGUgcmlnaHQgdG8gbGV0IHVzIGFsbCBzZWUgdGhlIHNwZWNpZmljYXRpb24uIEknbSBub3QgZ29p
bmcgdG8gc3BlbmQgbXkNCj4gdGltZSBzcGVjdWxhdGluZyBhYm91dCBhIHNlY3JldCBkb2N1bWVu
dC4gSG93ZXZlciwgdGhlIGJpdCB5b3UgcXVvdGU6DQo+ICJGbG93TGFiZWw6IFRoZSBsb3dlciBv
cmRlciAxNiBiaXRzIG9mIHRoZSBGbG93TGFiZWwgc2hhbGwgYmUgc2V0IHRvDQo+IENvbnRyYWN0
SUQuIFRoZSBoaWdoZXIgb3JkZXIgNCBiaXRzIHNoYWxsIGJlIGFsbCB6ZXJvcy4iDQo+IGNlcnRh
aW5seSBzZWVtcyB0byB2aW9sYXRlIFJGQyA2NDM3LiBXaGV0aGVyIGl0IHZpb2xhdGVkIHRoZSBz
b21ld2hhdA0KPiBjb25mdXNlZCBzaXR1YXRpb24gbGVmdCBieSBSRkMgMjQ2MCBhbmQgUkZDIDM2
OTcgaXMgbGVzcyBjbGVhci4gSSBoYXZlIG5vDQo+IHJlY29sbGVjdGlvbiBvZiBhbnlib2R5IGZy
b20gSVNBIG9yIElFQyB0YWxraW5nIHRvIHRoZSBJRVRGIGFib3V0IHRoaXMgaXNzdWUuDQo+IA0K
PiBSZWdhcmRzDQo+ICAgIEJyaWFuDQo+IA0KPiBPbiAxOS8wOC8yMDE0IDAwOjUxLCBQYXNjYWwg
VGh1YmVydCAocHRodWJlcnQpIHdyb3RlOg0KPiA+IEhlbGxvIEJyaWFuOg0KPiA+DQo+ID4gSSBk
byBub3QgdGhpbmsgdGhhdCB5b3UgY2FuIGZyZWVseSBkb3dubG9hZCB0aGUgc3BlY2lmaWNhdGlv
bi4gWW91DQo+ID4gcHJvYmFibHkgbmVlZCBtZW1iZXJzaGlwIGZpcnN0LiBUaGUgbGlua3MgZXhp
c3QgZnJvbSB0aGUgV2lraXBlZGlhDQo+ID4gcGFnZSBidXQgdGhleSBhcmUgYnJva2VuLiBTYW1l
IGdvZXMgZm9yIHRoZSBJRUMgdmVyc2lvbiB3aGljaCBpcyBJRUMNCj4gPiA2MjczNCwgYnV0IGlm
IHlvdSBoYXZlIGFjY2VzcyB0byB0aGUgSUVDIHRoZW4gdGhlIGN1cnJlbnQgd29yayBpcyBoZXJl
DQo+ID4gaHR0cDovL3d3dy5pZWMuY2gvY2dpLWJpbi9yZXN0cmljdGVkL2dldGZpbGUucGwvNjVD
XzczNWVhX0NEVi5wZGY/ZGlyPQ0KPiA+IDY1QyZmb3JtYXQ9cGRmJnR5cGU9X0NEViZmaWxlPTcz
NWVhLnBkZg0KPiA+DQo+ID4gUXVvdGVzOg0KPiA+DQo+ID4gIlRoZSBDb250cmFjdElEIGlzIGFz
c29jaWF0ZWQgd2l0aCBhIHBhcnRpY3VsYXIgRC1yb3V0ZS4gVGhpcyBtYXkgYmUgdXNlZA0KPiB3
aGVuIGEgcGFydGljdWxhciBncmFwaCBvciBzb3VyY2UgRC1yb3V0ZSBpcyBpbnRlbmRlZCB0byBw
cm92aWRlIGEgZGVmaW5lZA0KPiBsZXZlbCBvZiBzZXJ2aWNlIg0KPiA+DQo+ID4gIkZsb3dMYWJl
bDogVGhlIGxvd2VyIG9yZGVyIDE2IGJpdHMgb2YgdGhlIEZsb3dMYWJlbCBzaGFsbCBiZSBzZXQg
dG8NCj4gQ29udHJhY3RJRC4gVGhlIGhpZ2hlciBvcmRlciA0IGJpdHMgc2hhbGwgYmUgYWxsIHpl
cm9zLiBUaGlzIGZpZWxkIHNoYWxsIG9ubHkgYmUNCj4gcHJlc2VudCBpZiBvY3RldHMgMyB0aHJv
dWdoIDUgYXJlIHByZXNlbnQsIGFzIGluZGljYXRlZCBieSBMT1dQQU5fSVBIQw0KPiBlbmNvZGlu
Zy4iDQo+ID4NCj4gPiBOb3RlIHRoYXQgdGhlIDZUaVNDSCBhcmNoaXRlY3R1cmUgZWNob2VzIHRo
aXMgZGVzaWduLCBhbmQgYSBkLXJvdXRlIGlzIHZlcnkNCj4gc2ltaWxhciB0byBhIDZUaVNDSCB0
cmFjay4NCj4gPg0KPiA+IEZvciB0aGUgc2FrZSBvZiBoaXN0b3J5IGFuZCB0byBteSBiZXN0IGtu
b3dsZWRnZSwgSVNBMTAwLjExYSB3YXMgdGhlIGZpcnN0DQo+IGluZHVzdHJpYWwgc3RhbmRhcmQg
dG8gYWRvcHQgSVB2NiBmb3IgcHJvY2VzcyBjb250cm9sIGFwcGxpY2F0aW9ucyAoY29udHJvbA0K
PiBsb29wcyBhbmQgbW9uaXRvcmluZykuDQo+ID4gSXQgaXMgZWZmZWN0aXZlbHkgZW5hYmxpbmcg
SVAgaW4gdGhlIGNvbnRyb2wgbmV0d29yaywgd2hpY2ggaXMgYW4gaGlzdG9yaWNhbA0KPiBzdGVw
IHRvd2FyZCB0aGUgSVQvT1QgY29udmVyZ2VuY2UsIHRoYXQgaXMgdGhlIEluZHVzdHJpYWwgZXF1
aXZhbGVudCBvZiB2b2ljZQ0KPiBhbmQgdmlkZW8gY29udmVyZ2VuY2Ugb3ZlciBJUC4NCj4gPg0K
PiA+IEFuZCBhbHNvIHRvIG15IGJlc3Qga25vd2xlZGdlIGFuZCBjb25mb3JtaW5nIFJGQyAzNjk3
LCBJU0ExMDAuMTFhIGRvZXMNCj4gbm90IG11dGUgdGhlIEZsb3cgTGFiZWwgaW5zaWRlIHRoZSBu
ZXR3b3JrLCBhcyBNaWNoYWVsIHBvaW50cyBvdXQuIE9ubHkNCj4gd2hlbiB0aGUgYWRkaXRpb25h
bCBiYWNrYm9uZSBSb3V0ZXIgZnVuY3Rpb25hbGl0eSBpcyBkZWZpbmVkIGRvZXMgdGhlDQo+IHBy
b2JsZW0gb2YgcmV3cml0aW5nIGNvbWUgaW50byBwbGF5IGF0IHRoZSBCYWNrYm9uZSBSb3V0ZXIg
KHNhbWUgcG9zaXRpb24NCj4gYXMgUlBMIHJvb3QpLiBGb3IgYWxsIEkga25vdyB0aGlzIHdvcmsg
aXMgdGFraW5nIHBsYWNlIGF0IHRoZSBXaXJlbGVzcw0KPiBDb21wbGlhbmNlIEluc3RpdHV0ZSwg
V0NJLCBidXQgSSBkbyBub3QgaGF2ZSB0aGUgbGF0ZXN0Lg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+
DQo+ID4gUGFzY2FsDQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
PiA+PiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdt
YWlsLmNvbV0NCj4gPj4gU2VudDogc2FtZWRpIDE2IGFvw7t0IDIwMTQgMDM6MTMNCj4gPj4gVG86
IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkNCj4gPj4gQ2M6IFBoaWxpcCBMZXZpczsgUm91dGlu
ZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3M7IEluZXMNCj4gPj4gUm9ibGVzOyA2
bWFuIFdHOyA2bG9AaWV0Zi5vcmcgV0cNCj4gPj4gU3ViamVjdDogUmU6IFtSb2xsXSBbNmxvXSBX
R0xDIGZvcg0KPiA+PiBkcmFmdC10aHViZXJ0LTZtYW4tZmxvdy1sYWJlbC1mb3ItcnBsLTAzDQo+
ID4+DQo+ID4+IE9uIDE1LzA4LzIwMTQgMjA6NTEsIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkg
d3JvdGU6DQo+ID4+PiBIZWxsbyBCcmlhbg0KPiA+Pj4NCj4gPj4+IEkgZG8gbm90IHRoaW5rIHRo
YXQgSVNBMTAwMTEuYSB2aW9sYXRlcyBSRkMgMzY5Ny4gV2hhdCBleGFjdGx5IG1hZGUNCj4gPj4+
IHlvdQ0KPiA+PiBiZWxpZXZlIHNvPw0KPiA+Pg0KPiA+PiBJIHdhcyBvdmVyLWludGVycHJldGlu
ZyB3aGF0IHlvdSB3cm90ZSwgSSBndWVzcy4gSXQncyB0cnVlIHRoYXQgMzY5Nw0KPiA+PiB3YXMg
cmF0aGVyIHZhZ3VlIGFib3V0IHdoYXQgaXQgY2FsbGVkICJmbG93IHN0YXRlIGVzdGFibGlzaG1l
bnQNCj4gPj4gbWV0aG9kcyIgYW5kIHBlcm1pdHRlZCBib3RoIHNlcXVlbnRpYWwgYW5kIHBzZXVk
by1yYW5kb20gZmxvdyBsYWJlbA0KPiA+PiB2YWx1ZXMuIElzIHRoZSBJU0ExMDAxMS5hIG9uIGxp
bmUgc29tZXdoZXJlPw0KPiA+Pg0KPiA+Pj4gRm9yIGFsbCBJIGtub3cgSVNBMTAwIGRvZXMgZXZl
cnl0aGluZyBieSB0aGUgYm9vay4gTm90ZSB0aGF0IElTQTEwMA0KPiA+Pj4gZG9lcw0KPiA+PiBu
b3QgdXBkYXRlIGEgbm9uIHplcm8gRkwgb24gdGhlIGZseSBzaW5jZSBpdCBpcyBub3Qgc2V0IGJ5
IGEgc291cmNlDQo+ID4+IG91dHNpZGUgdGhlIExMTiBpZiB0aGF0IGlzIHlvdXIgY29uY2Vybi4N
Cj4gPj4+IE9UT0ggSXQgbWF5IHZpb2xhdGUgUkZDIDY0MzcgaW4gdGhhdCB0aGUgZmxvdyBpcyBu
b3QgYSByYW5kb20gYnV0IGENCj4gPj4+IHZhbHVlDQo+ID4+IGF0dHJpYnV0ZWQgYnkgYSBQQ0Ug
Y2FsbGVkIHN5c3RlbSBtYW5hZ2VyIChhbG9uZyBydWxlcyBpbiBzZWN0aW9uIDQpLg0KPiA+PiBB
cyB0aGluZ3Mgc3RhbmQsIHdlJ2QgY2VydGFpbmx5IHdhbnQgdGhlIGJhY2tib25lIHJvdXRlciBh
dCBMTE4NCj4gPj4gZWdyZXNzIHRvIHJld3JpdGUgdGhlIEZMIGluIHBhY2tldHMgdG93YXJkcyB0
aGUgSW50ZXJuZXQgd2l0aCBhDQo+ID4+IHJhbmRvbWl6ZWQgcGVyIGZsb3cgdmFsdWUuDQo+ID4+
PiBJdCB3aWxsIHZpb2xhdGUgUkZDIDY0MzcgYmVjYXVzZSBpZiB0aGUgZmxvdyBsYWJlbCBpcyBz
ZXQgYnkgYQ0KPiA+Pj4gcm91dGVyIGluIHRoZQ0KPiA+PiBJbnRlcm5ldCAtIG9yIGFuIHVwZGF0
ZWQgc291cmNlIHRoYXQgY29tcGxpZXMgdG8gNjQzNy0sIHRoZSBiYWNrYm9uZQ0KPiA+PiByb3V0
ZXIgYXQgTExOIEluZ3Jlc3Mgd2lsbCByZXdyaXRlIGl0Lg0KPiA+Pj4gQm90aCBpc3N1ZXMgYXJl
IGFkZHJlc3NlZCBpbiBteSBkcmFmdCBmb3IgYSBSUEwgZG9tYWluLiBBbiBSRkMgd2lsbA0KPiA+
Pj4gYWxzbw0KPiA+PiBoaW50IGEgcmV2aXNpb24gb2YgdGhlIGJhY2tib25lIHJvdXRlciB0aGF0
IGl0IHNob3VsZCByZXdyaXRlIHRoZSBGTA0KPiA+PiBvbiBvdXRnb2luZyBwYWNrZXRzLg0KPiA+
Pj4gV2hhdCBkbyB5b3UgdGhpbms/DQo+ID4+IEkgdGhpbmsgdGhhdCBQaGlsJ3MgbGFzdCBtZXNz
YWdlIGZyYW1lcyB0aGUgcXVlc3Rpb24gdG8gNm1hbg0KPiA+PiBjb3JyZWN0bHksIHNvIEkgd2ls
bCByZXNwb25kIHRvIGhpbS4uLg0KPiA+Pg0KPiA+PiBSZWdhcmRzDQo+ID4+ICAgICBCcmlhbg0K
PiA+Pj4gUGFzY2FsDQo+ID4+Pg0KPiA+Pj4+IExlIDE0IGFvw7t0IDIwMTQgw6AgMjI6MTgsICJC
cmlhbiBFIENhcnBlbnRlciINCj4gPj4gPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4gYSDD
qWNyaXQgOg0KPiA+Pj4+PiBPbiAxNC8wOC8yMDE0IDIyOjI4LCBQYXNjYWwgVGh1YmVydCAocHRo
dWJlcnQpIHdyb3RlOg0KPiA+Pj4+PiBXZSBjYW4gbGl2ZSB3aXRoIHRoaXMgQnJpYW4sDQo+ID4+
Pj4+DQo+ID4+Pj4+IGJ1dCB0aGVuIEkgY2FuIHdlIGFkZCBhdCBsZWFzdCBhbiBJU0ExMDAuMTFh
IG5ldHdvcms/IElTQTEwMC4xMWENCj4gPj4+Pj4gd2FzDQo+ID4+IGRlc2lnbmVkIGluIDIwMDcv
OCwgYWRvcHRlZCBJUHY2IGFuZCA2TG9XUEFOLCBhbmQgdXNlcyB0aGUgSVB2NiBmbG93DQo+ID4+
IGxhYmVsIHRvIGluZGljYXRlIHdoaWNoIGZsb3cgYSBwYWNrZXQgYmVsb25ncyB0by4NCj4gPj4+
PiBJIGhhdmUgbm8gaWRlYSB3aGF0IElTQTEwMC4xMWEgaXMgb3Igd2hpY2ggb3JnYW5pc2F0aW9u
IGRldmVsb3BlZA0KPiA+Pj4+IGl0LCBidXQgaXQgc291bmRzIGxpa2UgYSB2aW9sYXRpb24gb2Yg
dGhlIGZsb3cgbGFiZWwgc3RhbmRhcmQgYXQNCj4gPj4+PiB0aGF0IHRpbWUgKFJGQyAzNjk3KS4g
SWYgSSdkIGtub3duIGFib3V0IGl0LCB3ZSB3b3VsZCBwcm9iYWJseSBoYXZlDQo+ID4+Pj4gaW5j
bHVkZWQgaXQgaW4gdGhlIG1lbmFnZXJpZSBvZiBSRkMgNjI5NC4NCj4gPj4+Pg0KPiA+Pj4+IFRo
ZXJlJ3Mgbm90IG11Y2ggdGhlIElFVEYgY2FuIGRvIGFib3V0IG90aGVyIG9yZ2FuaXNhdGlvbnMg
dGhhdA0KPiA+Pj4+IG1pc3VzZSBvdXIgc3RhbmRhcmRzLCBhbHRob3VnaCBpbmRlZWQgd2Ugc29t
ZXRpbWVzIG5lZWQgdG8NCj4gZG9jdW1lbnQNCj4gPj4+PiBzdWNoIGNhc2VzLg0KPiA+Pj4+DQo+
ID4+Pj4gICBCcmlhbg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBJbiBtb3JlIGRldGFpbHMsIGRl
dmljZXMgYXJlIHByb3Zpc2lvbmVkIHdpdGggcGVyLWZsb3cgYmVoYXZpb3INCj4gPj4+PiAoaW5j
bHVkaW5nDQo+ID4+IHJvdXRpbmcpIGFuZCBzZXR0aW5ncyBpbiB3aGF0IGlzIGNhbGxlZCBhIGNv
bnRyYWN0Lg0KPiA+Pj4+IFRoZSBjb250cmFjdElEIGlzIGNhcnJpZWQgaW4gdGhlIElQdjYgZmxv
dyBsYWJlbC4NCj4gPj4+Pj4gSWYgc28gc2hvdWxkIHdlIG5hbWUgSVNBMTAwIHNwZWNpZmljYWxs
eSBvciB1c2UgYSBtb3JlIHZhZ3VlDQo+ID4+Pj4+IGRlc2NyaXB0aW9uDQo+ID4+IGxpa2UgYSAi
UlBMIG9yIHNpbWlsYXIgTExOIGRvbWFpbiINCj4gPj4+Pj4gV2UnbGwgbm90ZSB0aGF0IHJlc2V0
dGluZyBhbiBmbG93IGxhYmVsIHRoYXQgY29tZXMgZnJvbSB0aGUNCj4gPj4+Pj4gSW50ZXJuZXQg
aXMgYSBnZW5lcmljIG5lZWQgaXMgdGhhdCBmbG93IGxhYmVsIHdhcyBzZXQgYWNjb3JkaW5nIHRv
DQo+ID4+Pj4+IDY0MzcsIGNhbm5vdCBiZSB0cnVzdGVkIHRvIGJlIHVudGVtcGVyZWQgd2l0aCwN
Cj4gPj4+Pj4NCj4gPj4+Pj4gQ2hlZXJzLA0KPiA+Pj4+Pg0KPiA+Pj4+PiBQYXNjYWwNCj4gPj4+
Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+
PiBGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg
QnJpYW4gRQ0KPiA+Pj4+Pj4gQ2FycGVudGVyDQo+ID4+Pj4+PiBTZW50OiBtZXJjcmVkaSAxMyBh
b8O7dCAyMDE0IDIyOjUzDQo+ID4+Pj4+PiBUbzogUGhpbGlwIExldmlzDQo+ID4+Pj4+PiBDYzog
Um91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3M7IEluZXMgUm9ibGVzOyA2
bWFuDQo+ID4+Pj4+PiBXRzsgNmxvQGlldGYub3JnIFdHDQo+ID4+Pj4+PiBTdWJqZWN0OiBSZTog
W1JvbGxdIFs2bG9dIFdHTEMgZm9yDQo+ID4+Pj4+PiBkcmFmdC10aHViZXJ0LTZtYW4tZmxvdy1s
YWJlbC1mb3ItcnBsLTAzDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4+IE9uIDE0LzA4LzIwMTQgMDc6MDcs
IFBoaWxpcCBMZXZpcyB3cm90ZToNCj4gPj4+Pj4+PiBPbiBBdWcgMTMsIDIwMTQsIGF0IDk6NDgg
QU0sIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkNCj4gPj4+Pj4+IDxwdGh1YmVydEBjaXNjby5j
b20+IHdyb3RlOg0KPiA+Pj4+Pj4+PiBJZiB0aGlzIGRyYWZ0IGlzIG5vdCBhZG9wdGVkLCB0aGUg
ZmxvdyBsYWJlbCBmcm9tIExMTiB3aWxsDQo+ID4+Pj4+Pj4+IHByb2JhYmx5IHN0YXkgYWxsDQo+
ID4+Pj4+PiB6ZXJvZXMgYXMgaXQgaXMgdG9kYXkgYW5kIHRoZSBnb2FsIG9mIDY0Mzcgd2lsbCBu
b3QgYmUgYWNoaWV2ZWQuDQo+ID4+Pj4+Pj4gUGFzY2FsLCBJJ20gdHJ5aW5nIHRvIHJlY29uY2ls
ZSB5b3VyIGNsYWltIHRoYXQgdGhlIGdvYWwgb2YgNjQzNw0KPiA+Pj4+Pj4+IGlzIHRvIGFsbG93
IGVuY2xvc2VkIG5ldHdvcmtzIHRvIHVzZSB0aGUgZmxvdyBsYWJlbCB3aXRoIEJyaWFuJ3MNCj4g
Pj4+Pj4+PiBzdGF0ZW1lbnQNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBBY3R1YWxseSB0aGF0J3Mg
d2h5IEkgZG9uJ3Qgd2FudCB0byBzZWUgYSBmb3JtYWwgdXBkYXRlIHRvDQo+ID4+Pj4+Pj4+IDY0
MzcsIGJlY2F1c2UgdGhlIG9ubHkgcmF0aW9uYWwgdXBkYXRlIHdvdWxkIGJlIHRvIGFsbG93IGFu
eQ0KPiA+Pj4+Pj4+PiBjbG9zZWQgZG9tYWluIHRvIGludmVudCBpdHMgb3duIHVzYWdlLiBXZSBo
YWQgdGhhdCBhcmd1bWVudCBhdA0KPiA+Pj4+Pj4+PiBsZW5ndGggZHVyaW5nIHRoZSBkZXZlbG9w
bWVudCBvZiA2NDM3LCBhbmQgZGVjaWRlZCBhZ2FpbnN0IGl0Lg0KPiA+Pj4+Pj4+IFBoaWwNCj4g
Pj4+Pj4+IFJpZ2h0LiBJJ20gZHJhd2luZyBhIHZlcnkgc3VidGxlIGxpbmUgYmV0d2VlbiAoYSkg
c3RhdGluZyBhbg0KPiA+Pj4+Pj4gZXhjZXB0aW9uIHRvIDY0MzcgZm9yIHRoaXMgcGFydGljdWxh
ciB1c2FnZSBhbmQgKGIpIG9wZW5pbmcgdGhlDQo+ID4+Pj4+PiBkb29yIHRvIG90aGVyIHVzYWdl
cy4gU2luY2UgNm1hbiBjbGVhcmx5IGRpZG4ndCB3YW50IChiKSBkdXJpbmcNCj4gPj4+Pj4+IHRo
ZSBkZXZlbG9wbWVudCBvZg0KPiA+Pj4+Pj4gNjQzNyBJIHRoaW5rIHdlIGRvIG5lZWQgdG8gbGlt
aXQgb3Vyc2VsdmVzIHRvIChhKS4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgICBCcmlhbg0KPiA+Pj4+
Pj4NCj4gPj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pj4+PiAtLQ0KPiA+Pj4+Pj4gLSBJRVRGIElQdjYg
d29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgaXB2NkBpZXRmLm9yZw0KPiA+Pj4+Pj4gQWRtaW5p
c3RyYXRpdmUNCj4gPj4+Pj4+IFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2lwdjYNCj4gPj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+Pj4+PiAtLQ0KPiA+Pj4+Pj4g
LQ0KPiA+DQoNCg==


From nobody Fri Aug 22 07:40:07 2014
Return-Path: <heard@pobox.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4611A04E8 for <ipv6@ietfa.amsl.com>; Fri, 22 Aug 2014 07:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 YbfGspzJM2WX for <ipv6@ietfa.amsl.com>; Fri, 22 Aug 2014 07:40:02 -0700 (PDT)
Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767401A04BC for <6man@ietf.org>; Fri, 22 Aug 2014 07:40:02 -0700 (PDT)
Received: (qmail 4284 invoked from network); 22 Aug 2014 07:39:59 -0700
Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Aug 2014 07:39:59 -0700
Date: Fri, 22 Aug 2014 07:39:59 -0700 (PDT)
From: "C. M. Heard" <heard@pobox.com>
X-X-Sender: heard@shell4.bayarea.net
To: Fernando Gont <fgont@si6networks.com>
Subject: Companion to RFC 7045 for options (was:  New Version Notification for draft-gont-opsec-ipv6-eh-filtering-01.txt)
In-Reply-To: <53F70D1C.8080404@si6networks.com>
Message-ID: <Pine.LNX.4.64.1408220656040.20047@shell4.bayarea.net>
References: <20140816170731.13620.5804.idtracker@ietfa.amsl.com> <53EF9103.2000900@si6networks.com> <Pine.LNX.4.64.1408200811380.29207@shell4.bayarea.net> <53F5FAF6.1010000@si6networks.com> <Pine.LNX.4.64.1408210742020.27546@shell4.bayarea.net> <53F60AB6.7080909@si6networks.com> <Pine.LNX.4.64.1408210810270.27546@shell4.bayarea.net> <53F70D1C.8080404@si6networks.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/NxKB-oMDZWgfI6bR6NP0a7nhvCM
Cc: OPSEC <opsec@ietf.org>, 6MAN <6man@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Aug 2014 14:40:03 -0000

[ 6man added to cc: list ]

Fernando, I would have to agree that there is a need for a 
standards-track document doing for options what RFC 7045 did for 
extension headers.  The current rules in RFC 2460 for intermediate 
systems are:

(a) Inspect options in a hop-by-hop options header; process known 
options as specified in the document defining the option, otherwise 
take the action indicated in the upper two bits of the option code.

(b) Pass destination options transparently; do not inspect them or 
filter packets based on them.

There really aren't any provisions for intermediate systems to 
filter IPv6 packets on the basis of the options they contain.  That 
is not consonant with oft-repeated operational requirements.  The 
new document that you propose would need to provide for such 
filtering.  When that is done, the above rules are (IMHO) a 
reasonable starting point for deault behavior, modulo refinements 
such as discarding packets with options that appear in the wrong 
kind of options header.

Mike Heard

On Fri, 22 Aug 2014, Fernando Gont wrote:
> On 08/21/2014 12:57 PM, C. M. Heard wrote:
> > 
> > For one thing, I think you agreed that the advice should be to 
> > discard packets with options that appear in the wrong kind of 
> > options header. 
> 
> After giving this one some thought, I'd say that my take is that the
> best option is to produce a 6man document that specifies the default
> processing of options, such that we complement RFC7045 (which does that
> for IPv6 extension headers). -- this had been suggested by Brian
> Carpenter already.
> 
> After all, advice of the kind "Drop this packet if it contains two
> Router Alert options is really a default setting, rather than something
> an operator would configure".
> 
> In the worst case scenario (if the 6man document doesn't fly there, we
> may incorporate such defaults in this document).
> 
> Thoughts?
> 
> Thanks!
> 
> Best regards,
> 


From nobody Fri Aug 22 08:44:28 2014
Return-Path: <mariainesrobles@googlemail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5271A00DD; Fri, 22 Aug 2014 08:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level: 
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 cdAJtv2HAvTK; Fri, 22 Aug 2014 08:44:20 -0700 (PDT)
Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A141A032A; Fri, 22 Aug 2014 08:44:19 -0700 (PDT)
Received: by mail-la0-f41.google.com with SMTP id s18so10261236lam.14 for <multiple recipients>; Fri, 22 Aug 2014 08:44:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ahkIlJ8fPIrVbsSTxFF/Okmu/zljYFGaADFAXECSGm4=; b=nFvBEmOGujGO/GwLxS+DGXKbEIJ7dDxuHAjjb6uh4llzjzItbmU2A0Ls3t8tUibV5b Zz9iwD4ym5sAIBr9sFQk6lCo3n3q2TcLE+gnTRycH2mYFcxnMU41NHoduvrVHeJ+sQJm H4zoCck/mPtLcv2SNpFvzCDysv3x8uyvUjYQPtFtbwWM3m4ENciTNncf9YBXJH3CP+Ku yWM3IGdF2ejGIrMSgEbHBu/M6jCAQ3CcJJjzv6U8y9VAdcFo5GCwgUKPZmqShrQOPs24 8ObZUxqT5XcwwRVZ4LaP/E+MiTSTD3pLrn3bSEuu3Z987QMUPq/R161tTvU0yIRT/Orh Sk+g==
MIME-Version: 1.0
X-Received: by 10.112.150.106 with SMTP id uh10mr5084266lbb.11.1408722257886;  Fri, 22 Aug 2014 08:44:17 -0700 (PDT)
Received: by 10.25.209.212 with HTTP; Fri, 22 Aug 2014 08:44:17 -0700 (PDT)
In-Reply-To: <E045AECD98228444A58C61C200AE1BD842D503B7@xmb-rcd-x01.cisco.com>
References: <E045AECD98228444A58C61C200AE1BD842D503B7@xmb-rcd-x01.cisco.com>
Date: Fri, 22 Aug 2014 18:44:17 +0300
Message-ID: <CAP+sJUezEQW5GJC3nAeOeOuz1quhKbAp+vxEL7oTqtRArZh7Uw@mail.gmail.com>
Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
From: Ines  Robles <mariainesrobles@googlemail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Type: multipart/alternative; boundary=047d7b34340cc4c9f5050139b57c
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/xF8vMoc46N1LfTHVQZgDE26nw1Y
Cc: 6man WG <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Aug 2014 15:44:24 -0000

--047d7b34340cc4c9f5050139b57c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

Thank you all for your comments during this WGLC. Our conclusion is that we=
 did
not see consensus for the draft. We need please more participation on that.
(We think that most of the people are on vacations).

So, we leave this thread open, and we are going to have another WGLC during
september.

Thank you very much in advance,

Kind Regards,

Michael & Ines.


2014-08-22 15:56 GMT+03:00 Pascal Thubert (pthubert) <pthubert@cisco.com>:

> Hello Brian:
>
> The question of a liaison was discussed at both IEC and ISA100, and they
> were very positive about the idea. We can certainly make that happen.
> I doubt that there is value in analyzing finely ISA100.11a that is mostly
> cast in stone now. We made the analysis at the time and concluded that it
> was conforming RFC 3697, and we know now that it does not conform RFC 643=
7.
> We could still participate to the work on the backbone router but the
> rules in RFC 6437 will not be acceptable there for the exact same reasons
> that they are not acceptable in a RPL domain, and the Laurent+Carsten
> proposal will not change that a iota.
>
> The most constructive would be (IMHO):
> - adopt the proposed change to the 6MAN rules separately from the propose=
d
> use in RPL and
> - extend the rights that we are asking for a RPL domain to an ISA100
> subnetwork as well so as to make ISA100 compliant again
> - update 6284 to position ISA100.11a/IEC62734 vs. both RFCs and the 6MAN
> RPL flow label work (split or not) as Ines suggested
> - go to WCI and enforce the application of the new RFC so that packets
> outgoing the ISA100 subnetwork are made compliant to RFC 6437 (by the
> backbone router).
>
> Would we agree on this path?
>
> Pascal
>
>
> > -----Original Message-----
> > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> > Sent: mardi 19 ao=C3=BBt 2014 22:32
> > To: Pascal Thubert (pthubert)
> > Cc: Michael Richardson; Philip Levis; Routing Over Low power and Lossy
> > networks; Ines Robles; 6man WG; 6lo@ietf.org WG
> > Subject: Re: [Roll] [6lo] WGLC for
> draft-thubert-6man-flow-label-for-rpl-03
> >
> > Hi Pascal,
> >
> > If we're really going to discuss this, we need the IAB to establish
> liaison and
> > get the right to let us all see the specification. I'm not going to
> spend my
> > time speculating about a secret document. However, the bit you quote:
> > "FlowLabel: The lower order 16 bits of the FlowLabel shall be set to
> > ContractID. The higher order 4 bits shall be all zeros."
> > certainly seems to violate RFC 6437. Whether it violated the somewhat
> > confused situation left by RFC 2460 and RFC 3697 is less clear. I have =
no
> > recollection of anybody from ISA or IEC talking to the IETF about this
> issue.
> >
> > Regards
> >    Brian
> >
> > On 19/08/2014 00:51, Pascal Thubert (pthubert) wrote:
> > > Hello Brian:
> > >
> > > I do not think that you can freely download the specification. You
> > > probably need membership first. The links exist from the Wikipedia
> > > page but they are broken. Same goes for the IEC version which is IEC
> > > 62734, but if you have access to the IEC then the current work is her=
e
> > > http://www.iec.ch/cgi-bin/restricted/getfile.pl/65C_735ea_CDV.pdf?dir=
=3D
> > > 65C&format=3Dpdf&type=3D_CDV&file=3D735ea.pdf
> > >
> > > Quotes:
> > >
> > > "The ContractID is associated with a particular D-route. This may be
> used
> > when a particular graph or source D-route is intended to provide a
> defined
> > level of service"
> > >
> > > "FlowLabel: The lower order 16 bits of the FlowLabel shall be set to
> > ContractID. The higher order 4 bits shall be all zeros. This field shal=
l
> only be
> > present if octets 3 through 5 are present, as indicated by LOWPAN_IPHC
> > encoding."
> > >
> > > Note that the 6TiSCH architecture echoes this design, and a d-route i=
s
> very
> > similar to a 6TiSCH track.
> > >
> > > For the sake of history and to my best knowledge, ISA100.11a was the
> first
> > industrial standard to adopt IPv6 for process control applications
> (control
> > loops and monitoring).
> > > It is effectively enabling IP in the control network, which is an
> historical
> > step toward the IT/OT convergence, that is the Industrial equivalent of
> voice
> > and video convergence over IP.
> > >
> > > And also to my best knowledge and conforming RFC 3697, ISA100.11a doe=
s
> > not mute the Flow Label inside the network, as Michael points out. Only
> > when the additional backbone Router functionality is defined does the
> > problem of rewriting come into play at the Backbone Router (same positi=
on
> > as RPL root). For all I know this work is taking place at the Wireless
> > Compliance Institute, WCI, but I do not have the latest.
> > >
> > > Cheers,
> > >
> > > Pascal
> > >
> > >
> > >> -----Original Message-----
> > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> > >> Sent: samedi 16 ao=C3=BBt 2014 03:13
> > >> To: Pascal Thubert (pthubert)
> > >> Cc: Philip Levis; Routing Over Low power and Lossy networks; Ines
> > >> Robles; 6man WG; 6lo@ietf.org WG
> > >> Subject: Re: [Roll] [6lo] WGLC for
> > >> draft-thubert-6man-flow-label-for-rpl-03
> > >>
> > >> On 15/08/2014 20:51, Pascal Thubert (pthubert) wrote:
> > >>> Hello Brian
> > >>>
> > >>> I do not think that ISA10011.a violates RFC 3697. What exactly made
> > >>> you
> > >> believe so?
> > >>
> > >> I was over-interpreting what you wrote, I guess. It's true that 3697
> > >> was rather vague about what it called "flow state establishment
> > >> methods" and permitted both sequential and pseudo-random flow label
> > >> values. Is the ISA10011.a on line somewhere?
> > >>
> > >>> For all I know ISA100 does everything by the book. Note that ISA100
> > >>> does
> > >> not update a non zero FL on the fly since it is not set by a source
> > >> outside the LLN if that is your concern.
> > >>> OTOH It may violate RFC 6437 in that the flow is not a random but a
> > >>> value
> > >> attributed by a PCE called system manager (along rules in section 4)=
.
> > >> As things stand, we'd certainly want the backbone router at LLN
> > >> egress to rewrite the FL in packets towards the Internet with a
> > >> randomized per flow value.
> > >>> It will violate RFC 6437 because if the flow label is set by a
> > >>> router in the
> > >> Internet - or an updated source that complies to 6437-, the backbone
> > >> router at LLN Ingress will rewrite it.
> > >>> Both issues are addressed in my draft for a RPL domain. An RFC will
> > >>> also
> > >> hint a revision of the backbone router that it should rewrite the FL
> > >> on outgoing packets.
> > >>> What do you think?
> > >> I think that Phil's last message frames the question to 6man
> > >> correctly, so I will respond to him...
> > >>
> > >> Regards
> > >>     Brian
> > >>> Pascal
> > >>>
> > >>>> Le 14 ao=C3=BBt 2014 =C3=A0 22:18, "Brian E Carpenter"
> > >> <brian.e.carpenter@gmail.com> a =C3=A9crit :
> > >>>>> On 14/08/2014 22:28, Pascal Thubert (pthubert) wrote:
> > >>>>> We can live with this Brian,
> > >>>>>
> > >>>>> but then I can we add at least an ISA100.11a network? ISA100.11a
> > >>>>> was
> > >> designed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow
> > >> label to indicate which flow a packet belongs to.
> > >>>> I have no idea what ISA100.11a is or which organisation developed
> > >>>> it, but it sounds like a violation of the flow label standard at
> > >>>> that time (RFC 3697). If I'd known about it, we would probably hav=
e
> > >>>> included it in the menagerie of RFC 6294.
> > >>>>
> > >>>> There's not much the IETF can do about other organisations that
> > >>>> misuse our standards, although indeed we sometimes need to
> > document
> > >>>> such cases.
> > >>>>
> > >>>>   Brian
> > >>>>
> > >>>>
> > >>>> In more details, devices are provisioned with per-flow behavior
> > >>>> (including
> > >> routing) and settings in what is called a contract.
> > >>>> The contractID is carried in the IPv6 flow label.
> > >>>>> If so should we name ISA100 specifically or use a more vague
> > >>>>> description
> > >> like a "RPL or similar LLN domain"
> > >>>>> We'll note that resetting an flow label that comes from the
> > >>>>> Internet is a generic need is that flow label was set according t=
o
> > >>>>> 6437, cannot be trusted to be untempered with,
> > >>>>>
> > >>>>> Cheers,
> > >>>>>
> > >>>>> Pascal
> > >>>>>
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E
> > >>>>>> Carpenter
> > >>>>>> Sent: mercredi 13 ao=C3=BBt 2014 22:53
> > >>>>>> To: Philip Levis
> > >>>>>> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man
> > >>>>>> WG; 6lo@ietf.org WG
> > >>>>>> Subject: Re: [Roll] [6lo] WGLC for
> > >>>>>> draft-thubert-6man-flow-label-for-rpl-03
> > >>>>>>
> > >>>>>>> On 14/08/2014 07:07, Philip Levis wrote:
> > >>>>>>> On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert)
> > >>>>>> <pthubert@cisco.com> wrote:
> > >>>>>>>> If this draft is not adopted, the flow label from LLN will
> > >>>>>>>> probably stay all
> > >>>>>> zeroes as it is today and the goal of 6437 will not be achieved.
> > >>>>>>> Pascal, I'm trying to reconcile your claim that the goal of 643=
7
> > >>>>>>> is to allow enclosed networks to use the flow label with Brian'=
s
> > >>>>>>> statement
> > >>>>>>>
> > >>>>>>>> Actually that's why I don't want to see a formal update to
> > >>>>>>>> 6437, because the only rational update would be to allow any
> > >>>>>>>> closed domain to invent its own usage. We had that argument at
> > >>>>>>>> length during the development of 6437, and decided against it.
> > >>>>>>> Phil
> > >>>>>> Right. I'm drawing a very subtle line between (a) stating an
> > >>>>>> exception to 6437 for this particular usage and (b) opening the
> > >>>>>> door to other usages. Since 6man clearly didn't want (b) during
> > >>>>>> the development of
> > >>>>>> 6437 I think we do need to limit ourselves to (a).
> > >>>>>>
> > >>>>>>    Brian
> > >>>>>>
> > >>>>>> ----------------------------------------------------------------=
-
> > >>>>>> --
> > >>>>>> - IETF IPv6 working group mailing list ipv6@ietf.org
> > >>>>>> Administrative
> > >>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > >>>>>> ----------------------------------------------------------------=
-
> > >>>>>> --
> > >>>>>> -
> > >
>
>

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

<div dir=3D"ltr">Hello,<div><br></div><div>Thank you all for your comments =
during this WGLC. Our conclusion is that we=C2=A0<span style=3D"font-family=
:arial,sans-serif;font-size:13px">did not see consensus for the=C2=A0</span=
><span style=3D"font-family:arial,sans-serif;font-size:13px">draft. We need=
 please more participation on that. (We think that most of the people are o=
n vacations).=C2=A0</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">So,=
 we leave this thread open, and we are going to have another WGLC during se=
ptember.</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">Tha=
nk you very much in advance,</span></div><div><span style=3D"font-family:ar=
ial,sans-serif;font-size:13px"><br>
</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p=
x">Kind Regards,</span></div><div><span style=3D"font-family:arial,sans-ser=
if;font-size:13px"><br></span></div><div><span style=3D"font-family:arial,s=
ans-serif;font-size:13px">Michael &amp; Ines.</span></div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014-08=
-22 15:56 GMT+03:00 Pascal Thubert (pthubert) <span dir=3D"ltr">&lt;<a href=
=3D"mailto:pthubert@cisco.com" target=3D"_blank">pthubert@cisco.com</a>&gt;=
</span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hello Brian:<br>
<br>
The question of a liaison was discussed at both IEC and ISA100, and they we=
re very positive about the idea. We can certainly make that happen.<br>
I doubt that there is value in analyzing finely ISA100.11a that is mostly c=
ast in stone now. We made the analysis at the time and concluded that it wa=
s conforming RFC 3697, and we know now that it does not conform RFC 6437.<b=
r>

We could still participate to the work on the backbone router but the rules=
 in RFC 6437 will not be acceptable there for the exact same reasons that t=
hey are not acceptable in a RPL domain, and the Laurent+Carsten proposal wi=
ll not change that a iota.<br>

<br>
The most constructive would be (IMHO):<br>
- adopt the proposed change to the 6MAN rules separately from the proposed =
use in RPL and<br>
- extend the rights that we are asking for a RPL domain to an ISA100 subnet=
work as well so as to make ISA100 compliant again<br>
- update 6284 to position ISA100.11a/IEC62734 vs. both RFCs and the 6MAN RP=
L flow label work (split or not) as Ines suggested<br>
- go to WCI and enforce the application of the new RFC so that packets outg=
oing the ISA100 subnetwork are made compliant to RFC 6437 (by the backbone =
router).<br>
<br>
Would we agree on this path?<br>
<br>
Pascal<br>
<br>
<br>
&gt; -----Original Message-----<br>
&gt; From: Brian E Carpenter [mailto:<a href=3D"mailto:brian.e.carpenter@gm=
ail.com">brian.e.carpenter@gmail.com</a>]<br>
&gt; Sent: mardi 19 ao=C3=BBt 2014 22:32<br>
&gt; To: Pascal Thubert (pthubert)<br>
&gt; Cc: Michael Richardson; Philip Levis; Routing Over Low power and Lossy=
<br>
&gt; networks; Ines Robles; 6man WG; <a href=3D"mailto:6lo@ietf.org">6lo@ie=
tf.org</a> WG<br>
&gt; Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-r=
pl-03<br>
&gt;<br>
&gt; Hi Pascal,<br>
&gt;<br>
&gt; If we&#39;re really going to discuss this, we need the IAB to establis=
h liaison and<br>
&gt; get the right to let us all see the specification. I&#39;m not going t=
o spend my<br>
&gt; time speculating about a secret document. However, the bit you quote:<=
br>
&gt; &quot;FlowLabel: The lower order 16 bits of the FlowLabel shall be set=
 to<br>
&gt; ContractID. The higher order 4 bits shall be all zeros.&quot;<br>
&gt; certainly seems to violate RFC 6437. Whether it violated the somewhat<=
br>
&gt; confused situation left by RFC 2460 and RFC 3697 is less clear. I have=
 no<br>
&gt; recollection of anybody from ISA or IEC talking to the IETF about this=
 issue.<br>
&gt;<br>
&gt; Regards<br>
&gt;=C2=A0 =C2=A0 Brian<br>
&gt;<br>
&gt; On 19/08/2014 00:51, Pascal Thubert (pthubert) wrote:<br>
&gt; &gt; Hello Brian:<br>
&gt; &gt;<br>
&gt; &gt; I do not think that you can freely download the specification. Yo=
u<br>
&gt; &gt; probably need membership first. The links exist from the Wikipedi=
a<br>
&gt; &gt; page but they are broken. Same goes for the IEC version which is =
IEC<br>
&gt; &gt; 62734, but if you have access to the IEC then the current work is=
 here<br>
&gt; &gt; <a href=3D"http://www.iec.ch/cgi-bin/restricted/getfile.pl/65C_73=
5ea_CDV.pdf?dir=3D" target=3D"_blank">http://www.iec.ch/cgi-bin/restricted/=
getfile.pl/65C_735ea_CDV.pdf?dir=3D</a><br>
&gt; &gt; 65C&amp;format=3Dpdf&amp;type=3D_CDV&amp;file=3D735ea.pdf<br>
&gt; &gt;<br>
&gt; &gt; Quotes:<br>
&gt; &gt;<br>
&gt; &gt; &quot;The ContractID is associated with a particular D-route. Thi=
s may be used<br>
&gt; when a particular graph or source D-route is intended to provide a def=
ined<br>
&gt; level of service&quot;<br>
&gt; &gt;<br>
&gt; &gt; &quot;FlowLabel: The lower order 16 bits of the FlowLabel shall b=
e set to<br>
&gt; ContractID. The higher order 4 bits shall be all zeros. This field sha=
ll only be<br>
&gt; present if octets 3 through 5 are present, as indicated by LOWPAN_IPHC=
<br>
&gt; encoding.&quot;<br>
&gt; &gt;<br>
&gt; &gt; Note that the 6TiSCH architecture echoes this design, and a d-rou=
te is very<br>
&gt; similar to a 6TiSCH track.<br>
&gt; &gt;<br>
&gt; &gt; For the sake of history and to my best knowledge, ISA100.11a was =
the first<br>
&gt; industrial standard to adopt IPv6 for process control applications (co=
ntrol<br>
&gt; loops and monitoring).<br>
&gt; &gt; It is effectively enabling IP in the control network, which is an=
 historical<br>
&gt; step toward the IT/OT convergence, that is the Industrial equivalent o=
f voice<br>
&gt; and video convergence over IP.<br>
&gt; &gt;<br>
&gt; &gt; And also to my best knowledge and conforming RFC 3697, ISA100.11a=
 does<br>
&gt; not mute the Flow Label inside the network, as Michael points out. Onl=
y<br>
&gt; when the additional backbone Router functionality is defined does the<=
br>
&gt; problem of rewriting come into play at the Backbone Router (same posit=
ion<br>
&gt; as RPL root). For all I know this work is taking place at the Wireless=
<br>
&gt; Compliance Institute, WCI, but I do not have the latest.<br>
&gt; &gt;<br>
&gt; &gt; Cheers,<br>
&gt; &gt;<br>
&gt; &gt; Pascal<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;&gt; -----Original Message-----<br>
&gt; &gt;&gt; From: Brian E Carpenter [mailto:<a href=3D"mailto:brian.e.car=
penter@gmail.com">brian.e.carpenter@gmail.com</a>]<br>
&gt; &gt;&gt; Sent: samedi 16 ao=C3=BBt 2014 03:13<br>
&gt; &gt;&gt; To: Pascal Thubert (pthubert)<br>
&gt; &gt;&gt; Cc: Philip Levis; Routing Over Low power and Lossy networks; =
Ines<br>
&gt; &gt;&gt; Robles; 6man WG; <a href=3D"mailto:6lo@ietf.org">6lo@ietf.org=
</a> WG<br>
&gt; &gt;&gt; Subject: Re: [Roll] [6lo] WGLC for<br>
&gt; &gt;&gt; draft-thubert-6man-flow-label-for-rpl-03<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; On 15/08/2014 20:51, Pascal Thubert (pthubert) wrote:<br>
&gt; &gt;&gt;&gt; Hello Brian<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt; I do not think that ISA10011.a violates RFC 3697. What ex=
actly made<br>
&gt; &gt;&gt;&gt; you<br>
&gt; &gt;&gt; believe so?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; I was over-interpreting what you wrote, I guess. It&#39;s tru=
e that 3697<br>
&gt; &gt;&gt; was rather vague about what it called &quot;flow state establ=
ishment<br>
&gt; &gt;&gt; methods&quot; and permitted both sequential and pseudo-random=
 flow label<br>
&gt; &gt;&gt; values. Is the ISA10011.a on line somewhere?<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt;&gt; For all I know ISA100 does everything by the book. Note t=
hat ISA100<br>
&gt; &gt;&gt;&gt; does<br>
&gt; &gt;&gt; not update a non zero FL on the fly since it is not set by a =
source<br>
&gt; &gt;&gt; outside the LLN if that is your concern.<br>
&gt; &gt;&gt;&gt; OTOH It may violate RFC 6437 in that the flow is not a ra=
ndom but a<br>
&gt; &gt;&gt;&gt; value<br>
&gt; &gt;&gt; attributed by a PCE called system manager (along rules in sec=
tion 4).<br>
&gt; &gt;&gt; As things stand, we&#39;d certainly want the backbone router =
at LLN<br>
&gt; &gt;&gt; egress to rewrite the FL in packets towards the Internet with=
 a<br>
&gt; &gt;&gt; randomized per flow value.<br>
&gt; &gt;&gt;&gt; It will violate RFC 6437 because if the flow label is set=
 by a<br>
&gt; &gt;&gt;&gt; router in the<br>
&gt; &gt;&gt; Internet - or an updated source that complies to 6437-, the b=
ackbone<br>
&gt; &gt;&gt; router at LLN Ingress will rewrite it.<br>
&gt; &gt;&gt;&gt; Both issues are addressed in my draft for a RPL domain. A=
n RFC will<br>
&gt; &gt;&gt;&gt; also<br>
&gt; &gt;&gt; hint a revision of the backbone router that it should rewrite=
 the FL<br>
&gt; &gt;&gt; on outgoing packets.<br>
&gt; &gt;&gt;&gt; What do you think?<br>
&gt; &gt;&gt; I think that Phil&#39;s last message frames the question to 6=
man<br>
&gt; &gt;&gt; correctly, so I will respond to him...<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; Regards<br>
&gt; &gt;&gt;=C2=A0 =C2=A0 =C2=A0Brian<br>
&gt; &gt;&gt;&gt; Pascal<br>
&gt; &gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; Le 14 ao=C3=BBt 2014 =C3=A0 22:18, &quot;Brian E Carp=
enter&quot;<br>
&gt; &gt;&gt; &lt;<a href=3D"mailto:brian.e.carpenter@gmail.com">brian.e.ca=
rpenter@gmail.com</a>&gt; a =C3=A9crit :<br>
&gt; &gt;&gt;&gt;&gt;&gt; On 14/08/2014 22:28, Pascal Thubert (pthubert) wr=
ote:<br>
&gt; &gt;&gt;&gt;&gt;&gt; We can live with this Brian,<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; but then I can we add at least an ISA100.11a netw=
ork? ISA100.11a<br>
&gt; &gt;&gt;&gt;&gt;&gt; was<br>
&gt; &gt;&gt; designed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IP=
v6 flow<br>
&gt; &gt;&gt; label to indicate which flow a packet belongs to.<br>
&gt; &gt;&gt;&gt;&gt; I have no idea what ISA100.11a is or which organisati=
on developed<br>
&gt; &gt;&gt;&gt;&gt; it, but it sounds like a violation of the flow label =
standard at<br>
&gt; &gt;&gt;&gt;&gt; that time (RFC 3697). If I&#39;d known about it, we w=
ould probably have<br>
&gt; &gt;&gt;&gt;&gt; included it in the menagerie of RFC 6294.<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; There&#39;s not much the IETF can do about other orga=
nisations that<br>
&gt; &gt;&gt;&gt;&gt; misuse our standards, although indeed we sometimes ne=
ed to<br>
&gt; document<br>
&gt; &gt;&gt;&gt;&gt; such cases.<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;=C2=A0 =C2=A0Brian<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt; In more details, devices are provisioned with per-flo=
w behavior<br>
&gt; &gt;&gt;&gt;&gt; (including<br>
&gt; &gt;&gt; routing) and settings in what is called a contract.<br>
&gt; &gt;&gt;&gt;&gt; The contractID is carried in the IPv6 flow label.<br>
&gt; &gt;&gt;&gt;&gt;&gt; If so should we name ISA100 specifically or use a=
 more vague<br>
&gt; &gt;&gt;&gt;&gt;&gt; description<br>
&gt; &gt;&gt; like a &quot;RPL or similar LLN domain&quot;<br>
&gt; &gt;&gt;&gt;&gt;&gt; We&#39;ll note that resetting an flow label that =
comes from the<br>
&gt; &gt;&gt;&gt;&gt;&gt; Internet is a generic need is that flow label was=
 set according to<br>
&gt; &gt;&gt;&gt;&gt;&gt; 6437, cannot be trusted to be untempered with,<br=
>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; Cheers,<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt; Pascal<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; -----Original Message-----<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; From: ipv6 [mailto:<a href=3D"mailto:ipv6-bou=
nces@ietf.org">ipv6-bounces@ietf.org</a>] On Behalf Of Brian E<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; Carpenter<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; Sent: mercredi 13 ao=C3=BBt 2014 22:53<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; To: Philip Levis<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; Cc: Routing Over Low power and Lossy networks=
; Ines Robles; 6man<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; WG; <a href=3D"mailto:6lo@ietf.org">6lo@ietf.=
org</a> WG<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; Subject: Re: [Roll] [6lo] WGLC for<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; draft-thubert-6man-flow-label-for-rpl-03<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt; On 14/08/2014 07:07, Philip Levis wrote:<=
br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt; On Aug 13, 2014, at 9:48 AM, Pascal Thube=
rt (pthubert)<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; &lt;<a href=3D"mailto:pthubert@cisco.com">pth=
ubert@cisco.com</a>&gt; wrote:<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; If this draft is not adopted, the flo=
w label from LLN will<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; probably stay all<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; zeroes as it is today and the goal of 6437 wi=
ll not be achieved.<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt; Pascal, I&#39;m trying to reconcile your =
claim that the goal of 6437<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt; is to allow enclosed networks to use the =
flow label with Brian&#39;s<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt; statement<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Actually that&#39;s why I don&#39;t w=
ant to see a formal update to<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; 6437, because the only rational updat=
e would be to allow any<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; closed domain to invent its own usage=
. We had that argument at<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; length during the development of 6437=
, and decided against it.<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt;&gt; Phil<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; Right. I&#39;m drawing a very subtle line bet=
ween (a) stating an<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; exception to 6437 for this particular usage a=
nd (b) opening the<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; door to other usages. Since 6man clearly didn=
&#39;t want (b) during<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; the development of<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; 6437 I think we do need to limit ourselves to=
 (a).<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt;=C2=A0 =C2=A0 Brian<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; ---------------------------------------------=
--------------------<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; --<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; - IETF IPv6 working group mailing list <a hre=
f=3D"mailto:ipv6@ietf.org">ipv6@ietf.org</a><br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; Administrative<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; Requests: <a href=3D"https://www.ietf.org/mai=
lman/listinfo/ipv6" target=3D"_blank">https://www.ietf.org/mailman/listinfo=
/ipv6</a><br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; ---------------------------------------------=
--------------------<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; --<br>
&gt; &gt;&gt;&gt;&gt;&gt;&gt; -<br>
&gt; &gt;<br>
<br>
</blockquote></div><br></div>

--047d7b34340cc4c9f5050139b57c--


From nobody Fri Aug 22 20:07:52 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6A01A70E2; Fri, 22 Aug 2014 20:07:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 QKDBrVSI4Lm4; Fri, 22 Aug 2014 20:07:34 -0700 (PDT)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38DAE1A0B10; Fri, 22 Aug 2014 20:07:34 -0700 (PDT)
Received: by mail-pa0-f53.google.com with SMTP id rd3so17698614pab.40 for <multiple recipients>; Fri, 22 Aug 2014 20:07:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cp44kTSz5ct06tK7//Cp7f6jBf+Fu1C6llr/YAtVIXM=; b=ZV2vT32vkQtdoE+N7OvJCbAITxzRlzcd7PSSksRQxm4dODUenuDwbKO3j3tHPeiK5e DF4wGVOlbIaDr/NgpK8s/yt5ir9JtQ8uDlNG7fb9irNHoBn965sOCEivS5fKzPw69K/k nZHJE5hjGA2A3pG6cb4rBA2S3CoZOlp8NM8YzkXdPO7x7p5G+pemzdO79x7Xytj0/RtW sb5ibiFZVfnUY57tFWG1vFy5B5VjW8EBQ2Q0Ul55FnU9UDt7H6Wf3jfS2PPIgCcdbVy6 FkWjspVkcLRu4VcUh3ieyWPqcFyd3KI5twL6alZpeWEg4GRWBTt3frEfMc57PKX9g9J2 eErQ==
X-Received: by 10.66.163.164 with SMTP id yj4mr10710168pab.91.1408763253781; Fri, 22 Aug 2014 20:07:33 -0700 (PDT)
Received: from [192.168.178.23] (31.196.69.111.dynamic.snap.net.nz. [111.69.196.31]) by mx.google.com with ESMTPSA id h5sm29631089pdn.83.2014.08.22.20.07.29 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Aug 2014 20:07:33 -0700 (PDT)
Message-ID: <53F8057C.9080904@gmail.com>
Date: Sat, 23 Aug 2014 15:07:40 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
References: <E045AECD98228444A58C61C200AE1BD842D503B7@xmb-rcd-x01.cisco.com>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD842D503B7@xmb-rcd-x01.cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/2hVL6bxvhZvc6wee6Dn501CTNS4
Cc: 6man WG <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Aug 2014 03:07:39 -0000

Hi Pascal,

On 23/08/2014 00:56, Pascal Thubert (pthubert) wrote:
> Hello Brian:
>=20
> The question of a liaison was discussed at both IEC and ISA100, and the=
y were very positive about the idea. We can certainly make that happen.

That's something that you would need to raise with the IAB. I imagine the=
re
are quite a few IEC documents that are relevant to the IETF; given that
we have a long history of liaison with ITU and ISO, it's actually a bit
surprising we have never set it up with IEC. Anyway, that's above my
current pay grade in the IETF ;-).

> I doubt that there is value in analyzing finely ISA100.11a that is most=
ly cast in stone now. We made the analysis at the time and concluded that=
 it was conforming RFC 3697, and we know now that it does not conform RFC=
 6437.
> We could still participate to the work on the backbone router but the r=
ules in RFC 6437 will not be acceptable there for the exact same reasons =
that they are not acceptable in a RPL domain, and the Laurent+Carsten pro=
posal will not change that a iota.
>=20
> The most constructive would be (IMHO):
> - adopt the proposed change to the 6MAN rules separately from the propo=
sed use in RPL and=20

The problem is that something like this was in the draft that became RFC =
6437,
and was removed after a very negative reaction from 6MAN.

Quoting from a slide shown to 6MAN in November 2010:

"A network domain MUST NOT forward packets outside the
domain whose flow labels are other than zero or pseudorandom.
[Backstop rule for sites that break other rules.]
o New compared to RFC 3697."

This made it into draft-ietf-6man-flow-update-00 and then
draft-ietf-6man-flow-3697bis-00, but was removed from
draft-ietf-6man-flow-3697bis-01 because the WG simply didn't
want it.

The text "However, any node that sets flow label values
according to a stateful scheme MUST ensure that packets conform to
Section 3 of the present specification if they are sent outside the
network domain using the stateful scheme." was present in the -01
draft but was removed at WG request in -04.

So there was an extremely clear 6MAN consensus against this in 2010/11.
We were explicitly asked to remove the notion of domains with their
own rules.

   Brian

> - extend the rights that we are asking for a RPL domain to an ISA100 su=
bnetwork as well so as to make ISA100 compliant again
> - update 6284 to position ISA100.11a/IEC62734 vs. both RFCs and the 6MA=
N RPL flow label work (split or not) as Ines suggested
> - go to WCI and enforce the application of the new RFC so that packets =
outgoing the ISA100 subnetwork are made compliant to RFC 6437 (by the bac=
kbone router).
>=20
> Would we agree on this path?=20
>=20
> Pascal
>=20
>=20
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>> Sent: mardi 19 ao=C3=BBt 2014 22:32
>> To: Pascal Thubert (pthubert)
>> Cc: Michael Richardson; Philip Levis; Routing Over Low power and Lossy=

>> networks; Ines Robles; 6man WG; 6lo@ietf.org WG
>> Subject: Re: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-r=
pl-03
>>
>> Hi Pascal,
>>
>> If we're really going to discuss this, we need the IAB to establish li=
aison and
>> get the right to let us all see the specification. I'm not going to sp=
end my
>> time speculating about a secret document. However, the bit you quote:
>> "FlowLabel: The lower order 16 bits of the FlowLabel shall be set to
>> ContractID. The higher order 4 bits shall be all zeros."
>> certainly seems to violate RFC 6437. Whether it violated the somewhat
>> confused situation left by RFC 2460 and RFC 3697 is less clear. I have=
 no
>> recollection of anybody from ISA or IEC talking to the IETF about this=
 issue.
>>
>> Regards
>>    Brian
>>
>> On 19/08/2014 00:51, Pascal Thubert (pthubert) wrote:
>>> Hello Brian:
>>>
>>> I do not think that you can freely download the specification. You
>>> probably need membership first. The links exist from the Wikipedia
>>> page but they are broken. Same goes for the IEC version which is IEC
>>> 62734, but if you have access to the IEC then the current work is her=
e
>>> http://www.iec.ch/cgi-bin/restricted/getfile.pl/65C_735ea_CDV.pdf?dir=
=3D
>>> 65C&format=3Dpdf&type=3D_CDV&file=3D735ea.pdf
>>>
>>> Quotes:
>>>
>>> "The ContractID is associated with a particular D-route. This may be =
used
>> when a particular graph or source D-route is intended to provide a def=
ined
>> level of service"
>>> "FlowLabel: The lower order 16 bits of the FlowLabel shall be set to
>> ContractID. The higher order 4 bits shall be all zeros. This field sha=
ll only be
>> present if octets 3 through 5 are present, as indicated by LOWPAN_IPHC=

>> encoding."
>>> Note that the 6TiSCH architecture echoes this design, and a d-route i=
s very
>> similar to a 6TiSCH track.
>>> For the sake of history and to my best knowledge, ISA100.11a was the =
first
>> industrial standard to adopt IPv6 for process control applications (co=
ntrol
>> loops and monitoring).
>>> It is effectively enabling IP in the control network, which is an his=
torical
>> step toward the IT/OT convergence, that is the Industrial equivalent o=
f voice
>> and video convergence over IP.
>>> And also to my best knowledge and conforming RFC 3697, ISA100.11a doe=
s
>> not mute the Flow Label inside the network, as Michael points out. Onl=
y
>> when the additional backbone Router functionality is defined does the
>> problem of rewriting come into play at the Backbone Router (same posit=
ion
>> as RPL root). For all I know this work is taking place at the Wireless=

>> Compliance Institute, WCI, but I do not have the latest.
>>> Cheers,
>>>
>>> Pascal
>>>
>>>
>>>> -----Original Message-----
>>>> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
>>>> Sent: samedi 16 ao=C3=BBt 2014 03:13
>>>> To: Pascal Thubert (pthubert)
>>>> Cc: Philip Levis; Routing Over Low power and Lossy networks; Ines
>>>> Robles; 6man WG; 6lo@ietf.org WG
>>>> Subject: Re: [Roll] [6lo] WGLC for
>>>> draft-thubert-6man-flow-label-for-rpl-03
>>>>
>>>> On 15/08/2014 20:51, Pascal Thubert (pthubert) wrote:
>>>>> Hello Brian
>>>>>
>>>>> I do not think that ISA10011.a violates RFC 3697. What exactly made=

>>>>> you
>>>> believe so?
>>>>
>>>> I was over-interpreting what you wrote, I guess. It's true that 3697=

>>>> was rather vague about what it called "flow state establishment
>>>> methods" and permitted both sequential and pseudo-random flow label
>>>> values. Is the ISA10011.a on line somewhere?
>>>>
>>>>> For all I know ISA100 does everything by the book. Note that ISA100=

>>>>> does
>>>> not update a non zero FL on the fly since it is not set by a source
>>>> outside the LLN if that is your concern.
>>>>> OTOH It may violate RFC 6437 in that the flow is not a random but a=

>>>>> value
>>>> attributed by a PCE called system manager (along rules in section 4)=
=2E
>>>> As things stand, we'd certainly want the backbone router at LLN
>>>> egress to rewrite the FL in packets towards the Internet with a
>>>> randomized per flow value.
>>>>> It will violate RFC 6437 because if the flow label is set by a
>>>>> router in the
>>>> Internet - or an updated source that complies to 6437-, the backbone=

>>>> router at LLN Ingress will rewrite it.
>>>>> Both issues are addressed in my draft for a RPL domain. An RFC will=

>>>>> also
>>>> hint a revision of the backbone router that it should rewrite the FL=

>>>> on outgoing packets.
>>>>> What do you think?
>>>> I think that Phil's last message frames the question to 6man
>>>> correctly, so I will respond to him...
>>>>
>>>> Regards
>>>>     Brian
>>>>> Pascal
>>>>>
>>>>>> Le 14 ao=C3=BBt 2014 =C3=A0 22:18, "Brian E Carpenter"
>>>> <brian.e.carpenter@gmail.com> a =C3=A9crit :
>>>>>>> On 14/08/2014 22:28, Pascal Thubert (pthubert) wrote:
>>>>>>> We can live with this Brian,
>>>>>>>
>>>>>>> but then I can we add at least an ISA100.11a network? ISA100.11a
>>>>>>> was
>>>> designed in 2007/8, adopted IPv6 and 6LoWPAN, and uses the IPv6 flow=

>>>> label to indicate which flow a packet belongs to.
>>>>>> I have no idea what ISA100.11a is or which organisation developed
>>>>>> it, but it sounds like a violation of the flow label standard at
>>>>>> that time (RFC 3697). If I'd known about it, we would probably hav=
e
>>>>>> included it in the menagerie of RFC 6294.
>>>>>>
>>>>>> There's not much the IETF can do about other organisations that
>>>>>> misuse our standards, although indeed we sometimes need to
>> document
>>>>>> such cases.
>>>>>>
>>>>>>   Brian
>>>>>>
>>>>>>
>>>>>> In more details, devices are provisioned with per-flow behavior
>>>>>> (including
>>>> routing) and settings in what is called a contract.
>>>>>> The contractID is carried in the IPv6 flow label.
>>>>>>> If so should we name ISA100 specifically or use a more vague
>>>>>>> description
>>>> like a "RPL or similar LLN domain"
>>>>>>> We'll note that resetting an flow label that comes from the
>>>>>>> Internet is a generic need is that flow label was set according t=
o
>>>>>>> 6437, cannot be trusted to be untempered with,
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Pascal
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian E
>>>>>>>> Carpenter
>>>>>>>> Sent: mercredi 13 ao=C3=BBt 2014 22:53
>>>>>>>> To: Philip Levis
>>>>>>>> Cc: Routing Over Low power and Lossy networks; Ines Robles; 6man=

>>>>>>>> WG; 6lo@ietf.org WG
>>>>>>>> Subject: Re: [Roll] [6lo] WGLC for
>>>>>>>> draft-thubert-6man-flow-label-for-rpl-03
>>>>>>>>
>>>>>>>>> On 14/08/2014 07:07, Philip Levis wrote:
>>>>>>>>> On Aug 13, 2014, at 9:48 AM, Pascal Thubert (pthubert)
>>>>>>>> <pthubert@cisco.com> wrote:
>>>>>>>>>> If this draft is not adopted, the flow label from LLN will
>>>>>>>>>> probably stay all
>>>>>>>> zeroes as it is today and the goal of 6437 will not be achieved.=

>>>>>>>>> Pascal, I'm trying to reconcile your claim that the goal of 643=
7
>>>>>>>>> is to allow enclosed networks to use the flow label with Brian'=
s
>>>>>>>>> statement
>>>>>>>>>
>>>>>>>>>> Actually that's why I don't want to see a formal update to
>>>>>>>>>> 6437, because the only rational update would be to allow any
>>>>>>>>>> closed domain to invent its own usage. We had that argument at=

>>>>>>>>>> length during the development of 6437, and decided against it.=

>>>>>>>>> Phil
>>>>>>>> Right. I'm drawing a very subtle line between (a) stating an
>>>>>>>> exception to 6437 for this particular usage and (b) opening the
>>>>>>>> door to other usages. Since 6man clearly didn't want (b) during
>>>>>>>> the development of
>>>>>>>> 6437 I think we do need to limit ourselves to (a).
>>>>>>>>
>>>>>>>>    Brian
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------=
-
>>>>>>>> --
>>>>>>>> - IETF IPv6 working group mailing list ipv6@ietf.org
>>>>>>>> Administrative
>>>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>> ----------------------------------------------------------------=
-
>>>>>>>> --
>>>>>>>> -
>=20


From nobody Sat Aug 23 06:14:01 2014
Return-Path: <karsten_thomann@linfre.de>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59AF1A8797 for <ipv6@ietfa.amsl.com>; Sat, 23 Aug 2014 06:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.219
X-Spam-Level: 
X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 v-9nJ-0RyXyY for <ipv6@ietfa.amsl.com>; Sat, 23 Aug 2014 06:13:56 -0700 (PDT)
Received: from linfre.de (linfre.de [83.151.26.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBDE71A8796 for <ipv6@ietf.org>; Sat, 23 Aug 2014 06:13:55 -0700 (PDT)
Received: from e7240.linfre (91.96.121.217) by linfreserv.linfre (Axigen) with (AES256-SHA encrypted) ESMTPSA id 0FD245; Sat, 23 Aug 2014 15:13:46 +0200
From: Karsten Thomann <karsten_thomann@linfre.de>
To: ipv6@ietf.org
Subject: Re: [Fwd: I-D Action: draft-ietf-6man-why64-02.txt]
Date: Sat, 23 Aug 2014 15:13:45 +0200
Message-ID: <3587504.mxM6nxEtTn@e7240.linfre>
User-Agent: KMail/4.13.3 (Linux/3.15.8-44.g258e3b0-desktop; KDE/4.13.3; x86_64; ; )
In-Reply-To: <53F509F7.4090500@gmail.com>
References: <53EEB906.20206@gmail.com> <1408533920.87649.YahooMailNeo@web162204.mail.bf1.yahoo.com> <53F509F7.4090500@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart1431575.AJUZjtc9ki"
Content-Transfer-Encoding: 7Bit
X-AXIGEN-DK-Result: No records
DomainKey-Status: no signature
X-AxigenSpam-Level: 7
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/tcpHiwu2bhxLkIxTooBec9VCczo
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Aug 2014 13:13:58 -0000

This is a multi-part message in MIME format.

--nextPart1431575.AJUZjtc9ki
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

Hi,

two other nits
Section 2.
   o  Adding a subnet is easy - just take another /64 from the pool.  No
      estimates, calculations, consideration or judgment is needed.
missing "e" in "judgment"

Section 4.3.1
   o  the "L bit in the Prefix Information Options is honored for any
      arbitrary prefix length (whether shorter or longer than /64).
To be consistent with the point before this it should be "L" instead of "L.

Karsten

Am Donnerstag, 21. August 2014, 08:49:59 schrieb Brian E Carpenter:
> Thanks thanks Mark ;-)
> 
>    Brian
> 
> On 20/08/2014 23:25, Mark ZZZ Smith wrote:
> > ----- Original Message -----
> > 
> >> From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
> >> To: Brian E Carpenter <brian.e.carpenter@gmail.com>; 6man 
<ipv6@ietf.org>
> >> Cc:
> >> Sent: Wednesday, 20 August 2014 9:04 PM
> >> Subject: Re: [Fwd: I-D Action: draft-ietf-6man-why64-02.txt]
> >> 
> >> Hi,
> >> 
> >> I'm happy with the changes.
> >> 
> >> Minor nit, duplicate 'the'
> >> 
> >> " At the *the* time of publication
> >> 
> >>      of RFC 2710, the IPv6 addressing architecture specified link-local
> >>      addresses with 64-bit interface identifiers. "
> > 
> > (And my original mistake. I'll have to start doing detailed reviews of my
> > detailed reviews ;-) )> 
> >> Regards,
> >> Mark.
> >> 
> >> 
> >> 
> >> 
> >> ----- Original Message -----
> >> 
> >>>  From: Brian E Carpenter <brian.e.carpenter@gmail.com>
> >>>  To: 6man <ipv6@ietf.org>
> >>>  Cc:
> >>>  Sent: Saturday, 16 August 2014 11:51 AM
> >>>  Subject: [Fwd: I-D Action: draft-ietf-6man-why64-02.txt]
> >>> 
> >>> T his version is intended to respond to all the WG last call
> >>> 
> >>>  comments and reviews. Here are the changes:
> >>>  
> >>>  - numerous editorial improvements
> >>>  - numerous small technical clarifications
> >>>  - added reference to HD ratio
> >>>  - expanded MLD text
> >>>  - added text on duplicate address issue
> >>>  
> >>>  Comments welcome.
> >>>  
> >>>    Brian + co-authors
> >>>  
> >>>  -------- Original Message --------
> >>>  Subject: I-D Action: draft-ietf-6man-why64-02.txt
> >>>  Date: Fri, 15 Aug 2014 18:48:49 -0700
> >>>  From: internet-drafts@ietf.org
> >>>  To: i-d-announce@ietf.org
> >>>  CC: ipv6@ietf.org
> >>>  
> >>>  
> >>>  A New Internet-Draft is available from the on-line Internet-Drafts
> >> 
> >> directories.
> >> 
> >>>  This draft is a work item of the IPv6 Maintenance Working Group of 
the
> >> 
> >> IETF.
> >> 
> >>>          Title           : Analysis of the 64-bit Boundary in IPv6
> >> 
> >> Addressing
> >> 
> >>>          Authors         : Brian Carpenter
> >>>          
> >>>                            Tim Chown
> >>>                            Fernando Gont
> >>>                            Sheng Jiang
> >>>                            Alexandru Petrescu
> >>>                            Andrew Yourtchenko
> >>>      
> >>>      Filename        : draft-ietf-6man-why64-02.txt
> >>>      Pages           : 24
> >>>      Date            : 2014-08-15
> >>>  
> >>>  Abstract:
> >>>     The IPv6 unicast addressing format includes a separation 
between the
> >>>     prefix used to route packets to a subnet and the interface
> >>>     identifier
> >>>     used to specify a given interface connected to that subnet.
> >>>     Currently the interface identifier is defined as 64 bits long for
> >>>     almost every case, leaving 64 bits for the subnet prefix.  This
> >>>     document describes the advantages of this fixed boundary and
> >>>     analyses
> >>>     the issues that would be involved in treating it as a variable
> >>>     boundary.
> >>>  
> >>>  The IETF datatracker status page for this draft is:
> >>>  https://datatracker.ietf.org/doc/draft-ietf-6man-why64/
> >>>  
> >>>  There's also a htmlized version available at:
> >>>  http://tools.ietf.org/html/draft-ietf-6man-why64-02
> >>>  
> >>>  A diff from the previous version is available at:
> >>>  http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-why64-02
> >>>  
> >>>  
> >>>  Please note that it may take a couple of minutes from the time of
> >> 
> >> submission
> >> 
> >>>  until the htmlized version and diff are available at tools.ietf.org.
> >>>  
> >>>  Internet-Drafts are also available by anonymous FTP at:
> >>>  ftp://ftp.ietf.org/internet-drafts/
> >>>  
> >>>  --------------------------------------------------------------------
> >>>  IETF IPv6 working group mailing list
> >>>  ipv6@ietf.org
> >>>  Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>  --------------------------------------------------------------------
> >>>  
> >>>  --------------------------------------------------------------------
--nextPart1431575.AJUZjtc9ki
Content-Transfer-Encoding: 7Bit
Content-Type: text/html; charset="us-ascii"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
<html><head><meta name="qrichtext" content="1" /><style type="text/css">
p, li { white-space: pre-wrap; }
</style></head><body style=" font-family:'Sans Serif'; font-size:9pt; font-weight:400; font-style:normal;">
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">Hi,</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">two other nits</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">Section 2.</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;"><span style=" font-family:'Courier New,courier';">   o  Adding a subnet is easy - just take another /64 from the pool.  No</span></p>
<pre style=" margin-top:0px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;"><span style=" font-family:'Courier New,courier';">      estimates, calculations, consideration or judgment is needed.</span></pre>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">missing &quot;e&quot; in &quot;judgment&quot;</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">Section 4.3.1</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;"><span style=" font-family:'Courier New,courier';">   o  the &quot;L bit in the Prefix Information Options is honored for any</span></p>
<pre style=" margin-top:0px; margin-bottom:12px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;"><span style=" font-family:'Courier New,courier';">      arbitrary prefix length (whether shorter or longer than /64).</span></pre>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">To be consistent with the point before this it should be &quot;L&quot; instead of &quot;L.</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">Karsten</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px;">Am Donnerstag, 21. August 2014, 08:49:59 schrieb Brian E Carpenter:</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; Thanks thanks Mark ;-)</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt;    Brian</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; On 20/08/2014 23:25, Mark ZZZ Smith wrote:</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt; ----- Original Message -----</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; From: Mark ZZZ Smith &lt;markzzzsmith@yahoo.com.au&gt;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; To: Brian E Carpenter &lt;brian.e.carpenter@gmail.com&gt;; 6man &lt;ipv6@ietf.org&gt;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; Cc:</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; Sent: Wednesday, 20 August 2014 9:04 PM</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; Subject: Re: [Fwd: I-D Action: draft-ietf-6man-why64-02.txt]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; Hi,</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; I'm happy with the changes.</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; Minor nit, duplicate 'the'</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; &quot; At the *the* time of publication</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;      of RFC 2710, the IPv6 addressing architecture specified link-local</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;      addresses with 64-bit interface identifiers. &quot;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt; (And my original mistake. I'll have to start doing detailed reviews of my</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt; detailed reviews ;-) )&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; Regards,</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; Mark.</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; ----- Original Message -----</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  From: Brian E Carpenter &lt;brian.e.carpenter@gmail.com&gt;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  To: 6man &lt;ipv6@ietf.org&gt;</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  Cc:</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  Sent: Saturday, 16 August 2014 11:51 AM</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  Subject: [Fwd: I-D Action: draft-ietf-6man-why64-02.txt]</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt; T his version is intended to respond to all the WG last call</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  comments and reviews. Here are the changes:</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  - numerous editorial improvements</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  - numerous small technical clarifications</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  - added reference to HD ratio</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  - expanded MLD text</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  - added text on duplicate address issue</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  Comments welcome.</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;    Brian + co-authors</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  -------- Original Message --------</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  Subject: I-D Action: draft-ietf-6man-why64-02.txt</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  Date: Fri, 15 Aug 2014 18:48:49 -0700</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  From: internet-drafts@ietf.org</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  To: i-d-announce@ietf.org</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  CC: ipv6@ietf.org</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  A New Internet-Draft is available from the on-line Internet-Drafts</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; directories.</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  This draft is a work item of the IPv6 Maintenance Working Group of the</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; IETF.</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;          Title           : Analysis of the 64-bit Boundary in IPv6</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; Addressing</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;          Authors         : Brian Carpenter</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;          </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;                            Tim Chown</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;                            Fernando Gont</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;                            Sheng Jiang</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;                            Alexandru Petrescu</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;                            Andrew Yourtchenko</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;      </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;      Filename        : draft-ietf-6man-why64-02.txt</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;      Pages           : 24</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;      Date            : 2014-08-15</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  Abstract:</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;     The IPv6 unicast addressing format includes a separation between the</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;     prefix used to route packets to a subnet and the interface</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;     identifier</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;     used to specify a given interface connected to that subnet.</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;     Currently the interface identifier is defined as 64 bits long for</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;     almost every case, leaving 64 bits for the subnet prefix.  This</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;     document describes the advantages of this fixed boundary and</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;     analyses</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;     the issues that would be involved in treating it as a variable</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;     boundary.</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  The IETF datatracker status page for this draft is:</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  https://datatracker.ietf.org/doc/draft-ietf-6man-why64/</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  There's also a htmlized version available at:</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  http://tools.ietf.org/html/draft-ietf-6man-why64-02</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  A diff from the previous version is available at:</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-why64-02</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  Please note that it may take a couple of minutes from the time of</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; submission</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  until the htmlized version and diff are available at tools.ietf.org.</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  Internet-Drafts are also available by anonymous FTP at:</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  ftp://ftp.ietf.org/internet-drafts/</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  --------------------------------------------------------------------</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  IETF IPv6 working group mailing list</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  ipv6@ietf.org</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  --------------------------------------------------------------------</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  --------------------------------------------------------------------</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  IETF IPv6 working group mailing list</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  ipv6@ietf.org</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; &gt;&gt;&gt;  --------------------------------------------------------------------</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; </p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; --------------------------------------------------------------------</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; IETF IPv6 working group mailing list</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; ipv6@ietf.org</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6</p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">&gt; --------------------------------------------------------------------</p>
<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; ">&nbsp;</p></body></html>
--nextPart1431575.AJUZjtc9ki--


From nobody Mon Aug 25 09:41:15 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BF91A0055; Mon, 25 Aug 2014 09:41:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.469
X-Spam-Level: 
X-Spam-Status: No, score=-12.469 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 rg0F8gQUVqxT; Mon, 25 Aug 2014 09:41:05 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B1D1A0081; Mon, 25 Aug 2014 09:30:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18442; q=dns/txt; s=iport; t=1408984257; x=1410193857; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Sp91gMsmPaYhYcOlB+OfnHeEmNiaQfq7P5Q29bdH7Rs=; b=Ium0Y6uyghsSiYUwiv/r/gtPdkcrhG6lSw9neQYiV57Plm48Nm3S1339 es1oZ5LN59vF0HGjo0fSoZSVIrdwAKS4AO0mK3dcpgDmPS4UaL9FEOBkU LOpRBbVUSJuhZk04o6n6UsDMMzz72UJ88jym8Ar2zmUCeEzI/rTVLglEo E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhkFAGVk+1OtJA2I/2dsb2JhbABagw1TVwSCeMlSCodNARmBCRZ3hAMBAQECAgEBASARMwcLDAQCAQgRAQMBAQECAgYdAwICAh8GCxQBAgYIAQEEDgUIAYglAxENqyaPKQ2FIheBLItzgUoMCR0WGwcGgnM2gR0FhhGIb4ImhmOCMIpHhiCGNYNebAGBBkGBBwEBAQ
X-IronPort-AV: E=Sophos;i="5.04,397,1406592000"; d="scan'208";a="72150635"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP; 25 Aug 2014 16:30:55 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7PGUs7H030640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Aug 2014 16:30:55 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.56]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Mon, 25 Aug 2014 11:30:54 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: RE: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: Ac++CEw2eULOCzQzTxOZUvA7hQn3EwAoQK0AAHUlFjA=
Date: Mon, 25 Aug 2014 16:30:53 +0000
Deferred-Delivery: Mon, 25 Aug 2014 16:30:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD842D58843@xmb-rcd-x01.cisco.com>
References: <E045AECD98228444A58C61C200AE1BD842D503B7@xmb-rcd-x01.cisco.com> <53F8057C.9080904@gmail.com>
In-Reply-To: <53F8057C.9080904@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.55.22.9]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/txaKWDuZPzeY7P7XxVynFcmIcPo
Cc: 6man WG <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Aug 2014 16:41:11 -0000

SSB1bmRlcnN0YW5kLCBCcmlhbjoNCg0KSXQgbWFrZXMgc2Vuc2UgdG8gcHJvcG9zZSBhIGdlbmVy
aWMgcnVsZSBhbmQgdHJ5IGl0IG9uIHRoZSByZWFsIHdvcmxkLiBCdXQgaXQgaXMgbm90IHN1cnBy
aXNpbmcgdGhhdCBzdWNoIGEgYm9sZCBhcHByb2FjaCBmYWlscyB0byBiZSB1bml2ZXJzYWwgd2hl
biBjb25mcm9udGVkIHRvIHRoZSByZWFsIHdvcmxkLg0KVG8gYmUgdmVyeSBjbGVhciBvbiB0aGUg
bmVlZCBmb3IgNk1BTiB0byB0YWtlIG91ciByZXNwb25zaWJpbGl0aWVzLCBJIGFkZGVkIHRleHQg
dG8gY2xhcmlmeSB0aGF0IDY0MzcgYXMgb2YgdG9kYXkgaXMgZHJhbWF0aWNhbGx5IGNvdW50ZXJw
cm9kdWN0aXZlIGZvciB0aGUgZGV2ZWxvcG1lbnQgb2YgSVB2NiBpbiBMTE5zLg0KDQpPdGhlcndp
c2UsIEkgdXBkYXRlZCBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXRodWJlcnQtNm1hbi1m
bG93LWxhYmVsLWZvci1ycGwtMDUudHh0IGFsb25nIHdpdGggeW91ciByZWNvbW1lbmRhdGlvbnMg
YXMgZm9sbG93czoNCg0KLSByZW1vdmVkIHRoZSB1cGRhdGVkOiB0aWxsIHdlIGdldCBjb25zZW5z
dXMgb24gaGF2aW5nIGl0LCBidXQgZm9sbG93aW5nIFBoaWwncyByZWNvbW1lbmRhdGlvbiwgSSBp
c29sYXRlZCB0aGUgNjQzNyB1cGRhdGVzIGluIHNlY3Rpb24gNS4gIFVwZGF0ZWQgUnVsZXMNCi0g
cmVtb3ZlZCB0aGUgdGV4dCBvbiB0aGUgYXBwbGljYXRpb24gdG8gdGhlIFJQTCBvcHRpb24uIFRo
ZSBydWxlcyB0aGF0IGFyZSBuZWVkZWQgd2hhdGV2ZXIgdGhlIGRlY2lzaW9uIGlzIGxhdGVyIGlu
IExMTiBXR3MgYXMgb2YgaG93IHRoZSBSUEwgb3B0aW9uIGlzIGNvbXByZXNzZWQsIHlldCBsZWF2
aW5nIGFsbCBwb3NzaWJpbGl0aWVzIG9wZW4uIFRoaXMgYWxsb3dzIDZNQU4gdG8gbWFrZSBhbiBp
bmRlcGVuZGVudCBkZWNpc2lvbi4NCi0gaW5kaWNhdGVkIHRoYXQgYSBjb25zdHJhaW5lZCBMTE4g
ZG9tYWluIGlzIGFuIGV4Y2VwdGlvbiB0byB0aGUgZ2VuZXJhbG5lc3Mgb2YgNjQzNyB3aGVyZSBl
bmVyZ3ktc2F2aW5nIGlzIGFub3RoZXIgY29tcGVsbGluZyByZWFzb24gdG8gYWxsb3cgdGhlIG1v
ZGlmaWNhdGlvbiBvZiBhIG5vbi16ZXJvIGZsb3cgbGFiZWwuDQotIGV4dGVuZGVkIHRoZSBhcHBs
aWNhYmlsaXR5IHRvIElTQTEwMC4xMWEgbmV0d29ya3MgYXMgYW4gZWZmb3J0IGZyb20gdGhlIElF
VEYgdG8ga2VlcCB0aGF0IHN0YW5kYXJkIGNvbXBsaWFudCB3aXRoIElQdjYgYXMgd2VsbCBhcyBz
aW1pbGFyIExMTnMgc2luY2UgdGhlIGlzc3VlIHdpdGggNjQzNyBpcyBnZW5lcmljIHRvIGFsbCBj
b25zdHJhaW5lZCBMTE4uDQoNCkNoZWVycywNCg0KUGFzY2FsDQoNCg0KPiAtLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUu
Y2FycGVudGVyQGdtYWlsLmNvbV0NCj4gU2VudDogc2FtZWRpIDIzIGFvw7t0IDIwMTQgMDU6MDgN
Cj4gVG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkNCj4gQ2M6IE1pY2hhZWwgUmljaGFyZHNv
bjsgUGhpbGlwIExldmlzOyBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeQ0KPiBuZXR3
b3JrczsgSW5lcyBSb2JsZXM7IDZtYW4gV0c7IDZsb0BpZXRmLm9yZyBXRw0KPiBTdWJqZWN0OiBS
ZTogW1JvbGxdIFs2bG9dIFdHTEMgZm9yIGRyYWZ0LXRodWJlcnQtNm1hbi1mbG93LWxhYmVsLWZv
ci1ycGwtMDMNCj4gDQo+IEhpIFBhc2NhbCwNCj4gDQo+IE9uIDIzLzA4LzIwMTQgMDA6NTYsIFBh
c2NhbCBUaHViZXJ0IChwdGh1YmVydCkgd3JvdGU6DQo+ID4gSGVsbG8gQnJpYW46DQo+ID4NCj4g
PiBUaGUgcXVlc3Rpb24gb2YgYSBsaWFpc29uIHdhcyBkaXNjdXNzZWQgYXQgYm90aCBJRUMgYW5k
IElTQTEwMCwgYW5kIHRoZXkNCj4gd2VyZSB2ZXJ5IHBvc2l0aXZlIGFib3V0IHRoZSBpZGVhLiBX
ZSBjYW4gY2VydGFpbmx5IG1ha2UgdGhhdCBoYXBwZW4uDQo+IA0KPiBUaGF0J3Mgc29tZXRoaW5n
IHRoYXQgeW91IHdvdWxkIG5lZWQgdG8gcmFpc2Ugd2l0aCB0aGUgSUFCLiBJIGltYWdpbmUgdGhl
cmUNCj4gYXJlIHF1aXRlIGEgZmV3IElFQyBkb2N1bWVudHMgdGhhdCBhcmUgcmVsZXZhbnQgdG8g
dGhlIElFVEY7IGdpdmVuIHRoYXQgd2UNCj4gaGF2ZSBhIGxvbmcgaGlzdG9yeSBvZiBsaWFpc29u
IHdpdGggSVRVIGFuZCBJU08sIGl0J3MgYWN0dWFsbHkgYSBiaXQgc3VycHJpc2luZw0KPiB3ZSBo
YXZlIG5ldmVyIHNldCBpdCB1cCB3aXRoIElFQy4gQW55d2F5LCB0aGF0J3MgYWJvdmUgbXkgY3Vy
cmVudCBwYXkgZ3JhZGUNCj4gaW4gdGhlIElFVEYgOy0pLg0KPiANCj4gPiBJIGRvdWJ0IHRoYXQg
dGhlcmUgaXMgdmFsdWUgaW4gYW5hbHl6aW5nIGZpbmVseSBJU0ExMDAuMTFhIHRoYXQgaXMgbW9z
dGx5IGNhc3QNCj4gaW4gc3RvbmUgbm93LiBXZSBtYWRlIHRoZSBhbmFseXNpcyBhdCB0aGUgdGlt
ZSBhbmQgY29uY2x1ZGVkIHRoYXQgaXQgd2FzDQo+IGNvbmZvcm1pbmcgUkZDIDM2OTcsIGFuZCB3
ZSBrbm93IG5vdyB0aGF0IGl0IGRvZXMgbm90IGNvbmZvcm0gUkZDIDY0MzcuDQo+ID4gV2UgY291
bGQgc3RpbGwgcGFydGljaXBhdGUgdG8gdGhlIHdvcmsgb24gdGhlIGJhY2tib25lIHJvdXRlciBi
dXQgdGhlIHJ1bGVzDQo+IGluIFJGQyA2NDM3IHdpbGwgbm90IGJlIGFjY2VwdGFibGUgdGhlcmUg
Zm9yIHRoZSBleGFjdCBzYW1lIHJlYXNvbnMgdGhhdA0KPiB0aGV5IGFyZSBub3QgYWNjZXB0YWJs
ZSBpbiBhIFJQTCBkb21haW4sIGFuZCB0aGUgTGF1cmVudCtDYXJzdGVuIHByb3Bvc2FsDQo+IHdp
bGwgbm90IGNoYW5nZSB0aGF0IGEgaW90YS4NCj4gPg0KPiA+IFRoZSBtb3N0IGNvbnN0cnVjdGl2
ZSB3b3VsZCBiZSAoSU1ITyk6DQo+ID4gLSBhZG9wdCB0aGUgcHJvcG9zZWQgY2hhbmdlIHRvIHRo
ZSA2TUFOIHJ1bGVzIHNlcGFyYXRlbHkgZnJvbSB0aGUNCj4gPiBwcm9wb3NlZCB1c2UgaW4gUlBM
IGFuZA0KPiANCj4gVGhlIHByb2JsZW0gaXMgdGhhdCBzb21ldGhpbmcgbGlrZSB0aGlzIHdhcyBp
biB0aGUgZHJhZnQgdGhhdCBiZWNhbWUgUkZDDQo+IDY0MzcsIGFuZCB3YXMgcmVtb3ZlZCBhZnRl
ciBhIHZlcnkgbmVnYXRpdmUgcmVhY3Rpb24gZnJvbSA2TUFOLg0KPiANCj4gUXVvdGluZyBmcm9t
IGEgc2xpZGUgc2hvd24gdG8gNk1BTiBpbiBOb3ZlbWJlciAyMDEwOg0KPiANCj4gIkEgbmV0d29y
ayBkb21haW4gTVVTVCBOT1QgZm9yd2FyZCBwYWNrZXRzIG91dHNpZGUgdGhlIGRvbWFpbiB3aG9z
ZQ0KPiBmbG93IGxhYmVscyBhcmUgb3RoZXIgdGhhbiB6ZXJvIG9yIHBzZXVkb3JhbmRvbS4NCj4g
W0JhY2tzdG9wIHJ1bGUgZm9yIHNpdGVzIHRoYXQgYnJlYWsgb3RoZXIgcnVsZXMuXSBvIE5ldyBj
b21wYXJlZCB0byBSRkMNCj4gMzY5Ny4iDQo+IA0KPiBUaGlzIG1hZGUgaXQgaW50byBkcmFmdC1p
ZXRmLTZtYW4tZmxvdy11cGRhdGUtMDAgYW5kIHRoZW4gZHJhZnQtaWV0Zi02bWFuLQ0KPiBmbG93
LTM2OTdiaXMtMDAsIGJ1dCB3YXMgcmVtb3ZlZCBmcm9tDQo+IGRyYWZ0LWlldGYtNm1hbi1mbG93
LTM2OTdiaXMtMDEgYmVjYXVzZSB0aGUgV0cgc2ltcGx5IGRpZG4ndCB3YW50IGl0Lg0KPiANCj4g
VGhlIHRleHQgIkhvd2V2ZXIsIGFueSBub2RlIHRoYXQgc2V0cyBmbG93IGxhYmVsIHZhbHVlcyBh
Y2NvcmRpbmcgdG8gYQ0KPiBzdGF0ZWZ1bCBzY2hlbWUgTVVTVCBlbnN1cmUgdGhhdCBwYWNrZXRz
IGNvbmZvcm0gdG8gU2VjdGlvbiAzIG9mIHRoZQ0KPiBwcmVzZW50IHNwZWNpZmljYXRpb24gaWYg
dGhleSBhcmUgc2VudCBvdXRzaWRlIHRoZSBuZXR3b3JrIGRvbWFpbiB1c2luZyB0aGUNCj4gc3Rh
dGVmdWwgc2NoZW1lLiIgd2FzIHByZXNlbnQgaW4gdGhlIC0wMSBkcmFmdCBidXQgd2FzIHJlbW92
ZWQgYXQgV0cNCj4gcmVxdWVzdCBpbiAtMDQuDQo+IA0KPiBTbyB0aGVyZSB3YXMgYW4gZXh0cmVt
ZWx5IGNsZWFyIDZNQU4gY29uc2Vuc3VzIGFnYWluc3QgdGhpcyBpbiAyMDEwLzExLg0KPiBXZSB3
ZXJlIGV4cGxpY2l0bHkgYXNrZWQgdG8gcmVtb3ZlIHRoZSBub3Rpb24gb2YgZG9tYWlucyB3aXRo
IHRoZWlyIG93bg0KPiBydWxlcy4NCj4gDQo+ICAgIEJyaWFuDQo+IA0KPiA+IC0gZXh0ZW5kIHRo
ZSByaWdodHMgdGhhdCB3ZSBhcmUgYXNraW5nIGZvciBhIFJQTCBkb21haW4gdG8gYW4gSVNBMTAw
DQo+ID4gc3VibmV0d29yayBhcyB3ZWxsIHNvIGFzIHRvIG1ha2UgSVNBMTAwIGNvbXBsaWFudCBh
Z2Fpbg0KPiA+IC0gdXBkYXRlIDYyODQgdG8gcG9zaXRpb24gSVNBMTAwLjExYS9JRUM2MjczNCB2
cy4gYm90aCBSRkNzIGFuZCB0aGUNCj4gPiA2TUFOIFJQTCBmbG93IGxhYmVsIHdvcmsgKHNwbGl0
IG9yIG5vdCkgYXMgSW5lcyBzdWdnZXN0ZWQNCj4gPiAtIGdvIHRvIFdDSSBhbmQgZW5mb3JjZSB0
aGUgYXBwbGljYXRpb24gb2YgdGhlIG5ldyBSRkMgc28gdGhhdCBwYWNrZXRzDQo+IG91dGdvaW5n
IHRoZSBJU0ExMDAgc3VibmV0d29yayBhcmUgbWFkZSBjb21wbGlhbnQgdG8gUkZDIDY0MzcgKGJ5
IHRoZQ0KPiBiYWNrYm9uZSByb3V0ZXIpLg0KPiA+DQo+ID4gV291bGQgd2UgYWdyZWUgb24gdGhp
cyBwYXRoPw0KPiA+DQo+ID4gUGFzY2FsDQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUu
Y2FycGVudGVyQGdtYWlsLmNvbV0NCj4gPj4gU2VudDogbWFyZGkgMTkgYW/Du3QgMjAxNCAyMjoz
Mg0KPiA+PiBUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KPiA+PiBDYzogTWljaGFlbCBS
aWNoYXJkc29uOyBQaGlsaXAgTGV2aXM7IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kDQo+ID4+
IExvc3N5IG5ldHdvcmtzOyBJbmVzIFJvYmxlczsgNm1hbiBXRzsgNmxvQGlldGYub3JnIFdHDQo+
ID4+IFN1YmplY3Q6IFJlOiBbUm9sbF0gWzZsb10gV0dMQyBmb3INCj4gPj4gZHJhZnQtdGh1YmVy
dC02bWFuLWZsb3ctbGFiZWwtZm9yLXJwbC0wMw0KPiA+Pg0KPiA+PiBIaSBQYXNjYWwsDQo+ID4+
DQo+ID4+IElmIHdlJ3JlIHJlYWxseSBnb2luZyB0byBkaXNjdXNzIHRoaXMsIHdlIG5lZWQgdGhl
IElBQiB0byBlc3RhYmxpc2gNCj4gPj4gbGlhaXNvbiBhbmQgZ2V0IHRoZSByaWdodCB0byBsZXQg
dXMgYWxsIHNlZSB0aGUgc3BlY2lmaWNhdGlvbi4gSSdtDQo+ID4+IG5vdCBnb2luZyB0byBzcGVu
ZCBteSB0aW1lIHNwZWN1bGF0aW5nIGFib3V0IGEgc2VjcmV0IGRvY3VtZW50Lg0KPiBIb3dldmVy
LCB0aGUgYml0IHlvdSBxdW90ZToNCj4gPj4gIkZsb3dMYWJlbDogVGhlIGxvd2VyIG9yZGVyIDE2
IGJpdHMgb2YgdGhlIEZsb3dMYWJlbCBzaGFsbCBiZSBzZXQgdG8NCj4gPj4gQ29udHJhY3RJRC4g
VGhlIGhpZ2hlciBvcmRlciA0IGJpdHMgc2hhbGwgYmUgYWxsIHplcm9zLiINCj4gPj4gY2VydGFp
bmx5IHNlZW1zIHRvIHZpb2xhdGUgUkZDIDY0MzcuIFdoZXRoZXIgaXQgdmlvbGF0ZWQgdGhlIHNv
bWV3aGF0DQo+ID4+IGNvbmZ1c2VkIHNpdHVhdGlvbiBsZWZ0IGJ5IFJGQyAyNDYwIGFuZCBSRkMg
MzY5NyBpcyBsZXNzIGNsZWFyLiBJDQo+ID4+IGhhdmUgbm8gcmVjb2xsZWN0aW9uIG9mIGFueWJv
ZHkgZnJvbSBJU0Egb3IgSUVDIHRhbGtpbmcgdG8gdGhlIElFVEYgYWJvdXQNCj4gdGhpcyBpc3N1
ZS4NCj4gPj4NCj4gPj4gUmVnYXJkcw0KPiA+PiAgICBCcmlhbg0KPiA+Pg0KPiA+PiBPbiAxOS8w
OC8yMDE0IDAwOjUxLCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIHdyb3RlOg0KPiA+Pj4gSGVs
bG8gQnJpYW46DQo+ID4+Pg0KPiA+Pj4gSSBkbyBub3QgdGhpbmsgdGhhdCB5b3UgY2FuIGZyZWVs
eSBkb3dubG9hZCB0aGUgc3BlY2lmaWNhdGlvbi4gWW91DQo+ID4+PiBwcm9iYWJseSBuZWVkIG1l
bWJlcnNoaXAgZmlyc3QuIFRoZSBsaW5rcyBleGlzdCBmcm9tIHRoZSBXaWtpcGVkaWENCj4gPj4+
IHBhZ2UgYnV0IHRoZXkgYXJlIGJyb2tlbi4gU2FtZSBnb2VzIGZvciB0aGUgSUVDIHZlcnNpb24g
d2hpY2ggaXMgSUVDDQo+ID4+PiA2MjczNCwgYnV0IGlmIHlvdSBoYXZlIGFjY2VzcyB0byB0aGUg
SUVDIHRoZW4gdGhlIGN1cnJlbnQgd29yayBpcw0KPiA+Pj4gaGVyZQ0KPiA+Pj4gaHR0cDovL3d3
dy5pZWMuY2gvY2dpLWJpbi9yZXN0cmljdGVkL2dldGZpbGUucGwvNjVDXzczNWVhX0NEVi5wZGY/
ZGkNCj4gPj4+IHI9IDY1QyZmb3JtYXQ9cGRmJnR5cGU9X0NEViZmaWxlPTczNWVhLnBkZg0KPiA+
Pj4NCj4gPj4+IFF1b3RlczoNCj4gPj4+DQo+ID4+PiAiVGhlIENvbnRyYWN0SUQgaXMgYXNzb2Np
YXRlZCB3aXRoIGEgcGFydGljdWxhciBELXJvdXRlLiBUaGlzIG1heSBiZQ0KPiA+Pj4gdXNlZA0K
PiA+PiB3aGVuIGEgcGFydGljdWxhciBncmFwaCBvciBzb3VyY2UgRC1yb3V0ZSBpcyBpbnRlbmRl
ZCB0byBwcm92aWRlIGENCj4gPj4gZGVmaW5lZCBsZXZlbCBvZiBzZXJ2aWNlIg0KPiA+Pj4gIkZs
b3dMYWJlbDogVGhlIGxvd2VyIG9yZGVyIDE2IGJpdHMgb2YgdGhlIEZsb3dMYWJlbCBzaGFsbCBi
ZSBzZXQgdG8NCj4gPj4gQ29udHJhY3RJRC4gVGhlIGhpZ2hlciBvcmRlciA0IGJpdHMgc2hhbGwg
YmUgYWxsIHplcm9zLiBUaGlzIGZpZWxkDQo+ID4+IHNoYWxsIG9ubHkgYmUgcHJlc2VudCBpZiBv
Y3RldHMgMyB0aHJvdWdoIDUgYXJlIHByZXNlbnQsIGFzIGluZGljYXRlZA0KPiA+PiBieSBMT1dQ
QU5fSVBIQyBlbmNvZGluZy4iDQo+ID4+PiBOb3RlIHRoYXQgdGhlIDZUaVNDSCBhcmNoaXRlY3R1
cmUgZWNob2VzIHRoaXMgZGVzaWduLCBhbmQgYSBkLXJvdXRlDQo+ID4+PiBpcyB2ZXJ5DQo+ID4+
IHNpbWlsYXIgdG8gYSA2VGlTQ0ggdHJhY2suDQo+ID4+PiBGb3IgdGhlIHNha2Ugb2YgaGlzdG9y
eSBhbmQgdG8gbXkgYmVzdCBrbm93bGVkZ2UsIElTQTEwMC4xMWEgd2FzIHRoZQ0KPiA+Pj4gZmly
c3QNCj4gPj4gaW5kdXN0cmlhbCBzdGFuZGFyZCB0byBhZG9wdCBJUHY2IGZvciBwcm9jZXNzIGNv
bnRyb2wgYXBwbGljYXRpb25zDQo+ID4+IChjb250cm9sIGxvb3BzIGFuZCBtb25pdG9yaW5nKS4N
Cj4gPj4+IEl0IGlzIGVmZmVjdGl2ZWx5IGVuYWJsaW5nIElQIGluIHRoZSBjb250cm9sIG5ldHdv
cmssIHdoaWNoIGlzIGFuDQo+ID4+PiBoaXN0b3JpY2FsDQo+ID4+IHN0ZXAgdG93YXJkIHRoZSBJ
VC9PVCBjb252ZXJnZW5jZSwgdGhhdCBpcyB0aGUgSW5kdXN0cmlhbCBlcXVpdmFsZW50DQo+ID4+
IG9mIHZvaWNlIGFuZCB2aWRlbyBjb252ZXJnZW5jZSBvdmVyIElQLg0KPiA+Pj4gQW5kIGFsc28g
dG8gbXkgYmVzdCBrbm93bGVkZ2UgYW5kIGNvbmZvcm1pbmcgUkZDIDM2OTcsIElTQTEwMC4xMWEN
Cj4gPj4+IGRvZXMNCj4gPj4gbm90IG11dGUgdGhlIEZsb3cgTGFiZWwgaW5zaWRlIHRoZSBuZXR3
b3JrLCBhcyBNaWNoYWVsIHBvaW50cyBvdXQuDQo+ID4+IE9ubHkgd2hlbiB0aGUgYWRkaXRpb25h
bCBiYWNrYm9uZSBSb3V0ZXIgZnVuY3Rpb25hbGl0eSBpcyBkZWZpbmVkDQo+ID4+IGRvZXMgdGhl
IHByb2JsZW0gb2YgcmV3cml0aW5nIGNvbWUgaW50byBwbGF5IGF0IHRoZSBCYWNrYm9uZSBSb3V0
ZXINCj4gPj4gKHNhbWUgcG9zaXRpb24gYXMgUlBMIHJvb3QpLiBGb3IgYWxsIEkga25vdyB0aGlz
IHdvcmsgaXMgdGFraW5nIHBsYWNlDQo+ID4+IGF0IHRoZSBXaXJlbGVzcyBDb21wbGlhbmNlIElu
c3RpdHV0ZSwgV0NJLCBidXQgSSBkbyBub3QgaGF2ZSB0aGUgbGF0ZXN0Lg0KPiA+Pj4gQ2hlZXJz
LA0KPiA+Pj4NCj4gPj4+IFBhc2NhbA0KPiA+Pj4NCj4gPj4+DQo+ID4+Pj4gLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJy
aWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbV0NCj4gPj4+PiBTZW50OiBzYW1lZGkgMTYgYW/Du3Qg
MjAxNCAwMzoxMw0KPiA+Pj4+IFRvOiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQo+ID4+Pj4g
Q2M6IFBoaWxpcCBMZXZpczsgUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29y
a3M7IEluZXMNCj4gPj4+PiBSb2JsZXM7IDZtYW4gV0c7IDZsb0BpZXRmLm9yZyBXRw0KPiA+Pj4+
IFN1YmplY3Q6IFJlOiBbUm9sbF0gWzZsb10gV0dMQyBmb3INCj4gPj4+PiBkcmFmdC10aHViZXJ0
LTZtYW4tZmxvdy1sYWJlbC1mb3ItcnBsLTAzDQo+ID4+Pj4NCj4gPj4+PiBPbiAxNS8wOC8yMDE0
IDIwOjUxLCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIHdyb3RlOg0KPiA+Pj4+PiBIZWxsbyBC
cmlhbg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJIGRvIG5vdCB0aGluayB0aGF0IElTQTEwMDExLmEgdmlv
bGF0ZXMgUkZDIDM2OTcuIFdoYXQgZXhhY3RseQ0KPiA+Pj4+PiBtYWRlIHlvdQ0KPiA+Pj4+IGJl
bGlldmUgc28/DQo+ID4+Pj4NCj4gPj4+PiBJIHdhcyBvdmVyLWludGVycHJldGluZyB3aGF0IHlv
dSB3cm90ZSwgSSBndWVzcy4gSXQncyB0cnVlIHRoYXQNCj4gPj4+PiAzNjk3IHdhcyByYXRoZXIg
dmFndWUgYWJvdXQgd2hhdCBpdCBjYWxsZWQgImZsb3cgc3RhdGUNCj4gPj4+PiBlc3RhYmxpc2ht
ZW50IG1ldGhvZHMiIGFuZCBwZXJtaXR0ZWQgYm90aCBzZXF1ZW50aWFsIGFuZA0KPiA+Pj4+IHBz
ZXVkby1yYW5kb20gZmxvdyBsYWJlbCB2YWx1ZXMuIElzIHRoZSBJU0ExMDAxMS5hIG9uIGxpbmUN
Cj4gc29tZXdoZXJlPw0KPiA+Pj4+DQo+ID4+Pj4+IEZvciBhbGwgSSBrbm93IElTQTEwMCBkb2Vz
IGV2ZXJ5dGhpbmcgYnkgdGhlIGJvb2suIE5vdGUgdGhhdA0KPiA+Pj4+PiBJU0ExMDAgZG9lcw0K
PiA+Pj4+IG5vdCB1cGRhdGUgYSBub24gemVybyBGTCBvbiB0aGUgZmx5IHNpbmNlIGl0IGlzIG5v
dCBzZXQgYnkgYSBzb3VyY2UNCj4gPj4+PiBvdXRzaWRlIHRoZSBMTE4gaWYgdGhhdCBpcyB5b3Vy
IGNvbmNlcm4uDQo+ID4+Pj4+IE9UT0ggSXQgbWF5IHZpb2xhdGUgUkZDIDY0MzcgaW4gdGhhdCB0
aGUgZmxvdyBpcyBub3QgYSByYW5kb20gYnV0DQo+ID4+Pj4+IGEgdmFsdWUNCj4gPj4+PiBhdHRy
aWJ1dGVkIGJ5IGEgUENFIGNhbGxlZCBzeXN0ZW0gbWFuYWdlciAoYWxvbmcgcnVsZXMgaW4gc2Vj
dGlvbiA0KS4NCj4gPj4+PiBBcyB0aGluZ3Mgc3RhbmQsIHdlJ2QgY2VydGFpbmx5IHdhbnQgdGhl
IGJhY2tib25lIHJvdXRlciBhdCBMTE4NCj4gPj4+PiBlZ3Jlc3MgdG8gcmV3cml0ZSB0aGUgRkwg
aW4gcGFja2V0cyB0b3dhcmRzIHRoZSBJbnRlcm5ldCB3aXRoIGENCj4gPj4+PiByYW5kb21pemVk
IHBlciBmbG93IHZhbHVlLg0KPiA+Pj4+PiBJdCB3aWxsIHZpb2xhdGUgUkZDIDY0MzcgYmVjYXVz
ZSBpZiB0aGUgZmxvdyBsYWJlbCBpcyBzZXQgYnkgYQ0KPiA+Pj4+PiByb3V0ZXIgaW4gdGhlDQo+
ID4+Pj4gSW50ZXJuZXQgLSBvciBhbiB1cGRhdGVkIHNvdXJjZSB0aGF0IGNvbXBsaWVzIHRvIDY0
MzctLCB0aGUNCj4gPj4+PiBiYWNrYm9uZSByb3V0ZXIgYXQgTExOIEluZ3Jlc3Mgd2lsbCByZXdy
aXRlIGl0Lg0KPiA+Pj4+PiBCb3RoIGlzc3VlcyBhcmUgYWRkcmVzc2VkIGluIG15IGRyYWZ0IGZv
ciBhIFJQTCBkb21haW4uIEFuIFJGQw0KPiA+Pj4+PiB3aWxsIGFsc28NCj4gPj4+PiBoaW50IGEg
cmV2aXNpb24gb2YgdGhlIGJhY2tib25lIHJvdXRlciB0aGF0IGl0IHNob3VsZCByZXdyaXRlIHRo
ZQ0KPiA+Pj4+IEZMIG9uIG91dGdvaW5nIHBhY2tldHMuDQo+ID4+Pj4+IFdoYXQgZG8geW91IHRo
aW5rPw0KPiA+Pj4+IEkgdGhpbmsgdGhhdCBQaGlsJ3MgbGFzdCBtZXNzYWdlIGZyYW1lcyB0aGUg
cXVlc3Rpb24gdG8gNm1hbg0KPiA+Pj4+IGNvcnJlY3RseSwgc28gSSB3aWxsIHJlc3BvbmQgdG8g
aGltLi4uDQo+ID4+Pj4NCj4gPj4+PiBSZWdhcmRzDQo+ID4+Pj4gICAgIEJyaWFuDQo+ID4+Pj4+
IFBhc2NhbA0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gTGUgMTQgYW/Du3QgMjAxNCDDoCAyMjoxOCwgIkJy
aWFuIEUgQ2FycGVudGVyIg0KPiA+Pj4+IDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IGEg
w6ljcml0IDoNCj4gPj4+Pj4+PiBPbiAxNC8wOC8yMDE0IDIyOjI4LCBQYXNjYWwgVGh1YmVydCAo
cHRodWJlcnQpIHdyb3RlOg0KPiA+Pj4+Pj4+IFdlIGNhbiBsaXZlIHdpdGggdGhpcyBCcmlhbiwN
Cj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IGJ1dCB0aGVuIEkgY2FuIHdlIGFkZCBhdCBsZWFzdCBhbiBJ
U0ExMDAuMTFhIG5ldHdvcms/IElTQTEwMC4xMWENCj4gPj4+Pj4+PiB3YXMNCj4gPj4+PiBkZXNp
Z25lZCBpbiAyMDA3LzgsIGFkb3B0ZWQgSVB2NiBhbmQgNkxvV1BBTiwgYW5kIHVzZXMgdGhlIElQ
djYNCj4gPj4+PiBmbG93IGxhYmVsIHRvIGluZGljYXRlIHdoaWNoIGZsb3cgYSBwYWNrZXQgYmVs
b25ncyB0by4NCj4gPj4+Pj4+IEkgaGF2ZSBubyBpZGVhIHdoYXQgSVNBMTAwLjExYSBpcyBvciB3
aGljaCBvcmdhbmlzYXRpb24gZGV2ZWxvcGVkDQo+ID4+Pj4+PiBpdCwgYnV0IGl0IHNvdW5kcyBs
aWtlIGEgdmlvbGF0aW9uIG9mIHRoZSBmbG93IGxhYmVsIHN0YW5kYXJkIGF0DQo+ID4+Pj4+PiB0
aGF0IHRpbWUgKFJGQyAzNjk3KS4gSWYgSSdkIGtub3duIGFib3V0IGl0LCB3ZSB3b3VsZCBwcm9i
YWJseQ0KPiA+Pj4+Pj4gaGF2ZSBpbmNsdWRlZCBpdCBpbiB0aGUgbWVuYWdlcmllIG9mIFJGQyA2
Mjk0Lg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFRoZXJlJ3Mgbm90IG11Y2ggdGhlIElFVEYgY2FuIGRv
IGFib3V0IG90aGVyIG9yZ2FuaXNhdGlvbnMgdGhhdA0KPiA+Pj4+Pj4gbWlzdXNlIG91ciBzdGFu
ZGFyZHMsIGFsdGhvdWdoIGluZGVlZCB3ZSBzb21ldGltZXMgbmVlZCB0bw0KPiA+PiBkb2N1bWVu
dA0KPiA+Pj4+Pj4gc3VjaCBjYXNlcy4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAgIEJyaWFuDQo+ID4+
Pj4+Pg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEluIG1vcmUgZGV0YWlscywgZGV2aWNlcyBhcmUgcHJv
dmlzaW9uZWQgd2l0aCBwZXItZmxvdyBiZWhhdmlvcg0KPiA+Pj4+Pj4gKGluY2x1ZGluZw0KPiA+
Pj4+IHJvdXRpbmcpIGFuZCBzZXR0aW5ncyBpbiB3aGF0IGlzIGNhbGxlZCBhIGNvbnRyYWN0Lg0K
PiA+Pj4+Pj4gVGhlIGNvbnRyYWN0SUQgaXMgY2FycmllZCBpbiB0aGUgSVB2NiBmbG93IGxhYmVs
Lg0KPiA+Pj4+Pj4+IElmIHNvIHNob3VsZCB3ZSBuYW1lIElTQTEwMCBzcGVjaWZpY2FsbHkgb3Ig
dXNlIGEgbW9yZSB2YWd1ZQ0KPiA+Pj4+Pj4+IGRlc2NyaXB0aW9uDQo+ID4+Pj4gbGlrZSBhICJS
UEwgb3Igc2ltaWxhciBMTE4gZG9tYWluIg0KPiA+Pj4+Pj4+IFdlJ2xsIG5vdGUgdGhhdCByZXNl
dHRpbmcgYW4gZmxvdyBsYWJlbCB0aGF0IGNvbWVzIGZyb20gdGhlDQo+ID4+Pj4+Pj4gSW50ZXJu
ZXQgaXMgYSBnZW5lcmljIG5lZWQgaXMgdGhhdCBmbG93IGxhYmVsIHdhcyBzZXQgYWNjb3JkaW5n
DQo+ID4+Pj4+Pj4gdG8gNjQzNywgY2Fubm90IGJlIHRydXN0ZWQgdG8gYmUgdW50ZW1wZXJlZCB3
aXRoLA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gQ2hlZXJzLA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4g
UGFzY2FsDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KPiA+Pj4+Pj4+PiBGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGll
dGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gRQ0KPiA+Pj4+Pj4+PiBDYXJwZW50ZXINCj4gPj4+
Pj4+Pj4gU2VudDogbWVyY3JlZGkgMTMgYW/Du3QgMjAxNCAyMjo1Mw0KPiA+Pj4+Pj4+PiBUbzog
UGhpbGlwIExldmlzDQo+ID4+Pj4+Pj4+IENjOiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBM
b3NzeSBuZXR3b3JrczsgSW5lcyBSb2JsZXM7DQo+ID4+Pj4+Pj4+IDZtYW4gV0c7IDZsb0BpZXRm
Lm9yZyBXRw0KPiA+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW1JvbGxdIFs2bG9dIFdHTEMgZm9yDQo+
ID4+Pj4+Pj4+IGRyYWZ0LXRodWJlcnQtNm1hbi1mbG93LWxhYmVsLWZvci1ycGwtMDMNCj4gPj4+
Pj4+Pj4NCj4gPj4+Pj4+Pj4+IE9uIDE0LzA4LzIwMTQgMDc6MDcsIFBoaWxpcCBMZXZpcyB3cm90
ZToNCj4gPj4+Pj4+Pj4+IE9uIEF1ZyAxMywgMjAxNCwgYXQgOTo0OCBBTSwgUGFzY2FsIFRodWJl
cnQgKHB0aHViZXJ0KQ0KPiA+Pj4+Pj4+PiA8cHRodWJlcnRAY2lzY28uY29tPiB3cm90ZToNCj4g
Pj4+Pj4+Pj4+PiBJZiB0aGlzIGRyYWZ0IGlzIG5vdCBhZG9wdGVkLCB0aGUgZmxvdyBsYWJlbCBm
cm9tIExMTiB3aWxsDQo+ID4+Pj4+Pj4+Pj4gcHJvYmFibHkgc3RheSBhbGwNCj4gPj4+Pj4+Pj4g
emVyb2VzIGFzIGl0IGlzIHRvZGF5IGFuZCB0aGUgZ29hbCBvZiA2NDM3IHdpbGwgbm90IGJlIGFj
aGlldmVkLg0KPiA+Pj4+Pj4+Pj4gUGFzY2FsLCBJJ20gdHJ5aW5nIHRvIHJlY29uY2lsZSB5b3Vy
IGNsYWltIHRoYXQgdGhlIGdvYWwgb2YNCj4gPj4+Pj4+Pj4+IDY0MzcgaXMgdG8gYWxsb3cgZW5j
bG9zZWQgbmV0d29ya3MgdG8gdXNlIHRoZSBmbG93IGxhYmVsIHdpdGgNCj4gPj4+Pj4+Pj4+IEJy
aWFuJ3Mgc3RhdGVtZW50DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4+IEFjdHVhbGx5IHRoYXQn
cyB3aHkgSSBkb24ndCB3YW50IHRvIHNlZSBhIGZvcm1hbCB1cGRhdGUgdG8NCj4gPj4+Pj4+Pj4+
PiA2NDM3LCBiZWNhdXNlIHRoZSBvbmx5IHJhdGlvbmFsIHVwZGF0ZSB3b3VsZCBiZSB0byBhbGxv
dyBhbnkNCj4gPj4+Pj4+Pj4+PiBjbG9zZWQgZG9tYWluIHRvIGludmVudCBpdHMgb3duIHVzYWdl
LiBXZSBoYWQgdGhhdCBhcmd1bWVudA0KPiA+Pj4+Pj4+Pj4+IGF0IGxlbmd0aCBkdXJpbmcgdGhl
IGRldmVsb3BtZW50IG9mIDY0MzcsIGFuZCBkZWNpZGVkIGFnYWluc3QNCj4gaXQuDQo+ID4+Pj4+
Pj4+PiBQaGlsDQo+ID4+Pj4+Pj4+IFJpZ2h0LiBJJ20gZHJhd2luZyBhIHZlcnkgc3VidGxlIGxp
bmUgYmV0d2VlbiAoYSkgc3RhdGluZyBhbg0KPiA+Pj4+Pj4+PiBleGNlcHRpb24gdG8gNjQzNyBm
b3IgdGhpcyBwYXJ0aWN1bGFyIHVzYWdlIGFuZCAoYikgb3BlbmluZyB0aGUNCj4gPj4+Pj4+Pj4g
ZG9vciB0byBvdGhlciB1c2FnZXMuIFNpbmNlIDZtYW4gY2xlYXJseSBkaWRuJ3Qgd2FudCAoYikg
ZHVyaW5nDQo+ID4+Pj4+Pj4+IHRoZSBkZXZlbG9wbWVudCBvZg0KPiA+Pj4+Pj4+PiA2NDM3IEkg
dGhpbmsgd2UgZG8gbmVlZCB0byBsaW1pdCBvdXJzZWx2ZXMgdG8gKGEpLg0KPiA+Pj4+Pj4+Pg0K
PiA+Pj4+Pj4+PiAgICBCcmlhbg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiAtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+
Pj4+Pj4gLS0NCj4gPj4+Pj4+Pj4gLS0NCj4gPj4+Pj4+Pj4gLSBJRVRGIElQdjYgd29ya2luZyBn
cm91cCBtYWlsaW5nIGxpc3QgaXB2NkBpZXRmLm9yZw0KPiA+Pj4+Pj4+PiBBZG1pbmlzdHJhdGl2
ZQ0KPiA+Pj4+Pj4+PiBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9pcHY2DQo+ID4+Pj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4+Pj4+PiAtLQ0KPiA+Pj4+Pj4+PiAt
LQ0KPiA+Pj4+Pj4+PiAtDQo+ID4NCg0K


From nobody Tue Aug 26 09:57:17 2014
Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A4A1A02F8 for <ipv6@ietfa.amsl.com>; Tue, 26 Aug 2014 09:57:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.322
X-Spam-Level: **
X-Spam-Status: No, score=2.322 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 0lLXCXqWKSDx for <ipv6@ietfa.amsl.com>; Tue, 26 Aug 2014 09:57:15 -0700 (PDT)
Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33721A0193 for <ipv6@ietf.org>; Tue, 26 Aug 2014 09:57:14 -0700 (PDT)
Received: by mail-we0-f181.google.com with SMTP id k48so15079406wev.12 for <ipv6@ietf.org>; Tue, 26 Aug 2014 09:57:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:date:message-id:subject:from:to:cc:content-type;  bh=N4vWYTXVbsFp7+oprhaRAE74RZCNvOs1Ki/ImTA46cs=; b=wRo51YnCaXtunBYR9kgQkVrzWvbiBXVeSwuzCZyLWlIRMuGnSDM+JbS0agUxZ2OHhV hcxjAVY6YHV5BcFeYGuNLYbJGxhDV3pXer9n8XkUcDjt3fl29X7ECyfAqHu/ez3cr6o1 Xu92DzbJGPqxni8TcmNdtmc0NElxbHxmh3T/I8ojkxxfNC02UMSttXij4UhQxXrVI8Re 6OeqEXC7Mmo+23QytQuA5uOG3J81jT3Fx9LWxLUwxqPuLKwN/TmZss478lpvIOycJc7C MaM9NMlnheQuUrloJObLZmcNfzPsMfCNFQZH2Cwi/DA3Hf/VAxgWWNU2KzPmS7Qr3JHX TvjQ==
MIME-Version: 1.0
X-Received: by 10.180.80.133 with SMTP id r5mr22523257wix.62.1409072233192; Tue, 26 Aug 2014 09:57:13 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.123.164 with HTTP; Tue, 26 Aug 2014 09:57:13 -0700 (PDT)
Date: Tue, 26 Aug 2014 09:57:13 -0700
X-Google-Sender-Auth: M4ZtV1vWm37MPsD-IMwRpNY4pg4
Message-ID: <CAJE_bqfdOZi6U2AqUx3k9kUi_fO1=sNW-k_3b4Kg4Oy2qZdSrA@mail.gmail.com>
Subject: Re: draft-gont-6man-nd-opt-validation-00
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
To: Ronald Bonica <rbonica@juniper.net>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/wMVvFSEHtRwk4SmRtPnHuPMTukM
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Aug 2014 16:57:16 -0000

At Thu, 21 Aug 2014 18:41:07 +0000,
Ronald Bonica <rbonica@juniper.net> wrote:

> As instructed by the WG, Fernando and I have expanded the scope of draft- gont-6man-lla-opt-validation to include validation rules for all options used in all ND messages. The new document is called draft-gont-6man-nd-opt- valdation-00.

This should be "validation" ('i' is missing).  Same typo in the
message subject, which I've corrected.

> Please take a look at the draft. Tell us if we have done what the WG requested.

I don't know (or remember) precisely what the "WG requested", so I
can't say anything about it.  I have some comments on the draft
nevertheless:

- I previously commented on lla-opt-validation:
  http://www.ietf.org/mail-archive/web/ipv6/current/msg20389.html
  and I thought we agreed on some updates from that discussion.  But
  it looks like these points have been completely dropped in nd-opt-validation.
  Was that my misunderstanding about the result of the previous
  discussion, or is nd-opt-validation a completely new document mostly
  unrelated to the previous discussion, or something else?

- Related to the previous point, IIRC lla-opt-validation discusses the
  rationale of the validation, but nd-opt-validation generally only
  lists the validations.  Is this change intentional?

- Some of the described validation seem to come from the original
  specification (mostly RFC4861), while some others seem to be newly
  proposed.  I'd like the draft to clarify which ones are the
  former/latter.

- Maybe related to some of the previous bullet points, some of the
  proposed validations (which generally seem to be newly proposed
  ones?) require the entire ND message be dropped if a certain
  validation fails while some others just require that particular
  option be dropped, and it doesn't explain why the former case should
  be handled differently.  I'd at least like to see the rationale, and
  in general it seems to be against the sense of Section 9 of RFC
  4861.

- Section 5: what's the source of this restriction?

   The Prefix Length is an 8-bit unsigned integer that specifies the
   prefix length (i.e., the number of leading bits in the Prefix field
   that are significant).  Its value MUST be greater than or equal to
   32.

- Section 5: is this adjustment a new proposal of this draft or an
  existing one? (If it's the latter I should have missed something).
  And in any case I'm not sure if it really makes sense.  Especially
  if this is a new proposal I'd like to see more discussion on why we
  need this:

   Host SHOULD set the effective Valid Lifetime as follows:

           EffectiveVL = max(Valid Lifetime, MIN_VALID_LIFETIME)

   Where EffectiveVL is the effective 'Valid Lifetime', and
   MIN_VALID_LIFETIME is set to 1800 (seconds).

- Section 5: I think we should be more precise here:

   As stated in [RFC4861] the Preferred Lifetime MUST BE less than or
   equal to the Valid Lifetime.  If an incoming ND message does not pass
   this validation check, the Prefix Information Option MUST be ignored.

  Preferred Lifetime is only used for stateless address
  autoconfiguration, so when we say "PIO MUST be ignored" we should be
  clear whether it's in terms of on-link determination or SAAC.  In
  the context of the latter, RFC 4862 explicitly requires such PIO be
  ignored.  In the context of the former, this is certainly odd but
  doesn't do any actual harm.  So, if the intent is the latter, I'd
  like to see the rationale, just for the sake of paranoia, etc.

- Section 10: it's odd to me that it specifically covers the first two
  bits (of the first byte) of a label in that there are other forms of
  invalid wire format for domain names (e.g., it can't be longer than
  255 octet).

   The domain suffixes included in this option MUST be encoded with the
   simple encoding specified in Section 3.1 of [RFC1035].  Therefore, if
   any of the labels of a domain does not have the first two bits set to
   zero, the corresponding DNSSL option MUST be ignored.

  So I'd suggest revising the second sentence to more generic,
  e.g. "Therefore, if the encoded data are not a valid non-compressed
  form of domain name, the corresponding DNSSL option MUST be
  ignored."

- Editorial nits
  + Section 4: s/an/a/ (there are other instances of this type of typo)
   message contains an TLLA Option, the TLLA Option MUST be ignored.
  + Section 5: s/BE/be/ (ditto)
   The Length field MUST BE set to 4.  If an incoming ND message does

--
JINMEI, Tatuya


From nobody Tue Aug 26 13:03:18 2014
Return-Path: <Richard.Kelsey@silabs.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6D71A0252; Tue, 26 Aug 2014 13:03:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 xX7XKxzfcmVC; Tue, 26 Aug 2014 13:02:53 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5920B1A8769; Tue, 26 Aug 2014 13:02:44 -0700 (PDT)
Received: from BLUPR07MB611.namprd07.prod.outlook.com (10.141.207.16) by BLUPR07MB610.namprd07.prod.outlook.com (10.141.207.15) with Microsoft SMTP Server (TLS) id 15.0.1015.17; Tue, 26 Aug 2014 20:02:29 +0000
Received: from BLUPR07MB611.namprd07.prod.outlook.com ([10.141.207.16]) by BLUPR07MB611.namprd07.prod.outlook.com ([10.141.207.16]) with mapi id 15.00.1015.017; Tue, 26 Aug 2014 20:02:28 +0000
From: Richard Kelsey <Richard.Kelsey@silabs.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>, "Brian E Carpenter" <brian.e.carpenter@gmail.com>
Subject: RE: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [Roll] [6lo] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: Ac++CEw2ncG58gG1qkm9oMVdmX2ItgAdxngAAICihoAAOXaTGA==
Date: Tue, 26 Aug 2014 20:02:28 +0000
Message-ID: <8ed59484d41d44649bcc5e1150a1daef@BLUPR07MB611.namprd07.prod.outlook.com>
References: <E045AECD98228444A58C61C200AE1BD842D503B7@xmb-rcd-x01.cisco.com> <53F8057C.9080904@gmail.com>, <E045AECD98228444A58C61C200AE1BD842D58843@xmb-rcd-x01.cisco.com>
In-Reply-To: <E045AECD98228444A58C61C200AE1BD842D58843@xmb-rcd-x01.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [173.48.207.178]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;
x-forefront-prvs: 03152A99FF
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199003)(377454003)(51704005)(189002)(66066001)(19580405001)(2656002)(99286002)(4396001)(19580395003)(83322001)(76176999)(80022001)(95666004)(81342001)(64706001)(21056001)(85852003)(87936001)(50986999)(99396002)(90102001)(106356001)(105586002)(31966008)(33646002)(79102001)(230783001)(20776003)(107046002)(76482001)(81542001)(74662001)(74502001)(83072002)(85306004)(74316001)(46102001)(92566001)(76576001)(108616004)(86362001)(101416001)(77982001)(54356999)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR07MB610; H:BLUPR07MB611.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: silabs.com
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/MWqG5lMD6P9xnjSL-aa3902SyXk
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, Ines Robles <mariainesrobles@googlemail.com>, 6man WG <ipv6@ietf.org>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Aug 2014 20:03:03 -0000

> From: Pascal Thubert (pthubert) [pthubert@cisco.com]
> Sent: Monday, August 25, 2014 12:30 PM
>=20
> I understand, Brian:
>
> It makes sense to propose a generic rule and try it on the real
> world. But it is not surprising that such a bold approach fails to
> be universal when confronted to the real world.  To be very clear on
> the need for 6MAN to take our responsibilities, I added text to
> clarify that 6437 as of today is dramatically counterproductive for
> the development of IPv6 in LLNs.

Pascal,

Hold on a second.  First of all, not everyone doing IPv6 in LLNs
is using RPL.  Second of all, not everyone using RPL in LLNs is
particularly hindered by the overhead of using RFC 6553.  And finally,
Carsten's suggested 6lo encoding of the RPL Option arguably has
better properties than using the flow label and is definitely not
"dramatically" worse.

Personally, I think using the flow label in this way is a very bad
idea.  The games that are played within an LLN to make IPv6 work there
need to be invisible to the rest of the Internet.  Universal rules
are what its all about.

                               -Richard Kelsey



From nobody Tue Aug 26 13:05:35 2014
Return-Path: <internet-drafts@ietf.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358991A87AF; Tue, 26 Aug 2014 13:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 uaitGEkO4FW3; Tue, 26 Aug 2014 13:05:19 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6D01A8772; Tue, 26 Aug 2014 13:05:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action: draft-ietf-6man-why64-03.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 5.6.2.p5
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140826200518.16567.90360.idtracker@ietfa.amsl.com>
Date: Tue, 26 Aug 2014 13:05:18 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/mHQf7esYqkQbEfY3PZxgjfhQg64
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Aug 2014 20:05:25 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

        Title           : Analysis of the 64-bit Boundary in IPv6 Addressing
        Authors         : Brian Carpenter
                          Tim Chown
                          Fernando Gont
                          Sheng Jiang
                          Alexandru Petrescu
                          Andrew Yourtchenko
	Filename        : draft-ietf-6man-why64-03.txt
	Pages           : 24
	Date            : 2014-08-26

Abstract:
   The IPv6 unicast addressing format includes a separation between the
   prefix used to route packets to a subnet and the interface identifier
   used to specify a given interface connected to that subnet.
   Currently the interface identifier is defined as 64 bits long for
   almost every case, leaving 64 bits for the subnet prefix.  This
   document describes the advantages of this fixed boundary and analyses
   the issues that would be involved in treating it as a variable
   boundary.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6man-why64/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-6man-why64-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-why64-03


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

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


From nobody Tue Aug 26 13:19:02 2014
Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1505E1A87E3; Tue, 26 Aug 2014 13:18:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level: 
X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 uZo-Lw_ci-Xj; Tue, 26 Aug 2014 13:18:57 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3AC1A87E1; Tue, 26 Aug 2014 13:18:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1894; q=dns/txt; s=iport; t=1409084337; x=1410293937; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gShpDtW+2BWsJIdJ2Xn2dMstXfHQKA/nzEok5ixEgT0=; b=fo+5xdJzrKs2Gll+PTr1v2t0epzOwROew966LJKBF69E9iN/44OIXmM2 XfpNK4m4rW4vz56IrVReYFqirkxFD1A8KNTalkxVIa/RBLqbyXAj23Si0 RUKvpOclmWZGnDlwCRpzct2cIbFsUraJIm66/0lPt1t3+UpYrvh7pc7R/ Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AigFAM7q/FOtJV2Z/2dsb2JhbABbgw1TV8xTCodMAYEXFneEAwEBAQMBAQEBawsQAgEIFQEwJwslAgQOBYg6CA2/QhMEjxkzB4MvgR0FimyGQYsnlRSDXmyCTwEBAQ
X-IronPort-AV: E=Sophos;i="5.04,406,1406592000"; d="scan'208";a="350454121"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 26 Aug 2014 20:18:57 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s7QKIuoa026066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 20:18:56 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.236]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 15:18:56 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Richard Kelsey <Richard.Kelsey@silabs.com>
Subject: Re: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Topic: [6lo] [Roll] WGLC for draft-thubert-6man-flow-label-for-rpl-03
Thread-Index: AQHPwWjiidypJfPYN0WvEDAQ9LxuP5vjUxoi
Date: Tue, 26 Aug 2014 20:18:55 +0000
Message-ID: <93C4A100-0DEB-4C3F-99CA-D68298DA5F53@cisco.com>
References: <E045AECD98228444A58C61C200AE1BD842D503B7@xmb-rcd-x01.cisco.com> <53F8057C.9080904@gmail.com>, <E045AECD98228444A58C61C200AE1BD842D58843@xmb-rcd-x01.cisco.com>, <8ed59484d41d44649bcc5e1150a1daef@BLUPR07MB611.namprd07.prod.outlook.com>
In-Reply-To: <8ed59484d41d44649bcc5e1150a1daef@BLUPR07MB611.namprd07.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/CmAz5ckDRKxe0d063nO23qU_ARo
Cc: 6man WG <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, "6lo@ietf.org WG" <6lo@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Aug 2014 20:18:59 -0000

Richard:

Maybe you should read the draft.

I removed all references to my proposal of how to use the Flow label for RP=
L.

What the 6MAN draft is now asking is only the right to manipulate a flow la=
bel in the LLN, RPL or not RPL, be it only to reset it to zero so as to eli=
de it.

The Idea to propose a 6lowpan compression is actually from Laurent and I wa=
s the first on the ML to support it.

Cheers,
Pascal

Le 26 ao=FBt 2014 =E0 22:04, "Richard Kelsey" <Richard.Kelsey@silabs.com> a=
 =E9crit :

>> From: Pascal Thubert (pthubert) [pthubert@cisco.com]
>> Sent: Monday, August 25, 2014 12:30 PM
>>=20
>> I understand, Brian:
>>=20
>> It makes sense to propose a generic rule and try it on the real
>> world. But it is not surprising that such a bold approach fails to
>> be universal when confronted to the real world.  To be very clear on
>> the need for 6MAN to take our responsibilities, I added text to
>> clarify that 6437 as of today is dramatically counterproductive for
>> the development of IPv6 in LLNs.
>=20
> Pascal,
>=20
> Hold on a second.  First of all, not everyone doing IPv6 in LLNs
> is using RPL.  Second of all, not everyone using RPL in LLNs is
> particularly hindered by the overhead of using RFC 6553.  And finally,
> Carsten's suggested 6lo encoding of the RPL Option arguably has
> better properties than using the flow label and is definitely not
> "dramatically" worse.
>=20
> Personally, I think using the flow label in this way is a very bad
> idea.  The games that are played within an LLN to make IPv6 work there
> need to be invisible to the rest of the Internet.  Universal rules
> are what its all about.
>=20
>                               -Richard Kelsey
>=20
>=20
> _______________________________________________
> 6lo mailing list
> 6lo@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo


From nobody Tue Aug 26 13:45:09 2014
Return-Path: <bob.briscoe@bt.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C991A0198 for <ipv6@ietfa.amsl.com>; Tue, 26 Aug 2014 11:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.269
X-Spam-Level: 
X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
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 nT-WKJpCbC0f for <ipv6@ietfa.amsl.com>; Tue, 26 Aug 2014 11:40:08 -0700 (PDT)
Received: from hubrelay-by-03.bt.com (hubrelay-by-03.bt.com [62.7.242.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31C81A0166 for <ipv6@ietf.org>; Tue, 26 Aug 2014 11:40:07 -0700 (PDT)
Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR03-UKBR.bt.com (10.216.161.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 26 Aug 2014 19:40:03 +0100
Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.348.2; Tue, 26 Aug 2014 19:40:05 +0100
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.3.181.6; Tue, 26 Aug 2014 19:39:59 +0100
Received: from BTP075694.jungle.bt.co.uk ([10.109.159.142])	by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s7QIdvmI027117;	Tue, 26 Aug 2014 19:39:58 +0100
Message-ID: <201408261839.s7QIdvmI027117@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 26 Aug 2014 19:39:56 +0100
To: Fernando Gont <fernando@gont.com.ar>
From: Bob Briscoe <bob.briscoe@bt.com>
Subject: Re: Relax draft-gont-6man-deprecate-atomfrag-generation-00
In-Reply-To: <53F4B5AF.3060306@gont.com.ar>
References: <201408201356.s7KDuYc5026764@bagheera.jungle.bt.co.uk> <53F4B5AF.3060306@gont.com.ar>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/i_YGXMB6l4sqCYrI9WAm0x3j4c0
X-Mailman-Approved-At: Tue, 26 Aug 2014 13:45:06 -0700
Cc: ipv6@ietf.org, draft-gont-6man-deprecate-atomfrag-generation@tools.ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Aug 2014 18:40:09 -0000

Fernando,

Your wording is fine by me.

And thx for your and Brian's subsequent emails about what the specs 
say about v6-v4 translators, and Philip's about the practicality.

Cheers


Bob

At 15:50 20/08/2014, Fernando Gont wrote:
>On 08/20/2014 10:56 AM, Bob Briscoe wrote:
> >
> > [I've cc'd ipv6, but I'm not subscribed, so pls include me specifically
> > in any response.]
> >
> > S.4
> > Agree The current 2460 rule creates a vulnerability, but don't agree
> > with [sender] "MUST discard ICMPv6 Packet Too Big" as the remedy. I
> > would prefer "MUST NOT include a Fragment header in subsequent packets",
> > which is the minimum needed to address the actual attack.
>
>BTW, how about replacing the existing:
>
>  "IPv6 nodes MUST discard ICMPv6 Packet Too Big error messages that
>  report a Next-Hop MTU smaller than 1280 bytes (the minimum IPv6
>  MTU)."
>
>with
>
>"An IPv6 node that receives an ICMPv6 Packet Too Big error message that
>reports a Next-Hop MTU smaller than 1280 bytes (the minimum IPv6 MTU)
>MUST NOT include a Fragment header in subsequent packets sent to the
>corresponding destination. That is, IPv6 nodes MUST NOT generate IPv6
>atomic fragments."
>
>?
>
>Thanks!
>
>Best regards,
>--
>Fernando Gont
>e-mail: fernando@gont.com.ar || fgont@si6networks.com
>PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

________________________________________________________________
Bob Briscoe,                                                  BT 


From nobody Wed Aug 27 11:01:56 2014
Return-Path: <fernando@gont.com.ar>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7979B1A0085 for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 11:01:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 drKU9aQV7O_9 for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 11:01:50 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7C51A0035 for <6man@ietf.org>; Wed, 27 Aug 2014 11:01:49 -0700 (PDT)
Received: from 48-136-17-190.fibertel.com.ar ([190.17.136.48] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fernando@gont.com.ar>) id 1XMhXW-0004mt-Ni; Wed, 27 Aug 2014 20:01:46 +0200
Message-ID: <53FE1D07.5060309@gont.com.ar>
Date: Wed, 27 Aug 2014 15:01:43 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "6man@ietf.org" <6man@ietf.org>
Subject: Revision of the IPv6 atomic frag deprecation I-D (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-01.txt)
References: <20140827174304.18733.67331.idtracker@ietfa.amsl.com>
In-Reply-To: <20140827174304.18733.67331.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20140827174304.18733.67331.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/lv-1JI3vIlP6LR07NNLfu_HtuKg
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 18:01:53 -0000

Folks,

We have published a revision of the aforementioned document:
<http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-01.txt>

I'll try to summarize the changes incorporated in this version:

* Section 1 and Section 2 have been augmented to better explain the
rationale for the proposed update -- not just interms of the security
vulnerability being discussed, but also in terms of protocol robustness.

* We have relaxed the update to RFC2460, noting that ICMP PTB<1280
should not elicit atom frags (rather than "these packets should be
dropped"), as suggested by Bob Briscoe

* We have clarified the rationale for relying on IPv6 atom frags as part
of the SIIT design decision.

* We have incorporated an Appendix with a small and non-exhaustive
survey which shows that quite a few widely deployed OSes fail to
generate IPv6 atomic fragments in response to ICMPv6 PTB<1280.

* We have clarified why you cannot simply check the IPv6 Source Address
representing IPv4 nodes as a general mitigation to the vulnerability
discussed in this document. -- this is based on the thread with Tatuya
Jinmei.

* We have included (in Section 6) a formal update to RFC6145, as
suggested by Brian Carpenter. If the working group decides to take on
this document, a second-order decision might be whether to update RFC
2460 and RFC6145 in this doc, or just focus on atom frag generation
here, and do a complete RFC6145bis in a separate document. The whole
Section 6 is mostly meant as "this is what one should patch in RFC6145
such that it does not rely on IPv6 atomic fragments". However, we note
that the core of this document is really all Sections other than Section
6, since those are the ones providing the rationale for deprecating the
generation of IPv6 atomic fragments.


Please do let us know if we have missed anything, if there's anything
that needs further clarification, or if you like the I-D as is.

Thanks so much!
Fernando (and co-authors)




-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-6man-deprecate-atomfrag-generation-01.txt
Date: Wed, 27 Aug 2014 10:43:04 -0700
From: internet-drafts@ietf.org
To: Will(Shucheng) Liu <liushucheng@huawei.com>, Shucheng LIU (Will)
<liushucheng@huawei.com>, Tore Anderson <tore@redpill-linpro.com>, Tore
Anderson <tore@redpill-linpro.com>, Fernando Gont
<fgont@si6networks.com>, Fernando Gont <fgont@si6networks.com>


A new version of I-D, draft-gont-6man-deprecate-atomfrag-generation-01.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-6man-deprecate-atomfrag-generation
Revision:	01
Title:		Deprecating the Generation of IPv6 Atomic Fragments
Document date:	2014-08-27
Group:		Individual Submission
Pages:		17
URL:
http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-01.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-6man-deprecate-atomfrag-generation/
Htmlized:
http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-gont-6man-deprecate-atomfrag-generation-01

Abstract:
   The core IPv6 specification requires that when a host receives an
   ICMPv6 "Packet Too Big" message reporting a "Next-Hop MTU" smaller
   than 1280, the host includes a Fragment Header in all subsequent
   packets sent to that destination, without reducing the assumed Path-
   MTU.  The simplicity with which ICMPv6 "Packet Too Big" messages can
   be forged, coupled with the widespread filtering of IPv6 fragments,
   results in an attack vector that can be leveraged for Denial of
   Service purposes.  This document briefly discusses the aforementioned
   attack vector, and formally updates RFC2460 such that generation of
   IPv6 atomic fragments is deprecated, thus eliminating the
   aforementioned attack vector.  Additionally, it formally updates
   RFC6145 such that the Stateless IP/ICMP Translation Algorithm (SIIT)
   does not rely on the generation of IPv6 atomic fragments, thus
   improving the robustness of the protocol.





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

The IETF Secretariat





-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1




From nobody Wed Aug 27 11:52:11 2014
Return-Path: <rbonica@juniper.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C056D1A6F11 for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 11:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.702
X-Spam-Level: 
X-Spam-Status: No, score=-101.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 pFg-F6A66eOf for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 11:52:01 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3AA11A00F5 for <ipv6@ietf.org>; Wed, 27 Aug 2014 11:51:53 -0700 (PDT)
Received: from CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Wed, 27 Aug 2014 18:51:44 +0000
Received: from CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.216]) by CO1PR05MB442.namprd05.prod.outlook.com ([169.254.13.216]) with mapi id 15.00.1010.016; Wed, 27 Aug 2014 18:51:44 +0000
From: Ronald Bonica <rbonica@juniper.net>
To: =?utf-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Subject: RE: draft-gont-6man-nd-opt-validation-00
Thread-Topic: draft-gont-6man-nd-opt-validation-00
Thread-Index: AQHPwU7LyXrFQpLhm0KQSRdsRla2ZpvkxNsQ
Date: Wed, 27 Aug 2014 18:51:44 +0000
Message-ID: <1ac4ed99b2024cefb2a0dc24fd0fa7c4@CO1PR05MB442.namprd05.prod.outlook.com>
References: <CAJE_bqfdOZi6U2AqUx3k9kUi_fO1=sNW-k_3b4Kg4Oy2qZdSrA@mail.gmail.com>
In-Reply-To: <CAJE_bqfdOZi6U2AqUx3k9kUi_fO1=sNW-k_3b4Kg4Oy2qZdSrA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [66.129.241.10]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;
x-forefront-prvs: 0316567485
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(24454002)(377454003)(13464003)(199003)(189002)(20776003)(33646002)(74662001)(83072002)(77096002)(110136001)(21056001)(76176999)(31966008)(85306004)(74316001)(99396002)(80022001)(66066001)(50986999)(81542001)(2656002)(46102001)(92566001)(83322001)(15975445006)(87936001)(101416001)(86362001)(99286002)(106116001)(90102001)(19580395003)(4396001)(105586002)(107046002)(561944003)(106356001)(64706001)(54356999)(76482001)(15202345003)(230783001)(79102001)(76576001)(19580405001)(81342001)(95666004)(108616004)(85852003)(77982001)(74502001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB442; H:CO1PR05MB442.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/xIjRhk2kD5Dimfg56IhhDauj5Yc
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 18:52:02 -0000

SmlubWVpLA0KDQpBcyBhbHdheXMsIHRoYW5rcyBmb3IgeW91ciB0aG91Z2h0ZnVsIHJldmlldy4g
Q29tbWVudHMgaW5saW5lLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24NCg0K
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGppbm1laS50YXR1eWFAZ21h
aWwuY29tIFttYWlsdG86amlubWVpLnRhdHV5YUBnbWFpbC5jb21dIE9uIEJlaGFsZg0KPiBPZiA/
Pz8/DQo+IFNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAyNiwgMjAxNCAxMjo1NyBQTQ0KPiBUbzogUm9u
YWxkIEJvbmljYQ0KPiBDYzogaXB2NkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogZHJhZnQtZ29u
dC02bWFuLW5kLW9wdC12YWxpZGF0aW9uLTAwDQo+IA0KPiBBdCBUaHUsIDIxIEF1ZyAyMDE0IDE4
OjQxOjA3ICswMDAwLA0KPiBSb25hbGQgQm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0PiB3cm90
ZToNCj4gDQo+ID4gQXMgaW5zdHJ1Y3RlZCBieSB0aGUgV0csIEZlcm5hbmRvIGFuZCBJIGhhdmUg
ZXhwYW5kZWQgdGhlIHNjb3BlIG9mDQo+IGRyYWZ0LSBnb250LTZtYW4tbGxhLW9wdC12YWxpZGF0
aW9uIHRvIGluY2x1ZGUgdmFsaWRhdGlvbiBydWxlcyBmb3IgYWxsIG9wdGlvbnMNCj4gdXNlZCBp
biBhbGwgTkQgbWVzc2FnZXMuIFRoZSBuZXcgZG9jdW1lbnQgaXMgY2FsbGVkIGRyYWZ0LWdvbnQt
Nm1hbi1uZC0NCj4gb3B0LSB2YWxkYXRpb24tMDAuDQo+IA0KPiBUaGlzIHNob3VsZCBiZSAidmFs
aWRhdGlvbiIgKCdpJyBpcyBtaXNzaW5nKS4gIFNhbWUgdHlwbyBpbiB0aGUgbWVzc2FnZSBzdWJq
ZWN0LA0KPiB3aGljaCBJJ3ZlIGNvcnJlY3RlZC4NCj4gDQo+ID4gUGxlYXNlIHRha2UgYSBsb29r
IGF0IHRoZSBkcmFmdC4gVGVsbCB1cyBpZiB3ZSBoYXZlIGRvbmUgd2hhdCB0aGUgV0cNCj4gcmVx
dWVzdGVkLg0KPiANCj4gSSBkb24ndCBrbm93IChvciByZW1lbWJlcikgcHJlY2lzZWx5IHdoYXQg
dGhlICJXRyByZXF1ZXN0ZWQiLCBzbyBJIGNhbid0DQo+IHNheSBhbnl0aGluZyBhYm91dCBpdC4g
IEkgaGF2ZSBzb21lIGNvbW1lbnRzIG9uIHRoZSBkcmFmdA0KPiBuZXZlcnRoZWxlc3M6DQo+IA0K
PiAtIEkgcHJldmlvdXNseSBjb21tZW50ZWQgb24gbGxhLW9wdC12YWxpZGF0aW9uOg0KPiAgIGh0
dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pcHY2L2N1cnJlbnQvbXNnMjAzODku
aHRtbA0KPiAgIGFuZCBJIHRob3VnaHQgd2UgYWdyZWVkIG9uIHNvbWUgdXBkYXRlcyBmcm9tIHRo
YXQgZGlzY3Vzc2lvbi4gIEJ1dA0KPiAgIGl0IGxvb2tzIGxpa2UgdGhlc2UgcG9pbnRzIGhhdmUg
YmVlbiBjb21wbGV0ZWx5IGRyb3BwZWQgaW4gbmQtb3B0LQ0KPiB2YWxpZGF0aW9uLg0KPiAgIFdh
cyB0aGF0IG15IG1pc3VuZGVyc3RhbmRpbmcgYWJvdXQgdGhlIHJlc3VsdCBvZiB0aGUgcHJldmlv
dXMNCj4gICBkaXNjdXNzaW9uLCBvciBpcyBuZC1vcHQtdmFsaWRhdGlvbiBhIGNvbXBsZXRlbHkg
bmV3IGRvY3VtZW50IG1vc3RseQ0KPiAgIHVucmVsYXRlZCB0byB0aGUgcHJldmlvdXMgZGlzY3Vz
c2lvbiwgb3Igc29tZXRoaW5nIGVsc2U/DQo+IA0KPiAtIFJlbGF0ZWQgdG8gdGhlIHByZXZpb3Vz
IHBvaW50LCBJSVJDIGxsYS1vcHQtdmFsaWRhdGlvbiBkaXNjdXNzZXMgdGhlDQo+ICAgcmF0aW9u
YWxlIG9mIHRoZSB2YWxpZGF0aW9uLCBidXQgbmQtb3B0LXZhbGlkYXRpb24gZ2VuZXJhbGx5IG9u
bHkNCj4gICBsaXN0cyB0aGUgdmFsaWRhdGlvbnMuICBJcyB0aGlzIGNoYW5nZSBpbnRlbnRpb25h
bD8NCj4gDQpbUlBCXSANClRoZSBpbnRlbnQgb2YgdGhlIGRvY3VtZW50IGhhcyBjaGFuZ2VkIHNs
aWdodGx5LiBEcmFmdC0gZ29udC02bWFuLWxsYS1vcHQtdmFsaWRhdGlvbiBkZXNjcmliZWQgc2V2
ZXJhbCBORCB2dWxuZXJhYmlsaXRpZXMuIEl0IGFsc28gcHJvcG9zZWQgdmFsaWRhdGlvbnMgdGhh
dCBpbXBsZW1lbnRhdGlvbnMgY291bGQgaW1wb3NlIHVwb24gdGhlIFNMTEEgYW5kIFRMTEEgb3B0
aW9ucyB0byBtaXRpZ2F0ZSB0aGUgdnVsbmVyYWJpbGl0aWVzLg0KDQogQXQgSUVURiA4OSwgdGhl
IFdHIGluc3RydWN0ZWQgdGhlIGF1dGhvcnMgdG8gZXhwYW5kIHRoZSBzY29wZSBvZiB0aGUgZG9j
dW1lbnQuIFRoZSBuZXcgZG9jdW1lbnQgKGRyYWZ0LWdvbnQtNm1hbi1uZC1vcHQtdmFsaWRhdGlv
bikgZGVzY3JpYmVzIGFsbCB2YWxpZGF0aW9ucyB0aGF0IGFuIGltcGxlbWVudGF0aW9uIHNob3Vs
ZCBlbmZvcmNlIHVwb24gYWxsIE5EIG9wdGlvbnMuIFRoZXNlIHZhbGlkYXRpb25zIGFyZSBhIHN1
cGVyc2V0IG9mIHRoZSB2YWxpZGF0aW9ucyBkZXNjcmliZWQgaW4gZHJhZnQtIGdvbnQtNm1hbi1s
bGEtb3B0LXZhbGlkYXRpb24uDQoNCldoaWxlIHRoZSB0d28gdmFsaWRhdGlvbnMgZGVzY3JpYmVk
IGluIGRyYWZ0LSBnb250LTZtYW4tbGxhLW9wdC12YWxpZGF0aW9uIGFyZSBhc3NvY2lhdGVkIHdp
dGggdnVsbmVyYWJpbGl0aWVzLCBtYW55IG9mIHRoZSBuZXcgdmFsaWRhdGlvbnMgYXJlIG5vdC4g
U28sIHdlIGRyb3BwZWQgZGlzY3Vzc2lvbiBvZiB0aGUgdHdvIHZ1bG5lcmFiaWxpdGllcyBkZXNj
cmliZWQgaW4gZHJhZnQtIGdvbnQtNm1hbi1sbGEtb3B0LXZhbGlkYXRpb24uIEluIHJldHJvc3Bl
Y3QsIEkgZG9uJ3QgdGhpbmsgdGhhdCB3YXMgYSB2ZXJ5IGdvb2QgaWRlYS4NCg0KSW4gdGhlIG5l
eHQgcmV2aXNpb24sIHdlIHdpbGwgYWRkIGFuIGFwcGVuZGl4IGRlc2NyaWJpbmcgdGhlIHR3byBr
bm93biB2dWxuZXJhYmlsaXRpZXMuIFdlIHdpbGwgaW1wb3J0IHRoYXQgdGV4dCBmcm9tIHRoZSBv
bGQgZG9jdW1lbnQuDQoNCj4gLSBTb21lIG9mIHRoZSBkZXNjcmliZWQgdmFsaWRhdGlvbiBzZWVt
IHRvIGNvbWUgZnJvbSB0aGUgb3JpZ2luYWwNCj4gICBzcGVjaWZpY2F0aW9uIChtb3N0bHkgUkZD
NDg2MSksIHdoaWxlIHNvbWUgb3RoZXJzIHNlZW0gdG8gYmUgbmV3bHkNCj4gICBwcm9wb3NlZC4g
IEknZCBsaWtlIHRoZSBkcmFmdCB0byBjbGFyaWZ5IHdoaWNoIG9uZXMgYXJlIHRoZQ0KPiAgIGZv
cm1lci9sYXR0ZXIuDQoNCltSUEJdIA0KSW4gdGhlIG5leHQgcmV2aXNpb24sIHdlIHdpbGwgaWRl
bnRpZnkgdmFsaWRhdGlvbnMgdGhhdCB3ZXJlIGNhcnJpZWQgZm9yd2FyZCBmcm9tIHByZXZpb3Vz
IFJGQ3MNCg0KPiANCj4gLSBNYXliZSByZWxhdGVkIHRvIHNvbWUgb2YgdGhlIHByZXZpb3VzIGJ1
bGxldCBwb2ludHMsIHNvbWUgb2YgdGhlDQo+ICAgcHJvcG9zZWQgdmFsaWRhdGlvbnMgKHdoaWNo
IGdlbmVyYWxseSBzZWVtIHRvIGJlIG5ld2x5IHByb3Bvc2VkDQo+ICAgb25lcz8pIHJlcXVpcmUg
dGhlIGVudGlyZSBORCBtZXNzYWdlIGJlIGRyb3BwZWQgaWYgYSBjZXJ0YWluDQo+ICAgdmFsaWRh
dGlvbiBmYWlscyB3aGlsZSBzb21lIG90aGVycyBqdXN0IHJlcXVpcmUgdGhhdCBwYXJ0aWN1bGFy
DQo+ICAgb3B0aW9uIGJlIGRyb3BwZWQsIGFuZCBpdCBkb2Vzbid0IGV4cGxhaW4gd2h5IHRoZSBm
b3JtZXIgY2FzZSBzaG91bGQNCj4gICBiZSBoYW5kbGVkIGRpZmZlcmVudGx5LiAgSSdkIGF0IGxl
YXN0IGxpa2UgdG8gc2VlIHRoZSByYXRpb25hbGUsIGFuZA0KPiAgIGluIGdlbmVyYWwgaXQgc2Vl
bXMgdG8gYmUgYWdhaW5zdCB0aGUgc2Vuc2Ugb2YgU2VjdGlvbiA5IG9mIFJGQw0KPiAgIDQ4NjEu
DQpbUlBCXSANCldlIHdpbGwgYWxzbyBjYXRjaCB0aGlzIGluIHRoZSBuZXh0IHJldmlzaW9uLg0K
PiANCj4gLSBTZWN0aW9uIDU6IHdoYXQncyB0aGUgc291cmNlIG9mIHRoaXMgcmVzdHJpY3Rpb24/
DQo+IA0KPiAgICBUaGUgUHJlZml4IExlbmd0aCBpcyBhbiA4LWJpdCB1bnNpZ25lZCBpbnRlZ2Vy
IHRoYXQgc3BlY2lmaWVzIHRoZQ0KPiAgICBwcmVmaXggbGVuZ3RoIChpLmUuLCB0aGUgbnVtYmVy
IG9mIGxlYWRpbmcgYml0cyBpbiB0aGUgUHJlZml4IGZpZWxkDQo+ICAgIHRoYXQgYXJlIHNpZ25p
ZmljYW50KS4gIEl0cyB2YWx1ZSBNVVNUIGJlIGdyZWF0ZXIgdGhhbiBvciBlcXVhbCB0bw0KPiAg
ICAzMi4NCltSUEJdIA0KSSB0aG91Z2h0IHRoYXQgdGhpcyB2YWxpZGF0aW9uIG1pZ2h0IGJlIGEg
bGl0dGxlIGNvbnRyb3ZlcnNpYWwgOy0pDQoNCkl0J3MgY2xlYXIgdGhhdCBQSU8gd2l0aCA6Oi8w
IGlzIHBhdGhvbG9naWNhbC4gVGhlIHNhbWUgZm9yIGZlMDA6Oi84Lg0KDQpCdXQgaXQncyBub3Qg
Y2xlYXIgd2hhdCB0aGUgbGFyZ2VzdCBzYW5lIHByZWZpeCBsZW5ndGggaXMuIERvIHlvdSBoYXZl
IGEgc3VnZ2VzdGlvbj8NCg0KPiANCj4gLSBTZWN0aW9uIDU6IGlzIHRoaXMgYWRqdXN0bWVudCBh
IG5ldyBwcm9wb3NhbCBvZiB0aGlzIGRyYWZ0IG9yIGFuDQo+ICAgZXhpc3Rpbmcgb25lPyAoSWYg
aXQncyB0aGUgbGF0dGVyIEkgc2hvdWxkIGhhdmUgbWlzc2VkIHNvbWV0aGluZykuDQo+ICAgQW5k
IGluIGFueSBjYXNlIEknbSBub3Qgc3VyZSBpZiBpdCByZWFsbHkgbWFrZXMgc2Vuc2UuICBFc3Bl
Y2lhbGx5DQo+ICAgaWYgdGhpcyBpcyBhIG5ldyBwcm9wb3NhbCBJJ2QgbGlrZSB0byBzZWUgbW9y
ZSBkaXNjdXNzaW9uIG9uIHdoeSB3ZQ0KPiAgIG5lZWQgdGhpczoNCj4gDQo+ICAgIEhvc3QgU0hP
VUxEIHNldCB0aGUgZWZmZWN0aXZlIFZhbGlkIExpZmV0aW1lIGFzIGZvbGxvd3M6DQo+IA0KPiAg
ICAgICAgICAgIEVmZmVjdGl2ZVZMID0gbWF4KFZhbGlkIExpZmV0aW1lLCBNSU5fVkFMSURfTElG
RVRJTUUpDQo+IA0KPiAgICBXaGVyZSBFZmZlY3RpdmVWTCBpcyB0aGUgZWZmZWN0aXZlICdWYWxp
ZCBMaWZldGltZScsIGFuZA0KPiAgICBNSU5fVkFMSURfTElGRVRJTUUgaXMgc2V0IHRvIDE4MDAg
KHNlY29uZHMpLg0KW1JQQl0gDQpBZ3JlZS4gV2lsbCBhZGQgaW4gbmV4dCB2ZXJzaW9uLg0KPiAN
Cj4gLSBTZWN0aW9uIDU6IEkgdGhpbmsgd2Ugc2hvdWxkIGJlIG1vcmUgcHJlY2lzZSBoZXJlOg0K
PiANCj4gICAgQXMgc3RhdGVkIGluIFtSRkM0ODYxXSB0aGUgUHJlZmVycmVkIExpZmV0aW1lIE1V
U1QgQkUgbGVzcyB0aGFuIG9yDQo+ICAgIGVxdWFsIHRvIHRoZSBWYWxpZCBMaWZldGltZS4gIElm
IGFuIGluY29taW5nIE5EIG1lc3NhZ2UgZG9lcyBub3QgcGFzcw0KPiAgICB0aGlzIHZhbGlkYXRp
b24gY2hlY2ssIHRoZSBQcmVmaXggSW5mb3JtYXRpb24gT3B0aW9uIE1VU1QgYmUgaWdub3JlZC4N
Cj4gDQo+ICAgUHJlZmVycmVkIExpZmV0aW1lIGlzIG9ubHkgdXNlZCBmb3Igc3RhdGVsZXNzIGFk
ZHJlc3MNCj4gICBhdXRvY29uZmlndXJhdGlvbiwgc28gd2hlbiB3ZSBzYXkgIlBJTyBNVVNUIGJl
IGlnbm9yZWQiIHdlIHNob3VsZCBiZQ0KPiAgIGNsZWFyIHdoZXRoZXIgaXQncyBpbiB0ZXJtcyBv
ZiBvbi1saW5rIGRldGVybWluYXRpb24gb3IgU0FBQy4gIEluDQo+ICAgdGhlIGNvbnRleHQgb2Yg
dGhlIGxhdHRlciwgUkZDIDQ4NjIgZXhwbGljaXRseSByZXF1aXJlcyBzdWNoIFBJTyBiZQ0KPiAg
IGlnbm9yZWQuICBJbiB0aGUgY29udGV4dCBvZiB0aGUgZm9ybWVyLCB0aGlzIGlzIGNlcnRhaW5s
eSBvZGQgYnV0DQo+ICAgZG9lc24ndCBkbyBhbnkgYWN0dWFsIGhhcm0uICBTbywgaWYgdGhlIGlu
dGVudCBpcyB0aGUgbGF0dGVyLCBJJ2QNCj4gICBsaWtlIHRvIHNlZSB0aGUgcmF0aW9uYWxlLCBq
dXN0IGZvciB0aGUgc2FrZSBvZiBwYXJhbm9pYSwgZXRjLg0KW1JQQl0gDQpBZ3JlZS4gV2lsbCBj
YXRjaCB0aGlzIGluIHRoZSBuZXh0IHZlcnNpb24uDQoNCj4gDQo+IC0gU2VjdGlvbiAxMDogaXQn
cyBvZGQgdG8gbWUgdGhhdCBpdCBzcGVjaWZpY2FsbHkgY292ZXJzIHRoZSBmaXJzdCB0d28NCj4g
ICBiaXRzIChvZiB0aGUgZmlyc3QgYnl0ZSkgb2YgYSBsYWJlbCBpbiB0aGF0IHRoZXJlIGFyZSBv
dGhlciBmb3JtcyBvZg0KPiAgIGludmFsaWQgd2lyZSBmb3JtYXQgZm9yIGRvbWFpbiBuYW1lcyAo
ZS5nLiwgaXQgY2FuJ3QgYmUgbG9uZ2VyIHRoYW4NCj4gICAyNTUgb2N0ZXQpLg0KPiANCj4gICAg
VGhlIGRvbWFpbiBzdWZmaXhlcyBpbmNsdWRlZCBpbiB0aGlzIG9wdGlvbiBNVVNUIGJlIGVuY29k
ZWQgd2l0aCB0aGUNCj4gICAgc2ltcGxlIGVuY29kaW5nIHNwZWNpZmllZCBpbiBTZWN0aW9uIDMu
MSBvZiBbUkZDMTAzNV0uICBUaGVyZWZvcmUsIGlmDQo+ICAgIGFueSBvZiB0aGUgbGFiZWxzIG9m
IGEgZG9tYWluIGRvZXMgbm90IGhhdmUgdGhlIGZpcnN0IHR3byBiaXRzIHNldCB0bw0KPiAgICB6
ZXJvLCB0aGUgY29ycmVzcG9uZGluZyBETlNTTCBvcHRpb24gTVVTVCBiZSBpZ25vcmVkLg0KPiAN
Cj4gICBTbyBJJ2Qgc3VnZ2VzdCByZXZpc2luZyB0aGUgc2Vjb25kIHNlbnRlbmNlIHRvIG1vcmUg
Z2VuZXJpYywNCj4gICBlLmcuICJUaGVyZWZvcmUsIGlmIHRoZSBlbmNvZGVkIGRhdGEgYXJlIG5v
dCBhIHZhbGlkIG5vbi1jb21wcmVzc2VkDQo+ICAgZm9ybSBvZiBkb21haW4gbmFtZSwgdGhlIGNv
cnJlc3BvbmRpbmcgRE5TU0wgb3B0aW9uIE1VU1QgYmUNCj4gICBpZ25vcmVkLiINCltSUEJdIA0K
QWxzbyBhZ3JlZS4NCg0KPiANCj4gLSBFZGl0b3JpYWwgbml0cw0KPiAgICsgU2VjdGlvbiA0OiBz
L2FuL2EvICh0aGVyZSBhcmUgb3RoZXIgaW5zdGFuY2VzIG9mIHRoaXMgdHlwZSBvZiB0eXBvKQ0K
PiAgICBtZXNzYWdlIGNvbnRhaW5zIGFuIFRMTEEgT3B0aW9uLCB0aGUgVExMQSBPcHRpb24gTVVT
VCBiZSBpZ25vcmVkLg0KPiAgICsgU2VjdGlvbiA1OiBzL0JFL2JlLyAoZGl0dG8pDQo+ICAgIFRo
ZSBMZW5ndGggZmllbGQgTVVTVCBCRSBzZXQgdG8gNC4gIElmIGFuIGluY29taW5nIE5EIG1lc3Nh
Z2UgZG9lcw0KPiANCj4gLS0NCj4gSklOTUVJLCBUYXR1eWENCg==


From nobody Wed Aug 27 12:50:39 2014
Return-Path: <antonios.atlasis@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6521A0109 for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 12:50:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 2zQjqJpEf1CZ for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 12:50:35 -0700 (PDT)
Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95BB81A0111 for <6man@ietf.org>; Wed, 27 Aug 2014 12:50:35 -0700 (PDT)
Received: by mail-oa0-f50.google.com with SMTP id g18so591758oah.23 for <6man@ietf.org>; Wed, 27 Aug 2014 12:50:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KCy/ySE1BYyt/IHoYVoWwITLSRTP6b+gkc/m1xri4DY=; b=gADZvAPuoQ54nttRMCMyHeZ5Ir5RG6Ly/vYvQGxLXdtJo/f13v/aV+YgO4/hQTocMU 9/hKBSAkMq0O6uSNuR7jHYy9NfAltTdbsMnl1cAjFfJFcYDNUJrTEwyoPwYdoAdv/96C Sx0Y12gh6IpuklCEVymfz9An0SHj/+zKkN/wtx0qMFj41iG0U8pk0OPUKQJkzS6RapI+ 4Myln7yaUcImJFyZXoTDBStovBYSvkprQg/RS2dWTQBGAk/cD6uSfiVLEbsvL4CWAP34 51obherB7MmlkvVQdkbTUSCPBxdHBUSBIZ438QlfNY2LWl/6JQzA9mbg7kmtYUfvaeKU lQTA==
MIME-Version: 1.0
X-Received: by 10.182.224.227 with SMTP id rf3mr11816492obc.70.1409169034981;  Wed, 27 Aug 2014 12:50:34 -0700 (PDT)
Received: by 10.202.228.205 with HTTP; Wed, 27 Aug 2014 12:50:34 -0700 (PDT)
In-Reply-To: <53FE1D07.5060309@gont.com.ar>
References: <20140827174304.18733.67331.idtracker@ietfa.amsl.com> <53FE1D07.5060309@gont.com.ar>
Date: Wed, 27 Aug 2014 22:50:34 +0300
Message-ID: <CADoTVZLoYJFwRpVFmfgRcSjZf3qT=J2d-Q_MeVPnRoHqDb+1ow@mail.gmail.com>
Subject: Re: Revision of the IPv6 atomic frag deprecation I-D (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-01.txt)
From: Antonios Atlasis <antonios.atlasis@gmail.com>
To: Fernando Gont <fernando@gont.com.ar>
Content-Type: multipart/alternative; boundary=089e013a05dec235f10501a1bb9d
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/EQ53TQhc6M0xxwDo_jMGFm5RS_o
Cc: "6man@ietf.org" <6man@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 19:50:38 -0000

--089e013a05dec235f10501a1bb9d
Content-Type: text/plain; charset=UTF-8

Hi,

Regarding the information provided in Appendix A of the document:

I just re-tested Centos 6.5, which uses kernel 2.6.32, concerning the
generation of Atomic Fragments in response to ICMPv6 Packet Too Big
messages that report an MTU smaller than 1280 bytes. Specifically, when
reporting MTU=1200 bytes < 1280 bytes, at least the following two kernels
_generate_ Atomic Fragments:

2.6.32-431.20.3.el6.i686
2.6.32-431.23.3.el6.i686    (latest)

Regards

Antonios


2014-08-27 21:01 GMT+03:00 Fernando Gont <fernando@gont.com.ar>:

> Folks,
>
> We have published a revision of the aforementioned document:
> <
> http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-01.txt
> >
>
> I'll try to summarize the changes incorporated in this version:
>
> * Section 1 and Section 2 have been augmented to better explain the
> rationale for the proposed update -- not just interms of the security
> vulnerability being discussed, but also in terms of protocol robustness.
>
> * We have relaxed the update to RFC2460, noting that ICMP PTB<1280
> should not elicit atom frags (rather than "these packets should be
> dropped"), as suggested by Bob Briscoe
>
> * We have clarified the rationale for relying on IPv6 atom frags as part
> of the SIIT design decision.
>
> * We have incorporated an Appendix with a small and non-exhaustive
> survey which shows that quite a few widely deployed OSes fail to
> generate IPv6 atomic fragments in response to ICMPv6 PTB<1280.
>
> * We have clarified why you cannot simply check the IPv6 Source Address
> representing IPv4 nodes as a general mitigation to the vulnerability
> discussed in this document. -- this is based on the thread with Tatuya
> Jinmei.
>
> * We have included (in Section 6) a formal update to RFC6145, as
> suggested by Brian Carpenter. If the working group decides to take on
> this document, a second-order decision might be whether to update RFC
> 2460 and RFC6145 in this doc, or just focus on atom frag generation
> here, and do a complete RFC6145bis in a separate document. The whole
> Section 6 is mostly meant as "this is what one should patch in RFC6145
> such that it does not rely on IPv6 atomic fragments". However, we note
> that the core of this document is really all Sections other than Section
> 6, since those are the ones providing the rationale for deprecating the
> generation of IPv6 atomic fragments.
>
>
> Please do let us know if we have missed anything, if there's anything
> that needs further clarification, or if you like the I-D as is.
>
> Thanks so much!
> Fernando (and co-authors)
>
>
>
>
> -------- Forwarded Message --------
> Subject: New Version Notification for
> draft-gont-6man-deprecate-atomfrag-generation-01.txt
> Date: Wed, 27 Aug 2014 10:43:04 -0700
> From: internet-drafts@ietf.org
> To: Will(Shucheng) Liu <liushucheng@huawei.com>, Shucheng LIU (Will)
> <liushucheng@huawei.com>, Tore Anderson <tore@redpill-linpro.com>, Tore
> Anderson <tore@redpill-linpro.com>, Fernando Gont
> <fgont@si6networks.com>, Fernando Gont <fgont@si6networks.com>
>
>
> A new version of I-D, draft-gont-6man-deprecate-atomfrag-generation-01.txt
> has been successfully submitted by Fernando Gont and posted to the
> IETF repository.
>
> Name:           draft-gont-6man-deprecate-atomfrag-generation
> Revision:       01
> Title:          Deprecating the Generation of IPv6 Atomic Fragments
> Document date:  2014-08-27
> Group:          Individual Submission
> Pages:          17
> URL:
>
> http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-01.txt
> Status:
>
> https://datatracker.ietf.org/doc/draft-gont-6man-deprecate-atomfrag-generation/
> Htmlized:
> http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-01
> Diff:
>
> http://www.ietf.org/rfcdiff?url2=draft-gont-6man-deprecate-atomfrag-generation-01
>
> Abstract:
>    The core IPv6 specification requires that when a host receives an
>    ICMPv6 "Packet Too Big" message reporting a "Next-Hop MTU" smaller
>    than 1280, the host includes a Fragment Header in all subsequent
>    packets sent to that destination, without reducing the assumed Path-
>    MTU.  The simplicity with which ICMPv6 "Packet Too Big" messages can
>    be forged, coupled with the widespread filtering of IPv6 fragments,
>    results in an attack vector that can be leveraged for Denial of
>    Service purposes.  This document briefly discusses the aforementioned
>    attack vector, and formally updates RFC2460 such that generation of
>    IPv6 atomic fragments is deprecated, thus eliminating the
>    aforementioned attack vector.  Additionally, it formally updates
>    RFC6145 such that the Stateless IP/ICMP Translation Algorithm (SIIT)
>    does not rely on the generation of IPv6 atomic fragments, thus
>    improving the robustness of the protocol.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
>
> --
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@si6networks.com
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



-- 
=====================
Antonios Atlasis, PhD, MPhil
GXPN, GREM, GPEN, GWAPT, CCIH, GCIA

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

<div dir=3D"ltr"><div><div>Hi, <br><br></div>Regarding the information prov=
ided in Appendix A of the document:<br><br>I just re-tested Centos 6.5, whi=
ch uses kernel 2.6.32, concerning the generation of Atomic Fragments in res=
ponse to ICMPv6 Packet Too Big messages that report an MTU smaller than 128=
0 bytes. Specifically, when reporting MTU=3D1200 bytes &lt; 1280 bytes, at =
least the following two kernels _generate_ Atomic Fragments:<br>
</div><div><br>2.6.32-431.20.3.el6.i686 <br>2.6.32-431.23.3.el6.i686=C2=A0=
=C2=A0=C2=A0 (latest)<br><br></div><div>Regards<br><br>Antonios<br></div></=
div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014-08-2=
7 21:01 GMT+03:00 Fernando Gont <span dir=3D"ltr">&lt;<a href=3D"mailto:fer=
nando@gont.com.ar" target=3D"_blank">fernando@gont.com.ar</a>&gt;</span>:<b=
r>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Folks,<br>
<br>
We have published a revision of the aforementioned document:<br>
&lt;<a href=3D"http://www.ietf.org/internet-drafts/draft-gont-6man-deprecat=
e-atomfrag-generation-01.txt" target=3D"_blank">http://www.ietf.org/interne=
t-drafts/draft-gont-6man-deprecate-atomfrag-generation-01.txt</a>&gt;<br>
<br>
I&#39;ll try to summarize the changes incorporated in this version:<br>
<br>
* Section 1 and Section 2 have been augmented to better explain the<br>
rationale for the proposed update -- not just interms of the security<br>
vulnerability being discussed, but also in terms of protocol robustness.<br=
>
<br>
* We have relaxed the update to RFC2460, noting that ICMP PTB&lt;1280<br>
should not elicit atom frags (rather than &quot;these packets should be<br>
dropped&quot;), as suggested by Bob Briscoe<br>
<br>
* We have clarified the rationale for relying on IPv6 atom frags as part<br=
>
of the SIIT design decision.<br>
<br>
* We have incorporated an Appendix with a small and non-exhaustive<br>
survey which shows that quite a few widely deployed OSes fail to<br>
generate IPv6 atomic fragments in response to ICMPv6 PTB&lt;1280.<br>
<br>
* We have clarified why you cannot simply check the IPv6 Source Address<br>
representing IPv4 nodes as a general mitigation to the vulnerability<br>
discussed in this document. -- this is based on the thread with Tatuya<br>
Jinmei.<br>
<br>
* We have included (in Section 6) a formal update to RFC6145, as<br>
suggested by Brian Carpenter. If the working group decides to take on<br>
this document, a second-order decision might be whether to update RFC<br>
2460 and RFC6145 in this doc, or just focus on atom frag generation<br>
here, and do a complete RFC6145bis in a separate document. The whole<br>
Section 6 is mostly meant as &quot;this is what one should patch in RFC6145=
<br>
such that it does not rely on IPv6 atomic fragments&quot;. However, we note=
<br>
that the core of this document is really all Sections other than Section<br=
>
6, since those are the ones providing the rationale for deprecating the<br>
generation of IPv6 atomic fragments.<br>
<br>
<br>
Please do let us know if we have missed anything, if there&#39;s anything<b=
r>
that needs further clarification, or if you like the I-D as is.<br>
<br>
Thanks so much!<br>
Fernando (and co-authors)<br>
<br>
<br>
<br>
<br>
-------- Forwarded Message --------<br>
Subject: New Version Notification for<br>
draft-gont-6man-deprecate-atomfrag-generation-01.txt<br>
Date: Wed, 27 Aug 2014 10:43:04 -0700<br>
From: <a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org<=
/a><br>
To: Will(Shucheng) Liu &lt;<a href=3D"mailto:liushucheng@huawei.com">liushu=
cheng@huawei.com</a>&gt;, Shucheng LIU (Will)<br>
&lt;<a href=3D"mailto:liushucheng@huawei.com">liushucheng@huawei.com</a>&gt=
;, Tore Anderson &lt;<a href=3D"mailto:tore@redpill-linpro.com">tore@redpil=
l-linpro.com</a>&gt;, Tore<br>
Anderson &lt;<a href=3D"mailto:tore@redpill-linpro.com">tore@redpill-linpro=
.com</a>&gt;, Fernando Gont<br>
&lt;<a href=3D"mailto:fgont@si6networks.com">fgont@si6networks.com</a>&gt;,=
 Fernando Gont &lt;<a href=3D"mailto:fgont@si6networks.com">fgont@si6networ=
ks.com</a>&gt;<br>
<br>
<br>
A new version of I-D, draft-gont-6man-deprecate-atomfrag-generation-01.txt<=
br>
has been successfully submitted by Fernando Gont and posted to the<br>
IETF repository.<br>
<br>
Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-gont-6man-deprecate-ato=
mfrag-generation<br>
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001<br>
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Deprecating the Generation of IPv6=
 Atomic Fragments<br>
Document date:=C2=A0 2014-08-27<br>
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission<br>
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 17<br>
URL:<br>
<a href=3D"http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-at=
omfrag-generation-01.txt" target=3D"_blank">http://www.ietf.org/internet-dr=
afts/draft-gont-6man-deprecate-atomfrag-generation-01.txt</a><br>
Status:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-gont-6man-deprecate-atomf=
rag-generation/" target=3D"_blank">https://datatracker.ietf.org/doc/draft-g=
ont-6man-deprecate-atomfrag-generation/</a><br>
Htmlized:<br>
<a href=3D"http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-ge=
neration-01" target=3D"_blank">http://tools.ietf.org/html/draft-gont-6man-d=
eprecate-atomfrag-generation-01</a><br>
Diff:<br>
<a href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-gont-6man-deprecate-ato=
mfrag-generation-01" target=3D"_blank">http://www.ietf.org/rfcdiff?url2=3Dd=
raft-gont-6man-deprecate-atomfrag-generation-01</a><br>
<br>
Abstract:<br>
=C2=A0 =C2=A0The core IPv6 specification requires that when a host receives=
 an<br>
=C2=A0 =C2=A0ICMPv6 &quot;Packet Too Big&quot; message reporting a &quot;Ne=
xt-Hop MTU&quot; smaller<br>
=C2=A0 =C2=A0than 1280, the host includes a Fragment Header in all subseque=
nt<br>
=C2=A0 =C2=A0packets sent to that destination, without reducing the assumed=
 Path-<br>
=C2=A0 =C2=A0MTU.=C2=A0 The simplicity with which ICMPv6 &quot;Packet Too B=
ig&quot; messages can<br>
=C2=A0 =C2=A0be forged, coupled with the widespread filtering of IPv6 fragm=
ents,<br>
=C2=A0 =C2=A0results in an attack vector that can be leveraged for Denial o=
f<br>
=C2=A0 =C2=A0Service purposes.=C2=A0 This document briefly discusses the af=
orementioned<br>
=C2=A0 =C2=A0attack vector, and formally updates RFC2460 such that generati=
on of<br>
=C2=A0 =C2=A0IPv6 atomic fragments is deprecated, thus eliminating the<br>
=C2=A0 =C2=A0aforementioned attack vector.=C2=A0 Additionally, it formally =
updates<br>
=C2=A0 =C2=A0RFC6145 such that the Stateless IP/ICMP Translation Algorithm =
(SIIT)<br>
=C2=A0 =C2=A0does not rely on the generation of IPv6 atomic fragments, thus=
<br>
=C2=A0 =C2=A0improving the robustness of the protocol.<br>
<br>
<br>
<br>
<br>
<br>
Please note that it may take a couple of minutes from the time of submissio=
n<br>
until the htmlized version and diff are available at <a href=3D"http://tool=
s.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br>
<br>
The IETF Secretariat<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
<br>
<br>
<br>
--<br>
Fernando Gont<br>
e-mail: <a href=3D"mailto:fernando@gont.com.ar">fernando@gont.com.ar</a> ||=
 <a href=3D"mailto:fgont@si6networks.com">fgont@si6networks.com</a><br>
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1<br>
<br>
<br>
<br>
--------------------------------------------------------------------<br>
IETF IPv6 working group mailing list<br>
<a href=3D"mailto:ipv6@ietf.org">ipv6@ietf.org</a><br>
Administrative Requests: <a href=3D"https://www.ietf.org/mailman/listinfo/i=
pv6" target=3D"_blank">https://www.ietf.org/mailman/listinfo/ipv6</a><br>
--------------------------------------------------------------------<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br>=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Antonios Atlasis,=
 PhD, MPhil<br>
GXPN, GREM, GPEN, GWAPT, CCIH, GCIA
</div>

--089e013a05dec235f10501a1bb9d--


From nobody Wed Aug 27 12:52:03 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D581A0111 for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 12:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.002
X-Spam-Level: 
X-Spam-Status: No, score=-1.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 1H1cVsh0HqU8 for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 12:52:00 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB43A1A0163 for <ipv6@ietf.org>; Wed, 27 Aug 2014 12:51:59 -0700 (PDT)
Received: from 48-136-17-190.fibertel.com.ar ([190.17.136.48] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XMjG7-00059Z-B3; Wed, 27 Aug 2014 21:51:57 +0200
Message-ID: <53FE36D3.9000606@si6networks.com>
Date: Wed, 27 Aug 2014 16:51:47 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>,  Ronald Bonica <rbonica@juniper.net>
Subject: Re: draft-gont-6man-nd-opt-validation-00
References: <CAJE_bqfdOZi6U2AqUx3k9kUi_fO1=sNW-k_3b4Kg4Oy2qZdSrA@mail.gmail.com>
In-Reply-To: <CAJE_bqfdOZi6U2AqUx3k9kUi_fO1=sNW-k_3b4Kg4Oy2qZdSrA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/SSkvzVyKGINQRyZ7PVb9vs1jr24
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 19:52:02 -0000

Hi, Jinmei,

Thanks so much for your feedback! -- Please find my comments in-line...
[quite a few comments ommited, since Ron since to ahve responded some of
them]


On 08/26/2014 01:57 PM, 神明é�”哉 wrote:
>  I have some comments on the draft
> nevertheless:
> 
> - I previously commented on lla-opt-validation: 
> http://www.ietf.org/mail-archive/web/ipv6/current/msg20389.html and I
> thought we agreed on some updates from that discussion. 

It seems that I missed your post -- I'll respond in a separate thread.



> But it looks
> like these points have been completely dropped in nd-opt-validation. 
> Was that my misunderstanding about the result of the previous 
> discussion, or is nd-opt-validation a completely new document mostly 
> unrelated to the previous discussion, or something else?

nd-opt-validation is a superset of lla-opt-validation.


> - Related to the previous point, IIRC lla-opt-validation discusses
> the rationale of the validation, but nd-opt-validation generally
> only lists the validations.  Is this change intentional?

Yes. The rationale was that, since we're covering many ND options, it
was better to stick to the validation checks instead of delving into the
details of the associated attack vectors.



> - Maybe related to some of the previous bullet points, some of the 
> proposed validations (which generally seem to be newly proposed 
> ones?) require the entire ND message be dropped if a certain 
> validation fails while some others just require that particular 
> option be dropped, and it doesn't explain why the former case should 
> be handled differently.  I'd at least like to see the rationale, and 
> in general it seems to be against the sense of Section 9 of RFC 
> 4861.

Not sure what you mean. In this document we try to validate ND options,
and if an option seems to be malformed, we drop the packet. OTOH,
Section 9 of RFC4861 just notes that if you *don't recognize* an option,
you should still parse the other options.

In our case, its not that we couldn't recognize an option, but rather
that we recognized it as malformed.

That said, I understand that an alternative approach would be to just
drop the option rather than the whole packet. Me 8not necessarily my
co-atuhors) could live with that approach, too.

Thoughts?



> - Section 5: what's the source of this restriction?
> 
> The Prefix Length is an 8-bit unsigned integer that specifies the 
> prefix length (i.e., the number of leading bits in the Prefix field 
> that are significant).  Its value MUST be greater than or equal to 
> 32.

Of the top of my head, we incorporated a more relaxed sanity check that
that being employed by other stacks (length == 64 in some cases).

But I do agree that the sanity check is debatable. Thoughts?



> - Section 5: is this adjustment a new proposal of this draft or an 
> existing one? (If it's the latter I should have missed something). 
> And in any case I'm not sure if it really makes sense.  Especially if
> this is a new proposal I'd like to see more discussion on why we need
> this:
> 
> Host SHOULD set the effective Valid Lifetime as follows:
> 
> EffectiveVL = max(Valid Lifetime, MIN_VALID_LIFETIME)
> 
> Where EffectiveVL is the effective 'Valid Lifetime', and 
> MIN_VALID_LIFETIME is set to 1800 (seconds).

When sending the RA, RFC4861 specifies a lower limit. Here we're
enforcing such lower limit, but on the receive side.

This avoids e.g. having a node sending packet with a Valid lifetime of 1
second, which would make you configure your network interface and right
after drop such configuration.



> - Section 5: I think we should be more precise here:
> 
> As stated in [RFC4861] the Preferred Lifetime MUST BE less than or 
> equal to the Valid Lifetime.  If an incoming ND message does not
> pass this validation check, the Prefix Information Option MUST be
> ignored.
> 
> Preferred Lifetime is only used for stateless address 
> autoconfiguration, so when we say "PIO MUST be ignored" we should be 
> clear whether it's in terms of on-link determination or SAAC.

FWIW, since the Preferred Lifetime MUST (always) be less than or equal
to the
valid lifetime, if the option does not pass this check, we consider it
to be malformed and hence advice implementation to drop them


>  In the
> context of the latter, RFC 4862 explicitly requires such PIO be 
> ignored.  In the context of the former, this is certainly odd but 
> doesn't do any actual harm.  So, if the intent is the latter, I'd 
> like to see the rationale, just for the sake of paranoia, etc.

It's a MUST that is not being complied to, essentially.

Thanks so much!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492







From nobody Wed Aug 27 13:00:12 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B971A0154 for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 13:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 6TMJeAawGmWv for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 13:00:09 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF3351A0141 for <6man@ietf.org>; Wed, 27 Aug 2014 13:00:08 -0700 (PDT)
Received: from 48-136-17-190.fibertel.com.ar ([190.17.136.48] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XMjO3-0005B0-C7; Wed, 27 Aug 2014 22:00:07 +0200
Message-ID: <53FE38BF.5020306@si6networks.com>
Date: Wed, 27 Aug 2014 16:59:59 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Antonios Atlasis <antonios.atlasis@gmail.com>,  Fernando Gont <fernando@gont.com.ar>
Subject: Re: Revision of the IPv6 atomic frag deprecation I-D (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-01.txt)
References: <20140827174304.18733.67331.idtracker@ietfa.amsl.com> <53FE1D07.5060309@gont.com.ar> <CADoTVZLoYJFwRpVFmfgRcSjZf3qT=J2d-Q_MeVPnRoHqDb+1ow@mail.gmail.com>
In-Reply-To: <CADoTVZLoYJFwRpVFmfgRcSjZf3qT=J2d-Q_MeVPnRoHqDb+1ow@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/i4f4p74oynGMuRJPTQLL2Wf-UmE
Cc: "6man@ietf.org" <6man@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 20:00:10 -0000

Hi, Antonios,

On 08/27/2014 04:50 PM, Antonios Atlasis wrote:
> 
> Regarding the information provided in Appendix A of the document:
> 
> I just re-tested Centos 6.5, which uses kernel 2.6.32, concerning the
> generation of Atomic Fragments in response to ICMPv6 Packet Too Big
> messages that report an MTU smaller than 1280 bytes. Specifically, when
> reporting MTU=1200 bytes < 1280 bytes, at least the following two
> kernels _generate_ Atomic Fragments:
> 
> 2.6.32-431.20.3.el6.i686
> 2.6.32-431.23.3.el6.i686    (latest)

But these are not the kernel versions included in the table of Apendix
A, are they?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Wed Aug 27 13:08:29 2014
Return-Path: <antonios.atlasis@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BFC1A0127 for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 13:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 q6KemP8N0tlW for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 13:08:24 -0700 (PDT)
Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC5A1A0142 for <6man@ietf.org>; Wed, 27 Aug 2014 13:08:23 -0700 (PDT)
Received: by mail-ob0-f180.google.com with SMTP id uy5so610066obc.11 for <6man@ietf.org>; Wed, 27 Aug 2014 13:08:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UuILZqL0rf+KCL6IHvAfUDk25XIWe7GvJK+EgVcgQhM=; b=U8EM7OOUElPGAff9ayYRbulcNCS8GXO61NGsF3KsrJrHcRJi7xUHvOMKmeHdhoGemv hzObLzsGyLeBI5lGpgNUz9LrMJYol8eLOhdTyS1SKhyQQAnT6v0/+ecxEynssE0HD5tX U+VXuMKHuRNBDZsX7dMsx9x7XXo77Cvj0tsUL5gMBKq+vpX//yKeErIEZr19Emn3MHpR LFR32/MbKA2tqORrEGi/29WUh1J8/FCJTZCL1eNcfcj8k89xmmLhZlkjySjykTPf0lT4 fEdogKdQXdgeBDXj21p8tFWZlvugjUZyv5wZKYBgsikizUWitWl6QPs3RBC7oLj7vX4q W8oQ==
MIME-Version: 1.0
X-Received: by 10.182.27.5 with SMTP id p5mr36318788obg.42.1409170103221; Wed, 27 Aug 2014 13:08:23 -0700 (PDT)
Received: by 10.202.228.205 with HTTP; Wed, 27 Aug 2014 13:08:23 -0700 (PDT)
In-Reply-To: <53FE38BF.5020306@si6networks.com>
References: <20140827174304.18733.67331.idtracker@ietfa.amsl.com> <53FE1D07.5060309@gont.com.ar> <CADoTVZLoYJFwRpVFmfgRcSjZf3qT=J2d-Q_MeVPnRoHqDb+1ow@mail.gmail.com> <53FE38BF.5020306@si6networks.com>
Date: Wed, 27 Aug 2014 23:08:23 +0300
Message-ID: <CADoTVZLGPW2mWDAg8ycczXpEhxZk-F4-aPJoU5j6UUCyDNk=iw@mail.gmail.com>
Subject: Re: Revision of the IPv6 atomic frag deprecation I-D (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-01.txt)
From: Antonios Atlasis <antonios.atlasis@gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary=089e0115f6cc6e40d60501a1fbea
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/LuasTGuUyj46879TxkYKdDG6pEs
Cc: "6man@ietf.org" <6man@ietf.org>, Fernando Gont <fernando@gont.com.ar>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 20:08:26 -0000

--089e0115f6cc6e40d60501a1fbea
Content-Type: text/plain; charset=UTF-8

Hi Fernando,

yes, they are, this is why I mentioned it. Appendix A includes Linux kernel
2.6.32, the ones that I mentioned are the latest updates of this Linux
Kernel, at least at Centos (version 6.5), the Red Hat clone. It is referred
in our latest results at
http://www.insinuator.net/2014/08/packet-too-big-messages-and-atomic-fragments/.
Furthermore, Centos 6.5 is one of the two (the other one is FreeBSD 10)
that takes a really long time to recover (meaning to stop sending atomic
fragments).

Best

Antonios


2014-08-27 22:59 GMT+03:00 Fernando Gont <fgont@si6networks.com>:

> Hi, Antonios,
>
> On 08/27/2014 04:50 PM, Antonios Atlasis wrote:
> >
> > Regarding the information provided in Appendix A of the document:
> >
> > I just re-tested Centos 6.5, which uses kernel 2.6.32, concerning the
> > generation of Atomic Fragments in response to ICMPv6 Packet Too Big
> > messages that report an MTU smaller than 1280 bytes. Specifically, when
> > reporting MTU=1200 bytes < 1280 bytes, at least the following two
> > kernels _generate_ Atomic Fragments:
> >
> > 2.6.32-431.20.3.el6.i686
> > 2.6.32-431.23.3.el6.i686    (latest)
>
> But these are not the kernel versions included in the table of Apendix
> A, are they?
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>


-- 
=====================
Antonios Atlasis, PhD, MPhil
GXPN, GREM, GPEN, GWAPT, CCIH, GCIA

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

<div dir=3D"ltr"><div><div><div>Hi Fernando, <br><br></div>yes, they are, t=
his is why I mentioned it. Appendix A includes Linux kernel 2.6.32, the one=
s that I mentioned are the latest updates of this Linux Kernel, at least at=
 Centos (version 6.5), the Red Hat clone. It is referred in our latest resu=
lts at <a href=3D"http://www.insinuator.net/2014/08/packet-too-big-messages=
-and-atomic-fragments/">http://www.insinuator.net/2014/08/packet-too-big-me=
ssages-and-atomic-fragments/</a>. Furthermore, Centos 6.5 is one of the two=
 (the other one is FreeBSD 10) that takes a really long time to recover (me=
aning to stop sending atomic fragments). <br>
<br></div>Best<br><br></div>Antonios<br></div><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">2014-08-27 22:59 GMT+03:00 Fernando Gont <=
span dir=3D"ltr">&lt;<a href=3D"mailto:fgont@si6networks.com" target=3D"_bl=
ank">fgont@si6networks.com</a>&gt;</span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi, Antonios,<br>
<div class=3D""><br>
On 08/27/2014 04:50 PM, Antonios Atlasis wrote:<br>
&gt;<br>
&gt; Regarding the information provided in Appendix A of the document:<br>
&gt;<br>
&gt; I just re-tested Centos 6.5, which uses kernel 2.6.32, concerning the<=
br>
&gt; generation of Atomic Fragments in response to ICMPv6 Packet Too Big<br=
>
&gt; messages that report an MTU smaller than 1280 bytes. Specifically, whe=
n<br>
&gt; reporting MTU=3D1200 bytes &lt; 1280 bytes, at least the following two=
<br>
&gt; kernels _generate_ Atomic Fragments:<br>
&gt;<br>
&gt; 2.6.32-431.20.3.el6.i686<br>
&gt; 2.6.32-431.23.3.el6.i686=C2=A0 =C2=A0 (latest)<br>
<br>
</div>But these are not the kernel versions included in the table of Apendi=
x<br>
A, are they?<br>
<br>
Thanks,<br>
<span class=3D"HOEnZb"><font color=3D"#888888">--<br>
Fernando Gont<br>
SI6 Networks<br>
e-mail: <a href=3D"mailto:fgont@si6networks.com">fgont@si6networks.com</a><=
br>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492<br>
<br>
<br>
<br>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br>=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Antonios Atlasis,=
 PhD, MPhil<br>
GXPN, GREM, GPEN, GWAPT, CCIH, GCIA
</div>

--089e0115f6cc6e40d60501a1fbea--


From nobody Wed Aug 27 13:16:11 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638651A6F1A for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 13:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 qvBNH_IypWOm for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 13:16:00 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5FD1A032E for <6man@ietf.org>; Wed, 27 Aug 2014 13:15:39 -0700 (PDT)
Received: from 48-136-17-190.fibertel.com.ar ([190.17.136.48] helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XMjd3-0005EE-S1; Wed, 27 Aug 2014 22:15:38 +0200
Message-ID: <53FE3C61.9040603@si6networks.com>
Date: Wed, 27 Aug 2014 17:15:29 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Antonios Atlasis <antonios.atlasis@gmail.com>
Subject: Re: Revision of the IPv6 atomic frag deprecation I-D (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-01.txt)
References: <20140827174304.18733.67331.idtracker@ietfa.amsl.com>	<53FE1D07.5060309@gont.com.ar>	<CADoTVZLoYJFwRpVFmfgRcSjZf3qT=J2d-Q_MeVPnRoHqDb+1ow@mail.gmail.com>	<53FE38BF.5020306@si6networks.com> <CADoTVZLGPW2mWDAg8ycczXpEhxZk-F4-aPJoU5j6UUCyDNk=iw@mail.gmail.com>
In-Reply-To: <CADoTVZLGPW2mWDAg8ycczXpEhxZk-F4-aPJoU5j6UUCyDNk=iw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/rnVazvyOmIdfD5xx4bd53yATiPE
Cc: "6man@ietf.org" <6man@ietf.org>, Fernando Gont <fernando@gont.com.ar>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 20:16:05 -0000

On 08/27/2014 05:08 PM, Antonios Atlasis wrote:
> Hi Fernando,
> 
> yes, they are, this is why I mentioned it.

Please check the version numbers. As far as I recall,  the 2.6.32-XXX
represents a lot of revisions.


> Appendix A includes Linux
> kernel 2.6.32, the ones that I mentioned are the latest updates of this
> Linux Kernel,

Then it's not the same. :-)

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Wed Aug 27 13:38:03 2014
Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1351A02AC for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 13:38:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 qObTfgL6XWVI for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 13:38:00 -0700 (PDT)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F231A02A5 for <6man@ietf.org>; Wed, 27 Aug 2014 13:38:00 -0700 (PDT)
Received: by mail-pa0-f47.google.com with SMTP id kx10so1278516pab.20 for <6man@ietf.org>; Wed, 27 Aug 2014 13:38:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/iEynrrdoVSONwgd4tb0aJhuqHdWBdrG2qMuPhTWyEo=; b=oBXOg84YsDdSWZBx8M0ynuouatzlJ08IJ8kc8523gd8ao/1Ap7rsbqV1Ed2BvB6Top 9eyWCLFz18fZvpD+bPM3IoFlJziFB9WM04Z6Uvv4IG/0uCo4TTziEum6/RZgy2DPPFO4 TdjtKnOzdbxJIAJC1+Jnmab9WFrxq1eTyFG7ZaAns40BczOAzX/LdhLpjNkBLieeAFmT AE+lhcP4O545siKLI7xyh/OVaiQ97FfTGVIztSlyYF0gihxFmL0KBb0FJ2rwfQK/Ip6m /8Ty9C4WhJwmF6cekjOL09qe0CxcyHsSWGrz/sDuc8lOpqJCddIvlWWMHlHrfxWf8qKC qMyg==
X-Received: by 10.70.94.228 with SMTP id df4mr49481037pdb.64.1409171880292; Wed, 27 Aug 2014 13:38:00 -0700 (PDT)
Received: from [192.168.178.23] (149.199.69.111.dynamic.snap.net.nz. [111.69.199.149]) by mx.google.com with ESMTPSA id ry9sm4739972pab.37.2014.08.27.13.37.57 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Aug 2014 13:37:59 -0700 (PDT)
Message-ID: <53FE41A9.5070304@gmail.com>
Date: Thu, 28 Aug 2014 08:38:01 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
Subject: Re: Revision of the IPv6 atomic frag deprecation I-D (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-01.txt)
References: <20140827174304.18733.67331.idtracker@ietfa.amsl.com> <53FE1D07.5060309@gont.com.ar>
In-Reply-To: <53FE1D07.5060309@gont.com.ar>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/YboLxVzMhXBQAN_x0oRt3yr_9NE
Cc: "6man@ietf.org" <6man@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 20:38:02 -0000

Fernando,

Wow, what a lot of detailed work! I'll give my top-level views:

1. We need to ask the RFC 6145 authors to comment on the *accuracy*
of the proposed revisions and whether they have any unintended
side effects.

2. Then we need to decide whether the change is or isn't desirable
on balance. (I haven't really made up my mind yet on this, but I've
certainly always found this to be a very messay aspect of the SIIT
model.)

3. Finally, if we go ahead, we would need to decide whether it
would be simpler to publish RFC6145bis rather than spell out
all the diffs in this document.

Regards
   Brian

On 28/08/2014 06:01, Fernando Gont wrote:
> Folks,
> 
> We have published a revision of the aforementioned document:
> <http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-01.txt>
> 
> I'll try to summarize the changes incorporated in this version:
> 
> * Section 1 and Section 2 have been augmented to better explain the
> rationale for the proposed update -- not just interms of the security
> vulnerability being discussed, but also in terms of protocol robustness.
> 
> * We have relaxed the update to RFC2460, noting that ICMP PTB<1280
> should not elicit atom frags (rather than "these packets should be
> dropped"), as suggested by Bob Briscoe
> 
> * We have clarified the rationale for relying on IPv6 atom frags as part
> of the SIIT design decision.
> 
> * We have incorporated an Appendix with a small and non-exhaustive
> survey which shows that quite a few widely deployed OSes fail to
> generate IPv6 atomic fragments in response to ICMPv6 PTB<1280.
> 
> * We have clarified why you cannot simply check the IPv6 Source Address
> representing IPv4 nodes as a general mitigation to the vulnerability
> discussed in this document. -- this is based on the thread with Tatuya
> Jinmei.
> 
> * We have included (in Section 6) a formal update to RFC6145, as
> suggested by Brian Carpenter. If the working group decides to take on
> this document, a second-order decision might be whether to update RFC
> 2460 and RFC6145 in this doc, or just focus on atom frag generation
> here, and do a complete RFC6145bis in a separate document. The whole
> Section 6 is mostly meant as "this is what one should patch in RFC6145
> such that it does not rely on IPv6 atomic fragments". However, we note
> that the core of this document is really all Sections other than Section
> 6, since those are the ones providing the rationale for deprecating the
> generation of IPv6 atomic fragments.
> 
> 
> Please do let us know if we have missed anything, if there's anything
> that needs further clarification, or if you like the I-D as is.
> 
> Thanks so much!
> Fernando (and co-authors)
> 
> 
> 
> 
> -------- Forwarded Message --------
> Subject: New Version Notification for
> draft-gont-6man-deprecate-atomfrag-generation-01.txt
> Date: Wed, 27 Aug 2014 10:43:04 -0700
> From: internet-drafts@ietf.org
> To: Will(Shucheng) Liu <liushucheng@huawei.com>, Shucheng LIU (Will)
> <liushucheng@huawei.com>, Tore Anderson <tore@redpill-linpro.com>, Tore
> Anderson <tore@redpill-linpro.com>, Fernando Gont
> <fgont@si6networks.com>, Fernando Gont <fgont@si6networks.com>
> 
> 
> A new version of I-D, draft-gont-6man-deprecate-atomfrag-generation-01.txt
> has been successfully submitted by Fernando Gont and posted to the
> IETF repository.
> 
> Name:		draft-gont-6man-deprecate-atomfrag-generation
> Revision:	01
> Title:		Deprecating the Generation of IPv6 Atomic Fragments
> Document date:	2014-08-27
> Group:		Individual Submission
> Pages:		17
> URL:
> http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-gont-6man-deprecate-atomfrag-generation/
> Htmlized:
> http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-01
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-gont-6man-deprecate-atomfrag-generation-01
> 
> Abstract:
>    The core IPv6 specification requires that when a host receives an
>    ICMPv6 "Packet Too Big" message reporting a "Next-Hop MTU" smaller
>    than 1280, the host includes a Fragment Header in all subsequent
>    packets sent to that destination, without reducing the assumed Path-
>    MTU.  The simplicity with which ICMPv6 "Packet Too Big" messages can
>    be forged, coupled with the widespread filtering of IPv6 fragments,
>    results in an attack vector that can be leveraged for Denial of
>    Service purposes.  This document briefly discusses the aforementioned
>    attack vector, and formally updates RFC2460 such that generation of
>    IPv6 atomic fragments is deprecated, thus eliminating the
>    aforementioned attack vector.  Additionally, it formally updates
>    RFC6145 such that the Stateless IP/ICMP Translation Algorithm (SIIT)
>    does not rely on the generation of IPv6 atomic fragments, thus
>    improving the robustness of the protocol.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> 
> 
> 


From nobody Wed Aug 27 14:08:40 2014
Return-Path: <antonios.atlasis@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021D51A0141 for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 14:08:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 2ot7UfGhVTfB for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 14:08:37 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396981A0294 for <6man@ietf.org>; Wed, 27 Aug 2014 14:08:37 -0700 (PDT)
Received: by mail-oi0-f47.google.com with SMTP id x69so604445oia.6 for <6man@ietf.org>; Wed, 27 Aug 2014 14:08:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1t+IamV4SCh0/7hWaQt0rvTEED5nF04S/pn9Y+D0Y9k=; b=M0j2ktR484AnJburm7JIw431fQRqRFIYdZiQVSk5/dViIP0Rz5zf1wrpnJ4HmaDIa4 WZxWCD90jX3ArBwNmCgWSOMyMibZsPtq3428yd6JQNEchXlH0s6Ee8ptSNFB4J56dym6 epdroMhlHyOAIkEsaUOuJAzaYtpLZp+ZXv7pSjmDcRiioftZd+2fj3SQ8Tl8a8gWYi/N mEzfMfx9SHls3pv5BYNYP8VvL3eJqZcnGAADwemxarxyxx6OZy3EwcThSJA/+tqEWxMv uEVwB5Q2X1Bu8C8dkbTLQX/OTNcjHvgC8AjU/CAhed52xhAkaXuA7KL1uwilKZBzkV14 RM0w==
MIME-Version: 1.0
X-Received: by 10.60.34.98 with SMTP id y2mr38389486oei.9.1409173716297; Wed, 27 Aug 2014 14:08:36 -0700 (PDT)
Received: by 10.202.228.205 with HTTP; Wed, 27 Aug 2014 14:08:36 -0700 (PDT)
In-Reply-To: <53FE3C61.9040603@si6networks.com>
References: <20140827174304.18733.67331.idtracker@ietfa.amsl.com> <53FE1D07.5060309@gont.com.ar> <CADoTVZLoYJFwRpVFmfgRcSjZf3qT=J2d-Q_MeVPnRoHqDb+1ow@mail.gmail.com> <53FE38BF.5020306@si6networks.com> <CADoTVZLGPW2mWDAg8ycczXpEhxZk-F4-aPJoU5j6UUCyDNk=iw@mail.gmail.com> <53FE3C61.9040603@si6networks.com>
Date: Thu, 28 Aug 2014 00:08:36 +0300
Message-ID: <CADoTVZKkW9rMcO2UoOqzhTvR-m732UV8OX-ieRqLw53WDb1BYQ@mail.gmail.com>
Subject: Re: Revision of the IPv6 atomic frag deprecation I-D (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-01.txt)
From: Antonios Atlasis <antonios.atlasis@gmail.com>
To: Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary=089e01175d07c96e1e0501a2d2ab
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/wWKmaXGnJTWT66zaIiYxljagT28
Cc: "6man@ietf.org" <6man@ietf.org>, Fernando Gont <fernando@gont.com.ar>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 21:08:39 -0000

--089e01175d07c96e1e0501a2d2ab
Content-Type: text/plain; charset=UTF-8

Hi,



2014-08-27 23:15 GMT+03:00 Fernando Gont <fgont@si6networks.com>:

> On 08/27/2014 05:08 PM, Antonios Atlasis wrote:
> > Hi Fernando,
> >
> > yes, they are, this is why I mentioned it.
>
> Please check the version numbers. As far as I recall,  the 2.6.32-XXX
> represents a lot of revisions.
>
>
> > Appendix A includes Linux
> > kernel 2.6.32, the ones that I mentioned are the latest updates of this
> > Linux Kernel,
>
> Then it's not the same. :-)
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
>


-- 
=====================
Antonios Atlasis, PhD, MPhil
GXPN, GREM, GPEN, GWAPT, CCIH, GCIA

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

<div dir=3D"ltr">Hi, <br><br></div><div class=3D"gmail_extra"><br><br><div =
class=3D"gmail_quote">2014-08-27 23:15 GMT+03:00 Fernando Gont <span dir=3D=
"ltr">&lt;<a href=3D"mailto:fgont@si6networks.com" target=3D"_blank">fgont@=
si6networks.com</a>&gt;</span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 08/27/2014 05:08 PM, Anto=
nios Atlasis wrote:<br>
&gt; Hi Fernando,<br>
&gt;<br>
&gt; yes, they are, this is why I mentioned it.<br>
<br>
</div>Please check the version numbers. As far as I recall,=C2=A0 the 2.6.3=
2-XXX<br>
represents a lot of revisions.<br>
<div class=3D""><br>
<br>
&gt; Appendix A includes Linux<br>
&gt; kernel 2.6.32, the ones that I mentioned are the latest updates of thi=
s<br>
&gt; Linux Kernel,<br>
<br>
</div>Then it&#39;s not the same. :-)<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
Thanks,<br>
--<br>
Fernando Gont<br>
SI6 Networks<br>
e-mail: <a href=3D"mailto:fgont@si6networks.com">fgont@si6networks.com</a><=
br>
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492<br>
<br>
<br>
<br>
<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Antonios Atlasis,=
 PhD, MPhil<br>
GXPN, GREM, GPEN, GWAPT, CCIH, GCIA
</div>

--089e01175d07c96e1e0501a2d2ab--


From nobody Wed Aug 27 14:29:33 2014
Return-Path: <antonios.atlasis@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF401A02FE for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 14:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 2ClukukQ6W_g for <ipv6@ietfa.amsl.com>; Wed, 27 Aug 2014 14:29:29 -0700 (PDT)
Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE791A02A3 for <6man@ietf.org>; Wed, 27 Aug 2014 14:29:29 -0700 (PDT)
Received: by mail-ob0-f172.google.com with SMTP id wn1so692450obc.31 for <6man@ietf.org>; Wed, 27 Aug 2014 14:29:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hWvcZ9Tsj/8Tq93v7zUMo/ZCHa6CoYUTfi/1No1huZQ=; b=aol4m/QuXd92Kzi+wUYSdxtsvlYGFW7CW5ImMG6bwSBT5Wbh/7uaS8SiKt5Sw1+1YE 0ChwDGovLIrrfXQkWO7ydWuzOSNKY+Ll6miKC3F93z3u2UfjsUhjlOCMy4yJtxQtWxql 2Z/VklNLmp8gD2b3PRfSml57w6QH0bZTaLHyTy4Zn6n9kfGNmeQXlW8OPNxzKKn6YgSt SqhAC8SnXms2ezHS64ZglMMlYIBkDcjWEdzLuXls6qykmvVMcuTHH4C1Bzu2lOQ2o3C+ OKJ5CZ+zRdNrLECKbayL91qBX3eI46Mr7BukhHa8eBI8xY95b5y2Yi3PXpEErE8qa8SI dVcg==
MIME-Version: 1.0
X-Received: by 10.182.87.167 with SMTP id az7mr37037850obb.41.1409174968721; Wed, 27 Aug 2014 14:29:28 -0700 (PDT)
Received: by 10.202.228.205 with HTTP; Wed, 27 Aug 2014 14:29:28 -0700 (PDT)
In-Reply-To: <53FE41A9.5070304@gmail.com>
References: <20140827174304.18733.67331.idtracker@ietfa.amsl.com> <53FE1D07.5060309@gont.com.ar> <53FE41A9.5070304@gmail.com>
Date: Thu, 28 Aug 2014 00:29:28 +0300
Message-ID: <CADoTVZJXKASUoOaAL8v=C_NQayohURs6LCDmcTt=B568OTEvBA@mail.gmail.com>
Subject: Re: Revision of the IPv6 atomic frag deprecation I-D (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-01.txt)
From: Antonios Atlasis <antonios.atlasis@gmail.com>
To: Fernando Gont <fernando@gont.com.ar>, Fernando Gont <fgont@si6networks.com>
Content-Type: multipart/alternative; boundary=089e0111c0326fea270501a31d83
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/_T2VZtgFSRTFQPKNJtZgqb-e7Es
Cc: "6man@ietf.org" <6man@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Aug 2014 21:29:32 -0000

--089e0111c0326fea270501a31d83
Content-Type: text/plain; charset=UTF-8

Hi Fernando,

by no means I want to start / continue any kind of disagreement, I just
believe that when a document is written today, it would be great if it
could be included as much up-to-date information as possible.  To this end,
if the latest update of the Linux kernel 2.6.32 family generates Atomic
Fragments, especially if this is used by one of the most popular Linux
enterprise systems, it should also be taken into consideration (btw, do you
know which exact version/system of 2.6.32 failed to generate Atomic
Fragments in response to PTB with MTU < 1280?). Similarly for FreeBSD, as
you also write at rfc6946, this behaviour has changed at version 8.2 (and
later, I suppose). So, I would prefer to read about the latest updates of
these families and not about the previous / oldest versions.

The above note may change nothing regarding the main point of deprecation
of Atomic Fragments and it was not intended to be any kind of criticism, it
was just driven by my personal way of thinking of trying to include as much
up-to-date information as possible in my documents. That's all

Regards

Antonios


2014-08-27 23:38 GMT+03:00 Brian E Carpenter <brian.e.carpenter@gmail.com>:

> Fernando,
>
> Wow, what a lot of detailed work! I'll give my top-level views:
>
> 1. We need to ask the RFC 6145 authors to comment on the *accuracy*
> of the proposed revisions and whether they have any unintended
> side effects.
>
> 2. Then we need to decide whether the change is or isn't desirable
> on balance. (I haven't really made up my mind yet on this, but I've
> certainly always found this to be a very messay aspect of the SIIT
> model.)
>
> 3. Finally, if we go ahead, we would need to decide whether it
> would be simpler to publish RFC6145bis rather than spell out
> all the diffs in this document.
>
> Regards
>    Brian
>
> On 28/08/2014 06:01, Fernando Gont wrote:
> > Folks,
> >
> > We have published a revision of the aforementioned document:
> > <
> http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-01.txt
> >
> >
> > I'll try to summarize the changes incorporated in this version:
> >
> > * Section 1 and Section 2 have been augmented to better explain the
> > rationale for the proposed update -- not just interms of the security
> > vulnerability being discussed, but also in terms of protocol robustness.
> >
> > * We have relaxed the update to RFC2460, noting that ICMP PTB<1280
> > should not elicit atom frags (rather than "these packets should be
> > dropped"), as suggested by Bob Briscoe
> >
> > * We have clarified the rationale for relying on IPv6 atom frags as part
> > of the SIIT design decision.
> >
> > * We have incorporated an Appendix with a small and non-exhaustive
> > survey which shows that quite a few widely deployed OSes fail to
> > generate IPv6 atomic fragments in response to ICMPv6 PTB<1280.
> >
> > * We have clarified why you cannot simply check the IPv6 Source Address
> > representing IPv4 nodes as a general mitigation to the vulnerability
> > discussed in this document. -- this is based on the thread with Tatuya
> > Jinmei.
> >
> > * We have included (in Section 6) a formal update to RFC6145, as
> > suggested by Brian Carpenter. If the working group decides to take on
> > this document, a second-order decision might be whether to update RFC
> > 2460 and RFC6145 in this doc, or just focus on atom frag generation
> > here, and do a complete RFC6145bis in a separate document. The whole
> > Section 6 is mostly meant as "this is what one should patch in RFC6145
> > such that it does not rely on IPv6 atomic fragments". However, we note
> > that the core of this document is really all Sections other than Section
> > 6, since those are the ones providing the rationale for deprecating the
> > generation of IPv6 atomic fragments.
> >
> >
> > Please do let us know if we have missed anything, if there's anything
> > that needs further clarification, or if you like the I-D as is.
> >
> > Thanks so much!
> > Fernando (and co-authors)
> >
> >
> >
> >
> > -------- Forwarded Message --------
> > Subject: New Version Notification for
> > draft-gont-6man-deprecate-atomfrag-generation-01.txt
> > Date: Wed, 27 Aug 2014 10:43:04 -0700
> > From: internet-drafts@ietf.org
> > To: Will(Shucheng) Liu <liushucheng@huawei.com>, Shucheng LIU (Will)
> > <liushucheng@huawei.com>, Tore Anderson <tore@redpill-linpro.com>, Tore
> > Anderson <tore@redpill-linpro.com>, Fernando Gont
> > <fgont@si6networks.com>, Fernando Gont <fgont@si6networks.com>
> >
> >
> > A new version of I-D,
> draft-gont-6man-deprecate-atomfrag-generation-01.txt
> > has been successfully submitted by Fernando Gont and posted to the
> > IETF repository.
> >
> > Name:         draft-gont-6man-deprecate-atomfrag-generation
> > Revision:     01
> > Title:                Deprecating the Generation of IPv6 Atomic Fragments
> > Document date:        2014-08-27
> > Group:                Individual Submission
> > Pages:                17
> > URL:
> >
> http://www.ietf.org/internet-drafts/draft-gont-6man-deprecate-atomfrag-generation-01.txt
> > Status:
> >
> https://datatracker.ietf.org/doc/draft-gont-6man-deprecate-atomfrag-generation/
> > Htmlized:
> >
> http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfrag-generation-01
> > Diff:
> >
> http://www.ietf.org/rfcdiff?url2=draft-gont-6man-deprecate-atomfrag-generation-01
> >
> > Abstract:
> >    The core IPv6 specification requires that when a host receives an
> >    ICMPv6 "Packet Too Big" message reporting a "Next-Hop MTU" smaller
> >    than 1280, the host includes a Fragment Header in all subsequent
> >    packets sent to that destination, without reducing the assumed Path-
> >    MTU.  The simplicity with which ICMPv6 "Packet Too Big" messages can
> >    be forged, coupled with the widespread filtering of IPv6 fragments,
> >    results in an attack vector that can be leveraged for Denial of
> >    Service purposes.  This document briefly discusses the aforementioned
> >    attack vector, and formally updates RFC2460 such that generation of
> >    IPv6 atomic fragments is deprecated, thus eliminating the
> >    aforementioned attack vector.  Additionally, it formally updates
> >    RFC6145 such that the Stateless IP/ICMP Translation Algorithm (SIIT)
> >    does not rely on the generation of IPv6 atomic fragments, thus
> >    improving the robustness of the protocol.
> >
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> >
> >
> >
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>



-- 
=====================
Antonios Atlasis, PhD, MPhil
GXPN, GREM, GPEN, GWAPT, CCIH, GCIA

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

<div dir=3D"ltr"><div><div>Hi Fernando, <br><br></div>by no means I want to=
 start / continue any kind of disagreement, I just believe that when a docu=
ment is written today, it would be great if it could be included as much up=
-to-date information as possible.=C2=A0 To this end, if the latest update o=
f the Linux kernel 2.6.32 family generates Atomic Fragments, especially if =
this is used by one of the most popular Linux enterprise systems, it should=
 also be taken into consideration (btw, do you know which exact version/sys=
tem of 2.6.32 failed to generate Atomic Fragments in response to PTB with M=
TU &lt; 1280?). Similarly for FreeBSD, as you also write at rfc6946, this b=
ehaviour has changed at version 8.2 (and later, I suppose). So, I would pre=
fer to read about the latest updates of these families and not about the pr=
evious / oldest versions.<br>
<br></div><div>The above note may change nothing regarding the main point o=
f deprecation of Atomic Fragments and it was not intended to be any kind of=
 criticism, it was just driven by my personal way of thinking of trying to =
include as much up-to-date information as possible in my documents. That&#3=
9;s all<br>
<br></div><div>Regards<br><br>Antonios<br></div></div><div class=3D"gmail_e=
xtra"><br><br><div class=3D"gmail_quote">2014-08-27 23:38 GMT+03:00 Brian E=
 Carpenter <span dir=3D"ltr">&lt;<a href=3D"mailto:brian.e.carpenter@gmail.=
com" target=3D"_blank">brian.e.carpenter@gmail.com</a>&gt;</span>:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Fernando,<br>
<br>
Wow, what a lot of detailed work! I&#39;ll give my top-level views:<br>
<br>
1. We need to ask the RFC 6145 authors to comment on the *accuracy*<br>
of the proposed revisions and whether they have any unintended<br>
side effects.<br>
<br>
2. Then we need to decide whether the change is or isn&#39;t desirable<br>
on balance. (I haven&#39;t really made up my mind yet on this, but I&#39;ve=
<br>
certainly always found this to be a very messay aspect of the SIIT<br>
model.)<br>
<br>
3. Finally, if we go ahead, we would need to decide whether it<br>
would be simpler to publish RFC6145bis rather than spell out<br>
all the diffs in this document.<br>
<br>
Regards<br>
<span class=3D"HOEnZb"><font color=3D"#888888">=C2=A0 =C2=A0Brian<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
On 28/08/2014 06:01, Fernando Gont wrote:<br>
&gt; Folks,<br>
&gt;<br>
&gt; We have published a revision of the aforementioned document:<br>
&gt; &lt;<a href=3D"http://www.ietf.org/internet-drafts/draft-gont-6man-dep=
recate-atomfrag-generation-01.txt" target=3D"_blank">http://www.ietf.org/in=
ternet-drafts/draft-gont-6man-deprecate-atomfrag-generation-01.txt</a>&gt;<=
br>

&gt;<br>
&gt; I&#39;ll try to summarize the changes incorporated in this version:<br=
>
&gt;<br>
&gt; * Section 1 and Section 2 have been augmented to better explain the<br=
>
&gt; rationale for the proposed update -- not just interms of the security<=
br>
&gt; vulnerability being discussed, but also in terms of protocol robustnes=
s.<br>
&gt;<br>
&gt; * We have relaxed the update to RFC2460, noting that ICMP PTB&lt;1280<=
br>
&gt; should not elicit atom frags (rather than &quot;these packets should b=
e<br>
&gt; dropped&quot;), as suggested by Bob Briscoe<br>
&gt;<br>
&gt; * We have clarified the rationale for relying on IPv6 atom frags as pa=
rt<br>
&gt; of the SIIT design decision.<br>
&gt;<br>
&gt; * We have incorporated an Appendix with a small and non-exhaustive<br>
&gt; survey which shows that quite a few widely deployed OSes fail to<br>
&gt; generate IPv6 atomic fragments in response to ICMPv6 PTB&lt;1280.<br>
&gt;<br>
&gt; * We have clarified why you cannot simply check the IPv6 Source Addres=
s<br>
&gt; representing IPv4 nodes as a general mitigation to the vulnerability<b=
r>
&gt; discussed in this document. -- this is based on the thread with Tatuya=
<br>
&gt; Jinmei.<br>
&gt;<br>
&gt; * We have included (in Section 6) a formal update to RFC6145, as<br>
&gt; suggested by Brian Carpenter. If the working group decides to take on<=
br>
&gt; this document, a second-order decision might be whether to update RFC<=
br>
&gt; 2460 and RFC6145 in this doc, or just focus on atom frag generation<br=
>
&gt; here, and do a complete RFC6145bis in a separate document. The whole<b=
r>
&gt; Section 6 is mostly meant as &quot;this is what one should patch in RF=
C6145<br>
&gt; such that it does not rely on IPv6 atomic fragments&quot;. However, we=
 note<br>
&gt; that the core of this document is really all Sections other than Secti=
on<br>
&gt; 6, since those are the ones providing the rationale for deprecating th=
e<br>
&gt; generation of IPv6 atomic fragments.<br>
&gt;<br>
&gt;<br>
&gt; Please do let us know if we have missed anything, if there&#39;s anyth=
ing<br>
&gt; that needs further clarification, or if you like the I-D as is.<br>
&gt;<br>
&gt; Thanks so much!<br>
&gt; Fernando (and co-authors)<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; -------- Forwarded Message --------<br>
&gt; Subject: New Version Notification for<br>
&gt; draft-gont-6man-deprecate-atomfrag-generation-01.txt<br>
&gt; Date: Wed, 27 Aug 2014 10:43:04 -0700<br>
&gt; From: <a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf=
.org</a><br>
&gt; To: Will(Shucheng) Liu &lt;<a href=3D"mailto:liushucheng@huawei.com">l=
iushucheng@huawei.com</a>&gt;, Shucheng LIU (Will)<br>
&gt; &lt;<a href=3D"mailto:liushucheng@huawei.com">liushucheng@huawei.com</=
a>&gt;, Tore Anderson &lt;<a href=3D"mailto:tore@redpill-linpro.com">tore@r=
edpill-linpro.com</a>&gt;, Tore<br>
&gt; Anderson &lt;<a href=3D"mailto:tore@redpill-linpro.com">tore@redpill-l=
inpro.com</a>&gt;, Fernando Gont<br>
&gt; &lt;<a href=3D"mailto:fgont@si6networks.com">fgont@si6networks.com</a>=
&gt;, Fernando Gont &lt;<a href=3D"mailto:fgont@si6networks.com">fgont@si6n=
etworks.com</a>&gt;<br>
&gt;<br>
&gt;<br>
&gt; A new version of I-D, draft-gont-6man-deprecate-atomfrag-generation-01=
.txt<br>
&gt; has been successfully submitted by Fernando Gont and posted to the<br>
&gt; IETF repository.<br>
&gt;<br>
&gt; Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-gont-6man-deprecate-atomf=
rag-generation<br>
&gt; Revision:=C2=A0 =C2=A0 =C2=A001<br>
&gt; Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Deprecat=
ing the Generation of IPv6 Atomic Fragments<br>
&gt; Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2014-08-27<br>
&gt; Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu=
al Submission<br>
&gt; Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 17<br>
&gt; URL:<br>
&gt; <a href=3D"http://www.ietf.org/internet-drafts/draft-gont-6man-depreca=
te-atomfrag-generation-01.txt" target=3D"_blank">http://www.ietf.org/intern=
et-drafts/draft-gont-6man-deprecate-atomfrag-generation-01.txt</a><br>
&gt; Status:<br>
&gt; <a href=3D"https://datatracker.ietf.org/doc/draft-gont-6man-deprecate-=
atomfrag-generation/" target=3D"_blank">https://datatracker.ietf.org/doc/dr=
aft-gont-6man-deprecate-atomfrag-generation/</a><br>
&gt; Htmlized:<br>
&gt; <a href=3D"http://tools.ietf.org/html/draft-gont-6man-deprecate-atomfr=
ag-generation-01" target=3D"_blank">http://tools.ietf.org/html/draft-gont-6=
man-deprecate-atomfrag-generation-01</a><br>
&gt; Diff:<br>
&gt; <a href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-gont-6man-deprecat=
e-atomfrag-generation-01" target=3D"_blank">http://www.ietf.org/rfcdiff?url=
2=3Ddraft-gont-6man-deprecate-atomfrag-generation-01</a><br>
&gt;<br>
&gt; Abstract:<br>
&gt;=C2=A0 =C2=A0 The core IPv6 specification requires that when a host rec=
eives an<br>
&gt;=C2=A0 =C2=A0 ICMPv6 &quot;Packet Too Big&quot; message reporting a &qu=
ot;Next-Hop MTU&quot; smaller<br>
&gt;=C2=A0 =C2=A0 than 1280, the host includes a Fragment Header in all sub=
sequent<br>
&gt;=C2=A0 =C2=A0 packets sent to that destination, without reducing the as=
sumed Path-<br>
&gt;=C2=A0 =C2=A0 MTU.=C2=A0 The simplicity with which ICMPv6 &quot;Packet =
Too Big&quot; messages can<br>
&gt;=C2=A0 =C2=A0 be forged, coupled with the widespread filtering of IPv6 =
fragments,<br>
&gt;=C2=A0 =C2=A0 results in an attack vector that can be leveraged for Den=
ial of<br>
&gt;=C2=A0 =C2=A0 Service purposes.=C2=A0 This document briefly discusses t=
he aforementioned<br>
&gt;=C2=A0 =C2=A0 attack vector, and formally updates RFC2460 such that gen=
eration of<br>
&gt;=C2=A0 =C2=A0 IPv6 atomic fragments is deprecated, thus eliminating the=
<br>
&gt;=C2=A0 =C2=A0 aforementioned attack vector.=C2=A0 Additionally, it form=
ally updates<br>
&gt;=C2=A0 =C2=A0 RFC6145 such that the Stateless IP/ICMP Translation Algor=
ithm (SIIT)<br>
&gt;=C2=A0 =C2=A0 does not rely on the generation of IPv6 atomic fragments,=
 thus<br>
&gt;=C2=A0 =C2=A0 improving the robustness of the protocol.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Please note that it may take a couple of minutes from the time of subm=
ission<br>
&gt; until the htmlized version and diff are available at <a href=3D"http:/=
/tools.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br>
&gt;<br>
&gt; The IETF Secretariat<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">-----------------------=
---------------------------------------------<br>
IETF IPv6 working group mailing list<br>
<a href=3D"mailto:ipv6@ietf.org">ipv6@ietf.org</a><br>
Administrative Requests: <a href=3D"https://www.ietf.org/mailman/listinfo/i=
pv6" target=3D"_blank">https://www.ietf.org/mailman/listinfo/ipv6</a><br>
--------------------------------------------------------------------<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Antonios Atlasis,=
 PhD, MPhil<br>
GXPN, GREM, GPEN, GWAPT, CCIH, GCIA
</div>

--089e0111c0326fea270501a31d83--


From nobody Thu Aug 28 00:42:42 2014
Return-Path: <tore@fud.no>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CC51A06D5 for <ipv6@ietfa.amsl.com>; Thu, 28 Aug 2014 00:42:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level: 
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham
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 4MQqpACT44dI for <ipv6@ietfa.amsl.com>; Thu, 28 Aug 2014 00:42:33 -0700 (PDT)
Received: from greed.fud.no (greed.fud.no [IPv6:2a02:c0:1001:100::145]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F541A06D4 for <6man@ietf.org>; Thu, 28 Aug 2014 00:42:33 -0700 (PDT)
Received: from [2a02:c0:2:1:1194:17:0:1000] (port=51508 helo=echo.ms.redpill-linpro.com) by greed.fud.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <tore@fud.no>) id 1XMuLl-0003R8-26; Thu, 28 Aug 2014 09:42:29 +0200
Message-ID: <53FEDD0B.7050703@fud.no>
Date: Thu, 28 Aug 2014 09:40:59 +0200
From: Tore Anderson <tore@fud.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>,  Fernando Gont <fernando@gont.com.ar>
Subject: Re: Revision of the IPv6 atomic frag deprecation I-D (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-01.txt)
References: <20140827174304.18733.67331.idtracker@ietfa.amsl.com> <53FE1D07.5060309@gont.com.ar> <53FE41A9.5070304@gmail.com>
In-Reply-To: <53FE41A9.5070304@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/uaq7QLYHH57eS1vLGwFK-Aqomr0
Cc: "6man@ietf.org" <6man@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Aug 2014 07:42:39 -0000

* Brian E Carpenter

> 2. Then we need to decide whether the change is or isn't desirable
> on balance. (I haven't really made up my mind yet on this, but I've
> certainly always found this to be a very messay aspect of the SIIT
> model.)

Having used SIIT for quite a while, I think that the new approach is
quite acceptable. In my experience, IPv4 paths with MTUs < 1260 are
extremely infrequent anyway, so the problem solved (either by the atomic
fragments approach or the new one we propose) is pretty much only of
academic interest anyway, the way I see it.

> 3. Finally, if we go ahead, we would need to decide whether it
> would be simpler to publish RFC6145bis rather than spell out
> all the diffs in this document.

I'd prefer a RFC6145bis. Reading first one document and then reading
another to mentally "patch" the information in the first one isn't a
good way to convey information...

Tore


From nobody Thu Aug 28 04:57:46 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7541C1A0235 for <ipv6@ietfa.amsl.com>; Thu, 28 Aug 2014 04:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 A3mnAcjJAHPm for <ipv6@ietfa.amsl.com>; Thu, 28 Aug 2014 04:57:41 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0EEE1A0387 for <6man@ietf.org>; Thu, 28 Aug 2014 04:57:37 -0700 (PDT)
Received: from [2001:5c0:1000:a::def] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XMyKc-0001gU-9z; Thu, 28 Aug 2014 13:57:34 +0200
Message-ID: <53FF12B6.403@si6networks.com>
Date: Thu, 28 Aug 2014 08:29:58 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>,  Fernando Gont <fernando@gont.com.ar>
Subject: Re: Revision of the IPv6 atomic frag deprecation I-D (Fwd: New Version Notification for draft-gont-6man-deprecate-atomfrag-generation-01.txt)
References: <20140827174304.18733.67331.idtracker@ietfa.amsl.com> <53FE1D07.5060309@gont.com.ar> <53FE41A9.5070304@gmail.com>
In-Reply-To: <53FE41A9.5070304@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/7TBGkZ-Rncy4bahLvDkPbdcph_c
Cc: "6man@ietf.org" <6man@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Aug 2014 11:57:43 -0000

Hi, Brian,

Thanks so much for your feedback! Please let me offer a clarification
and some comments in-line...

On 08/27/2014 05:38 PM, Brian E Carpenter wrote:
> 
> 1. We need to ask the RFC 6145 authors to comment on the *accuracy* 
> of the proposed revisions and whether they have any unintended side
> effects.
> 
> 2. Then we need to decide whether the change is or isn't desirable on
> balance. (I haven't really made up my mind yet on this, but I've 
> certainly always found this to be a very messay aspect of the SIIT 
> model.)

The alternative approach that we have proposed is essentially already
offered n Section 6 (starting right in page 25) of RFC 6145, as a
workaround to deal with scenarios where nodes e.g. fail to generate IPv6
atomic fragments.

i.e., what we're proposing is not a "brand new way of SIIT operation",
but rather making the default something that is already there in RFC6145.

FWIW, Section 6 (Updating RFC6145) of *our* document is rather lengthy,
but just because there are several parts of RFC6145 where atomic
fragments are mentioned.


> 3. Finally, if we go ahead, we would need to decide whether it would
> be simpler to publish RFC6145bis rather than spell out all the diffs
> in this document.

I think it would be better to have our document just deprecate the
generation of IPv6 atomic fragments and RFC6145bis do the RFC6145
updates.. Otherwise, for a guy reading RFC6145, things gets too messy,
since RFC6145 needs to be patched here and there.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





From nobody Thu Aug 28 08:56:20 2014
Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975001A875A for <ipv6@ietfa.amsl.com>; Thu, 28 Aug 2014 08:56:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.978
X-Spam-Level: 
X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 WZR9rKXphuXq for <ipv6@ietfa.amsl.com>; Thu, 28 Aug 2014 08:56:16 -0700 (PDT)
Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E83B1A02E1 for <ipv6@ietf.org>; Thu, 28 Aug 2014 08:56:16 -0700 (PDT)
Received: by mail-wi0-f181.google.com with SMTP id e4so1153649wiv.14 for <ipv6@ietf.org>; Thu, 28 Aug 2014 08:56:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lGA7bUb38Uf1TAY+QmfhjdzGhGk+9frxIH1Uf+t2dMk=; b=npdLEk6T1vtZdP8Hle+gwJmHvsUaOd2/3xQVdQMpeHnArob2Ts3W3xgvv/SYiQOVsa y8JpupcQvdnsemXgRp47d2Pw5g1WKX/YmKipT2nOeKeLZQ4TrJSpqyv0VRX5N5s3EHJz x0z/Jy926SxMfBh1y1RyXsHFPAXs5VUv79DTDw9UB7VqQeRx0dIDa6wskXyXtFJPyPIG VbYnTqdKTF8FQ0x3s9BM71Mkrs5bqgPojP25K+k3DiTBxCjrEdjW4wmpBehluQH45v0p 0ydBcW7EOOcNwicYPqdjKlcPkiwx+yUxicocwx2TS8W/ObCcCQ8+4hUN7L1r4TAiJnSx ropQ==
MIME-Version: 1.0
X-Received: by 10.181.13.116 with SMTP id ex20mr7300645wid.31.1409241373553; Thu, 28 Aug 2014 08:56:13 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.123.164 with HTTP; Thu, 28 Aug 2014 08:56:13 -0700 (PDT)
In-Reply-To: <1ac4ed99b2024cefb2a0dc24fd0fa7c4@CO1PR05MB442.namprd05.prod.outlook.com>
References: <CAJE_bqfdOZi6U2AqUx3k9kUi_fO1=sNW-k_3b4Kg4Oy2qZdSrA@mail.gmail.com> <1ac4ed99b2024cefb2a0dc24fd0fa7c4@CO1PR05MB442.namprd05.prod.outlook.com>
Date: Thu, 28 Aug 2014 08:56:13 -0700
X-Google-Sender-Auth: zkw-12nUYXsdsokX4EP-_wFvyVE
Message-ID: <CAJE_bqdUhfKVtYREMMdYQacW7pWOM-JW2KerGtN6C20Md524HQ@mail.gmail.com>
Subject: Re: draft-gont-6man-nd-opt-validation-00
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
To: Ronald Bonica <rbonica@juniper.net>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/FuDBG3RSApRizDG4-CUp9_-rvxc
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Aug 2014 15:56:17 -0000

At Wed, 27 Aug 2014 18:51:44 +0000,
Ronald Bonica <rbonica@juniper.net> wrote:

> > - Section 5: what's the source of this restriction?
> >
> >    The Prefix Length is an 8-bit unsigned integer that specifies the
> >    prefix length (i.e., the number of leading bits in the Prefix field
> >    that are significant).  Its value MUST be greater than or equal to
> >    32.
> [RPB]
> I thought that this validation might be a little controversial ;-)
>
> It's clear that PIO with ::/0 is pathological. The same for fe00::/8.
>
> But it's not clear what the largest sane prefix length is. Do you have a suggestion?

I'm not sure if we can effectively impose a simple restriction on the
prefix length.  Even a prefix length of 0 (which means a prefix of
::/0) with the L bit on might make sense if this is a single-link
network with a "router" effectively acting as an RA server to tell
hosts that all unicast addresses are on-link by default (while ::/0
covers others addresses such as multicast addresses, but hosts should
handle these as an exception anyway).

Maybe this is a good example of why we'd generally need a discussion
on the rationale of the restrictions.  Depending on why we want to
impose such a limitation, we may be able to find a reasonable value or
we may find it ineffective to impose a limitation on some specific
cases.

--
JINMEI, Tatuya


From nobody Thu Aug 28 10:14:36 2014
Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847D21A0B04 for <ipv6@ietfa.amsl.com>; Thu, 28 Aug 2014 10:14:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.378
X-Spam-Level: 
X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 rkJxtVO0Z3vL for <ipv6@ietfa.amsl.com>; Thu, 28 Aug 2014 10:14:32 -0700 (PDT)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 901AA1A8834 for <ipv6@ietf.org>; Thu, 28 Aug 2014 10:14:07 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id m15so1032858wgh.23 for <ipv6@ietf.org>; Thu, 28 Aug 2014 10:14:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=n6SeIkR+n8RxfUWHD8ZloBomDnOSSDExoFGSqzSX2gQ=; b=U6DnAWT6Mn+IPX+8gnMvWtOz3tdRH68aaa4zDSWkvG6IYLjAZ9q6IGxEhyyAk3tMW1 wl2m4clFQlc5RKXHorZ8Ub/8GOeD7HgY1Pdwg4qkAnnoDRcII0mzPkPXzyrUjn4LaDCe t/0B2AltfOfTE29WrsapkeDwjv4q0qLgKc8D+L6MO/Uc2tJMnaJ5gd6LiN52Rg0CMj9o zPp2ZGa/bYhnMSye9fgJ04T/5fZijp5ruSJkGVVbpTqBef6xm4sDstgwrgeovbA2TSTt YsBYNnenF8J8Eu7gbduxwbYdLAYzwmnzn2C9IX/juWlVx8o9aRpdJP3nH+k1GWTQeJib BelQ==
MIME-Version: 1.0
X-Received: by 10.180.86.1 with SMTP id l1mr7686761wiz.62.1409246046224; Thu, 28 Aug 2014 10:14:06 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.123.164 with HTTP; Thu, 28 Aug 2014 10:14:06 -0700 (PDT)
In-Reply-To: <53FE36D3.9000606@si6networks.com>
References: <CAJE_bqfdOZi6U2AqUx3k9kUi_fO1=sNW-k_3b4Kg4Oy2qZdSrA@mail.gmail.com> <53FE36D3.9000606@si6networks.com>
Date: Thu, 28 Aug 2014 10:14:06 -0700
X-Google-Sender-Auth: OveLX_XJPRLfYPsQ8lVZJMyEIm4
Message-ID: <CAJE_bqcJ0UdEb-x2wom16JmkqGroh+gNKgAb=4jwn8Fz+pt-2Q@mail.gmail.com>
Subject: Re: draft-gont-6man-nd-opt-validation-00
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
To: Fernando Gont <fgont@si6networks.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/WuzSmUY6yBWVa_QqzfZ2ydnoZNs
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Aug 2014 17:14:34 -0000

At Wed, 27 Aug 2014 16:51:47 -0300,
Fernando Gont <fgont@si6networks.com> wrote:

> > - Related to the previous point, IIRC lla-opt-validation discusses
> > the rationale of the validation, but nd-opt-validation generally
> > only lists the validations.  Is this change intentional?
>
> Yes. The rationale was that, since we're covering many ND options, it
> was better to stick to the validation checks instead of delving into the
> details of the associated attack vectors.

In some cases the rationale is not really clear.  Some specific cases
of lla-opt as discussed before are one example, and the prefix length
in the PIO is another.  I don't think it a good idea to completely omit
background discussions unconditionally.  If we find we need such
additional discussions in too many cases and rather want to keep the
document body concise, one option would be to discuss them in an
appendix as Ron proposed.

> > - Maybe related to some of the previous bullet points, some of the
> > proposed validations (which generally seem to be newly proposed
> > ones?) require the entire ND message be dropped if a certain
> > validation fails while some others just require that particular
> > option be dropped, and it doesn't explain why the former case should
> > be handled differently.  I'd at least like to see the rationale, and
> > in general it seems to be against the sense of Section 9 of RFC
> > 4861.
>
> Not sure what you mean. In this document we try to validate ND options,
> and if an option seems to be malformed, we drop the packet. OTOH,
> Section 9 of RFC4861 just notes that if you *don't recognize* an option,
> you should still parse the other options.
>
> In our case, its not that we couldn't recognize an option, but rather
> that we recognized it as malformed.
>
> That said, I understand that an alternative approach would be to just
> drop the option rather than the whole packet. Me 8not necessarily my
> co-atuhors) could live with that approach, too.

I see there may be a logic leap in my original comment.  Let me
rephrase it: I saw two issues in the mixture of dropping a specific
option and dropping the entire ND message:

1. it's not clear why we have two different actions
2. in the case of dropping the entire message (as this seems to be
   newly introduced in the draft), it may be an overkill

I now understand the intent that would answer issue #1; this draft
considers a certain type of validation failures to be "malformed", and
proposes dropping the entire message for these types of failures.
The intent wasn't obvious to me, and it would help if it explicitly
states the general idea somewhere in the draft.

The second issue is related to my original comment referring to
Section 9 of RFC4861.  I imagined a possibility that a future
extension of the protocol allows, e.g., the length field of PIO >
4 to include some additional information.  Obviously, a host that
doesn't know this extension can't handle this version of PIO, but
should still be able to parse and process other options (which may
contain another PIO in the old format for compatibility) as long as
the entire integrity of the message is preserved.  If it's really a
malicious attempt or data corruption, the host should be able to
detect it once it completes parsing the whole options (e.g., it may
find one ND option is too long for the entire message), at which point
it can/should drop the entire message.

I don't know if RFC4861 Section 9 intended to include this type of
extension, but that's what I tried to say by referring to that section
in this context.

I also think this is another example of why it's generally better to
discuss the rationale of specific restrictions.  If there's a concrete
bad scenario when a node just skips an option instead of dropping the
entire message, such a less likely possibility of option extensions
wouldn't justify the leniency.  Without such a discussion, we'd always
encounter the question of "why".

> > - Section 5: what's the source of this restriction?
> >
> > The Prefix Length is an 8-bit unsigned integer that specifies the
> > prefix length (i.e., the number of leading bits in the Prefix field
> > that are significant).  Its value MUST be greater than or equal to
> > 32.
>
> Of the top of my head, we incorporated a more relaxed sanity check that
> that being employed by other stacks (length == 64 in some cases).
>
> But I do agree that the sanity check is debatable. Thoughts?

See my response to Ron.  I don't have a specific idea right now,
including whether we can really impose a specific restriction.

> > - Section 5: is this adjustment a new proposal of this draft or an
> > existing one? (If it's the latter I should have missed something).
> > And in any case I'm not sure if it really makes sense.  Especially if
> > this is a new proposal I'd like to see more discussion on why we need
> > this:
> >
> > Host SHOULD set the effective Valid Lifetime as follows:
> >
> > EffectiveVL = max(Valid Lifetime, MIN_VALID_LIFETIME)
> >
> > Where EffectiveVL is the effective 'Valid Lifetime', and
> > MIN_VALID_LIFETIME is set to 1800 (seconds).
>
> When sending the RA, RFC4861 specifies a lower limit. Here we're
> enforcing such lower limit, but on the receive side.

??? I'm afraid I'm now totally confused.  Could you specify the exact
part of RFC 4861 that defines the "lower limit"?  As far as I can see,
the only occurrence of the magic number of "1800" in RFC4861 is this:

      MaxRtrAdvInterval
                     The maximum time allowed between sending
                     unsolicited multicast Router Advertisements from
                     the interface, in seconds.  MUST be no less than 4
                     seconds and no greater than 1800 seconds.

Is this where this "MIN_VALID_LIFETIME" comes from?

> This avoids e.g. having a node sending packet with a Valid lifetime of 1
> second, which would make you configure your network interface and right
> after drop such configuration.

But I thought the ND spec actually intends to allow a legitimate
administrator to advertise such a low value of Valid Lifetime, even 0
(maybe to force hosts to send all packets to the router from now on).
RFC4682 has its own defense against too small values for Valid
Lifetime in the context SLAAC, and in my memory we intentionally
didn't do it for the case of on-link determination.

Anyway, more detailed discussion may reveal the need for such a
restriction.  Yet another example of why "why" is generally necessary.

> > - Section 5: I think we should be more precise here:
> >
> > As stated in [RFC4861] the Preferred Lifetime MUST BE less than or
> > equal to the Valid Lifetime.  If an incoming ND message does not
> > pass this validation check, the Prefix Information Option MUST be
> > ignored.
> >
> > Preferred Lifetime is only used for stateless address
> > autoconfiguration, so when we say "PIO MUST be ignored" we should be
> > clear whether it's in terms of on-link determination or SAAC.
>
> FWIW, since the Preferred Lifetime MUST (always) be less than or equal
> to the
> valid lifetime, if the option does not pass this check, we consider it
> to be malformed and hence advice implementation to drop them
>
> >  In the
> > context of the latter, RFC 4862 explicitly requires such PIO be
> > ignored.  In the context of the former, this is certainly odd but
> > doesn't do any actual harm.  So, if the intent is the latter, I'd
> > like to see the rationale, just for the sake of paranoia, etc.
>
> It's a MUST that is not being complied to, essentially.

I don't get this...do you mean, by "not being complied", that this
MUST NOT of RFC4861

      Preferred Lifetime
...
                     Note that the value of this field MUST NOT exceed
                     the Valid Lifetime field to avoid preferring
                     addresses that are no longer valid.

is not complied because hosts do not check the preferred lifetime (and
do "allow" pltime > vltime as a result) as part of on-link determination?
Clearly it's really enforced in the context RFC4862 as described in
step c of Section 5.5.3, and I believe sensible router implementations
prohibit the admin from configuring pltime being larger than vltime.
And, pltime isn't used for on-link determination at all.  I personally
don't regard this situation as "not being complied".

--
JINMEI, Tatuya


From nobody Thu Aug 28 18:04:39 2014
Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3EB1A01DC for <ipv6@ietfa.amsl.com>; Thu, 28 Aug 2014 18:04:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 nqOfi9iIutPh for <ipv6@ietfa.amsl.com>; Thu, 28 Aug 2014 18:04:34 -0700 (PDT)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4EF1A01F6 for <6man@ietf.org>; Thu, 28 Aug 2014 18:04:34 -0700 (PDT)
Received: from cl-1071.udi-01.br.sixxs.net ([2001:1291:200:42e::2]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <fgont@si6networks.com>) id 1XNAcB-00056t-7c; Fri, 29 Aug 2014 03:04:31 +0200
Message-ID: <53FFD198.4040704@si6networks.com>
Date: Thu, 28 Aug 2014 22:04:24 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: "6man@ietf.org" <6man@ietf.org>
Subject: Transmission and Processing of IPv6 Options (Fwd: New Version Notification for draft-gont-6man-ipv6-opt-transmit-00.txt)
References: <20140829005522.6354.39129.idtracker@ietfa.amsl.com>
In-Reply-To: <20140829005522.6354.39129.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20140829005522.6354.39129.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/f9SWwvKL_vhpoo3Fu8DmEf_RRac
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Aug 2014 01:04:38 -0000

Folks,

We have published a new I-D entitled "Transmission and Processing of
IPv6 Options". It is meant to complement RFC7045.

The I-D is available at:
<http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-opt-transmit-00.txt>

Any comments will be very appreciated.

Thanks!

Best regards,
Fernando (and co-authors)




-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-6man-ipv6-opt-transmit-00.txt
Date: Thu, 28 Aug 2014 17:55:22 -0700
From: internet-drafts@ietf.org
To: Will(Shucheng) Liu <liushucheng@huawei.com>, Shucheng LIU (Will)
<liushucheng@huawei.com>, Fernando Gont <fgont@si6networks.com>, Ron
Bonica <rbonica@juniper.net>, Fernando Gont <fgont@si6networks.com>,
Ronald P. Bonica <rbonica@juniper.net>


A new version of I-D, draft-gont-6man-ipv6-opt-transmit-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-6man-ipv6-opt-transmit
Revision:	00
Title:		Transmission and Processing of IPv6 Options
Document date:	2014-08-28
Group:		Individual Submission
Pages:		14
URL:
http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-opt-transmit-00.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-6man-ipv6-opt-transmit/
Htmlized:
http://tools.ietf.org/html/draft-gont-6man-ipv6-opt-transmit-00


Abstract:
   Various IPv6 options have been standardized since the core IPv6
   standard was first published.  This document updates RFC 2460 to
   clarify how nodes should deal with such IPv6 options and with any
   options that are defined in the future.  It complements [RFC7045],
   which offers a similar clarification regarding IPv6 Extension
   Headers.





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

The IETF Secretariat