From nobody Sun Dec 2 23:47:02 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3998130E03 for ; Sun, 2 Dec 2018 23:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjPr0cy26Qsm for ; Sun, 2 Dec 2018 23:46:57 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 46751124C04 for ; Sun, 2 Dec 2018 23:46:57 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id y20so12641825qtm.13 for ; Sun, 02 Dec 2018 23:46:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Iii/QH6CjFhbcBe4EakvT/NxdG1fmvJLDinkHCLGWa0=; b=ENgRMBq81gUOZQDcMX4/Wus6Ca1X/dlyXf87l9J9gs/R/izHdhe+7mxctpmTvs7e22 4dryGjgf36HpazrmADei3VsKCVdoxAgBL/CfEbCBZMio7fFRMvRE4cxRgaBpDdbFjErj pBPqpD62Q6+5N0aRV+aULI9fqFZSIAYp3mPr7E6C6wvh2vhva64t9kTMuY2ojkiqXu/w 1QeKyatXVNzD/YN/VjKdNNWsoGbh7xy/EWOhvmcVs+rEdp79G7xEwN3N5E/nFiA8QTSt Rlxmc76JnhwLSGpzH6fiBw0CnOvIU7NnV40jxhlscYLEJHjtNPZzqAov64S6SFqa07Bj ziVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Iii/QH6CjFhbcBe4EakvT/NxdG1fmvJLDinkHCLGWa0=; b=elnFhO2DRayDCxjt4gKMU49K0wMVkKkNfrAt2e1FegI1F5zkqpDSSXEgdKMi66J6Tr KQr6oEcHPjkZUDJx0RF+wNxrPd31yVmGu3Se5c50kjParNI360mdCQCodOoe0111lDSx F+plUjAZR16/ZLeK31FpF+QQr6Wj6ZPB+jXhAYI4VAos6Buvq8syYQbUKJkE7ZctMh84 vRauCiglTgLAsqVkXopnKu+pTQDajHCZ0IqrjpWZkx5wNthRQYkxHOQMK2aGDHiczIf8 COTstdD/5b6I8gxaU9z7dJiTeGSGqY3fAiStYL3HyzirhLf5orn+EMBnXLuMf9qRwwMr tEMg== X-Gm-Message-State: AA+aEWZLUf3ZQjKOA4fjDBLNWtnM3m4wO/gpKMH9xAB1V3M8PXuT09t3 1lUpLtm96h4XTRrP9z5Ieh3jb4F6Q/kzDu1qlpQ= X-Google-Smtp-Source: AFSGD/W0chNrUHuk/dQgK0hMwvt31LMRYgZFXABGXrTbizAspqQB/VprYnL8nXw717gSxd9R13wUs31OqDPT/w2mdxI= X-Received: by 2002:ac8:528b:: with SMTP id s11mr13859259qtn.199.1543823216384; Sun, 02 Dec 2018 23:46:56 -0800 (PST) MIME-Version: 1.0 References: <30D71C7B-1FBF-49C2-A5C6-40948550CA69@consulintel.es> <007D3C39-C6F2-4F80-8AB0-4972DE692554@apple.com> In-Reply-To: <007D3C39-C6F2-4F80-8AB0-4972DE692554@apple.com> From: Davey Song Date: Mon, 3 Dec 2018 15:46:43 +0800 Message-ID: To: tpauly@apple.com Cc: jordi.palet=40consulintel.es@dmarc.ietf.org, v6ops@ietf.org Content-Type: multipart/alternative; boundary="000000000000689f83057c195a72" Archived-At: Subject: Re: [v6ops] draft-xie-v6ops-network-happyeyeballs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 07:47:01 -0000 --000000000000689f83057c195a72 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I checked related work in IPPM WG and quote RFC 2681 for round-trip delay metric. I'm looking forward to more input from IPPM to fit NHE usecase. btw, thanks for your mail to IPPM. Davey On Fri, 30 Nov 2018 at 07:01, Tommy Pauly wrote: > Even with non-customer traffic, is syslog really the state of the art for > sending data back to servers? Do you want anyone and everyone to see this > information? > > Regarding the active measurements themselves, I think the draft would > benefit from referencing some of the RFCs and drafts from the IPPM Workin= g > Group. We have various documents on one-way and two-way active measuremen= ts > (OWAMP/TWAMP). You can also take a look at some standard ways of reportin= g > the metrics themselves, as described here: > draft-ietf-ippm-initial-registry-08. > > Thanks, > Tommy > > > On Nov 27, 2018, at 5:22 AM, JORDI PALET MARTINEZ 40consulintel.es@dmarc.ietf.org> wrote: > > > > Hi Mikael, > > > > I got the impression that when I originally proposed this, syslog was a > privacy issue because it is sending data from "customers traffic" from > their own devices to the ISP. > > > > But in the actual proposal, the data is NOT from any customer, neither > identifying the customer at all. > > > > So not sure to understand if we have failed to clearly describe the way > we are measuring, or you'd in mind the previous document? > > > > Regards, > > Jordi > > > > > > > > =EF=BB=BF-----Mensaje original----- > > De: v6ops en nombre de Mikael Abrahamsson < > swmike@swm.pp.se> > > Organizaci=C3=B3n: People's Front Against WWW > > Fecha: martes, 27 de noviembre de 2018, 12:45 > > Para: Ron Bonica > > CC: "v6ops@ietf.org list" > > Asunto: Re: [v6ops] draft-xie-v6ops-network-happyeyeballs > > > > On Mon, 26 Nov 2018, Ron Bonica wrote: > > > >> This week, please review and comment on > >> draft-xie-v6ops-network-happyeyeballs. > > > > I think it's a great idea to tell the operator about problems, that > kind > > of telemetry can really help in operating the network. > > > > However, the proposed method of doing it (syslog) and the informatio= n > it > > reports (IP addresses and domains the user is communicating with) ha= s > huge > > privacy implications. Also you have no idea who might be grabbing > this > > information before it even makes it to the ISP). > > > > I think at a minimum there needs to be an encrypted and verified > mechanism > > (https perhaps?) for doing the reporting, so you know where the > report > > goes. > > > > I see three entities that have interest in this information, it's th= e > ISP, > > the operating system manufacturer, and the web site which is having > > problems. If HE fails, I see very little harm (privacy) in telling > the > > website about it using the address family that actually did work. So > that > > could be included. For the device manufacturer, they have "send > > diagnostics information to vendor", so here customers can opt in. Fo= r > the > > ISP, I have no idea. Here it might be better to define an API betwee= n > the > > device vendor and the ISP, so that the device vendor can report > problems > > seen, at an aggregate? I have personally been involved in getting > > operational people from my employer talking to device vendors to > figure > > out what might be wrong, and automating this would be great. > > > > Also, the DNSSEC implications are glossed over grossly. We should > take for > > granted that end devices are running validating resolvers and handle > that > > use-case. > > > > So I'm supportive of the problem statement and it would help ISPs > greatly > > if they could get telemetry from end devices, I just have great > concerns > > over the method proposed in this draft. > > > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.theipv6company.com > > The IPv6 Company > > > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000689f83057c195a72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I checked related work in IPPM WG and quo= te RFC=C2=A02681 for r<= /span>ound-trip= delay metric.=C2=A0 I'm looking forward to more input from IPPM to fit= NHE usecase.
<= span style=3D"font-size:13.3333px">
btw, thanks for your mail = to IPPM.

Davey
=
On Fri, 30 Nov 2018 at 07:0= 1, Tommy Pauly <tpauly@apple.com= > wrote:
Even with non-customer = traffic, is syslog really the state of the art for sending data back to ser= vers? Do you want anyone and everyone to see this information?

Regarding the active measurements themselves, I think the draft would benef= it from referencing some of the RFCs and drafts from the IPPM Working Group= . We have various documents on one-way and two-way active measurements (OWA= MP/TWAMP). You can also take a look at some standard ways of reporting the = metrics themselves, as described here: draft-ietf-ippm-initial-registry-08.=

Thanks,
Tommy

> On Nov 27, 2018, at 5:22 AM, JORDI PALET MARTINEZ <jordi.palet=3D40consul= intel.es@dmarc.ietf.org> wrote:
>
> Hi Mikael,
>
> I got the impression that when I originally proposed this, syslog was = a privacy issue because it is sending data from "customers traffic&quo= t; from their own devices to the ISP.
>
> But in the actual proposal, the data is NOT from any customer, neither= identifying the customer at all.
>
> So not sure to understand if we have failed to clearly describe the wa= y we are measuring, or you'd in mind the previous document?
>
> Regards,
> Jordi
>
>
>
> =EF=BB=BF-----Mensaje original-----
> De: v6ops <v6ops-bounces@ietf.org> en nombre de Mikael Abrahamsson <swmike@swm.pp.se><= br> > Organizaci=C3=B3n: People's Front Against WWW
> Fecha: martes, 27 de noviembre de 2018, 12:45
> Para: Ron Bonica <rbonica@juniper.net>
> CC: "v6ops@ie= tf.org list" <v6ops@ietf.org>
> Asunto: Re: [v6ops] draft-xie-v6ops-network-happyeyeballs
>
>=C2=A0 =C2=A0 On Mon, 26 Nov 2018, Ron Bonica wrote:
>
>> This week, please review and comment on
>> draft-xie-v6ops-network-happyeyeballs.
>
>=C2=A0 =C2=A0 I think it's a great idea to tell the operator about = problems, that kind
>=C2=A0 =C2=A0 of telemetry can really help in operating the network. >
>=C2=A0 =C2=A0 However, the proposed method of doing it (syslog) and the= information it
>=C2=A0 =C2=A0 reports (IP addresses and domains the user is communicati= ng with) has huge
>=C2=A0 =C2=A0 privacy implications. Also you have no idea who might be = grabbing this
>=C2=A0 =C2=A0 information before it even makes it to the ISP).
>
>=C2=A0 =C2=A0 I think at a minimum there needs to be an encrypted and v= erified mechanism
>=C2=A0 =C2=A0 (https perhaps?) for doing the reporting, so you know whe= re the report
>=C2=A0 =C2=A0 goes.
>
>=C2=A0 =C2=A0 I see three entities that have interest in this informati= on, it's the ISP,
>=C2=A0 =C2=A0 the operating system manufacturer, and the web site which= is having
>=C2=A0 =C2=A0 problems. If HE fails, I see very little harm (privacy) i= n telling the
>=C2=A0 =C2=A0 website about it using the address family that actually d= id work. So that
>=C2=A0 =C2=A0 could be included. For the device manufacturer, they have= "send
>=C2=A0 =C2=A0 diagnostics information to vendor", so here customer= s can opt in. For the
>=C2=A0 =C2=A0 ISP, I have no idea. Here it might be better to define an= API between the
>=C2=A0 =C2=A0 device vendor and the ISP, so that the device vendor can = report problems
>=C2=A0 =C2=A0 seen, at an aggregate? I have personally been involved in= getting
>=C2=A0 =C2=A0 operational people from my employer talking to device ven= dors to figure
>=C2=A0 =C2=A0 out what might be wrong, and automating this would be gre= at.
>
>=C2=A0 =C2=A0 Also, the DNSSEC implications are glossed over grossly. W= e should take for
>=C2=A0 =C2=A0 granted that end devices are running validating resolvers= and handle that
>=C2=A0 =C2=A0 use-case.
>
>=C2=A0 =C2=A0 So I'm supportive of the problem statement and it wou= ld help ISPs greatly
>=C2=A0 =C2=A0 if they could get telemetry from end devices, I just have= great concerns
>=C2=A0 =C2=A0 over the method proposed in this draft.
>
>=C2=A0 =C2=A0 --
>=C2=A0 =C2=A0 Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se
>
>=C2=A0 =C2=A0 _______________________________________________
>=C2=A0 =C2=A0 v6ops mailing list
>=C2=A0 =C2=A0 v6ops= @ietf.org
>=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/v= 6ops
>
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged o= r confidential. The information is intended to be for the exclusive use of = the individual(s) named above and further non-explicilty authorized disclos= ure, copying, distribution or use of the contents of this information, even= if partially, including attached files, is strictly prohibited and will be= considered a criminal offense. If you are not the intended recipient be aw= are that any disclosure, copying, distribution or use of the contents of th= is information, even if partially, including attached files, is strictly pr= ohibited, will be considered a criminal offense, so you must reply to the o= riginal sender to inform about this communication and delete it.
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000689f83057c195a72-- From nobody Mon Dec 3 00:02:46 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAD212D4E7 for ; Mon, 3 Dec 2018 00:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDij7MhZONKk for ; Mon, 3 Dec 2018 00:02:42 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 9016D128D68 for ; Mon, 3 Dec 2018 00:02:42 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id k12so12687409qtf.7 for ; Mon, 03 Dec 2018 00:02:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a4niCL8GhEDi8wogtCATfdniFAo/zfk/qLs8rytLZok=; b=huz5xLqThtVLWmo5qN45q4KgRdvyD4rPJo7l9F+6qNmQjkkgm2qa5AAiPLOBxboA4r WnlOnzvINStoYilCiXCWHew9c1OdTSqz4bB/amqh43Qno2Whpqq3JqAFIOjkRGEFOUZX G7hmr7vMhtG/b9z5zgf2cUFmHI/7mjUxsXu/bWfy+QU4WcOaLptrvmAobKIwst1B/dN5 7WiDjbsI8l75cRvu2z70ki7DAuwT2/J84ryN/tXEZgWG4g/gu19UzjQeOO8lf7xkafGJ KjfbanAc2CLq8Uv0AG2Ut7H2CX96iXN/0AjRfyLceZbT0rL7JgdBNpXsvHO15cPUEXfZ I/7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a4niCL8GhEDi8wogtCATfdniFAo/zfk/qLs8rytLZok=; b=KPf+cXKjpCJ7kpBAPc3P+xRp0vE55rokMzUKluOaHttBNeewGRLh7zG/IVOdJQ+qpm 5Ei02Jte7wktTjI22vUzAxQ2Kn0ricyWDKW/vAXrkZTSXYclnggTUfygZTI1wok/wU/v oE2vdkJy/fZ4/8zU5VjQZt+BprV1Z7igMSNM4OIHkkEuHdBE/VX2UZlYKDw4xRF/gqsQ dxiCWe32VY3Zx+xKX0UhDv4UUma+TyT7Oo2vkTjAym4O7HD1lqofae/NmcvYJ5+ZtkDS symNV4mhauKj9s/eAPeyJj29S5IPhBGDd0z0bqKFfW3Lgb3qb7Zv0Yjy8AR/avbNEChN uQcA== X-Gm-Message-State: AA+aEWb8R1j+x00K3CIXodtKEDFoX9q7HyHdSj4pZ+x6Ix0q3BBd1wYJ qxO/3QrVnyOhzPKdrjGyeHiGUm7Ohl/PRhTsVNE= X-Google-Smtp-Source: AFSGD/Xd5Crx6y6IdgJE4PBFe5STnPh5r69h1sss9DQ+jAaHreePH8/xF4yQM6u65yw1l16KugY2dHtF3WJzuHNcNZM= X-Received: by 2002:ac8:70d7:: with SMTP id g23mr14866927qtp.162.1543824161703; Mon, 03 Dec 2018 00:02:41 -0800 (PST) MIME-Version: 1.0 References: <30D71C7B-1FBF-49C2-A5C6-40948550CA69@consulintel.es> <2372941b-67e7-a418-d81c-545aa4ab1010@foobar.org> <3FA83EEE-79ED-40BA-A1C4-37021457A407@apple.com> In-Reply-To: From: Davey Song Date: Mon, 3 Dec 2018 16:02:29 +0800 Message-ID: To: lencse@hit.bme.hu, Tommy Pauly Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="000000000000c10d48057c19920f" Archived-At: Subject: Re: [v6ops] draft-xie-v6ops-network-happyeyeballs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 08:02:45 -0000 --000000000000c10d48057c19920f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, the running code and data-based analysis is important. As we met in IETF103, the authors plan to setup a open source repo in Github doing the following steps : #1 To develop a methord (packets capturing and analysis) to measure and collect the data on the delay of IPv4-fallback issue in dualstack network. We would like to invite network operators to test in their network. This step is helpful for us to understand how severe the problem is. It may vary for different ISPs. #2 if #1 proves it a valid problem to solve, then we are going to develop a active monitoring tool based on NHE draft. We would like to ask volunteers to try and implement in some ISPs network to study the impact and gains. #3 We will see later the result of #1 and #2, and decide how to proceed any document in IETF. For each step, peer review and comments from IETF are helpful. Best regards, Davey On Sat, 1 Dec 2018 at 00:55, Lencse G=C3=A1bor wrote: > > > 11/29/2018 11:53 PM keltez=C3=A9ssel, Tommy Pauly =C3=ADrta: > > > >> On Nov 27, 2018, at 7:52 AM, JORDI PALET MARTINEZ 40consulintel.es@dmarc.ietf.org> wrote: > >> > >> In the previous related work, I was told otherwise: let's the ISPs do > it, not the O/S vendors ... > > I think the point being made here is that open source software can be > created and distributed to ISPs to run in their networks; it doesn't > necessarily require any standard or draft to do it. > > I think you are completely right that the software can be written > without an I-D, however, I think that its specification would benefit > from a matured draft. > > G=C3=A1bor > > > Thanks, > > Tommy > >> Regards, > >> Jordi > >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000c10d48057c19920f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, the running code and data-based anal= ysis is important. As we met in IETF103, the authors plan to setup a open s= ource repo in Github doing the following steps :

=
#1 To develop a methord (packets capturing and analysis) to measure an= d collect the data on the delay of IPv4-fallback issue in dualstack network= . We would like to invite network operators to test in their network. This = step is helpful for us to understand how severe the problem is. It may vary= for different ISPs.

#2 if #1 proves it a valid pr= oblem to solve, then we are going to develop a active monitoring tool based= on NHE draft. We would like to ask volunteers to try and implement in some= ISPs network to study the impact and gains.

#= 3 We will see later the result of #1 and #2, and decide how to proceed any = document in IETF.

For each step, peer review and c= omments from IETF are helpful.=C2=A0

Best regards,=
Davey=C2=A0

On Sat, 1 Dec 2018 at 00:55, Lencse G=C3=A1bor <lencse@hit.bme.hu> wrote:


11/29/2018 11:53 PM keltez=C3=A9ssel, Tommy Pauly =C3=ADrta:
>
>> On Nov 27, 2018, at 7:52 AM, JORDI PALET MARTINEZ <jordi.palet= =3D40c= onsulintel.es@dmarc.ietf.org> wrote:
>>
>> In the previous related work, I was told otherwise: let's the = ISPs do it, not the O/S vendors ...
> I think the point being made here is that open source software can be = created and distributed to ISPs to run in their networks; it doesn't ne= cessarily require any standard or draft to do it.

I think you are completely right that the software can be written
without an I-D, however, I think that its specification would benefit
from a matured draft.

G=C3=A1bor

> Thanks,
> Tommy
>> Regards,
>> Jordi
>>

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000c10d48057c19920f-- From nobody Mon Dec 3 01:13:15 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE4B130E2A for ; Mon, 3 Dec 2018 01:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gV_sZXykFhKN for ; Mon, 3 Dec 2018 01:13:11 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4C9126C01 for ; Mon, 3 Dec 2018 01:13:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1543828386; x=1544433186; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=0l4DUICLbn5G9bH8iU531PqKXQp5JQrgq0rAkyuiZGs=; b=qisRexVdQjvm6 fqGiSgGECqKe3l9Yurjahoo/LbsCjRWw5QitmBk1o0k9gVHD6NMM+j2sigrLGZXn h6I0kypaAJhg3qOn2vKUmGvhSBFQ96el8916KkXdqawf79adiDjTg8sjZJ7Mbrul 0Y9V5AGzrBoRQsSjUi5BgvQPX0Khok= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 03 Dec 2018 10:13:06 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 03 Dec 2018 10:13:05 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006031596.msg for ; Mon, 03 Dec 2018 10:13:04 +0100 X-MDRemoteIP: 2001:470:1f09:495:59f6:b748:6542:ebc6 X-MDHelo: [10.10.10.99] X-MDArrival-Date: Mon, 03 Dec 2018 10:13:04 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1875b8bdb6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.4.181110 Date: Mon, 03 Dec 2018 10:13:02 +0100 From: JORDI PALET MARTINEZ To: Tommy Pauly , JORDI PALET MARTINEZ CC: "v6ops@ietf.org list" Message-ID: <3C05EC2C-BC3F-4398-BD96-3A01CEEC32F0@consulintel.es> Thread-Topic: [v6ops] draft-xie-v6ops-network-happyeyeballs References: <30D71C7B-1FBF-49C2-A5C6-40948550CA69@consulintel.es> <007D3C39-C6F2-4F80-8AB0-4972DE692554@apple.com> In-Reply-To: <007D3C39-C6F2-4F80-8AB0-4972DE692554@apple.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-xie-v6ops-network-happyeyeballs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 09:13:13 -0000 The reason for using syslog is because it is widely deployed by ISPs. Not all the ISPs have other ways of collecting data. So, it is a matter of simplicity towards deploying it, not looking for the = "state of the art" measurement system. What we can do is to provide instead of just syslog, support for IPPM syste= ms and let the ISPs to choose what they have in their own network. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Tommy Pauly Fecha: viernes, 30 de noviembre de 2018, 0:01 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org list" Asunto: Re: [v6ops] draft-xie-v6ops-network-happyeyeballs Even with non-customer traffic, is syslog really the state of the art f= or sending data back to servers? Do you want anyone and everyone to see thi= s information? =20 Regarding the active measurements themselves, I think the draft would b= enefit from referencing some of the RFCs and drafts from the IPPM Working G= roup. We have various documents on one-way and two-way active measurements = (OWAMP/TWAMP). You can also take a look at some standard ways of reporting = the metrics themselves, as described here: draft-ietf-ippm-initial-registry= -08. =20 Thanks, Tommy =20 > On Nov 27, 2018, at 5:22 AM, JORDI PALET MARTINEZ wrote: >=20 > Hi Mikael, >=20 > I got the impression that when I originally proposed this, syslog was= a privacy issue because it is sending data from "customers traffic" from t= heir own devices to the ISP. >=20 > But in the actual proposal, the data is NOT from any customer, neithe= r identifying the customer at all. >=20 > So not sure to understand if we have failed to clearly describe the w= ay we are measuring, or you'd in mind the previous document? >=20 > Regards, > Jordi >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de Mikael Abrahamsson > Organizaci=C3=B3n: People's Front Against WWW > Fecha: martes, 27 de noviembre de 2018, 12:45 > Para: Ron Bonica > CC: "v6ops@ietf.org list" > Asunto: Re: [v6ops] draft-xie-v6ops-network-happyeyeballs >=20 > On Mon, 26 Nov 2018, Ron Bonica wrote: >=20 >> This week, please review and comment on=20 >> draft-xie-v6ops-network-happyeyeballs. >=20 > I think it's a great idea to tell the operator about problems, tha= t kind=20 > of telemetry can really help in operating the network. >=20 > However, the proposed method of doing it (syslog) and the informat= ion it=20 > reports (IP addresses and domains the user is communicating with) = has huge=20 > privacy implications. Also you have no idea who might be grabbing = this=20 > information before it even makes it to the ISP). >=20 > I think at a minimum there needs to be an encrypted and verified m= echanism=20 > (https perhaps?) for doing the reporting, so you know where the re= port=20 > goes. >=20 > I see three entities that have interest in this information, it's = the ISP,=20 > the operating system manufacturer, and the web site which is havin= g=20 > problems. If HE fails, I see very little harm (privacy) in telling= the=20 > website about it using the address family that actually did work. = So that=20 > could be included. For the device manufacturer, they have "send=20 > diagnostics information to vendor", so here customers can opt in. = For the=20 > ISP, I have no idea. Here it might be better to define an API betw= een the=20 > device vendor and the ISP, so that the device vendor can report pr= oblems=20 > seen, at an aggregate? I have personally been involved in getting= =20 > operational people from my employer talking to device vendors to f= igure=20 > out what might be wrong, and automating this would be great. >=20 > Also, the DNSSEC implications are glossed over grossly. We should = take for=20 > granted that end devices are running validating resolvers and hand= le that=20 > use-case. >=20 > So I'm supportive of the problem statement and it would help ISPs = greatly=20 > if they could get telemetry from end devices, I just have great co= ncerns=20 > over the method proposed in this draft. >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company >=20 > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Dec 3 06:47:51 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDFA130E7F for ; Mon, 3 Dec 2018 06:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telecentro.net.ar Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0rp6vsqTi2H for ; Mon, 3 Dec 2018 06:47:45 -0800 (PST) Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF85F130E19 for ; Mon, 3 Dec 2018 06:47:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id CF3243201FB3; Mon, 3 Dec 2018 11:47:41 -0300 (-03) Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id WLzLBZr-lnMh; Mon, 3 Dec 2018 11:47:40 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 964453201F86; Mon, 3 Dec 2018 11:47:40 -0300 (-03) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar 964453201F86 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1543848460; bh=1G86cVA6GACsnLmfuMOPuyRoy+3vVy9/tJZ559URnm4=; h=Date:From:To:Message-ID:MIME-Version; b=ST22d5M2Zut24K7esgE9V0HyltoRqqt11F3sHFzY2psGelLmo/pgC1cAvhsMaroub ND1Mt4VUFshfud52K40VPPtuf34sNZLlwy+KiA3Azj1MT6XynIvnUUbnQ6TCeCdyCc Ve92cVwsa3ODD5IoP1ep251GfSOp26W2nbkDSZm4R+jTAvS/pGwDFvJNLdUndUhua1 ZxmaBDNR7DrQhacBgf+eCMfeo71ilruuYChcceeEw/Pmoy2l1UMgQBsqv4k/fbFhco 8cvrANBpaoMu0DYQ8zEX1oJO75NosSS632cBHyE8B3VQvQM3b6A41g2+t2Tt9688We 6a9e8qdf1VulA== X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id C9lmh1L5ckJc; Mon, 3 Dec 2018 11:47:40 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 6334A3201F4B; Mon, 3 Dec 2018 11:47:40 -0300 (-03) Date: Mon, 3 Dec 2018 11:47:39 -0300 (ART) From: Alejandro D'Egidio To: JORDI PALET MARTINEZ Cc: "v6ops@ietf.org list" Message-ID: <97380526.38495143.1543848459101.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: References: <154361671222.27410.9436586350814710547@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.8.8_GA_3008 (ZimbraWebClient - GC70 (Win)/8.8.8_GA_1703) Thread-Topic: I-D Action: draft-ietf-v6ops-transition-ipv4aas-11.txt Thread-Index: IYDzRmTLZWZZeZpQFrVcm6mJCNAU2A== Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-11.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 14:47:50 -0000 Hello Jordi, I hope you are doing well. I've read all the document and think the it's great! Just a simple note (not technical) regarding this: It is not relevant who provides the IPv6 Transition CE Router. In most of the cases is the service provider, and in fact is responsible, typically, of provisioning/managing at least the WAN side. However, commonly the user has access to configure the LAN interfaces, firewall, DMZ, and many other features. However, in many cases, the user must supply or may replace the IPv6 Transition CE Router. This underscores the importance of the IPv6 Transition CE Routers supporting the same requirements defined in this document. Maybe the first "However"can be replaced by "In addition" or simply startin= g with Commonly... But, it's not important in comparison with all this work. Regards, Alejandro ----- Mensaje original ----- De: "JORDI PALET MARTINEZ" Para: "v6ops@ietf.org list" Enviados: Viernes, 30 de Noviembre 2018 19:28:09 Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-11.txt Hi all, The new version of this document has been updated only to apply editorial e= dits as requested by our AD. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Responder a: Fecha: viernes, 30 de noviembre de 2018, 23:25 Para: CC: Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-11.txt =20 A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations WG of the IETF. =20 Title : Requirements for IPv6 Customer Edge Routers t= o Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima =09Filename : draft-ietf-v6ops-transition-ipv4aas-11.txt =09Pages : 22 =09Date : 2018-11-30 =20 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or through the retail market. =20 Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS). This is necessary because there aren't sufficient IPv4 addresses available for every possible customer/device. However, devices or application= s in the customer LANs may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services at the Internet. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-11 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4a= as-11 =20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-transition-ipv4aas= -11 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Dec 3 07:11:10 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860DE130EAE for ; Mon, 3 Dec 2018 07:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bX7Zhf0T6pFf for ; Mon, 3 Dec 2018 07:11:00 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F00E130E5F for ; Mon, 3 Dec 2018 07:10:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1543849856; x=1544454656; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=QCz4VgHrSWeBsS/XMCyRn P+LwC9yvuLR2zwETz6Izqk=; b=eIpPIhVufny/zuGKnWbXFgLBKpY+XiPvqPKOO zxVviHQF9dEKtYRMorLRt2B7SjzxxQLY/35Vw5VpjotXNtGjEL9NUdakitEEHDWu dEows3LfJ+BEN8Kc5J9Q8u+IbtEr8vWf+qZAV76URDjHKRuQuQuQ+j85act/eXpP tbs4ng= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 03 Dec 2018 16:10:56 +0100 X-Spam-Processed: mail.consulintel.es, Mon, 03 Dec 2018 16:10:56 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006032534.msg for ; Mon, 03 Dec 2018 16:10:54 +0100 X-MDRemoteIP: 2001:470:1f09:495:3898:f51a:9a02:a38c X-MDHelo: [10.10.10.99] X-MDArrival-Date: Mon, 03 Dec 2018 16:10:54 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1875b8bdb6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.4.181110 Date: Mon, 03 Dec 2018 16:10:51 +0100 From: JORDI PALET MARTINEZ To: Alejandro D'Egidio CC: "v6ops@ietf.org list" Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-11.txt Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-11.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 15:11:04 -0000 Hi Alejandro, This is already now in last call/IESG review, so I'm not sure if this can b= e addressed, not really making a difference ... Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Alejandro D'Egidio Fecha: lunes, 3 de diciembre de 2018, 15:48 Para: JORDI PALET MARTINEZ CC: "v6ops@ietf.org list" Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-11.txt Hello Jordi, I hope you are doing well. I've read all the document and think the it's great! Just a simple note (not technical) regarding this: =20 It is not relevant who provides the IPv6 Transition CE Router. In most of the cases is the service provider, and in fact is responsible, typically, of provisioning/managing at least the WAN side. However, commonly the user has access to configure the LAN interfaces, firewall, DMZ, and many other features. However, in man= y cases, the user must supply or may replace the IPv6 Transition CE Router. This underscores the importance of the IPv6 Transition CE Routers supporting the same requirements defined in this document. =20 Maybe the first "However"can be replaced by "In addition" or simply sta= rting with Commonly... But, it's not important in comparison with all this work. =20 =20 Regards, Alejandro =20 ----- Mensaje original ----- De: "JORDI PALET MARTINEZ" Para: "v6ops@ietf.org list" Enviados: Viernes, 30 de Noviembre 2018 19:28:09 Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-11.= txt =20 Hi all, =20 The new version of this document has been updated only to apply editori= al edits as requested by our AD. =20 Regards, Jordi =20 =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Responder a: Fecha: viernes, 30 de noviembre de 2018, 23:25 Para: CC: Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-11.txt =20 =20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the IPv6 Operations WG of the IETF. =20 Title : Requirements for IPv6 Customer Edge Route= rs to Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-11.txt Pages : 22 Date : 2018-11-30 =20 Abstract: This document specifies the IPv4 service continuity requirements= for an IPv6 Customer Edge (CE) router, either provided by the servic= e provider or through the retail market. =20 Specifically, this document extends the "Basic Requirements for = IPv6 Customer Edge Routers" in order to allow the provisioning of IPv= 6 transition services for the support of "IPv4 as-a-Service" (IPv4= aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS). This i= s necessary because there aren't sufficient IPv4 addresses availab= le for every possible customer/device. However, devices or applica= tions in the customer LANs may be IPv4-only or IPv6-only and still nee= d to communicate with IPv4-only services at the Internet. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aa= s/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-11 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-i= pv4aas-11 =20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-transition-ipv= 4aas-11 =20 =20 Please note that it may take a couple of minutes from the time of s= ubmission until the htmlized version and diff are available at tools.ietf.org= . =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited and will be = considered a criminal offense. If you are not the intended recipient be awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Dec 3 07:15:35 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEAE130E4B for ; Mon, 3 Dec 2018 07:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JsIEgW5-Dd6 for ; Mon, 3 Dec 2018 07:15:30 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 B89C2130E3C for ; Mon, 3 Dec 2018 07:15:29 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id j10so12560632wru.4 for ; Mon, 03 Dec 2018 07:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aYb9n90IfFldQAdJsxkab4GTJTdsbuY0fpDJYfckztM=; b=xmtkiaDsMqa3LcMszjbiHqcKoetDnJGJWja/o0PtxQhtRt9w0909TwwOEyb8L+R8KL JcMA2b4wTLqRE5cki0+WBvKyOn5gPk8O0t/ICPAPwunamSUnbq/iZ4O06YevIuXjpe1C kPDgadN+4CCcFwSK7/G65ZdTx/7+UxzOENzrYXT6+RarkPn2jdGEmOCEpQJ4CISepz7C /QWOe/Jkcgu3V699p3cvkhXqxsj8/dxPFIOZjxX5Tkf7qp0dNf8b4i16KfK3z/QDOkOB EFyTn1N5JT3eMdSOwT/mXEntyj+3g4xCjZc9DfTLnjTgqZGOEWA4O5AxNJNKPhSpCqBQ NH6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aYb9n90IfFldQAdJsxkab4GTJTdsbuY0fpDJYfckztM=; b=UoK6fYME9jm7yjMivJ2naIgaqvwhWPXAbrTIkVzMrLB0y8bznvmrFjNegUr8vRGb9G ezeLdQctqjpTnZilgcLolA+jt4B9KtIZo2O69oCH9tHby4LqmgCgitHTeF6v7TWNp4vI hNxhYKyzXKTUISZwqsISvONZoEZw9esyhVMnupy0PhF0S30o7XPzHOEwanj/QJo54sqC 1VyAahVrmtQLy4c/yz9rdsTO82qs2Af537sGFHgccchwHVNzRwh8U7xUFtapbcymJMuP 6BfSAByUOWcQEzJ6D3uo/9nC63KxJNjqBSEpuJy/1xFBpZBERnTS+qZ/lqlIYBHzcBw5 e8ag== X-Gm-Message-State: AA+aEWYxPWlqNsQmh7OJhsjOZFbPPN4+9f9hObRjQl/B+qFcnzcGKPUF FO2NG5b+E259prgDXAVYF7MxXQP8dGFwxfJCvCRlpkb7lvQoQA== X-Google-Smtp-Source: AFSGD/V6GuSFPByWZZDZt+jUxIFAeiOrrMoKmUvOfeAe+AGfegNGnxJuJLhrNwAzzAEk9P2yCVirVJCmw/8qUQ4hR8I= X-Received: by 2002:a5d:4e82:: with SMTP id e2mr14127045wru.291.1543850127646; Mon, 03 Dec 2018 07:15:27 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Mon, 3 Dec 2018 10:14:49 -0500 Message-ID: To: jordi.palet=40consulintel.es@dmarc.ietf.org Cc: adegidio=40telecentro.net.ar@dmarc.ietf.org, IPv6 Operations Content-Type: multipart/alternative; boundary="00000000000071f82f057c1f9e08" Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-11.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 15:15:34 -0000 --00000000000071f82f057c1f9e08 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 3, 2018 at 10:11 AM JORDI PALET MARTINEZ wrote: > Hi Alejandro, > > This is already now in last call/IESG review, so I'm not sure if this can > be addressed, not really making a difference ... > > Thanks Jordi and Alejandro - we can submit a new version after IETF, and / or thinks like this can be fixed up by the RFC Editor / during AUTH48.. Thanks, W > Regards, > Jordi > > > > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de Alejandro D'Egidio > > Fecha: lunes, 3 de diciembre de 2018, 15:48 > Para: JORDI PALET MARTINEZ > CC: "v6ops@ietf.org list" > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-11.tx= t > > Hello Jordi, > I hope you are doing well. > I've read all the document and think the it's great! > Just a simple note (not technical) regarding this: > > It is not relevant who provides the IPv6 Transition CE Router. In > most of the cases is the service provider, and in fact is > responsible, typically, of provisioning/managing at least the WAN > side. However, commonly the user has access to configure the LAN > interfaces, firewall, DMZ, and many other features. However, in > many > cases, the user must supply or may replace the IPv6 Transition CE > Router. This underscores the importance of the IPv6 Transition CE > Routers supporting the same requirements defined in this document. > > Maybe the first "However"can be replaced by "In addition" or simply > starting with Commonly... > But, it's not important in comparison with all this work. > > > Regards, > Alejandro > > ----- Mensaje original ----- > De: "JORDI PALET MARTINEZ" 40consulintel.es@dmarc.ietf.org> > Para: "v6ops@ietf.org list" > Enviados: Viernes, 30 de Noviembre 2018 19:28:09 > Asunto: Re: [v6ops] I-D Action: > draft-ietf-v6ops-transition-ipv4aas-11.txt > > Hi all, > > The new version of this document has been updated only to apply > editorial edits as requested by our AD. > > Regards, > Jordi > > > > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de < > internet-drafts@ietf.org> > Responder a: > Fecha: viernes, 30 de noviembre de 2018, 23:25 > Para: > CC: > Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-11.tx= t > > > A New Internet-Draft is available from the on-line Internet-Draft= s > directories. > This draft is a work item of the IPv6 Operations WG of the IETF. > > Title : Requirements for IPv6 Customer Edge > Routers to Support IPv4 Connectivity as-a-Service > Authors : Jordi Palet Martinez > Hans M.-H. Liu > Masanobu Kawashima > Filename : > draft-ietf-v6ops-transition-ipv4aas-11.txt > Pages : 22 > Date : 2018-11-30 > > Abstract: > This document specifies the IPv4 service continuity > requirements for > an IPv6 Customer Edge (CE) router, either provided by the > service > provider or through the retail market. > > Specifically, this document extends the "Basic Requirements fo= r > IPv6 > Customer Edge Routers" in order to allow the provisioning of > IPv6 > transition services for the support of "IPv4 as-a-Service" > (IPv4aaS) > by means of new transition mechanisms. The document only cove= rs > transition technologies for delivering IPv4 in IPv6-only acces= s > networks, commonly called "IPv4 as-a-Service" (IPv4aaS). This > is > necessary because there aren't sufficient IPv4 addresses > available > for every possible customer/device. However, devices or > applications > in the customer LANs may be IPv4-only or IPv6-only and still > need to > communicate with IPv4-only services at the Internet. > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-1= 1 > > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4aas= -11 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-transition-ipv4aas-1= 1 > > > 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/ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive use = of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --00000000000071f82f057c1f9e08 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mo= n, Dec 3, 2018 at 10:11 AM JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org= > wrote:
Hi Alejandro,

This is already now in last call/IESG review, so I'm not sure if this c= an be addressed, not really making a difference ...


Thanks Jordi and=C2=A0Alejandro - we can submit a new version a= fter IETF, and / or thinks like this can be fixed up by the RFC Editor / du= ring AUTH48..

Thanks,= =C2=A0
W

=C2=A0
Regards,
Jordi



=EF=BB=BF-----Mensaje original-----
De: v6ops <v= 6ops-bounces@ietf.org> en nombre de Alejandro D'Egidio <adegi= dio=3D40telecentro.net.ar@dmarc.ietf.org>
Fecha: lunes, 3 de diciembre de 2018, 15:48
Para: JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org&= gt;
CC: "v6ops@ietf.or= g list" <v6= ops@ietf.org>
Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-11.txt<= br>
=C2=A0 =C2=A0 Hello Jordi,
=C2=A0 =C2=A0 I hope you are doing well.
=C2=A0 =C2=A0 I've read all the document and think the it's great!<= br> =C2=A0 =C2=A0 Just a simple note (not technical) regarding this:

=C2=A0 =C2=A0 It is not relevant who provides the IPv6 Transition CE Router= .=C2=A0 In
=C2=A0 =C2=A0 =C2=A0 =C2=A0most of the cases is the service provider, and i= n fact is
=C2=A0 =C2=A0 =C2=A0 =C2=A0responsible, typically, of provisioning/managing= at least the WAN
=C2=A0 =C2=A0 =C2=A0 =C2=A0side.=C2=A0 However, commonly the user has acces= s to configure the LAN
=C2=A0 =C2=A0 =C2=A0 =C2=A0interfaces, firewall, DMZ, and many other featur= es.=C2=A0 However, in many
=C2=A0 =C2=A0 =C2=A0 =C2=A0cases, the user must supply or may replace the I= Pv6 Transition CE
=C2=A0 =C2=A0 =C2=A0 =C2=A0Router.=C2=A0 This underscores the importance of= the IPv6 Transition CE
=C2=A0 =C2=A0 =C2=A0 =C2=A0Routers supporting the same requirements defined= in this document.

=C2=A0 =C2=A0 Maybe the first "However"can be replaced by "I= n addition" or simply starting with Commonly...
=C2=A0 =C2=A0 But, it's not important in comparison with all this work.=


=C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 Alejandro

=C2=A0 =C2=A0 ----- Mensaje original -----
=C2=A0 =C2=A0 De: "JORDI PALET MARTINEZ" <jordi.palet=3D40consulinte= l.es@dmarc.ietf.org>
=C2=A0 =C2=A0 Para: "v6ops@ietf.org list" <v6ops@ietf.org>
=C2=A0 =C2=A0 Enviados: Viernes, 30 de Noviembre 2018 19:28:09
=C2=A0 =C2=A0 Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-i= pv4aas-11.txt

=C2=A0 =C2=A0 Hi all,

=C2=A0 =C2=A0 The new version of this document has been updated only to app= ly editorial edits as requested by our AD.

=C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 Jordi



=C2=A0 =C2=A0 =EF=BB=BF-----Mensaje original-----
=C2=A0 =C2=A0 De: v6ops <v6ops-bounces@ietf.org> en nombre de <internet-drafts@ietf.org>
=C2=A0 =C2=A0 Responder a: <v6ops@ietf.org>
=C2=A0 =C2=A0 Fecha: viernes, 30 de noviembre de 2018, 23:25
=C2=A0 =C2=A0 Para: <i-d-announce@ietf.org>
=C2=A0 =C2=A0 CC: <v= 6ops@ietf.org>
=C2=A0 =C2=A0 Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4a= as-11.txt


=C2=A0 =C2=A0 =C2=A0 =C2=A0 A New Internet-Draft is available from the on-l= ine Internet-Drafts directories.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 This draft is a work item of the IPv6 Operation= s WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0: Requirements for IPv6 Customer Edge Routers to= Support IPv4 Connectivity as-a-Service
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0: Jordi Palet Martinez
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hans M.-H. Liu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Masanobu Kawashima
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2= =A0 =C2=A0 =C2=A0 : draft-ietf-v6ops-transition-ipv4aas-11.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0: 22
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2018-11-30

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Abstract:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This document specifies the IPv4 s= ervice continuity requirements for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0an IPv6 Customer Edge (CE) router,= either provided by the service
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0provider or through the retail mar= ket.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Specifically, this document extend= s the "Basic Requirements for IPv6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Customer Edge Routers" in ord= er to allow the provisioning of IPv6
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transition services for the suppor= t of "IPv4 as-a-Service" (IPv4aaS)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by means of new transition mechani= sms.=C2=A0 The document only covers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0transition technologies for delive= ring IPv4 in IPv6-only access
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0networks, commonly called "IP= v4 as-a-Service" (IPv4aaS).=C2=A0 This is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0necessary because there aren't= sufficient IPv4 addresses available
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for every possible customer/device= .=C2=A0 However, devices or applications
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in the customer LANs may be IPv4-o= nly or IPv6-only and still need to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0communicate with IPv4-only service= s at the Internet.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 The IETF datatracker status page for this draft= is:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 htt= ps://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 There are also htmlized versions available at:<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 https:= //tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4a= as-11

=C2=A0 =C2=A0 =C2=A0 =C2=A0 A diff from the previous version is available a= t:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-transition-ipv4aas-1= 1


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Please note that it may take a couple of minute= s from the time of submission
=C2=A0 =C2=A0 =C2=A0 =C2=A0 until the htmlized version and diff are availab= le at tools.ietf.org.

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 v6ops@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/= listinfo/v6ops




=C2=A0 =C2=A0 **********************************************
=C2=A0 =C2=A0 IPv4 is over
=C2=A0 =C2=A0 Are you ready for the new Internet ?
=C2=A0 =C2=A0 http://www.theipv6company.com
=C2=A0 =C2=A0 The IPv6 Company

=C2=A0 =C2=A0 This electronic message contains information which may be pri= vileged or confidential. The information is intended to be for the exclusiv= e use of the individual(s) named above and further non-explicilty authorize= d disclosure, copying, distribution or use of the contents of this informat= ion, even if partially, including attached files, is strictly prohibited an= d will be considered a criminal offense. If you are not the intended recipi= ent be aware that any disclosure, copying, distribution or use of the conte= nts of this information, even if partially, including attached files, is st= rictly prohibited, will be considered a criminal offense, so you must reply= to the original sender to inform about this communication and delete it.


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 v6ops@iet= f.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/v6o= ps

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 v6ops@iet= f.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/v6o= ps




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.



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


--
I don't t= hink the execution is relevant when it was obviously a bad idea in the firs= t place.
This is like putting rabid weasels in your pants, and later exp= ressing regret at having chosen those particular rabid weasels and that pai= r of pants.
=C2=A0 =C2=A0---maf
--00000000000071f82f057c1f9e08-- From nobody Mon Dec 3 08:57:01 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF002130E0E for ; Mon, 3 Dec 2018 08:56:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.161 X-Spam-Level: X-Spam-Status: No, score=-4.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9Yky91lJZBc for ; Mon, 3 Dec 2018 08:56:57 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 9D71B130E1E for ; Mon, 3 Dec 2018 08:56:57 -0800 (PST) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id wB3GsVVa017550 for ; Mon, 3 Dec 2018 08:56:53 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=kcowA9/kQMew/ZRwd8QMPL1WsOzVwaRs4AulKPKlugw=; b=m6ka2N3VgPkUsQulsRD67OnYCAeR/jex814zFXeToyu4Yj5xlW8y6o7Zv/MBCqk0OrNQ UZfQhh98dL6BAtnTOeTWGW7V4oFRYsEDta1PYJpAdEp9/DlHzRobMdBpuBXaByZeSWgN /h8O+Nt80NZFuimfJfl5lJpVUPbrT1rfKh0EQ38fN6s56MDViBLy351S3QoTKaKx0Wks HFO+877abdnJnc2nVcsw4NPuB03jr1MUFgnqwwsJAcUz57I327GUv3dm1MpYqeR8iL3a Y/YyqHTqIAfz8eVB6698+GXFxaF+B3HOVPwq4KSN/ncjg/Pzg3fKUlKvPZvx1n80Ol6J PA== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2054.outbound.protection.outlook.com [104.47.36.54]) by mx0b-00273201.pphosted.com with ESMTP id 2p58a8g0jy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 03 Dec 2018 08:56:53 -0800 Received: from BYAPR05MB4245.namprd05.prod.outlook.com (20.176.252.26) by BYAPR05MB5400.namprd05.prod.outlook.com (20.177.184.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.11; Mon, 3 Dec 2018 16:56:51 +0000 Received: from BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::9dc7:1844:64f1:65b3]) by BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::9dc7:1844:64f1:65b3%5]) with mapi id 15.20.1404.016; Mon, 3 Dec 2018 16:56:51 +0000 From: Ron Bonica To: "v6ops@ietf.org list" Thread-Topic: draft-bp-v6ops-ipv6-ready-dns-dnssec Thread-Index: AdSLKSeqFQVQ7vMyTiulnE0efkbxvg== Date: Mon, 3 Dec 2018 16:56:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB5400; 6:cgzVV5Vw3UhfEyguRypfvReBCGjFnY4qlBS606LocPoPFBzaTbm7505XM70hjgYy+G+QtZDHigDA06gT1w/jnE5Yo8eXAhP9U2iwhS8CvHuXY6M/BnBqvxez+nQUggYGOOBgvGffkMDShB8Vn3CBMwZtfrW+oJQx5WdOidAv1qhcGPO2wX7VidXu9J/+xYgjhgtleUDjyu0Byt7Z2yMds9NBBVnkJEINJXYlGJGJYVr8a8U8jfhMMFxQVrakkOFYLkjC/GAg2Ms8bO8se3vkmwU4uIL/30Lg/2zBT9di9Hh9AKOra0paTZ2olD54jCawCrNSJVph7JIF7+aFnpiHexKEGTbBaig5cJr8BJ9q5jh5YVTjEOTiGeQgXEthu7jQC0z+NzMRqcn+aduRr4vA+d96b3goJB/vYQZitpqvOXJ9uNA4uqqwfduHqvDbLZB7qFMOLarJre9AtuUAC5SuCw==; 5:9P0ewmcj/mNwbCxEDmyjuTAqtR56ooGi2fulPkB45tqqzZH6OYwbWTQImA62VyUtGD71YIQQorT8bW3KjvFvk8lviKs/ml7COqHwIQcL35dz/F9wyAC6QeAVeEFzwFxAOWC/NEngMQnmr7VJEerhCWWy0AWxn6XG1FfLyjPbiog=; 7:hg3ej0vx8LUVu9DwazkuiY68r28LgPhzwzkhDzwWmP5pRH70AyEASjdiLzJvdIfIdUDp4e60GWkwEpIo5yJlZU2VSN3pku1G9D2XPne8+LcH4v8wtfqPeSs2J02aJ0DKZJ6jsIuSf3/ABzKC1WPMpg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 1512e93f-7fa1-408f-5929-08d65940527c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB5400; x-ms-traffictypediagnostic: BYAPR05MB5400: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231455)(999002)(944501493)(52105112)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:BYAPR05MB5400; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB5400; x-forefront-prvs: 08756AC3C8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(39860400002)(376002)(346002)(396003)(199004)(189003)(256004)(25786009)(74316002)(97736004)(26005)(66066001)(7736002)(71200400001)(71190400001)(305945005)(99286004)(186003)(68736007)(102836004)(7696005)(6506007)(6116002)(3846002)(6916009)(9686003)(81156014)(476003)(8936002)(81166006)(8676002)(5660300001)(53936002)(486006)(86362001)(558084003)(316002)(55016002)(478600001)(106356001)(105586002)(2906002)(6436002)(33656002)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5400; H:BYAPR05MB4245.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: oduOJPofm9OHX6EDfRFMh495cNt4Fl7WbBxcWUYdfiEnxQ9+beq2ngOqfSmci1pbsL76H388UP0c+rL7YpnKVN2h9RdK1l5SmLkMy5CIqcRf4MmyAjBAgpUWuSJeeZdMXv2QNDCiz6n5+p8u84CxUc/fOVoX7pC85rvJKJEAiTanp/+9jCt3+WdpCDai7RzzYs3Z2mGQ9UmVGjTjyCemmLK9ponPD3048JQNXEN2W8c12W3LdXKS8NxSCAptt2eH0pLgzIgxSAjozqJBs9nyQW0oL2Ms9MvUAL6oQ2NoMp9XJWfy+H1nu3GK9P9tKz88oBY64rCfBtC+jw1NMewCVbagCYa7I5qlYtpZ/4142ps= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 1512e93f-7fa1-408f-5929-08d65940527c X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2018 16:56:51.4932 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5400 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-03_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=394 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812030158 Archived-At: Subject: [v6ops] draft-bp-v6ops-ipv6-ready-dns-dnssec X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 16:57:00 -0000 Folks, Each week between now and IETF 104, we will review and discuss one draft wi= th an eye towards progressing it. This week, please review and comment on draft-bp-v6ops-ipv6-ready-dns-dnsse= c. Fred and Ron From nobody Tue Dec 4 08:06:31 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F3E130EDF for ; Tue, 4 Dec 2018 08:06:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdDRRbXQitpi for ; Tue, 4 Dec 2018 08:06:25 -0800 (PST) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.142]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9191E130EE6 for ; Tue, 4 Dec 2018 08:06:24 -0800 (PST) Received: from rew09926dag07c.domain1.systemhost.net (10.55.202.42) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 4 Dec 2018 16:06:21 +0000 Received: from rew09926dag07b.domain1.systemhost.net (10.55.202.38) by rew09926dag07c.domain1.systemhost.net (10.55.202.42) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 4 Dec 2018 16:06:21 +0000 Received: from rew09926dag07b.domain1.systemhost.net ([fe80::3597:bc94:cdb8:9d49]) by rew09926dag07b.domain1.systemhost.net ([fe80::3597:bc94:cdb8:9d49%12]) with mapi id 15.00.1395.000; Tue, 4 Dec 2018 16:06:21 +0000 From: To: Thread-Topic: apnic IPv6 stats Thread-Index: AdSL60wcqhgjjwoRQ+mu4DrG0MJqGg== Date: Tue, 4 Dec 2018 16:06:21 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.233] Content-Type: multipart/alternative; boundary="_000_a19ba5531a14411bb21006563018f10frew09926dag07bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [v6ops] apnic IPv6 stats X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2018 16:06:29 -0000 --_000_a19ba5531a14411bb21006563018f10frew09926dag07bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey Does someone know and could they please give me a brief description of tech= nically how apnic get gather these % IPv6 capable stats ? https://stats.labs.apnic.net/ipv6/AS2856?c=3DGB&p=3D1&v=3D1&w=3D30&x=3D1 Many thanks in advance Mal --_000_a19ba5531a14411bb21006563018f10frew09926dag07bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey

 

Does someone know and could th= ey please give me a brief description of technically how apnic get gather t= hese % IPv6 capable stats ?=

 

https://stats.labs.apnic.net/ipv6/AS2856?c=3DGB&p=3D1&v=3D1&w= =3D30&x=3D1

 

Many thanks in advance

 

Mal

 

 

--_000_a19ba5531a14411bb21006563018f10frew09926dag07bdomain1sy_-- From nobody Tue Dec 4 08:52:35 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F52130EB4 for ; Tue, 4 Dec 2018 08:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNDUyEcGn51H for ; Tue, 4 Dec 2018 08:52:31 -0800 (PST) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 312D3130934 for ; Tue, 4 Dec 2018 08:52:31 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id e7so10239467vsc.2 for ; Tue, 04 Dec 2018 08:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7YnEHXc+EY6SWba/jwEamMOpmkrpYnLHxGTu1JlNqDM=; b=Dj4IDXzgKlSqR60Qpd6e+ogzwxDZuW2EdMehmGceRuYp2Qh7ZGigLJPidXHcb8Pqdc NMfTefv4GmHymyCOZ1gPLl1pDIMNGj+BtQsLNIDhkUYAYIv4PRcMcl3C97kb8TcfTZUG 5EIidtUA7mdT/p42QwqouNIT4McUW3bsxenlM870Fk1MMsnOXOHNb6LqguY4s0MF7cig 7oWUeVblU/j876Snsij0f+z7CY3q5k+ZTkkhJrazOUKM85PKDusqgXZhYXfvTyYWPCKo 6UXA4KlfwZ8HRI3KzQxeRRtH+eiWZy5L/cii1iynd9KgZhLlx26tU9OqNxZPD5EtlTGU jc0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7YnEHXc+EY6SWba/jwEamMOpmkrpYnLHxGTu1JlNqDM=; b=mCIMThqwx23HPh/5neZds7JBm+qcHbSMD7PNe+pX1AeY4s2cbGuzoh575vjhAnmt1/ h1S0uOklt0OqYg4UA7nvG5Qxguf1p28MnarRXez1maVEtEUr86oCTeTu5rcqo7B4DuJ0 a4QgXCVcyTDZzk0e7s0t2Iubls1GNJE9cGJxzoz9Mt5qJ7Z5Cfl4WKgkEzNPppvTxqD3 UCHetwCT+jQ2dZydjBS3mVAooJ3okUcGjAJNzTIZ7kbbV/JsloaA3skK9zx10/fNCM6W mj/OP0exu1xSN5WPf1Pd6/AXg417mOZNdRSfEVhtjp3t4x2+Oc8BOrVxWNgttNrHXKUC amSg== X-Gm-Message-State: AA+aEWYTbPSzOf/WB8jj3mU7EcJ7/vX45vedYrdaHa6Y5dCs8V+oRNqE mL82WGnt2QrP0jv3+dI4Cvoix2Govo5xwEFb3k0= X-Google-Smtp-Source: AFSGD/U2pBOyzPy/KU/DiGV+XkzGZkwUmJnABPRuxqMY4mbDWNjbEZUigiPX6YEqHwUBEYcFqkuUjqxxldLyxo/FS+0= X-Received: by 2002:a67:e0d4:: with SMTP id m20mr9165819vsl.182.1543942350312; Tue, 04 Dec 2018 08:52:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yu Tianpeng Date: Tue, 4 Dec 2018 16:52:19 +0000 Message-ID: To: mal.hubert@bt.com Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="000000000000581b1e057c351750" Archived-At: Subject: Re: [v6ops] apnic IPv6 stats X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2018 16:52:33 -0000 --000000000000581b1e057c351750 Content-Type: text/plain; charset="UTF-8" Hi Mal, This might help. https://labs.apnic.net/?p=266 Regards, Tim On Tue, 4 Dec 2018, 16:06 Hey > > > > Does someone know and could they please give me a brief description of > technically how apnic get gather these % IPv6 capable stats ? > > > > https://stats.labs.apnic.net/ipv6/AS2856?c=GB&p=1&v=1&w=30&x=1 > > > > Many thanks in advance > > > > Mal > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --000000000000581b1e057c351750 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mal,
This might help.
Regards,
Tim



On Tue, 4 Dec 2018, 16:06 <mal.hubert@bt.com wrote:

Hey

=C2=A0

Does someone know and could th= ey please give me a brief description of technically how apnic get gather t= hese % IPv6 capable stats ?<= /u>

=C2=A0

https://stats.labs.apnic.net/ipv6/AS2= 856?c=3DGB&p=3D1&v=3D1&w=3D30&x=3D1

=C2=A0

Many thanks in advance<= u>

=C2=A0

Mal

=C2=A0

=C2=A0

_______________________________________________
v6ops mailing list
v6op= s@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--000000000000581b1e057c351750-- From nobody Tue Dec 4 09:03:12 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C26130F62 for ; Tue, 4 Dec 2018 09:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6u3jNHYZW5Z for ; Tue, 4 Dec 2018 09:03:09 -0800 (PST) Received: from atl4mhob06.registeredsite.com (atl4mhob06.registeredsite.com [209.17.115.44]) by ietfa.amsl.com (Postfix) with ESMTP id D0381130F5B for ; Tue, 4 Dec 2018 09:03:06 -0800 (PST) Received: from mailpod.hostingplatform.com (atl4qobmail02pod6.registeredsite.com [10.30.71.210]) by atl4mhob06.registeredsite.com (8.14.4/8.14.4) with ESMTP id wB4H34m9024798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 4 Dec 2018 12:03:04 -0500 Received: (qmail 12749 invoked by uid 0); 4 Dec 2018 17:03:04 -0000 X-TCPREMOTEIP: 74.10.107.195 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?172.22.36.75?) (lee@asgard.org@74.10.107.195) by 0 with ESMTPA; 4 Dec 2018 17:03:03 -0000 To: v6ops@ietf.org References: From: Lee Howard Message-ID: <7fea82cf-2a44-d2b1-2de8-a1ba8046e951@asgard.org> Date: Tue, 4 Dec 2018 12:03:03 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A7E3089E6DE907ECF5F80B58" Content-Language: en-US Archived-At: Subject: Re: [v6ops] apnic IPv6 stats X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2018 17:03:11 -0000 This is a multi-part message in MIME format. --------------A7E3089E6DE907ECF5F80B58 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Paging Geoff Huston and George Michaelson! One explanatory blog post is at https://labs.apnic.net/?p=266 Briefly, as I understand it, APNIC buys ads on a global ad network. When the ad is served to a device, it pulls two unique objects, one IPv4-only and one IPv6-only. Because they're unique, they can tell when a device GETs the IPv4 object and whether they GET the IPv6 object. Then it's just the percentage of total fetches coming over IPv6. They do a bit of normalizing the results, and of course knowing the source IP addresses is how they categorize the origin ASN. I'm not authoritative, but that's my understanding. Lee On 12/4/18 11:06 AM, mal.hubert@bt.com wrote: > > Hey > > Does someone know and could they please give me a brief description of > technically how apnic get gather these % IPv6 capable stats ? > > https://stats.labs.apnic.net/ipv6/AS2856?c=GB&p=1&v=1&w=30&x=1 > > Many thanks in advance > > Mal > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------A7E3089E6DE907ECF5F80B58 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Paging Geoff Huston and George Michaelson!

One explanatory blog post is at https://labs.apnic.net/?p=266

Briefly, as I understand it, APNIC buys ads on a global ad network. When the ad is served to a device, it pulls two unique objects, one IPv4-only and one IPv6-only. Because they're unique, they can tell when a device GETs the IPv4 object and whether they GET the IPv6 object. Then it's just the percentage of total fetches coming over IPv6.

They do a bit of normalizing the results, and of course knowing the source IP addresses is how they categorize the origin ASN.

I'm not authoritative, but that's my understanding.

Lee


On 12/4/18 11:06 AM, mal.hubert@bt.com wrote:

Hey

 

Does someone know and could they please give me a brief description of technically how apnic get gather these % IPv6 capable stats ?

 

https://stats.labs.apnic.net/ipv6/AS2856?c=GB&p=1&v=1&w=30&x=1

 

Many thanks in advance

 

Mal

 

 


_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--------------A7E3089E6DE907ECF5F80B58-- From nobody Tue Dec 4 09:38:49 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D87130F8E for ; Tue, 4 Dec 2018 09:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42_HdM-aK_GG for ; Tue, 4 Dec 2018 09:38:43 -0800 (PST) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 1ABB7130F6C for ; Tue, 4 Dec 2018 09:38:43 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id z28so14633313edi.8 for ; Tue, 04 Dec 2018 09:38:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Q/TFIiFlsc+jzylrSc5Ja0UvW8YhS+9oPw/6c5nYEBU=; b=A09fFyZLCAwdyavil72wtR0gwifW86ShkZM3KWjF3Txjz+wheG8l/0G7i3BpOaiiDF hGXvkHJ4lqLMCd3Kl5xwpjsISgfFeVR3NLw9hwN4MHX98z8YADsiiDdIPLHbnhZo4m/L AQgbh7VQT0r2/+JM8/5uNnebrDQ/py8VeBnSrfUwjYHQ/qBaxs8Ihk/L8iwnJKS12SqJ L4mS++TjN7ExJkDDJTVh2+7J4RAbVECbmfHJMBdPJLJst39fGJAsWS+MDe3iSmgQYE31 nDx7o4qg6jO9DQaiU07w5AHDVu2AXR2TDMTYkWgyUgi5pkkJIW9/zqCqfxI2XIBTViZ9 bqeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Q/TFIiFlsc+jzylrSc5Ja0UvW8YhS+9oPw/6c5nYEBU=; b=Qc4dahaJnPKhIAde+zwo+Eqr4z1lDnnDAdMv6VsyOh5CVZmjhx1qhB3noGH/CaLSyi lHWvbqMNkUYDM4xAYvCzj0uiDpNjOTgVTClpv76AD0bGDZ9eG27GB2bG2OxQItWScTnw yqsCI2xizUwpS8zNOtO3XLdQCUFi4CBw8UCYuybw0eG0Vcl2sjOE5VA40ZCm1j2qt2Ae gpZSjpusQI2bwG9W4AsxiBLUXg1rC/y0JexKgGDicdlMvrZXxcG+h/5FqSt3qZ8qVTJr fECqXTvrutzJ1TdLDI2/JeIzS2LLccOFEB75Lg82AvO7Bc6r8PT9s8PAjH+9EogmtZJM oTYQ== X-Gm-Message-State: AA+aEWbT6FPgC/AoKfDQsMelqB1I3wTUYrdMWZ0hyKRYLlIFmrGu0Hmz XzV6xRsb9tRVmy+qAE4sQh/2e61/ X-Google-Smtp-Source: AFSGD/Ux/EeVhT+wXYTSx5XaDaTn4CxeT4E4SUBwR1zsqHJYQ+R+ACt/hRMLB8g1EsfUSxgQbXQBCQ== X-Received: by 2002:a17:906:7751:: with SMTP id o17-v6mr16449601ejn.15.1543945121511; Tue, 04 Dec 2018 09:38:41 -0800 (PST) Received: from ?IPv6:2600:8802:5600:1546::1042? ([2600:8802:5600:1546::1042]) by smtp.gmail.com with ESMTPSA id 24sm4823288eds.97.2018.12.04.09.38.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Dec 2018 09:38:40 -0800 (PST) From: Fred Baker Message-Id: <55E4430F-4BE4-4704-8F00-BBCDBE524B49@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_32CC9008-8C73-423F-8F75-1C5639BAB315"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 4 Dec 2018 09:38:35 -0800 In-Reply-To: <7fea82cf-2a44-d2b1-2de8-a1ba8046e951@asgard.org> Cc: v6ops list To: Lee Howard References: <7fea82cf-2a44-d2b1-2de8-a1ba8046e951@asgard.org> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [v6ops] apnic IPv6 stats X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2018 17:38:47 -0000 --Apple-Mail=_32CC9008-8C73-423F-8F75-1C5639BAB315 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Dec 4, 2018, at 9:03 AM, Lee Howard wrote: >=20 > Paging Geoff Huston and George Michaelson! >=20 > One explanatory blog post is at https://labs.apnic.net/?p=3D266 >=20 > Briefly, as I understand it, APNIC buys ads on a global ad network. = When the ad is served to a device, it pulls two unique objects, one = IPv4-only and one IPv6-only. Because they're unique, they can tell when = a device GETs the IPv4 object and whether they GET the IPv6 object. Then = it's just the percentage of total fetches coming over IPv6. It actually has three names that it resolves and uses. One only has an A = record, and an access in today's Internet tells APNIC that there was an = access. One only has a AAAA record; if that address is accessed, APNIC = knows that the entire path from client to server is IPv6-capable. One = has both resource records; if the client uses the IPv6 one, George = infers that it *prefers* IPv6, as it made that choice. > They do a bit of normalizing the results, and of course knowing the = source IP addresses is how they categorize the origin ASN. >=20 > I'm not authoritative, but that's my understanding. >=20 > Lee >=20 >=20 > On 12/4/18 11:06 AM, mal.hubert@bt.com wrote: >> Hey >>=20 >> Does someone know and could they please give me a brief description = of technically how apnic get gather these % IPv6 capable stats ? >>=20 >> https://stats.labs.apnic.net/ipv6/AS2856?c=3DGB&p=3D1&v=3D1&w=3D30&x=3D= 1 >>=20 >> Many thanks in advance >>=20 >> Mal >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >>=20 >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu --Apple-Mail=_32CC9008-8C73-423F-8F75-1C5639BAB315 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlwGu5sACgkQEhdRnd2G P+CWNw/+KU2izv3LcGWObVujiaZebCaZJPos3D0qykDvbUbtkgjaqSdXFMnSYDhR yyXx++kquIOVXhZ3lCLcxZ9FrrEky66Mo0bAi69S5OXkKiDxvRSB/as2JxzzkJz8 0aFV4YfXeufzmjhiUZU4BWRVsdAlHA6SerD6tj13Gor5XJWp5GPKcpywUqsq4MIg emumzRO4Vt+tuuH1SndV8gxoONOygh3U0YGJRtHcqQKi6WrIN9iKYOk1a8HA0ooX gyfrPwvGY6vad7klg0AQBvtmBH4Ar5SxLQqR8PLdO8QpD0toohdKEsZlQjsa1JDB iovw3ARaUXLMqZoLOlFWJ1tgCezgPp3X/kj9IbPQQ3iNdKa4Yf0OKBVa2/IPG8kN toFTjrTPebKlzkm5eyv9jY1rx4A6/PztwHNRrEDFUDXSW0ek6G2Xfhv5XUVLS/oG uYMdY1vuthA7pouzcAeO113u0Cddxga/5y0KCXrB8ZabeVECewGfkATlPcmCr7gF xMAKnAF/LafIPmkV41unJYPX7R/INQncXbFwnqAwBQF1hBz+OumwqJPfvo6vJaVy ldS0rQSq2hIpCqhLAizYu2jTTGhnfS8tgSUa3AAlqTjveJzp3wn/uPDSB/9+ocKy f5rg163u1GHxexjlrkfY4Xif/gSn3+ylKgusk6Ryd7h5LQeOLiM= =OL6W -----END PGP SIGNATURE----- --Apple-Mail=_32CC9008-8C73-423F-8F75-1C5639BAB315-- From nobody Wed Dec 5 07:17:03 2018 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 071D312785F; Wed, 5 Dec 2018 07:16:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dan Romascanu To: Cc: v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-transition-ipv4aas.all@ietf.org, dromasca@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154402301597.32013.16456863816253687025@ietfa.amsl.com> Date: Wed, 05 Dec 2018 07:16:56 -0800 Archived-At: Subject: [v6ops] Opsdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 15:16:56 -0000 Reviewer: Dan Romascanu Review result: Has Issues Please find below the OPS-DIR review of draft-ietf-v6ops-transition-ipv4aas. As this is not the definition of a new protocol or extension of an existing protocol, a full RFC 5706 review does not apply. However, its topic is relevant for the operators community, and I would recommend that the OPS ADs pay attention to it. There are some issues that I recommend to be addressed before this document is approved. 1. In the Abstract section: > This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or through the retail market. It is not clear to me what is meant by 'the retail market' and how the IETF can discuss requirements to a 'market'. Maybe the requirement is for vendors who sell in the 'retail market'? 2. Section 1.1 includes a 'Special Note' about keywords that includes the following text: > The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document, are not used as described in RFC 2119 [RFC2119]. This document uses these keywords not strictly for the purpose of interoperability, but rather for the purpose of establishing industry-common baseline functionality. I am not sure if there is a precedent to such a note that was discussed and approved by the IESG. I find this problematic, because if the usage is not conform to RFC 2119 it is not clear how readers of this document should interpret the capitalized keywords in the text. If the authors decided to not abide by RFC 2119, why did not they just use the non-capitalized versions of the keywords? 3. Section 1 specifies: > Since it is impossible to know prior to sale which transition mechanism a device will need over the lifetime of the device, IPv6 Transition CE Router intended for the retail market MUST support all the IPv4aaS transition mechanism supported by this document. But then sections 3.2.1 to 3.2.5 use SHOULD for the described mechanisms. For example in 3.2.1: > The IPv6 Transition CE Router SHOULD support CLAT functionality. How does the initial generic MUST for all mechanisms works with the specific SHOULDs for the defined techniques? 7. Section 7 looks through the code and memory considerations as well as to development costs and conclude that these are reasonable compared to the benefits. > The other issue seems to be the cost of developing the code for those new functionalities. However, at the time of writing this document, it has been confirmed that there are several open source versions of the required code for supporting all the new transition mechanisms, and several vendors already have implementations and provide it to ISPs, so the development cost is negligible, and only integration and testing cost may become a minor issue. This is fine and I appreciate taking all these aspects into consideration. However, there is one more incremental costs assumed by the customer operators in what concerns training operators on the different techniques and their configuration. I believe that those are worth being analyzed and the conclusions included also in this section. Nits: 1. I trust the RFC Editor to correct most if not all language problems. There are a few which may be addressed by a careful pass of the authors through the text (e.g. 'all the transition mechanism', 'because as in an IPv6-in-IPv4 tunneling', etc.) 2. It would be useful to expand acronyms at first encounter (e.g. HNCP, CGN 3. Inconsistent usage of double brackets for references (e.g. in 464XLAT-3) From nobody Wed Dec 5 07:36:01 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6594130E4D; Wed, 5 Dec 2018 07:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh2U3S2p2A1y; Wed, 5 Dec 2018 07:35:46 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5EC0130E5D; Wed, 5 Dec 2018 07:35:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1544024141; x=1544628941; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=gdb6cIreolRJ52os7srv6JkgLKmCcy63BHk6Osa4clY=; b=W7ZlBWvsrWOBv u1yNc1deH0fRyTirNxF5xecoiBiqYDFY8oxfkV85unSOUxxO/dagUphGO+AF3sbb pxH/1DWi9w7ks954vI3vzANGi+z4f7XrOSKMFWKcnDVg6x4/G90u/vpX4fu8ckjw m9szLEPnq0tZK2tNBB9y7kzRM+GOMA= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 05 Dec 2018 16:35:41 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 05 Dec 2018 16:35:40 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006039075.msg; Wed, 05 Dec 2018 16:35:40 +0100 X-MDRemoteIP: 2001:470:1f09:495:9909:aaac:c488:1c25 X-MDHelo: [10.10.10.99] X-MDArrival-Date: Wed, 05 Dec 2018 16:35:40 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1877b7b732=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.4.181110 Date: Wed, 05 Dec 2018 16:35:39 +0100 From: JORDI PALET MARTINEZ To: Dan Romascanu , CC: , , Message-ID: Thread-Topic: [v6ops] Opsdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 References: <154402301597.32013.16456863816253687025@ietfa.amsl.com> In-Reply-To: <154402301597.32013.16456863816253687025@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Opsdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 15:35:54 -0000 Hi Dan, Thanks for your review. Se below in-line my responses. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Dan Romascanu Fecha: mi=C3=A9rcoles, 5 de diciembre de 2018, 16:17 Para: CC: , , , Asunto: [v6ops] Opsdir last call review of draft-ietf-v6ops-transition-ipv4= aas-11 Reviewer: Dan Romascanu Review result: Has Issues =20 Please find below the OPS-DIR review of draft-ietf-v6ops-transition-ipv= 4aas. As this is not the definition of a new protocol or extension of an existin= g protocol, a full RFC 5706 review does not apply. However, its topic is = relevant for the operators community, and I would recommend that the OPS ADs pay attention to it. There are some issues that I recommend to be addressed= before this document is approved. =20 1. In the Abstract section: =20 > This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or through the retail market. =20 It is not clear to me what is meant by 'the retail market' and how the = IETF can discuss requirements to a 'market'. Maybe the requirement is for vendor= s who sell in the 'retail market'? I'm happy with that "vendors who sell in the retail market". =20 2. Section 1.1 includes a 'Special Note' about keywords that includes t= he following text: =20 > The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document, are not used as described in RFC 2119 [RFC2119]. This document uses these keywords not strictly for the purpose of interoperability, but rather for the purpose of establishing industry-common baseline functionality. =20 I am not sure if there is a precedent to such a note that was discussed= and approved by the IESG. I find this problematic, because if the usage is = not conform to RFC 2119 it is not clear how readers of this document should interpret the capitalized keywords in the text. If the authors decided = to not abide by RFC 2119, why did not they just use the non-capitalized versio= ns of the keywords? This document started as an update of RFC7084, and this text was taken from= that one. I understand that at that time it was accepted. =20 3. Section 1 specifies: =20 > Since it is impossible to know prior to sale which transition mechanism a device will need over the lifetime of the device, IPv6 Transition CE Router intended for the retail market MUS= T support all the IPv4aaS transition mechanism supported by this document. =20 But then sections 3.2.1 to 3.2.5 use SHOULD for the described mechanism= s. =20 For example in 3.2.1: =20 > The IPv6 Transition CE Router SHOULD support CLAT functionality. =20 How does the initial generic MUST for all mechanisms works with the spe= cific SHOULDs for the defined techniques? The intent was to say that, if a product is targeted to the retail market, = it must support all the transition mechanisms. Then at the level of each in= dividual transition mechanism, to make it work, it should support this and = that. From our perspective it is clear, but I'm happy to heard alternative = wordings. =20 7. Section 7 looks through the code and memory considerations as well a= s to development costs and conclude that these are reasonable compared to th= e benefits. =20 > The other issue seems to be the cost of developing the code for those new functionalities. However, at the time of writing this document, it has been confirmed that there are several open source versions of the required code for supporting all the new transition mechanisms, and several vendors already have implementations and provide it to ISPs, so the development cost is negligible, and only integration an= d testing cost may become a minor issue. =20 This is fine and I appreciate taking all these aspects into considerati= on. However, there is one more incremental costs assumed by the customer op= erators in what concerns training operators on the different techniques and the= ir configuration. I believe that those are worth being analyzed and the conclusions included also in this section. I don't think so. Typically, an operator will take one, maybe two transitio= n mechanism, and the cost associated to what the CEs support or not, is not= changing the cost in terms of training or operation. =20 Nits: =20 1. I trust the RFC Editor to correct most if not all language problems.= There are a few which may be addressed by a careful pass of the authors throu= gh the text (e.g. 'all the transition mechanism', 'because as in an IPv6-in-IP= v4 tunneling', etc.) =20 2. It would be useful to expand acronyms at first encounter (e.g. HNCP,= CGN =20 3. Inconsistent usage of double brackets for references (e.g. in 464XLA= T-3) =20 I will also take care of all those nits. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Dec 6 05:05:40 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AC0127AC2 for ; Thu, 6 Dec 2018 05:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDW677IhbNP1 for ; Thu, 6 Dec 2018 05:05:31 -0800 (PST) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (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 6E3B712785F for ; Thu, 6 Dec 2018 05:05:31 -0800 (PST) Received: from [192.168.1.119] (host-79-121-43-125.kabelnet.hu [79.121.43.125]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id wB6D5Hva032434 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 6 Dec 2018 14:05:26 +0100 (CET) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-43-125.kabelnet.hu [79.121.43.125] claimed to be [192.168.1.119] To: v6ops@ietf.org References: From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: Date: Thu, 6 Dec 2018 14:05:13 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.100.1 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.43.125; helo=[192.168.1.119]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] draft-bp-v6ops-ipv6-ready-dns-dnssec X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 13:05:39 -0000 Hi, I have just found a paper, which recommends an alternative solution: "DNSSEC in the networks with a NAT64/DNS64". Available: https://ieeexplore.ieee.org/document/8501446 However, I am not sure, how good it is. Gábor 12/3/2018 5:56 PM keltezéssel, Ron Bonica írta: > Folks, > > Each week between now and IETF 104, we will review and discuss one draft with an eye towards progressing it. > > This week, please review and comment on draft-bp-v6ops-ipv6-ready-dns-dnssec. > > Fred and Ron > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Dec 7 11:34:53 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75FB130E96 for ; Fri, 7 Dec 2018 11:34:50 -0800 (PST) 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_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwvhlfmQ6rez for ; Fri, 7 Dec 2018 11:34:49 -0800 (PST) Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 9D5401200D7 for ; Fri, 7 Dec 2018 11:34:48 -0800 (PST) Received: by mail-wr1-f44.google.com with SMTP id l9so4798844wrt.13 for ; Fri, 07 Dec 2018 11:34:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/u6S2afcfDWLmF0lQwgyv5FM+jDftk9BHAJBmxyXLUQ=; b=QJHesjNx5pO28gPjSlPGfqzSfNp4ZLhUqNcXgthtjgvjBzK1lEH+eNwYgt0zyhdoIu 8uPSqGhNGYakQ5BLUV89c1k0DKlGV4F/wyhMVqW3VnEV+acGG/xwn07ky7jcBzJcb5JZ 4JxrT/47vRy18C/C2MBmFI+Cr2XGSgSjYXxkGgS4kn+c+N27MSuzpb6mDpbZHjRiZ/w/ WEbInek6O1vhSJ7s3ulYC0z7R2NdqIwcseFNMX8rrQ1ofP6NBjAXnzvaeS5dW3B9qpd7 02+Y2Yt0gu+Bv/2nwXSf6x5tFkWW7HwQFTchgzsZi4joVSSTUrQE0w18VLGbGluDSMol rwPg== X-Gm-Message-State: AA+aEWY+LUlwUBquhj1OwJ9Kcb4XGwjVcLs7yr8t+wQx/dC/90Nm9bRi xzqSdQQA6KYqjVwayOoWfROJaJVVrkZQLgFjzJ4= X-Google-Smtp-Source: AFSGD/VjzW7zyyTpen0GsnfXalITqfTpBdjRW96SaCd9BZ5vqQBEbQwOjUqNQervJ2SenxbVoegSk6p1PFImWB+sEAw= X-Received: by 2002:adf:f703:: with SMTP id r3mr2823981wrp.93.1544211286662; Fri, 07 Dec 2018 11:34:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 7 Dec 2018 11:34:34 -0800 Message-ID: To: Ronald Bonica Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="000000000000332017057c73b5fc" Archived-At: Subject: Re: [v6ops] draft-bp-v6ops-ipv6-ready-dns-dnssec X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 19:34:51 -0000 --000000000000332017057c73b5fc Content-Type: text/plain; charset="UTF-8" At Mon, 3 Dec 2018 16:56:51 +0000, Ron Bonica wrote: > Each week between now and IETF 104, we will review and discuss one draft with an eye towards progressing it. > > This week, please review and comment on draft-bp-v6ops-ipv6-ready-dns-dnssec. I've read draft-bp-v6ops-ipv6-ready-dns-dnssec-00. While the motivation is laudable, I have to say I'm skeptical about its effectiveness if one main audience is "the IPv4 laggards". Just as it may be "unfair" that an IPv6-only service provider needs to handle A-only DNSSEC signed zones, it would be "unfair" for these "laggards" that they are required to deploy IPv6 services and publish corresponding AAAAs when they only need (for whatever reasons) IPv4-only services. I suspect referring to RFC6540 doesn't help for those people. On a related note, there's one thing I'm not sure from the draft: whether "requiring AAAA" also means "requiring to provide the corresponding service over IPv6" (here I assume the existence of such a service; that should normally be the case in practice). In the previous paragraph I assumed the draft requires this too, but if it only means some AAAA that is correctly signed but the address doesn't have to be accessible over IPv6, then it might be more acceptable for lazy "laggards". Ideally such an unreachable IPv6 address should cause an immediate failure when an IPv6 node tries to send a packet to it, but some smartness like HE may be good enough to handle cases where those IPv6 addresses create a blackhole. If that's the intent of the draft, I'd suggest making it clearer, possibly with suggesting some specific IPv6 addresses (maybe ::?) to be used for this purpose. This draft seems to also talk about providing IPv6 reachability to name servers (which is irrelevant to providing DNSSEC-signed AAAA). For example Section 6 states: In the context of this document, and others that may be generated as a consequence of it, "IPv6-Ready DNS/DNSSEC Infrastructure" means that a DNS/DNSSEC server (root, TLD, authoritative NS, others) is fully accessible and operational if queried either from a remote dual-stack network or an IPv6-only network. Is my understanding correct? If so, I suspect it's more likely to be just ignored by the "laggards" for the same reason as that I mentioned above. And, in any case, I personally think it's better if this document focuses on the issue of interaction between DNSSEC and DNS64. If my understanding of this part is incorrect, then it's not clear to me what it means and I'd suggest rewriting it. -- JINMEI, Tatuya --000000000000332017057c73b5fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At Mon, 3 Dec 2018 16:56:51 +0000,
Ron= Bonica <rbonica@juniper.net&= gt; wrote:

> Each week between now and IETF 104, we will review a= nd discuss one draft with an eye towards progressing it.
>
> T= his week, please review and comment on draft-bp-v6ops-ipv6-ready-dns-dnssec= .

I've read draft-bp-v6ops-ipv6-ready-dns-dnssec-00.

Whil= e the motivation is laudable, I have to say I'm skeptical about
its = effectiveness if one main audience is "the IPv4 laggards".=C2=A0 = Just
as it may be "unfair" that an IPv6-only service provider = needs to
handle A-only DNSSEC signed zones, it would be "unfair&quo= t; for these
"laggards" that they are required to deploy IPv6 = services and publish
corresponding AAAAs when they only need (for whatev= er reasons)
IPv4-only services.=C2=A0 I suspect referring to RFC6540 doe= sn't help for
those people.

On a related note, there's on= e thing I'm not sure from the draft:
whether "requiring AAAA&qu= ot; also means "requiring to provide the
corresponding service over= IPv6" (here I assume the existence of such
a service; that should = normally be the case in practice).=C2=A0 In the
previous paragraph I ass= umed the draft requires this too, but if it
only means some AAAA that is= correctly signed but the address doesn't
have to be accessible over= IPv6, then it might be more acceptable for
lazy "laggards".= =C2=A0 Ideally such an unreachable IPv6 address should
cause an immediat= e failure when an IPv6 node tries to send a packet to
it, but some smart= ness like HE may be good enough to handle cases
where those IPv6 address= es create a blackhole.=C2=A0 If that's the intent
of the draft, I= 9;d suggest making it clearer, possibly with suggesting
some specific IP= v6 addresses (maybe ::?) to be used for this purpose.

This draft see= ms to also talk about providing IPv6 reachability to
name servers (which= is irrelevant to providing DNSSEC-signed AAAA).
For example Section 6 s= tates:

=C2=A0=C2=A0 In the context of this document, and others that= may be generated as
=C2=A0=C2=A0 a consequence of it, "IPv6-Ready = DNS/DNSSEC Infrastructure" means
=C2=A0=C2=A0 that a DNS/DNSSEC ser= ver (root, TLD, authoritative NS, others) is
=C2=A0=C2=A0 fully accessib= le and operational if queried either from a remote
=C2=A0=C2=A0 dual-sta= ck network or an IPv6-only network.

Is my understanding correct?=C2= =A0 If so, I suspect it's more likely to be
just ignored by the &quo= t;laggards" for the same reason as that I mentioned
above.=C2=A0 An= d, in any case, I personally think it's better if this
document focu= ses on the issue of interaction between DNSSEC and
DNS64.=C2=A0 If my un= derstanding of this part is incorrect, then it's not
clear to me wha= t it means and I'd suggest rewriting it.

--
JINMEI, Tatuya
--000000000000332017057c73b5fc-- From nobody Fri Dec 7 11:51:37 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55498130E96 for ; Fri, 7 Dec 2018 11:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0T2muDrm4lm for ; Fri, 7 Dec 2018 11:51:33 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 D24C21200D7 for ; Fri, 7 Dec 2018 11:51:32 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id z11so2167816pgu.0 for ; Fri, 07 Dec 2018 11:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8n/BpP90hsBA1jkY+I6NZmyhQLsZFV0DiIYvykcKnHY=; b=nu2B8MFQCepG+ceEOVwBegeZnS8ajiv6ieGcHlr995goeBTfKHiJb6U+z9ky8XEVEz P/FVboT0kzJ7ZaFOWmiQ90+I7c4YUdkGOFCEdx2DFvvhwGfbXzJScK0/A/ijxnm6Duis YvUb6l0qFkIkVwPtOlj2uB65awQxdq/ZZ83Qd95/FeOJ5eCIsH+9T5SJR63h0BBtqiw0 ejlfVnpwc7JHK681oDvlTrC8YpfKSzgWg6o1h74VGOfq61aTmqWQiu31PMJe8f+SJKYa jbPlUJqZlvJftx7S/dRiWufJnES77ZZkHfKBwMflyPnAfqOoFX6Mx0AlxJcJBiC1vQaK qOxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8n/BpP90hsBA1jkY+I6NZmyhQLsZFV0DiIYvykcKnHY=; b=MLlSZNFAmi4p93NP1TcAycoC/w71X1AJSfVbi2h2DdXX/gRNY4NKTLWi7+4Sd1SiAY JP4WXdHouYAG9dn+PQM38Tezy0f60ycfLHsW4EnhhSN8EHsoL2gXCs8rQ4ZNu8ULuY2L FmyDLYRAjJAYxAGDlFM2Z3p7WNFP6DPg0UMwpRy6uijQ8nGdGUdDVs+TBmxHCfdNvHZ+ FnFMgIahQ0nkLPGE6QFq4a7k/0rIqtNRx6rKvuSamo9fjucKunqDa8DBQEOYXIyqTEK1 9q/cLduW3Syy7FFx6D0xJtfHbdN1QbDDT3ejoAVBfxRryAka2X5bSiG+yCpr20Ml3ks5 UTGw== X-Gm-Message-State: AA+aEWZRxB9XNTBBlzFCscmiMi3N6xXLubmsRb0brwycfWqLzh9GNiOx H3AqPJodr50e3LqYCgRrCkeKjy/P8So= X-Google-Smtp-Source: AFSGD/XC4wAV/rwVixyEHphDoSEnm+qCQ8lynLrXCQ3z8IdhSe/rkYdCl2sKFueAOcDHzcNC1KDquA== X-Received: by 2002:a63:24c2:: with SMTP id k185mr2994964pgk.406.1544212292147; Fri, 07 Dec 2018 11:51:32 -0800 (PST) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id o66sm12616081pgo.75.2018.12.07.11.51.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Dec 2018 11:51:31 -0800 (PST) To: =?UTF-8?B?56We5piO6YGU5ZOJ?= , Ronald Bonica Cc: v6ops@ietf.org References: From: Brian E Carpenter Message-ID: <32f99408-8ece-81e0-c6f8-42ff253e33fa@gmail.com> Date: Sat, 8 Dec 2018 08:51:26 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-bp-v6ops-ipv6-ready-dns-dnssec X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 19:51:35 -0000 On 2018-12-08 08:34, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Mon, 3 Dec 2018 16:56:51 +0000, > Ron Bonica wrote: >=20 >> Each week between now and IETF 104, we will review and discuss one dra= ft > with an eye towards progressing it. >> >> This week, please review and comment on > draft-bp-v6ops-ipv6-ready-dns-dnssec. >=20 > I've read draft-bp-v6ops-ipv6-ready-dns-dnssec-00. >=20 > While the motivation is laudable, I have to say I'm skeptical about > its effectiveness if one main audience is "the IPv4 laggards". =20 Unfortunately I have to agree. An IETF RFC seems like the least likely method of achieving the desired result. I think past experience shows that hard, persistent work through the major operational gatherings and forums, particularly the various RIR-sponsored meetings, with help from ISOC, is the only way to get anywhere. Brian > Just > as it may be "unfair" that an IPv6-only service provider needs to > handle A-only DNSSEC signed zones, it would be "unfair" for these > "laggards" that they are required to deploy IPv6 services and publish > corresponding AAAAs when they only need (for whatever reasons) > IPv4-only services. I suspect referring to RFC6540 doesn't help for > those people. >=20 > On a related note, there's one thing I'm not sure from the draft: > whether "requiring AAAA" also means "requiring to provide the > corresponding service over IPv6" (here I assume the existence of such > a service; that should normally be the case in practice). In the > previous paragraph I assumed the draft requires this too, but if it > only means some AAAA that is correctly signed but the address doesn't > have to be accessible over IPv6, then it might be more acceptable for > lazy "laggards". Ideally such an unreachable IPv6 address should > cause an immediate failure when an IPv6 node tries to send a packet to > it, but some smartness like HE may be good enough to handle cases > where those IPv6 addresses create a blackhole. If that's the intent > of the draft, I'd suggest making it clearer, possibly with suggesting > some specific IPv6 addresses (maybe ::?) to be used for this purpose. >=20 > This draft seems to also talk about providing IPv6 reachability to > name servers (which is irrelevant to providing DNSSEC-signed AAAA). > For example Section 6 states: >=20 > In the context of this document, and others that may be generated as= > a consequence of it, "IPv6-Ready DNS/DNSSEC Infrastructure" means > that a DNS/DNSSEC server (root, TLD, authoritative NS, others) is > fully accessible and operational if queried either from a remote > dual-stack network or an IPv6-only network. >=20 > Is my understanding correct? If so, I suspect it's more likely to be > just ignored by the "laggards" for the same reason as that I mentioned > above. And, in any case, I personally think it's better if this > document focuses on the issue of interaction between DNSSEC and > DNS64. If my understanding of this part is incorrect, then it's not > clear to me what it means and I'd suggest rewriting it. >=20 > -- > JINMEI, Tatuya >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Fri Dec 7 12:15:40 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59946130FCE for ; Fri, 7 Dec 2018 12:15:38 -0800 (PST) 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_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUGJA4LdPisG for ; Fri, 7 Dec 2018 12:15:36 -0800 (PST) Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (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 4DFFD130FCB for ; Fri, 7 Dec 2018 12:15:36 -0800 (PST) Received: by mail-wm1-f46.google.com with SMTP id y139so5477349wmc.5 for ; Fri, 07 Dec 2018 12:15:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6dP7yOPjgNSroyIniteATeRH6Yb3oIZngjsxaYHmTfc=; b=Sw+8ZDf+AyKOVdp1tdE7THBJwdRa1xEt/2yub5PPhdHSrG7+7NoDO4C4LuK9fvF33h pXImnfR5Gdf0y4tLfTWFY7KQD4SZitUOq4Of20zfweq/13+SRg5CF2VOF/S3VrYAAtgn ATq8bpgGbkOQVPqDsvqzRhQqHapU8qS+Rsz8jQOPXua+Cuo+gOfbxqQO6ntokVPhCerd RzdnsXkDJmlMGbbL39L6zQ3CvjhczRcOGA0zLxrkvevkVKwxLqi4ZItJt8CHHfgaqRs7 drC656qjzjj+ocg4ZfMTi1hG8pqaerivGkDGwDb4MWzPIq2nB3idG5j8gEK6zm+IFdMs 65Og== X-Gm-Message-State: AA+aEWZpLj7rOTSPACHRNWwwuzUDH6m4ujfmNGaTgl8GfVbZ8m8zSM8z GF7oQX8ukpjYQIWZRTRMokVCOzKfW09U+qIXZpprss54 X-Google-Smtp-Source: AFSGD/XU8sJYQZiyI/9OKpo6YFV116nv2utMsuasRCxzTf/Jr0j8xfk7gtt18Mhto2OxmNtU1VqgnR2vL6exfwdtMQU= X-Received: by 2002:a1c:8d49:: with SMTP id p70mr3670740wmd.68.1544213734429; Fri, 07 Dec 2018 12:15:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 7 Dec 2018 12:15:22 -0800 Message-ID: To: Ronald Bonica Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="000000000000191b24057c7447d1" Archived-At: Subject: Re: [v6ops] draft-bp-v6ops-ipv6-ready-dns-dnssec X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 20:15:38 -0000 --000000000000191b24057c7447d1 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 7, 2018 at 11:34 wrote: > On a related note, there's one thing I'm not sure from the draft: > whether "requiring AAAA" also means "requiring to provide the > corresponding service over IPv6" (here I assume the existence of > such a service; that should normally be the case in practice). Immediately after sending the message I realized I was confused here...it should obviously mean "also providing IPv6 services"; otherwise the IPv6-only networks would still need some trick to deal with "inauthentic AAAAs". So I think the draft should state it even more clearly. It's quite easy and cheap to Just sign and publish AAAA, but it's certainly more complicated and costly for a now-IPv4-only network to support IPv6 services. It would be misleading to simply say "requiring AAAA" without clarifying that point. And then my higher point about the effectiveness applies, though... -- JINMEI, Tatuya --000000000000191b24057c7447d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 7, 2018 at 11:34 <jinmei@wide.ad.jp> wrote:

>= =C2=A0=C2=A0=C2=A0 On a related note, there's one thing I'm not sur= e from the draft:
>=C2=A0=C2=A0=C2=A0 whether "requiring AAAA&qu= ot; also means "requiring to provide the
>=C2=A0=C2=A0=C2=A0 cor= responding service over IPv6" (here I assume the existence of
>= =C2=A0=C2=A0=C2=A0 such a service; that should normally be the case in prac= tice).

Immediately after sending the message I realized I was confus= ed
here...it should obviously mean "also providing IPv6 services&qu= ot;;
otherwise the IPv6-only networks would still need some trick to dea= l
with "inauthentic AAAAs".=C2=A0 So I think the draft should = state it even
more clearly.=C2=A0 It's quite easy and cheap to Just = sign and publish
AAAA, but it's certainly more complicated and costl= y for a
now-IPv4-only network to support IPv6 services.=C2=A0 It would b= e
misleading to simply say "requiring AAAA" without clarifying= that
point.=C2=A0 And then my higher point about the effectiveness appl= ies,
though...

--
JINMEI, Tatuya
--000000000000191b24057c7447d1-- From nobody Fri Dec 7 13:23:40 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FFE130FEB for ; Fri, 7 Dec 2018 13:23:38 -0800 (PST) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqyFvAKQaWin for ; Fri, 7 Dec 2018 13:23:36 -0800 (PST) Received: from atl4mhob12.registeredsite.com (atl4mhob12.registeredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id 580C5130FEE for ; Fri, 7 Dec 2018 13:23:36 -0800 (PST) Received: from mailpod.hostingplatform.com (atl4qobmail03pod6.registeredsite.com [10.30.71.211]) by atl4mhob12.registeredsite.com (8.14.4/8.14.4) with ESMTP id wB7LNXrP001787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 7 Dec 2018 16:23:33 -0500 Received: (qmail 18140 invoked by uid 0); 7 Dec 2018 21:23:33 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.103?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 7 Dec 2018 21:23:33 -0000 To: v6ops@ietf.org References: From: Lee Howard Message-ID: <865b83dc-15db-e293-f320-c951634dc14f@asgard.org> Date: Fri, 7 Dec 2018 16:23:32 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] draft-bp-v6ops-ipv6-ready-dns-dnssec X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2018 21:23:39 -0000 On 12/3/18 11:56 AM, Ron Bonica wrote: > Folks, > > Each week between now and IETF 104, we will review and discuss one draft with an eye towards progressing it. > > This week, please review and comment on draft-bp-v6ops-ipv6-ready-dns-dnssec. > > Fred and Ron I like the wording of draft-byrne-v6ops-dnssecaaaa better. The substantive change here is section 7, the actual timeline, and I expect it would have the same effectiveness as rfc5211 "An Internet Transition Plan," which indicated a transition phase January 2010 - December 2011. In all other ways I find this document inferior to draft-byrne-v6ops-dnssecaaaa, a document I supported (with comments, like wanting to know if there are ever any DNSSEC validators behind DNS64). For judging consensus: I think a document would be useful in this space, but I don't think this is that document. Detailed review follows. _Abstract_: A key issue for this, is the need for a global support to A key need is for global support _Introduction_: which will help to ensure that, when a network or part of it, becomes IPv6-only, still can have access to IPv4-only resources. to which will help to ensure that, when a network has IPv6 only, devices still have access to IPv4-only hosts. DNS64 ([RFC6147 ]) is a widely deployed technology allowing hundreds of millions of IPv6-only hosts/networks to reach IPv4-only resources. Sounds like there's something uniquely scalable about DNS64. The description is section 3 is better, but also completely redundant with this paragraph. The text from "Furthermore, the deployment of those transition mechanisms" to "deployment in a fair way" seems out of place for an IETF document. I completely agree that it's unfair that those without IPv4 addresses must bear the cost of connecting to those with IPv4 addresses, I'm just not sure that's a consideration for the IETF. _Section 3_ I don't understand "While DNS64([RFC6147 ]) outlines may work in harmony". Is that meant to read "as outlined"? Or are there outlines in DNS64? Suggest editing: The document also states that the most complete and expedient path to avoid any negative interactions is, for the DNSSEC signed resources, to always include IPv6 AAAA resources records. to The best path to avoid any negative interactions is for all DNSSEC signed resources to always include IPv6 AAAA resource records. _Section 4_ unlikely to changes to unlikely to change not recommend to not recommended The sentence Ultimately, this guidance is simply restating [RFC6540 ], that IPv6 is mandatory for all Internet systems.  is true, but begs the question of why this document is needed. The text from the original introduction is better: As stated in [RFC6540 ], IPv6 [RFC8200 ] is not optional and failing to support IPv6 may result in failure to communicate on the internet, especially when DNSSEC signed IPv4-only resources are present. There is no reason for sections 3 and 4 to be separate sections, and there is no need for section 5, and I don't understand any reason for section 6. Section 7 was mentioned earlier. Section 8 could be rewritten to point out that if users get frequent warnings of DNSSEC validation failures (due to DNS64), they will begin to ignore them. Section 9 is not really within the authority of the IETF. ICANN does have an IPv6 program, and a proposal to track DNSSEC and IPv6 on servers is something they could do, but such a request would have to come via a liaison statement from the IAB, or even better, suggestions from the supporting organizations, including SSAC, RSSAC, ASO, gNSO, ccNSO, and maybe GAC. I hope that's useful. Lee From nobody Mon Dec 10 07:03:54 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB71129533 for ; Mon, 10 Dec 2018 07:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.161 X-Spam-Level: X-Spam-Status: No, score=-4.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvW8lL9JXwKz for ; Mon, 10 Dec 2018 07:03:45 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 CC8CD130F18 for ; Mon, 10 Dec 2018 07:03:45 -0800 (PST) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id wBAEsC7E000489 for ; Mon, 10 Dec 2018 07:03:45 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=JsXW8OgMLnjlHpwfmjwVnRVOwc0C0jq91P0v54O20Dw=; b=CGqv4vWpZJPqHdAAkNUSSBIOD5cY7dtiYP9nNoqmyiETyQot5LU38xJOD32BgkQrSf1w OyduthhMv05SkeGbri6ZqMUcpT2z2sX1C8IkUc4wj2tY7yQAPa/xG9DdkiMb24Y3m4v1 SgOQmaCOPkzWmf6QEKmKCUAI3ZeU+A66SWPwssowAGGiyAiXgqsjQG85T16ZI+yCXaBQ P/3QqFmRgBg8HV/En+IuuSKMJHp+40lX0ch3EP4GmjYiRAW97fMiiuwdgEXwsyF0Somb an2ZUb/3tf8InzrdeFcHRKAxx0bF4DwQPsY65wr8OaaFg2h1+uV9AerMjhPILbqIV+YN Lw== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp2058.outbound.protection.outlook.com [104.47.34.58]) by mx0a-00273201.pphosted.com with ESMTP id 2p9s32r58x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 10 Dec 2018 07:03:44 -0800 Received: from BYAPR05MB4245.namprd05.prod.outlook.com (20.176.252.26) by BYAPR05MB5015.namprd05.prod.outlook.com (20.177.230.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.6; Mon, 10 Dec 2018 15:03:42 +0000 Received: from BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::9dc7:1844:64f1:65b3]) by BYAPR05MB4245.namprd05.prod.outlook.com ([fe80::9dc7:1844:64f1:65b3%5]) with mapi id 15.20.1425.016; Mon, 10 Dec 2018 15:03:42 +0000 From: Ron Bonica To: "v6ops@ietf.org list" Thread-Topic: draft-ietf-v6ops-nat64-deployment Thread-Index: AdSQmX9Jkr1iMm+8RgmfVb5+ctwGjQ== Date: Mon, 10 Dec 2018 15:03:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.600.7 dlp-reaction: no-action x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR05MB5015; 6:f9neDm8R1X/YWyHKGYS2Rg5vMhs22Ul68q4Tiqg+K1+xg/303Fm5QeBycf7r3OLpJmLq9fXom5ZI1LREK1B5NdNFm5l29Qv/cQmJ0cJMBMY7p7XeAR5jXnUiEKJQYoVd8HdQMW9h/L5KXRzWKMzxO5F+6Yn0VKXYW6fdIsmKXy5P62AOH7dFiJ2Zk+876aIzU1ZRuFvQh9oINCnasqW3YMokborVBPToKlj6kasA3pTy5zpWw0K9HRoGlhr0gqrIGOnNDZA26xVwufVaaWCwV6p3ezJid+D/uH8Oa2XyHGjcSUUQR4tS/+DfGBkZL7oILx6eLXWDBiV0kIaLVoJJgBeD19IbMntafqXA4z7Vy+Z0k8tmlxuAPxrfUxr+eQvaW7rhc6Ghs3PBGZqXXB1Q3vfYbqdArvSRG+NFtDkrWQiKUzn6oNe2m6pdkbGqPCzFnLug/vtgCWOuKnpb6IoqXw==; 5:r+C0faeR/U3CmVOfLrDk+RuqXnr1JqKOwLhzJHdJF/Qwb6eJXQrNzQQAnAJKV1bRs2YzQh7fN7K4GoRgKAbIuQWDT7lht9ihb96JIaVByo0UHSUY/PBM8nTSlSIKU2xyEtcNHYySG0/ORPNxUrpMB9cNn7JeOIHMgqy1+aXAlYQ=; 7:RF0MlLP9E2uV8NPErRKyHIdj25DWWUIAYX8mZZQBBHLCVMVARnOG5gbjLgVreBXxjeRRIgeDHZC7UKsnALy8Id9imoVh8O+mfVFrGmuPdycVlvdby2b/gaUIqGRMbYmtPx91vGFLq09YX+G/MA0sGA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5d69c059-be58-4da0-8bec-08d65eb0ac75 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB5015; x-ms-traffictypediagnostic: BYAPR05MB5015: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230017)(999002)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231472)(944501520)(52105112)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:BYAPR05MB5015; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB5015; x-forefront-prvs: 08828D20BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(366004)(136003)(376002)(39860400002)(199004)(189003)(4743002)(99286004)(102836004)(26005)(186003)(316002)(6506007)(558084003)(7696005)(6916009)(8676002)(81156014)(68736007)(74316002)(33656002)(6436002)(97736004)(86362001)(81166006)(305945005)(8936002)(5660300001)(7736002)(55016002)(9686003)(3846002)(6116002)(2906002)(53936002)(66066001)(256004)(106356001)(105586002)(25786009)(478600001)(14454004)(476003)(486006)(71200400001)(71190400001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5015; H:BYAPR05MB4245.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: plRvTprp/7xfErHEgrhEl8t27JxopEs9qFuLSeFS5qzTTmS8VWZO3dHDWioBEzQYfbvDt+dMKrpsjAkSCON46EDCTEkHR3aOnx5MmgNNyLYF9tVeWVEYVNLKRQsWL4It3jSiwC5o3ku6jZfHEA1Wh/3/ZqZmGV+RwyKkE7C62uNOCf3CXjvC5NX6gaRrxVpUlUwC84bPmyc4jwfoG9ykY9+PjZxKvWETBHjhgfZoSZ4Zj4KKKmPat/7DI72YpqqxvScSfI0KV/KVpCSaCT/erDBpBs9wevRAPLiY+KdhDdouFT3rLw2Jcj3Orm8kwWL1 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 5d69c059-be58-4da0-8bec-08d65eb0ac75 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2018 15:03:41.9112 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5015 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-10_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=519 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812100136 Archived-At: Subject: [v6ops] draft-ietf-v6ops-nat64-deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 15:03:53 -0000 Folks, Each week between now and IETF 104, we will review and discuss one draft wi= th an eye towards progressing it. This week, please review and comment on draft-ietf-v6ops-nat64-deployment. Fred and Ron From nobody Thu Dec 13 12:49:49 2018 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 901AC130E9B; Thu, 13 Dec 2018 12:49:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema To: Cc: v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-transition-ipv4aas.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154473417654.32125.9104927217788947044@ietfa.amsl.com> Date: Thu, 13 Dec 2018 12:49:36 -0800 Archived-At: Subject: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 20:49:37 -0000 Reviewer: Christian Huitema Review result: Has Issues I have reviewed draft-ietf-v6ops-transition-ipv4aas-11 as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is "ready with issue". The document describes solution for providing "IPv4 as a service", i.e. provision of IPv4 as a service over an IPv6 only network. It calls this support "transition as a service". For various reasons, IETF working groups have standardized not just one but five different mechanisms for providing this transition: 464XLAT [RFC6877], Dual-Stack Lite [RFC6333], Lightweight 4over6 (lw4o6) [RFC7596], MAP-E [RFC7597], and MAP-T [RFC7599]. (I am sure that Monty Python could have produced a nice sketch about that.) The purpose of the draft is to state how home routers (a.k.a. customer premise equipment, CPE) should inform local devices about which of the mechanisms are available, which should be preferred, and what parameters should be used when deploying the chosen services. This is done using the DHCPv6 "S46" option specified in RFC 8026. The draft also makes specific recommendation regarding the use of the UPnP and PCP services, by requiring specific error codes when a requested port mapping is not available through the specified transition technology. The security section briefly points to the "Basic Requirements for IPv6 Customer Edge Routers" specified in RFC 7084, and to the security section of each of the RFC describing the security technologies, and implicitly argues that there are no other security issues. I think that is insufficient. The draft introduces a reliance on the DHCPv6 "S46" option for assessing the relative priority of different transition technologies. An attacker could spoof the DHCPv6 response, and direct client traffic to a different technology than selected by the service provider. This could be used, for example, to capture IPv4 traffic in an IPv6 network and send it to a route chosen by the attacker. The attack might also be used in a dual stack network that does not support any transition technology. I don't understand how this attack is mitigated. Nits: The introduction uses the acronym WAN without spelling out "Wide Area Network". Also, WAN is used as substitute for local Internet Service Provider network. We could debate whether such networks are always "wide area", by opposition to say "metropolitan" or "regional". This is the same convention used in RFC 7084 that this document updates. It is arguably defined by reference, but spelling it out would be nice. The comparison with RFC7084 section includes a mangled sentence: This document doesn't include support for 6rd ([RFC5969]), because as in an IPv6-in-IPv4 tunneling. Please rephrase. Please also rephrase the next sentence, for similar reasons: Regarding DS-LITE [RFC6333], this document includes slightly different requirements, because the PCP ([RFC6887]) support and the prioritization of the transition mechanisms, including dual-stack. From nobody Thu Dec 13 14:09:34 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A6A130EAB; Thu, 13 Dec 2018 14:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: 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_UocSz880fb; Thu, 13 Dec 2018 14:09:18 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E740F130EA9; Thu, 13 Dec 2018 14:09:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1544738953; x=1545343753; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=wr+XANuANecS0GYlO+Omfz5q8NiilK8Ke9B377eVZYs=; b=OxFrD8td9bD3R l9CtefcdORS9X8pStsNMOf0y8zQV+CK2PnsOEJd6hCUiA0C8FKy5Odh7IKcwz3vF vRmWpjXOh4hBJdPe0Jn1OR5e/65vw5cn7dkfJ+dCRBShBShkAQs/93R/EmDdn18T gRH6kchQsb3BzE8OxrhUZ32Dh/WhHg= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 13 Dec 2018 23:09:13 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 13 Dec 2018 23:09:12 +0100 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006063193.msg; Thu, 13 Dec 2018 23:09:12 +0100 X-MDRemoteIP: 2001:470:1f09:495:a811:1373:c444:4be5 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Thu, 13 Dec 2018 23:09:12 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1885a872f7=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Thu, 13 Dec 2018 23:09:09 +0100 From: JORDI PALET MARTINEZ To: Christian Huitema , CC: , , Message-ID: <5BF30E2E-4B57-415E-8D8D-6C6815B604FF@consulintel.es> Thread-Topic: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 References: <154473417654.32125.9104927217788947044@ietfa.amsl.com> In-Reply-To: <154473417654.32125.9104927217788947044@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 22:09:21 -0000 Hi Christian, Thanks a lot for your review. Please see below in-line. I'm working in a new version according to the comments got from the ops rev= iew as well, so will be able to integrate yours very quickly. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Christian Huitema Fecha: jueves, 13 de diciembre de 2018, 21:50 Para: CC: , , Asunto: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4= aas-11 Reviewer: Christian Huitema Review result: Has Issues =20 I have reviewed draft-ietf-v6ops-transition-ipv4aas-11 as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG ch= airs should treat these comments just like any other last call comments. =20 The summary of the review is "ready with issue". =20 The document describes solution for providing "IPv4 as a service", i.e. provision of IPv4 as a service over an IPv6 only network. It calls this support "transition as a service". =20 For various reasons, IETF working groups have standardized not just one= but five different mechanisms for providing this transition: 464XLAT [RFC68= 77], Dual-Stack Lite [RFC6333], Lightweight 4over6 (lw4o6) [RFC7596], MAP-E [RFC7597], and MAP-T [RFC7599]. (I am sure that Monty Python coul= d have produced a nice sketch about that.) The purpose of the draft is to state how home routers (a.k.a. customer premise equipment, CPE) should inform local devices about which of the mechanisms are available, which should be preferred, and what parameters should be used when deploying the chosen services. This is done using the DHCPv6 "S46" option specified in RFC 8026. =20 The draft also makes specific recommendation regarding the use of the U= PnP and PCP services, by requiring specific error codes when a requested port m= apping=20 is not available through the specified transition technology. =20 The security section briefly points to the "Basic Requirements for IPv6 Customer Edge Routers" specified in RFC 7084, and to the security section of each of the RFC describing the security technologies, and im= plicitly argues that there are no other security issues. I think that is insuffi= cient. =20 The draft introduces a reliance on the DHCPv6 "S46" option for assessin= g the relative priority of different transition technologies. An attacker cou= ld spoof the DHCPv6 response, and direct client traffic to a different technolog= y than selected by the service provider. This could be used, for example, to c= apture IPv4 traffic in an IPv6 network and send it to a route chosen by the at= tacker. The attack might also be used in a dual stack network that does not sup= port any transition technology. I don't understand how this attack is mitiga= ted. Not sure if you will suggest here that we should say something about the se= curity considerations already mention in RFC8026. In general all those are = generic DHCPv6 security considerations I think. =20 Nits: =20 The introduction uses the acronym WAN without spelling out "Wide Area N= etwork".=20 Also, WAN is used as substitute for local Internet Service Provider net= work. We could debate whether such networks are always "wide area", by opposition to s= ay "metropolitan" or "regional". This is the same convention used in RFC 7= 084 that this document updates. It is arguably defined by reference, but spellin= g it out would be nice. =20 Will do. =20 The comparison with RFC7084 section includes a mangled sentence:=20 =20 This document doesn't include support for 6rd ([RFC5969]), because a= s in an IPv6-in-IPv4 tunneling. Typo, sorry the correct sentence was: This document doesn't include support for 6rd ([RFC5969]), because i= s an IPv6-in-IPv4 tunneling. =20 Please rephrase. Please also rephrase the next sentence, for similar re= asons: =20 Regarding DS-LITE [RFC6333], this document includes slightly different requirements, because the PCP ([RFC6887]) support and the prioritization of the transition mechanisms, including dual-stack. I think it is much clear this way: Regarding DS-LITE [RFC6333], this document includes slightly different requirements, related to the support of PCP ([RFC6887]), IGD-PCP IWF [RFC6970] and the prioritization of the transition=20 mechanisms, including dual-stack. =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Dec 13 23:32:57 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C025126C01; Thu, 13 Dec 2018 23:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xX7uASxIQe8; Thu, 13 Dec 2018 23:32:41 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981371310C2; Thu, 13 Dec 2018 23:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1544772758; x=1545377558; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=bjwZVhty+r7g8955qMvA+mk6BWbmAPRnXQt0vOI5ikY=; b=VoptqCqfnPep6 EJxrmuXvNDrLG3dbM0Rinq80or8rGlxbbIxXmc24onG4XOPvaR981hgJqn6G3iGr 3gRq9KNMOod54Z1v26UboqvgNCh/jPjNZXB1UClaPv4W5P/8g0m5Qm8f0ipJaZd/ Gua+bxv4khrQFxrzftWzSOWyuWGK+M= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 14 Dec 2018 08:32:38 +0100 X-Spam-Processed: mail.consulintel.es, Fri, 14 Dec 2018 08:32:38 +0100 Received: from [10.10.10.99] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006064428.msg; Fri, 14 Dec 2018 08:32:36 +0100 X-MDRemoteIP: 2001:470:1f09:495:2d51:35fd:4fd9:8498 X-MDHelo: [10.10.10.99] X-MDArrival-Date: Fri, 14 Dec 2018 08:32:36 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=18861ebfab=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Fri, 14 Dec 2018 08:32:35 +0100 From: JORDI PALET MARTINEZ To: Christian Huitema , CC: , , Message-ID: Thread-Topic: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 References: <154473417654.32125.9104927217788947044@ietfa.amsl.com> <5BF30E2E-4B57-415E-8D8D-6C6815B604FF@consulintel.es> <2a90813d-bae7-1bd0-90fa-9fd1a8621b78@huitema.net> In-Reply-To: <2a90813d-bae7-1bd0-90fa-9fd1a8621b78@huitema.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 07:32:44 -0000 Regarding the DHCPv6 unsafety ... The problem I see is that your recommenda= tion will be against the use of DHCPv6 in a generic way. This is a much broader problem that our document, so out of scope of this d= ocument itself ! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: ietf en nombre de Christian Huitema Fecha: viernes, 14 de diciembre de 2018, 8:26 Para: JORDI PALET MARTINEZ , CC: , , Asunto: Re: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-= ipv4aas-11 =20 On 12/13/2018 2:09 PM, JORDI PALET MARTINEZ wrote: > Hi Christian, > > Thanks a lot for your review. > > Please see below in-line. > > I'm working in a new version according to the comments got from the o= ps review as well, so will be able to integrate yours very quickly. > > Regards, > Jordi > =20 > =20 > > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de Christian Huitema > Fecha: jueves, 13 de diciembre de 2018, 21:50 > Para: > CC: , , > Asunto: [v6ops] Secdir last call review of draft-ietf-v6ops-transitio= n-ipv4aas-11 > > Reviewer: Christian Huitema > Review result: Has Issues > =20 > I have reviewed draft-ietf-v6ops-transition-ipv4aas-11 as part of= the > security directorate's ongoing effort to review all IETF document= s > being processed by the IESG. These comments were written primari= ly for > the benefit of the security area directors. Document editors and= WG chairs > should treat these comments just like any other last call comment= s. > =20 > The summary of the review is "ready with issue". > =20 > The document describes solution for providing "IPv4 as a service"= , i.e. > provision of IPv4 as a service over an IPv6 only network. > It calls this support "transition as a service". > =20 > For various reasons, IETF working groups have standardized not ju= st one but > five different mechanisms for providing this transition: 464XLAT = [RFC6877], > Dual-Stack Lite [RFC6333], Lightweight 4over6 (lw4o6) [RFC7596], > MAP-E [RFC7597], and MAP-T [RFC7599]. (I am sure that Monty Pytho= n could have > produced a nice sketch about that.) The purpose of the draft is t= o > state how home routers (a.k.a. customer premise equipment, CPE) s= hould > inform local devices about which of the mechanisms are available,= which > should be preferred, and what parameters should be used when depl= oying > the chosen services. This is done using the DHCPv6 "S46" option > specified in RFC 8026. > =20 > The draft also makes specific recommendation regarding the use of= the UPnP and > PCP services, by requiring specific error codes when a requested = port mapping=20 > is not available through the specified transition technology. > =20 > The security section briefly points to the "Basic Requirements fo= r IPv6 > Customer Edge Routers" specified in RFC 7084, and to the security > section of each of the RFC describing the security technologies, = and implicitly > argues that there are no other security issues. I think that is i= nsufficient. > =20 > The draft introduces a reliance on the DHCPv6 "S46" option for as= sessing the > relative priority of different transition technologies. An attack= er could spoof > the DHCPv6 response, and direct client traffic to a different tec= hnology than > selected by the service provider. This could be used, for example= , to capture > IPv4 traffic in an IPv6 network and send it to a route chosen by = the attacker. > The attack might also be used in a dual stack network that does n= ot support > any transition technology. I don't understand how this attack is = mitigated. > > Not sure if you will suggest here that we should say something about = the security considerations already mention in RFC8026. In general all thos= e are generic DHCPv6 security considerations I think. =20 Basically, the devices should be programmed to ignore DHCPv6 if they have another more secure way of getting their configuration data. Plus, apply general defense against DHCPv6 hacks in the network, etc. I understand that your draft is meant to inform the building of CPEs, but its effect is generalization of an unsafe mechanism. =20 =20 > =20 > Nits: > =20 > The introduction uses the acronym WAN without spelling out "Wide = Area Network".=20 > Also, WAN is used as substitute for local Internet Service Provid= er network. We could > debate whether such networks are always "wide area", by oppositio= n to say > "metropolitan" or "regional". This is the same convention used in= RFC 7084 that > this document updates. It is arguably defined by reference, but s= pelling it out > would be nice. > =20 > Will do. > > =20 > The comparison with RFC7084 section includes a mangled sentence:= =20 > =20 > This document doesn't include support for 6rd ([RFC5969]), bec= ause as > in an IPv6-in-IPv4 tunneling. > > Typo, sorry the correct sentence was: > This document doesn't include support for 6rd ([RFC5969]), bec= ause is > an IPv6-in-IPv4 tunneling. =20 This document doesn't include support for 6rd ([RFC5969]), becau= se it is an IPv6-in-IPv4 tunneling. =20 > =20 > Please rephrase. Please also rephrase the next sentence, for simi= lar reasons: > =20 > Regarding DS-LITE [RFC6333], this document includes slightly > different requirements, because the PCP ([RFC6887]) support an= d the > prioritization of the transition mechanisms, including dual-st= ack. > > I think it is much clear this way: > > Regarding DS-LITE [RFC6333], this document includes slightly > different requirements, related to the support of PCP ([RFC688= 7]), > IGD-PCP IWF [RFC6970] and the prioritization of the transition= =20 > mechanisms, including dual-stack. =20 =20 OK. =20 =20 > =20 > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > =20 > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged = or confidential. The information is intended to be for the exclusive use of= the individual(s) named above and further non-explicilty authorized disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, will be considered a criminal offense, so you must reply to the = original sender to inform about this communication and delete it. > > > =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu Dec 13 23:41:45 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DBC130DC4 for ; Thu, 13 Dec 2018 23:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3u7S-LtC3rC for ; Thu, 13 Dec 2018 23:41:42 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 EEF761310C2 for ; Thu, 13 Dec 2018 23:41:40 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx105.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gXhrR-0006pm-Ua for v6ops@ietf.org; Fri, 14 Dec 2018 08:26:19 +0100 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gXhrI-0000ec-TK for v6ops@ietf.org; Fri, 14 Dec 2018 02:26:09 -0500 Received: (qmail 18090 invoked from network); 14 Dec 2018 07:26:03 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.39]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 14 Dec 2018 07:26:03 -0000 To: JORDI PALET MARTINEZ , secdir@ietf.org Cc: v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-transition-ipv4aas.all@ietf.org References: <154473417654.32125.9104927217788947044@ietfa.amsl.com> <5BF30E2E-4B57-415E-8D8D-6C6815B604FF@consulintel.es> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <2a90813d-bae7-1bd0-90fa-9fd1a8621b78@huitema.net> Date: Thu, 13 Dec 2018 23:26:00 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <5BF30E2E-4B57-415E-8D8D-6C6815B604FF@consulintel.es> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: 168.144.250.230 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.13) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5hqkWmZN4WN3xEFt7tF6zcJ602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOxqmjSBeYFUbx3tX4ouiS+JVjyn5UrUp4n4yKOOaq9Axf4FFFYXG1Q5VutXKX+mx5FDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5jmcs6wj/46gnUNWAdTw+hKXe0Of4jddu9xC8 8+iQ5nb6BRFVjXUbiREH8mlR1JtPfYZ1V10x8j0kNETJD+nyXtcV2Hz37FuQUlYMDMlHwjIJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+1QmdZsu6 kxo/qWEj6Z1d7VIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdseygOIcx4SICe6nNcjjd/M50Y6QGVSvC9ATxEYI3bPwB8SDPWIMIEKMF AxWprElCBnlqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1RWkNIWnHjoiI9QIik6sV5hq 8RGminksXtFq8ejOBuf1PiUt8a2Lj9MmCjDfgJI6+RA1ehb6HWONF4LFnY3FB8iDg5/bq7ChmPMN Ycw1QSmR0sTjSbUIhBfwFuwUtaRLEnxso15tFnk+9NDilEmVjcpm4zuNRcgRKiGg7nXFaZTxCXRq rnqpvNj9xYi9OgZhih19I4GlR3I7yPSC6eTb8vy+NTKQHNkjJg8xvPcdYB8XrwJaVYn9nnZjaUrj DGzQ2f27lItOpPwlvQ6ktwDuRituj6ZEfB9v4x8THVh0rVtlyOZYRaCjaXhrY3nerbmurCmoQsay Zkd2YakTHWoyevr4xM5tUrEfL92iWzfzWX2vc1ctxv2vDEIpeWV/lG6Wmg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 07:41:44 -0000 On 12/13/2018 2:09 PM, JORDI PALET MARTINEZ wrote: > Hi Christian, > > Thanks a lot for your review. > > Please see below in-line. > > I'm working in a new version according to the comments got from the ops review as well, so will be able to integrate yours very quickly. > > Regards, > Jordi > > > > -----Mensaje original----- > De: v6ops en nombre de Christian Huitema > Fecha: jueves, 13 de diciembre de 2018, 21:50 > Para: > CC: , , > Asunto: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 > > Reviewer: Christian Huitema > Review result: Has Issues > > I have reviewed draft-ietf-v6ops-transition-ipv4aas-11 as part of the > security directorate's ongoing effort to review all IETF documents > being processed by the IESG. These comments were written primarily for > the benefit of the security area directors. Document editors and WG chairs > should treat these comments just like any other last call comments. > > The summary of the review is "ready with issue". > > The document describes solution for providing "IPv4 as a service", i.e. > provision of IPv4 as a service over an IPv6 only network. > It calls this support "transition as a service". > > For various reasons, IETF working groups have standardized not just one but > five different mechanisms for providing this transition: 464XLAT [RFC6877], > Dual-Stack Lite [RFC6333], Lightweight 4over6 (lw4o6) [RFC7596], > MAP-E [RFC7597], and MAP-T [RFC7599]. (I am sure that Monty Python could have > produced a nice sketch about that.) The purpose of the draft is to > state how home routers (a.k.a. customer premise equipment, CPE) should > inform local devices about which of the mechanisms are available, which > should be preferred, and what parameters should be used when deploying > the chosen services. This is done using the DHCPv6 "S46" option > specified in RFC 8026. > > The draft also makes specific recommendation regarding the use of the UPnP and > PCP services, by requiring specific error codes when a requested port mapping > is not available through the specified transition technology. > > The security section briefly points to the "Basic Requirements for IPv6 > Customer Edge Routers" specified in RFC 7084, and to the security > section of each of the RFC describing the security technologies, and implicitly > argues that there are no other security issues. I think that is insufficient. > > The draft introduces a reliance on the DHCPv6 "S46" option for assessing the > relative priority of different transition technologies. An attacker could spoof > the DHCPv6 response, and direct client traffic to a different technology than > selected by the service provider. This could be used, for example, to capture > IPv4 traffic in an IPv6 network and send it to a route chosen by the attacker. > The attack might also be used in a dual stack network that does not support > any transition technology. I don't understand how this attack is mitigated. > > Not sure if you will suggest here that we should say something about the security considerations already mention in RFC8026. In general all those are generic DHCPv6 security considerations I think. Basically, the devices should be programmed to ignore DHCPv6 if they have another more secure way of getting their configuration data. Plus, apply general defense against DHCPv6 hacks in the network, etc. I understand that your draft is meant to inform the building of CPEs, but its effect is generalization of an unsafe mechanism. > > Nits: > > The introduction uses the acronym WAN without spelling out "Wide Area Network". > Also, WAN is used as substitute for local Internet Service Provider network. We could > debate whether such networks are always "wide area", by opposition to say > "metropolitan" or "regional". This is the same convention used in RFC 7084 that > this document updates. It is arguably defined by reference, but spelling it out > would be nice. > > Will do. > > > The comparison with RFC7084 section includes a mangled sentence: > > This document doesn't include support for 6rd ([RFC5969]), because as > in an IPv6-in-IPv4 tunneling. > > Typo, sorry the correct sentence was: > This document doesn't include support for 6rd ([RFC5969]), because is > an IPv6-in-IPv4 tunneling. This document doesn't include support for 6rd ([RFC5969]), because it is an IPv6-in-IPv4 tunneling. > > Please rephrase. Please also rephrase the next sentence, for similar reasons: > > Regarding DS-LITE [RFC6333], this document includes slightly > different requirements, because the PCP ([RFC6887]) support and the > prioritization of the transition mechanisms, including dual-stack. > > I think it is much clear this way: > > Regarding DS-LITE [RFC6333], this document includes slightly > different requirements, related to the support of PCP ([RFC6887]), > IGD-PCP IWF [RFC6970] and the prioritization of the transition > mechanisms, including dual-stack. OK. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > From nobody Thu Dec 13 23:44:46 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B74E1310CC; Thu, 13 Dec 2018 23:44:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGBPB-8Tak34; Thu, 13 Dec 2018 23:44:30 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C95A21310C2; Thu, 13 Dec 2018 23:44:29 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 43GMy41f3wz8tbS; Fri, 14 Dec 2018 08:44:28 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 43GMy40jd2z5vNC; Fri, 14 Dec 2018 08:44:28 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0415.000; Fri, 14 Dec 2018 08:44:27 +0100 From: To: Christian Huitema , JORDI PALET MARTINEZ , "secdir@ietf.org" CC: "v6ops@ietf.org" , "ietf@ietf.org" , "draft-ietf-v6ops-transition-ipv4aas.all@ietf.org" Thread-Topic: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 Thread-Index: AQHUk35gwIitBLjfoEqKymi2z0/HLKV92cbw Date: Fri, 14 Dec 2018 07:44:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302E059014@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <154473417654.32125.9104927217788947044@ietfa.amsl.com> <5BF30E2E-4B57-415E-8D8D-6C6815B604FF@consulintel.es> <2a90813d-bae7-1bd0-90fa-9fd1a8621b78@huitema.net> In-Reply-To: <2a90813d-bae7-1bd0-90fa-9fd1a8621b78@huitema.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 07:44:33 -0000 Q2hyaXN0aWFuLA0KDQpBcyBtZW50aW9uZWQgYnkgSm9yZGksIFJGQzgwMjYgYWxyZWFkeSBkZXNj cmliZXMgdGhlIGF0dGFjayB2ZWN0b3IgeW91IG1lbnRpb25lZC4gDQoNCldvdWxkbid0IHBvaW50 aW5nIHRvIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4NDE1I3NlY3Rpb24tMjIgYmUg c3VmZmljaWVudCBoZXJlPyANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQo+IERlwqA6IGlldGYgW21haWx0bzppZXRmLWJvdW5jZXNAaWV0Zi5vcmddIERl IGxhIHBhcnQgZGUgQ2hyaXN0aWFuIEh1aXRlbWENCj4gRW52b3nDqcKgOiB2ZW5kcmVkaSAxNCBk w6ljZW1icmUgMjAxOCAwODoyNg0KPiDDgMKgOiBKT1JESSBQQUxFVCBNQVJUSU5FWjsgc2VjZGly QGlldGYub3JnDQo+IENjwqA6IHY2b3BzQGlldGYub3JnOyBpZXRmQGlldGYub3JnOyBkcmFmdC1p ZXRmLXY2b3BzLXRyYW5zaXRpb24tDQo+IGlwdjRhYXMuYWxsQGlldGYub3JnDQo+IE9iamV0wqA6 IFJlOiBbdjZvcHNdIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtdjZvcHMt dHJhbnNpdGlvbi0NCj4gaXB2NGFhcy0xMQ0KPiANCj4gDQo+IE9uIDEyLzEzLzIwMTggMjowOSBQ TSwgSk9SREkgUEFMRVQgTUFSVElORVogd3JvdGU6DQo+ID4gSGkgQ2hyaXN0aWFuLA0KPiA+DQo+ ID4gVGhhbmtzIGEgbG90IGZvciB5b3VyIHJldmlldy4NCj4gPg0KPiA+IFBsZWFzZSBzZWUgYmVs b3cgaW4tbGluZS4NCj4gPg0KPiA+IEknbSB3b3JraW5nIGluIGEgbmV3IHZlcnNpb24gYWNjb3Jk aW5nIHRvIHRoZSBjb21tZW50cyBnb3QgZnJvbSB0aGUgb3BzDQo+IHJldmlldyBhcyB3ZWxsLCBz byB3aWxsIGJlIGFibGUgdG8gaW50ZWdyYXRlIHlvdXJzIHZlcnkgcXVpY2tseS4NCj4gPg0KPiA+ IFJlZ2FyZHMsDQo+ID4gSm9yZGkNCj4gPg0KPiA+DQo+ID4NCj4gPiDvu78tLS0tLU1lbnNhamUg b3JpZ2luYWwtLS0tLQ0KPiA+IERlOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gZW4g bm9tYnJlIGRlIENocmlzdGlhbiBIdWl0ZW1hDQo+IDxodWl0ZW1hQGh1aXRlbWEubmV0Pg0KPiA+ IEZlY2hhOiBqdWV2ZXMsIDEzIGRlIGRpY2llbWJyZSBkZSAyMDE4LCAyMTo1MA0KPiA+IFBhcmE6 IDxzZWNkaXJAaWV0Zi5vcmc+DQo+ID4gQ0M6IDx2Nm9wc0BpZXRmLm9yZz4sIDxpZXRmQGlldGYu b3JnPiwgPGRyYWZ0LWlldGYtdjZvcHMtdHJhbnNpdGlvbi0NCj4gaXB2NGFhcy5hbGxAaWV0Zi5v cmc+DQo+ID4gQXN1bnRvOiBbdjZvcHNdIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0 LWlldGYtdjZvcHMtdHJhbnNpdGlvbi0NCj4gaXB2NGFhcy0xMQ0KPiA+DQo+ID4gICAgIFJldmll d2VyOiBDaHJpc3RpYW4gSHVpdGVtYQ0KPiA+ICAgICBSZXZpZXcgcmVzdWx0OiBIYXMgSXNzdWVz DQo+ID4NCj4gPiAgICAgSSBoYXZlIHJldmlld2VkIGRyYWZ0LWlldGYtdjZvcHMtdHJhbnNpdGlv bi1pcHY0YWFzLTExIGFzIHBhcnQgb2YgdGhlDQo+ID4gICAgIHNlY3VyaXR5IGRpcmVjdG9yYXRl J3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cw0KPiA+ICAgICBi ZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4g cHJpbWFyaWx5IGZvcg0KPiA+ICAgICB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBk aXJlY3RvcnMuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRw0KPiBjaGFpcnMNCj4gPiAgICAgc2hv dWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNv bW1lbnRzLg0KPiA+DQo+ID4gICAgIFRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcgaXMgInJlYWR5 IHdpdGggaXNzdWUiLg0KPiA+DQo+ID4gICAgIFRoZSBkb2N1bWVudCBkZXNjcmliZXMgc29sdXRp b24gZm9yIHByb3ZpZGluZyAiSVB2NCBhcyBhIHNlcnZpY2UiLCBpLmUuDQo+ID4gICAgIHByb3Zp c2lvbiBvZiBJUHY0IGFzIGEgc2VydmljZSBvdmVyIGFuIElQdjYgb25seSBuZXR3b3JrLg0KPiA+ ICAgICBJdCBjYWxscyB0aGlzIHN1cHBvcnQgInRyYW5zaXRpb24gYXMgYSBzZXJ2aWNlIi4NCj4g Pg0KPiA+ICAgICBGb3IgdmFyaW91cyByZWFzb25zLCBJRVRGIHdvcmtpbmcgZ3JvdXBzIGhhdmUg c3RhbmRhcmRpemVkIG5vdCBqdXN0IG9uZQ0KPiBidXQNCj4gPiAgICAgZml2ZSBkaWZmZXJlbnQg bWVjaGFuaXNtcyBmb3IgcHJvdmlkaW5nIHRoaXMgdHJhbnNpdGlvbjogNDY0WExBVA0KPiBbUkZD Njg3N10sDQo+ID4gICAgIER1YWwtU3RhY2sgTGl0ZSBbUkZDNjMzM10sIExpZ2h0d2VpZ2h0IDRv dmVyNiAobHc0bzYpIFtSRkM3NTk2XSwNCj4gPiAgICAgTUFQLUUgW1JGQzc1OTddLCBhbmQgTUFQ LVQgW1JGQzc1OTldLiAoSSBhbSBzdXJlIHRoYXQgTW9udHkgUHl0aG9uDQo+IGNvdWxkIGhhdmUN Cj4gPiAgICAgcHJvZHVjZWQgYSBuaWNlIHNrZXRjaCBhYm91dCB0aGF0LikgVGhlIHB1cnBvc2Ug b2YgdGhlIGRyYWZ0IGlzIHRvDQo+ID4gICAgIHN0YXRlIGhvdyBob21lIHJvdXRlcnMgKGEuay5h LiBjdXN0b21lciBwcmVtaXNlIGVxdWlwbWVudCwgQ1BFKSBzaG91bGQNCj4gPiAgICAgaW5mb3Jt IGxvY2FsIGRldmljZXMgYWJvdXQgd2hpY2ggb2YgdGhlIG1lY2hhbmlzbXMgYXJlIGF2YWlsYWJs ZSwgd2hpY2gNCj4gPiAgICAgc2hvdWxkIGJlIHByZWZlcnJlZCwgYW5kIHdoYXQgcGFyYW1ldGVy cyBzaG91bGQgYmUgdXNlZCB3aGVuIGRlcGxveWluZw0KPiA+ICAgICB0aGUgY2hvc2VuIHNlcnZp Y2VzLiBUaGlzIGlzIGRvbmUgdXNpbmcgdGhlIERIQ1B2NiAiUzQ2IiBvcHRpb24NCj4gPiAgICAg c3BlY2lmaWVkIGluIFJGQyA4MDI2Lg0KPiA+DQo+ID4gICAgIFRoZSBkcmFmdCBhbHNvIG1ha2Vz IHNwZWNpZmljIHJlY29tbWVuZGF0aW9uIHJlZ2FyZGluZyB0aGUgdXNlIG9mIHRoZQ0KPiBVUG5Q IGFuZA0KPiA+ICAgICBQQ1Agc2VydmljZXMsIGJ5IHJlcXVpcmluZyBzcGVjaWZpYyBlcnJvciBj b2RlcyB3aGVuIGEgcmVxdWVzdGVkIHBvcnQNCj4gbWFwcGluZw0KPiA+ICAgICBpcyBub3QgYXZh aWxhYmxlIHRocm91Z2ggdGhlIHNwZWNpZmllZCB0cmFuc2l0aW9uIHRlY2hub2xvZ3kuDQo+ID4N Cj4gPiAgICAgVGhlIHNlY3VyaXR5IHNlY3Rpb24gYnJpZWZseSBwb2ludHMgdG8gdGhlICJCYXNp YyBSZXF1aXJlbWVudHMgZm9yIElQdjYNCj4gPiAgICAgQ3VzdG9tZXIgRWRnZSBSb3V0ZXJzIiBz cGVjaWZpZWQgaW4gUkZDIDcwODQsIGFuZCB0byB0aGUgc2VjdXJpdHkNCj4gPiAgICAgc2VjdGlv biBvZiBlYWNoIG9mIHRoZSBSRkMgZGVzY3JpYmluZyB0aGUgc2VjdXJpdHkgdGVjaG5vbG9naWVz LCBhbmQNCj4gaW1wbGljaXRseQ0KPiA+ICAgICBhcmd1ZXMgdGhhdCB0aGVyZSBhcmUgbm8gb3Ro ZXIgc2VjdXJpdHkgaXNzdWVzLiBJIHRoaW5rIHRoYXQgaXMNCj4gaW5zdWZmaWNpZW50Lg0KPiA+ DQo+ID4gICAgIFRoZSBkcmFmdCBpbnRyb2R1Y2VzIGEgcmVsaWFuY2Ugb24gdGhlIERIQ1B2NiAi UzQ2IiBvcHRpb24gZm9yDQo+IGFzc2Vzc2luZyB0aGUNCj4gPiAgICAgcmVsYXRpdmUgcHJpb3Jp dHkgb2YgZGlmZmVyZW50IHRyYW5zaXRpb24gdGVjaG5vbG9naWVzLiBBbiBhdHRhY2tlcg0KPiBj b3VsZCBzcG9vZg0KPiA+ICAgICB0aGUgREhDUHY2IHJlc3BvbnNlLCBhbmQgZGlyZWN0IGNsaWVu dCB0cmFmZmljIHRvIGEgZGlmZmVyZW50DQo+IHRlY2hub2xvZ3kgdGhhbg0KPiA+ICAgICBzZWxl Y3RlZCBieSB0aGUgc2VydmljZSBwcm92aWRlci4gVGhpcyBjb3VsZCBiZSB1c2VkLCBmb3IgZXhh bXBsZSwgdG8NCj4gY2FwdHVyZQ0KPiA+ICAgICBJUHY0IHRyYWZmaWMgaW4gYW4gSVB2NiBuZXR3 b3JrIGFuZCBzZW5kIGl0IHRvIGEgcm91dGUgY2hvc2VuIGJ5IHRoZQ0KPiBhdHRhY2tlci4NCj4g PiAgICAgVGhlIGF0dGFjayBtaWdodCBhbHNvIGJlIHVzZWQgaW4gYSBkdWFsIHN0YWNrIG5ldHdv cmsgdGhhdCBkb2VzIG5vdA0KPiBzdXBwb3J0DQo+ID4gICAgIGFueSB0cmFuc2l0aW9uIHRlY2hu b2xvZ3kuIEkgZG9uJ3QgdW5kZXJzdGFuZCBob3cgdGhpcyBhdHRhY2sgaXMNCj4gbWl0aWdhdGVk Lg0KPiA+DQo+ID4gTm90IHN1cmUgaWYgeW91IHdpbGwgc3VnZ2VzdCBoZXJlIHRoYXQgd2Ugc2hv dWxkIHNheSBzb21ldGhpbmcgYWJvdXQgdGhlDQo+IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFs cmVhZHkgbWVudGlvbiBpbiBSRkM4MDI2LiBJbiBnZW5lcmFsIGFsbCB0aG9zZSBhcmUNCj4gZ2Vu ZXJpYyBESENQdjYgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgSSB0aGluay4NCj4gDQo+IEJhc2lj YWxseSwgdGhlIGRldmljZXMgc2hvdWxkIGJlIHByb2dyYW1tZWQgdG8gaWdub3JlIERIQ1B2NiBp ZiB0aGV5DQo+IGhhdmUgYW5vdGhlciBtb3JlIHNlY3VyZSB3YXkgb2YgZ2V0dGluZyB0aGVpciBj b25maWd1cmF0aW9uIGRhdGEuIFBsdXMsDQo+IGFwcGx5IGdlbmVyYWwgZGVmZW5zZSBhZ2FpbnN0 IERIQ1B2NiBoYWNrcyBpbiB0aGUgbmV0d29yaywgZXRjLiBJDQo+IHVuZGVyc3RhbmQgdGhhdCB5 b3VyIGRyYWZ0IGlzIG1lYW50IHRvIGluZm9ybSB0aGUgYnVpbGRpbmcgb2YgQ1BFcywgYnV0DQo+ IGl0cyBlZmZlY3QgaXMgZ2VuZXJhbGl6YXRpb24gb2YgYW4gdW5zYWZlIG1lY2hhbmlzbS4NCj4g DQo+IA0KPiA+DQo+ID4gICAgIE5pdHM6DQo+ID4NCj4gPiAgICAgVGhlIGludHJvZHVjdGlvbiB1 c2VzIHRoZSBhY3JvbnltIFdBTiB3aXRob3V0IHNwZWxsaW5nIG91dCAiV2lkZSBBcmVhDQo+IE5l dHdvcmsiLg0KPiA+ICAgICBBbHNvLCBXQU4gaXMgdXNlZCBhcyBzdWJzdGl0dXRlIGZvciBsb2Nh bCBJbnRlcm5ldCBTZXJ2aWNlIFByb3ZpZGVyDQo+IG5ldHdvcmsuIFdlIGNvdWxkDQo+ID4gICAg IGRlYmF0ZSB3aGV0aGVyIHN1Y2ggbmV0d29ya3MgYXJlIGFsd2F5cyAid2lkZSBhcmVhIiwgYnkg b3Bwb3NpdGlvbiB0bw0KPiBzYXkNCj4gPiAgICAgIm1ldHJvcG9saXRhbiIgb3IgInJlZ2lvbmFs Ii4gVGhpcyBpcyB0aGUgc2FtZSBjb252ZW50aW9uIHVzZWQgaW4gUkZDDQo+IDcwODQgdGhhdA0K PiA+ICAgICB0aGlzIGRvY3VtZW50IHVwZGF0ZXMuIEl0IGlzIGFyZ3VhYmx5IGRlZmluZWQgYnkg cmVmZXJlbmNlLCBidXQNCj4gc3BlbGxpbmcgaXQgb3V0DQo+ID4gICAgIHdvdWxkIGJlIG5pY2Uu DQo+ID4NCj4gPiBXaWxsIGRvLg0KPiA+DQo+ID4NCj4gPiAgICAgVGhlIGNvbXBhcmlzb24gd2l0 aCBSRkM3MDg0IHNlY3Rpb24gaW5jbHVkZXMgYSBtYW5nbGVkIHNlbnRlbmNlOg0KPiA+DQo+ID4g ICAgICAgIFRoaXMgZG9jdW1lbnQgZG9lc24ndCBpbmNsdWRlIHN1cHBvcnQgZm9yIDZyZCAoW1JG QzU5NjldKSwgYmVjYXVzZQ0KPiBhcw0KPiA+ICAgICAgICBpbiBhbiBJUHY2LWluLUlQdjQgdHVu bmVsaW5nLg0KPiA+DQo+ID4gVHlwbywgc29ycnkgdGhlIGNvcnJlY3Qgc2VudGVuY2Ugd2FzOg0K PiA+ICAgICAgICBUaGlzIGRvY3VtZW50IGRvZXNuJ3QgaW5jbHVkZSBzdXBwb3J0IGZvciA2cmQg KFtSRkM1OTY5XSksIGJlY2F1c2UNCj4gaXMNCj4gPiAgICAgICAgYW4gSVB2Ni1pbi1JUHY0IHR1 bm5lbGluZy4NCj4gDQo+ICAgICAgICBUaGlzIGRvY3VtZW50IGRvZXNuJ3QgaW5jbHVkZSBzdXBw b3J0IGZvciA2cmQgKFtSRkM1OTY5XSksIGJlY2F1c2UgaXQNCj4gaXMNCj4gICAgICAgIGFuIElQ djYtaW4tSVB2NCB0dW5uZWxpbmcuDQo+IA0KPiA+DQo+ID4gICAgIFBsZWFzZSByZXBocmFzZS4g UGxlYXNlIGFsc28gcmVwaHJhc2UgdGhlIG5leHQgc2VudGVuY2UsIGZvciBzaW1pbGFyDQo+IHJl YXNvbnM6DQo+ID4NCj4gPiAgICAgICAgUmVnYXJkaW5nIERTLUxJVEUgW1JGQzYzMzNdLCB0aGlz IGRvY3VtZW50IGluY2x1ZGVzIHNsaWdodGx5DQo+ID4gICAgICAgIGRpZmZlcmVudCByZXF1aXJl bWVudHMsIGJlY2F1c2UgdGhlIFBDUCAoW1JGQzY4ODddKSBzdXBwb3J0IGFuZCB0aGUNCj4gPiAg ICAgICAgcHJpb3JpdGl6YXRpb24gb2YgdGhlIHRyYW5zaXRpb24gbWVjaGFuaXNtcywgaW5jbHVk aW5nIGR1YWwtc3RhY2suDQo+ID4NCj4gPiBJIHRoaW5rIGl0IGlzIG11Y2ggY2xlYXIgdGhpcyB3 YXk6DQo+ID4NCj4gPiAgICAgICAgUmVnYXJkaW5nIERTLUxJVEUgW1JGQzYzMzNdLCB0aGlzIGRv Y3VtZW50IGluY2x1ZGVzIHNsaWdodGx5DQo+ID4gICAgICAgIGRpZmZlcmVudCByZXF1aXJlbWVu dHMsIHJlbGF0ZWQgdG8gdGhlIHN1cHBvcnQgb2YgUENQIChbUkZDNjg4N10pLA0KPiA+ICAgICAg ICBJR0QtUENQIElXRiBbUkZDNjk3MF0gYW5kIHRoZSBwcmlvcml0aXphdGlvbiBvZiB0aGUgdHJh bnNpdGlvbg0KPiA+ICAgICAgICBtZWNoYW5pc21zLCBpbmNsdWRpbmcgZHVhbC1zdGFjay4NCj4g DQo+IE9LLg0KPiANCj4gDQo+ID4NCj4gPg0KPiA+ICAgICBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ICAgICB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4g PiAgICAgdjZvcHNAaWV0Zi5vcmcNCj4gPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby92Nm9wcw0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiA+IElQdjQgaXMgb3Zlcg0KPiA+IEFy ZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KPiA+IGh0dHA6Ly93d3cudGhlaXB2 NmNvbXBhbnkuY29tDQo+ID4gVGhlIElQdjYgQ29tcGFueQ0KPiA+DQo+ID4gVGhpcyBlbGVjdHJv bmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQg b3INCj4gY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9y IHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZQ0KPiBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFu ZCBmdXJ0aGVyIG5vbi1leHBsaWNpbHR5IGF1dGhvcml6ZWQgZGlzY2xvc3VyZSwNCj4gY29weWlu ZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlv biwgZXZlbiBpZg0KPiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZCBhbmQgd2lsbCBiZQ0KPiBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2Zm ZW5zZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZQ0KPiB0 aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBj b250ZW50cyBvZiB0aGlzDQo+IGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVk aW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseQ0KPiBwcm9oaWJpdGVkLCB3aWxsIGJlIGNv bnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUNCj4g b3JpZ2luYWwgc2VuZGVyIHRvIGluZm9ybSBhYm91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRl bGV0ZSBpdC4NCj4gPg0KPiA+DQo+ID4NCg0K From nobody Fri Dec 14 11:01:38 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB351131267 for ; Fri, 14 Dec 2018 11:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oovcNlPwEoe for ; Fri, 14 Dec 2018 11:01:33 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 39C04131269 for ; Fri, 14 Dec 2018 11:01:32 -0800 (PST) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx120.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1gXsi8-000ajk-9O for v6ops@ietf.org; Fri, 14 Dec 2018 20:01:28 +0100 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1gXsi2-0002oV-UJ for v6ops@ietf.org; Fri, 14 Dec 2018 14:01:19 -0500 Received: (qmail 22276 invoked from network); 14 Dec 2018 19:01:09 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.39]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 14 Dec 2018 19:01:09 -0000 To: mohamed.boucadair@orange.com, JORDI PALET MARTINEZ , "secdir@ietf.org" Cc: "v6ops@ietf.org" , "ietf@ietf.org" , "draft-ietf-v6ops-transition-ipv4aas.all@ietf.org" References: <154473417654.32125.9104927217788947044@ietfa.amsl.com> <5BF30E2E-4B57-415E-8D8D-6C6815B604FF@consulintel.es> <2a90813d-bae7-1bd0-90fa-9fd1a8621b78@huitema.net> <787AE7BB302AE849A7480A190F8B93302E059014@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: Christian Huitema Openpgp: preference=signencrypt Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Fri, 14 Dec 2018 11:01:06 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302E059014@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 168.144.250.215 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.11) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5vwon9KZlglxxIbQMkBX98l602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOxqmjSBeYFUbx3tX4ouiS+JVjyn5UrUp4n4yKOOaq9AxsIXWGJGxrQaNpr5azoXgOlDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5/z+vAHDOlLgrSj+stMQp+KXe0Of4jddu9xC8 8+iQ5nb6BRFVjXUbiREH8mlR1JtPfYZ1V10x8j0kNETJD+nyXtcV2Hz37FuQUlYMDMlHwjIJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+1QmdZsu6 kxo/qWEj6Z1d7VIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdseytLy0an6SuH9Dnc48fGLITxB/2kIQu8EKhrGnpyzWchQsQ29n43ZkI Obvbc1dlV6dqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1RWkNIWnHjoiI9QIik6sV5hq 8RGminksXtFq8ejOBuf1PiUt8a2Lj9MmCjDfgJI6+a9HWwMUNATk5aqJgNL5XJKDg5/bq7ChmPMN Ycw1QSmR0QkKT1cv90ugAOndANB3Rusmzt2frfP9KghCuwVRJn9m4zuNRcgRKiGg7nXFaZTxCXRq rnqpvNj9xYi9OgZhihfVX7Nwkf86OVuF6l8Zp2++NTKQHNkjJg8xvPcdYB8Xv0lqRWmYZel4DctY KBjcJP27lItOpPwlvQ6ktwDuRituj6ZEfB9v4x8THVh0rVtlyOZYRaCjaXhrY3nerbmurCmoQsay Zkd2YakTHWoyevr4xM5tUrEfL92iWzfzWX2vc1ctxv2vDEIpeWV/lG6Wmg== X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [v6ops] Secdir last call review of draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 19:01:37 -0000 Pointing to the RFC8415 security section would definitely help. What is specific about your draft is that attackers can leverage the DHCPv6 issue and mislead nodes into choosing transition schemes in the wrong order. This is an additional exploitation mechanism on top of=C2=A0 the existing issues mentioned in the DHCPv6 RFC. I would also mention that these security issues are hard to mitigate and that secure environments might require other configuration methods. This also begs the larger question about why we have so many transition mechanisms in the first place, and why the local nodes even need to be aware about them. It seems that this could be radically simplified, by having the router either advertise IPv4 connectivity using traditional IPv4 means, or advertise a NAT64 prefix if it expects local nodes to perform their own mapping. On 12/13/2018 11:44 PM, mohamed.boucadair@orange.com wrote: > Christian, > > As mentioned by Jordi, RFC8026 already describes the attack vector you = mentioned.=20 > > Wouldn't pointing to https://tools.ietf.org/html/rfc8415#section-22 be = sufficient here?=20 > > Cheers, > Med > >> -----Message d'origine----- >> De=C2=A0: ietf [mailto:ietf-bounces@ietf.org] De la part de Christian = Huitema >> Envoy=C3=A9=C2=A0: vendredi 14 d=C3=A9cembre 2018 08:26 >> =C3=80=C2=A0: JORDI PALET MARTINEZ; secdir@ietf.org >> Cc=C2=A0: v6ops@ietf.org; ietf@ietf.org; draft-ietf-v6ops-transition- >> ipv4aas.all@ietf.org >> Objet=C2=A0: Re: [v6ops] Secdir last call review of draft-ietf-v6ops-t= ransition- >> ipv4aas-11 >> >> >> On 12/13/2018 2:09 PM, JORDI PALET MARTINEZ wrote: >>> Hi Christian, >>> >>> Thanks a lot for your review. >>> >>> Please see below in-line. >>> >>> I'm working in a new version according to the comments got from the o= ps >> review as well, so will be able to integrate yours very quickly. >>> Regards, >>> Jordi >>> >>> >>> >>> =EF=BB=BF-----Mensaje original----- >>> De: v6ops en nombre de Christian Huitema >> >>> Fecha: jueves, 13 de diciembre de 2018, 21:50 >>> Para: >>> CC: , , > ipv4aas.all@ietf.org> >>> Asunto: [v6ops] Secdir last call review of draft-ietf-v6ops-transitio= n- >> ipv4aas-11 >>> Reviewer: Christian Huitema >>> Review result: Has Issues >>> >>> I have reviewed draft-ietf-v6ops-transition-ipv4aas-11 as part of= the >>> security directorate's ongoing effort to review all IETF document= s >>> being processed by the IESG. These comments were written primari= ly for >>> the benefit of the security area directors. Document editors and= WG >> chairs >>> should treat these comments just like any other last call comment= s. >>> >>> The summary of the review is "ready with issue". >>> >>> The document describes solution for providing "IPv4 as a service"= , i.e. >>> provision of IPv4 as a service over an IPv6 only network. >>> It calls this support "transition as a service". >>> >>> For various reasons, IETF working groups have standardized not ju= st one >> but >>> five different mechanisms for providing this transition: 464XLAT >> [RFC6877], >>> Dual-Stack Lite [RFC6333], Lightweight 4over6 (lw4o6) [RFC7596], >>> MAP-E [RFC7597], and MAP-T [RFC7599]. (I am sure that Monty Pytho= n >> could have >>> produced a nice sketch about that.) The purpose of the draft is t= o >>> state how home routers (a.k.a. customer premise equipment, CPE) s= hould >>> inform local devices about which of the mechanisms are available,= which >>> should be preferred, and what parameters should be used when depl= oying >>> the chosen services. This is done using the DHCPv6 "S46" option >>> specified in RFC 8026. >>> >>> The draft also makes specific recommendation regarding the use of= the >> UPnP and >>> PCP services, by requiring specific error codes when a requested = port >> mapping >>> is not available through the specified transition technology. >>> >>> The security section briefly points to the "Basic Requirements fo= r IPv6 >>> Customer Edge Routers" specified in RFC 7084, and to the security= >>> section of each of the RFC describing the security technologies, = and >> implicitly >>> argues that there are no other security issues. I think that is >> insufficient. >>> The draft introduces a reliance on the DHCPv6 "S46" option for >> assessing the >>> relative priority of different transition technologies. An attack= er >> could spoof >>> the DHCPv6 response, and direct client traffic to a different >> technology than >>> selected by the service provider. This could be used, for example= , to >> capture >>> IPv4 traffic in an IPv6 network and send it to a route chosen by = the >> attacker. >>> The attack might also be used in a dual stack network that does n= ot >> support >>> any transition technology. I don't understand how this attack is >> mitigated. >>> Not sure if you will suggest here that we should say something about = the >> security considerations already mention in RFC8026. In general all tho= se are >> generic DHCPv6 security considerations I think. >> >> Basically, the devices should be programmed to ignore DHCPv6 if they >> have another more secure way of getting their configuration data. Plus= , >> apply general defense against DHCPv6 hacks in the network, etc. I >> understand that your draft is meant to inform the building of CPEs, bu= t >> its effect is generalization of an unsafe mechanism. >> >> >>> Nits: >>> >>> The introduction uses the acronym WAN without spelling out "Wide = Area >> Network". >>> Also, WAN is used as substitute for local Internet Service Provid= er >> network. We could >>> debate whether such networks are always "wide area", by oppositio= n to >> say >>> "metropolitan" or "regional". This is the same convention used in= RFC >> 7084 that >>> this document updates. It is arguably defined by reference, but >> spelling it out >>> would be nice. >>> >>> Will do. >>> >>> >>> The comparison with RFC7084 section includes a mangled sentence: >>> >>> This document doesn't include support for 6rd ([RFC5969]), bec= ause >> as >>> in an IPv6-in-IPv4 tunneling. >>> >>> Typo, sorry the correct sentence was: >>> This document doesn't include support for 6rd ([RFC5969]), bec= ause >> is >>> an IPv6-in-IPv4 tunneling. >> This document doesn't include support for 6rd ([RFC5969]), beca= use it >> is >> an IPv6-in-IPv4 tunneling. >> >>> Please rephrase. Please also rephrase the next sentence, for simi= lar >> reasons: >>> Regarding DS-LITE [RFC6333], this document includes slightly >>> different requirements, because the PCP ([RFC6887]) support an= d the >>> prioritization of the transition mechanisms, including dual-st= ack. >>> >>> I think it is much clear this way: >>> >>> Regarding DS-LITE [RFC6333], this document includes slightly >>> different requirements, related to the support of PCP ([RFC688= 7]), >>> IGD-PCP IWF [RFC6970] and the prioritization of the transition= >>> mechanisms, including dual-stack. >> OK. >> >> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >>> >>> >>> >>> ********************************************** >>> IPv4 is over >>> Are you ready for the new Internet ? >>> http://www.theipv6company.com >>> The IPv6 Company >>> >>> This electronic message contains information which may be privileged = or >> confidential. The information is intended to be for the exclusive use = of the >> individual(s) named above and further non-explicilty authorized disclo= sure, >> copying, distribution or use of the contents of this information, even= if >> partially, including attached files, is strictly prohibited and will b= e >> considered a criminal offense. If you are not the intended recipient b= e aware >> that any disclosure, copying, distribution or use of the contents of t= his >> information, even if partially, including attached files, is strictly >> prohibited, will be considered a criminal offense, so you must reply t= o the >> original sender to inform about this communication and delete it. >>> >>> From nobody Sat Dec 15 07:15:00 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17B4126DBF for ; Sat, 15 Dec 2018 07:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.761 X-Spam-Level: X-Spam-Status: No, score=-5.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=I3IwWD95; dkim=pass (1024-bit key) header.d=ericsson.com header.b=kTA7rBiN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUJpCvuZctzP for ; Sat, 15 Dec 2018 07:14:51 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEA64124C04 for ; Sat, 15 Dec 2018 07:14:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1544886884; x=1547478884; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=u9YlRkrpqdo8t2rvg25yWIYqGbLvLm84EImdx/gH9X8=; b=I3IwWD95u7CnmmXQeuvUVsESpsg1fFXgHF79e/kyP1cLVuZVg4kRyqJWfL3DUGN5 a6tr4+VnK1rshgYZZGeDiVv6TWoWV6Q/kWa7TADiEdYBC//A1HSK2iMn6hjPzBmh goyijEUW9TCxqCw2mWaqcGCRFEFz/r/ycbcYIdqP7bE=; X-AuditID: c1b4fb3a-14fff7000000672c-a3-5c151a6484aa Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 4B.95.26412.46A151C5; Sat, 15 Dec 2018 16:14:44 +0100 (CET) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 15 Dec 2018 16:14:44 +0100 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sat, 15 Dec 2018 16:14:44 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u9YlRkrpqdo8t2rvg25yWIYqGbLvLm84EImdx/gH9X8=; b=kTA7rBiNWGqtSvTI96CCZ8Ot3H+89Ij+pP4aDBdIIUgCYyu/f1aT44ycu8SSr2RMvbIWZdkUWh9SK+jxLO3BVhlX2HIVHYgNYT2TN8ysHYRxW4ZXvmoskGiVZuzD5ETj7qqooW1TqLMZc6nIEgpreQ0buTwFkYluMpFpv8DDJ1E= Received: from HE1PR07MB4329.eurprd07.prod.outlook.com (20.176.167.14) by HE1PR07MB4331.eurprd07.prod.outlook.com (20.176.167.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.13; Sat, 15 Dec 2018 15:14:42 +0000 Received: from HE1PR07MB4329.eurprd07.prod.outlook.com ([fe80::fd45:e780:d637:a7ea]) by HE1PR07MB4329.eurprd07.prod.outlook.com ([fe80::fd45:e780:d637:a7ea%4]) with mapi id 15.20.1446.013; Sat, 15 Dec 2018 15:14:42 +0000 From: Daniele Ceccarelli To: " (rtg-ads@ietf.org)" CC: "rtg-dir@ietf.org" , "draft-ietf-v6ops-transition-ipv4aas.all@ietf.org" , "v6ops@ietf.org" Thread-Topic: RtgDir review: draft-ietf-v6ops-transition-ipv4aas-11 Thread-Index: AdSTk9+MZL7Z8wouS4SnYSnRffuIHQ== Date: Sat, 15 Dec 2018 15:14:42 +0000 Message-ID: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [93.38.67.165] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB4331; 6:ZaXusxZxvD2tjcS4GDudiCD+RECFZmBtmmHx7cLm/UO6cD3+TU51fzmox+PVUOeisKzfGVchO7HbpMXDasbUT/l/93dg8B1HiQvN4TZ+GYFADhM84qjhB9qepz89ZuXPAm1gC//8TJaPH2Vll+onX3N7Z3SLflj01EcD/D3hU995qXN1qR7CA0QCe6aip7ncD0DuAhGil6HVuq/zmFF2ltu/mgRKHC9rx27hIMEmNP/o/49E7pJ8mML9wfGO2fwEQqBn+PFJ/QweMDY0We4yrnIIRlHcqihQTAwqP+FqiV5o1M0IvxavrJnaTUhXrj/E0CO8MZd17KNzYcVqbz25sPAQ3BaPyquloIivANIc8G2HDrjJRSC3kR4S8Qvsf5chhn7AcP0N+BWcIzE+iP7GM0G16qqdfQ3ZNt4EIzhiQV9ptG/Gdd+YNMJ+dHKuLoPEmEOUqQfmVL4clUGzucNgvg==; 5:SWJiLwbDOS4SGClm4fsfbQIeBj+0neu/2wCeU+yEdc9aVYRx+SMX4iCjrQ05s1Lr0eydUdXxoQCShr1z/gsKW0Ja9wcwDM2BwtYDHgXNt/Z3lIZpt7PhDopB0bkJjlkKnRM78Svr3mE4sPzASELPukaqMnmiFYzn2lbiZtSDGwc=; 7:BF1RdIrS3d1fmgyAoT0Uk+5k170+UQ334UITpvufjvWsLt/S8rLFt+mPJgv3NTRUs8zAcE9wsExGhXjwMvffVjw74Xs94YjsBE57BMqwM5uYuppfntkMmzlJBC34gzq4ofdPzkJWxmp1Aovu4qK3sg== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e7a7759c-9103-4a27-8e0e-08d662a00a64 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4331; x-ms-traffictypediagnostic: HE1PR07MB4331: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231475)(944501520)(52105112)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB4331; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB4331; x-forefront-prvs: 088751B4D4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(136003)(346002)(366004)(39860400002)(189003)(199004)(186003)(33656002)(606006)(68736007)(7736002)(5660300001)(4326008)(450100002)(55016002)(25786009)(54896002)(6306002)(53936002)(236005)(9686003)(66066001)(74316002)(3846002)(81156014)(81166006)(2906002)(790700001)(486006)(476003)(44832011)(14444005)(256004)(8676002)(86362001)(66574012)(8936002)(6116002)(105586002)(71200400001)(71190400001)(106356001)(6436002)(478600001)(97736004)(102836004)(99286004)(4001150100001)(6506007)(14454004)(316002)(26005)(54906003)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4331; H:HE1PR07MB4329.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: UWCS3Fb+rlWoksjHTINUCGQL2kmV3HtcxOfDaF9yNzyPG905El9ka/7dMQoMZZDzo21Q4tdzxiNCH3hauxpxPjgYzquEv9EJ8bbQjWm/c7C3FYO/ckRHoO8MLxQa2MbNtKgCQZTZsZLfecYJq8ERI6u0bBI7I0e7nOdkOvpiVHfFSZzILN/in4yspbrfBqfcgdGIn1vMby0Yl2vMrQxRwn+8nrKjq77B7c+VJPfbL4jY4XD1noHPepdj4AWPpV6SbQL873duUCZwoKbt6uh+Kuyj21CDlgIibGKpmXO2lP2oXUKrQ5anTROxhsNRN5KS spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR07MB4329DDC51DFEDECDF0F99FA8F0A20HE1PR07MB4329eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e7a7759c-9103-4a27-8e0e-08d662a00a64 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2018 15:14:42.7675 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4331 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+3bOtuNo9rk0X03NnQzKmObwjyEhRXSDAvsjrBit1Q5qXtsx L0Em1KC8lGRLNEOJ0WUpXpjpslJPqZiY9xKFQF0sU9B0lOItt7PA/37v+zzP+/HARxGyGqE/ lZCSzuhTtEm0SEKWnmvMVOj8fdQH6oaVqrXc50jVVb5IqCqrfohV3R3viUPkCZNpSRCDLkgO 6pikhAxGHx59SRK/2thCpL0pEGR9ftGAclGtQZCHPCjAkZD3vUSchySUDH9CMFjQR/DDHwQl pQ8F/GASwGzHX5dC4iICVo0m5MzLcLEA1qtCeNcEArNxgMxDFCXCUWDjTjnRG0dDWb/CaSGw FcEyN+F6e/vG3vyh3nXHGx8B+51qEc9hUGuwEk4m8R64Z5kSOlmK1dDzssTlRzgQipqfuZjA vjBqq3D3wWB610vw7ANTk2tC3n8ZagxNbk8wNAx0kjwHwkBFPuL5qwhmbgPPCpgzGt13TsO3 8XlXecB9CAzt6yJeCIWFoRG3KREWftvdHATmwnGSD4wQYOZWxLwQAEPcY3d4WAgtXEQRUpRt KsFzKlhe9ZJlrtJe0FVq22BqY78Pat6G8xY5PMofF/O8FwzlT8Wb95VIbEY+LMOyyXFKZRij T7jCsqkpYSlMej3a+EZtluWoJtRmP8whTCF6q3SW8FHLhNoMNjuZQ0ARtLdUluatlkl12uwb jD5Vo7+exLAc2kmRtK90RealluE4bTqTyDBpjP6/KqA8/HNRFm29SeWcv6bJjBzdpfnSfKaA 0QnlZ+W9T2jP2PtL3IPo5IU5YRV2mAdtTBC9OP9Tc/HXxx112bFMRWjM1bFjVnqLorDYUtcz HXsc2pU5nfZqTX3jeoCjZfLojKM1MuTWybu7yzzVix6O4LF+yerr7m3ziSt+pfH7W6flfv00 ycZrI0IJPav9B+MRKm1CAwAA Archived-At: Subject: [v6ops] RtgDir review: draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2018 15:14:53 -0000 --_000_HE1PR07MB4329DDC51DFEDECDF0F99FA8F0A20HE1PR07MB4329eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXI8aHR0cDovL3RyYWMudG9vbHMu aWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rpcj4NCg0KQWx0aG91Z2ggdGhlc2UgY29t bWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdv dWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkg b3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2 ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBk cmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtdjZvcHMtdHJhbnNpdGlvbi1pcHY0YWFzLTEx LnR4dA0KUmV2aWV3ZXI6IERhbmllbGUgQ2VjY2FyZWxsaQ0KUmV2aWV3IERhdGU6IDIwMTgtMTIt MTQNCklFVEYgTEMgRW5kIERhdGU6IGRhdGUtaWYta25vdw0KSW50ZW5kZWQgU3RhdHVzOiBJbmZv cm1hdGlvbmFsDQoNClN1bW1hcnk6DQoNCiogICAgICAgSSBoYXZlIHNvbWUgbWlub3IgY29uY2Vy bnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJlIHJlc29sdmVkIGJl Zm9yZSBwdWJsaWNhdGlvbi4NCg0KQ29tbWVudHM6DQoNCiogICAgICAgSSBmaW5kIHRoaXMgZHJh ZnQgcXVpdGUgZGlmZmljdWx0IHRvIHJlYWQuIFByb2JhYmx5IGl04oCZcyBkdWUgdG8gbXkgbGFj ayBvZiBjb21wZXRlbmNlIGluIHRoZSB0b3BpYy4gSWYgdGhlIGFpbSBpcyB0byBtYWtlIGl0IHVz YWJsZSBieSBleHBlcnRzIGl0IGNvdWxkIGJlIG9rLiBUaGlzIGRvY3VtZW50IGlzIG5vdCBkZWZp bmluZyBwcm90b2NvbHMgZXh0ZW5zaW9ucyAoaGVuY2UgdGFyZ2V0aW5nIGV4cGVydHMpLCBidXQg cmVxdWlyZW1lbnRzIGFuZCBtZWNoYW5pc21zICBmb3IgSVB2NC1JUHY2IHRyYW5zaXRpb24gaGVu Y2UgaXQgc2hvdWxkIGJlIHN0YXJ0aW5nIHBvaW50IGZvciBhIG5ld2JpZSB0byBnZXQgdG8gdW5k ZXJzdGFuZCB0aGUgdG9waWMuIFNvbWUgZHJhd2luZ3MgdG8gaGVscCB1bmRlcnN0YW5kaW5nIHRo ZSBjb250ZXh0IGFuZCBhIG1vcmUgZGV0YWlsZWQgZXhwbGFuYXRpb24gaW4gdGhlIGludHJvIHdv dWxkIGJlIGhlbHBmdWwuIEUuZy4gdGhlIGNvbnRlbnQgb2YgQW5uZXggQiBjb3VsZCBiZSBhIGdv b2Qgc3RhcnRpbmcgcG9pbnQuDQoNCk1ham9yIElzc3VlczoNCg0KKiAgICAgICAxLjEuICBSZXF1 aXJlbWVudHMgTGFuZ3VhZ2UgLSBTcGVjaWFsIE5vdGUg4oCTIFZlcnkgcGFydGljdWxhciB1c2Fn ZSBvZiB0aGUgcmVxdWlyZW1lbnRzIGxhbmd1YWdlLiBJdCBzYXlzIOKAnFRoaXMgZG9jdW1lbnQg dXNlcyB0aGVzZSBrZXl3b3JkcyBub3Qgc3RyaWN0bHkgZm9yIHRoZSBwdXJwb3NlIG9mIGludGVy b3BlcmFiaWxpdHksIGJ1dCByYXRoZXIgZm9yIHRoZSBwdXJwb3NlIG9mIGVzdGFibGlzaGluZyBp bmR1c3RyeS1jb21tb24gYmFzZWxpbmUgZnVuY3Rpb25hbGl0eS7igJ0uIEkgZG9u4oCZdCBzZWUg YSBiaWcgZGlmZmVyZW5jZS4gSW4gYm90aCBjYXNlcyBpdCB0ZWxscyBob3cgdGhpbmdzIHNob3Vs ZCBiZSBkb25lLiBNb3Jlb3ZlciB0aGVyZSBhcmUgdmFyaW91cyBvY2N1cnJlbmNlcyBvZiBNVVNU L1NIT1VMRCB0aGF0IHJlYWxseSBzZWVtIHRvIGNvbmZvcm0gUkZDMjExOS4NCg0KTWlub3IgSXNz dWVzOg0KDQoqICAgICAgIEFic3RyYWN0OiDigJxUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUg SVB2NCBzZXJ2aWNlIGNvbnRpbnVpdHkgcmVxdWlyZW1lbnRzIGZvciBhbiBJUHY2IEN1c3RvbWVy IEVkZ2UgKENFKSByb3V0ZXIsIGVpdGhlciBwcm92aWRlZCBieSB0aGUgc2VydmljZSBwcm92aWRl ciBvciB0aHJvdWdoIHRoZSByZXRhaWwgbWFya2V0LuKAnSBEbyB5b3UgbWVhbiDigJxvciBieSBw cm9kdWNlcnMgb2YgZGV2aWNlcyBmb3IgdGhlIHJldGFpbCBtYXJrZXTigJ0gPw0KKiAgICAgICBB YnN0cmFjdDogIkJhc2ljIFJlcXVpcmVtZW50cyBmb3IgSVB2NiBDdXN0b21lciBFZGdlIFJvdXRl cnMiLiBTaW5jZSB0aGlzIGlzIGluIHF1b3RlcyBJIGd1ZXNzIGl0IHJlZmVyZW5jZXMgc29tZXRo aW5nIHdlbGwga25vd24uIEFkZGluZyB0aGUgcmVmZXJlbmNlIGNvdWxkIGJlIGhlbHBmdWwuIEZ1 cnRoZXIgcmVhZGluZyBJ4oCZdmUgZm91bmQgUkZDNzA4NCBhcyByZWZlcmVuY2UuIFlvdSBjYW4g YWRkIGl0Lg0KKiAgICAgICBUaGUgc2NvcGUgb2YgdGhlIGRyYWZ0IGlzIG5vdCBjbGVhciBmcm9t IHRoZSBzdGF0ZW1lbnQgaW4gdGhlIGludHJvOiDigJxzbyB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1 bWVudCBpcyB0byBlbnN1cmUgdGhlIElQdjQgInNlcnZpY2UgY29udGludWl0eSIgc3VwcG9ydCwg aW4gdGhlIExBTiBzaWRlIGFuZCB0aGUgYWNjZXNzIHRvIElQdjQtb25seSBJbnRlcm5ldCBzZXJ2 aWNlcyBmcm9tIGFuIElQdjYtb25seSBhY2Nlc3MgV0FOIGV2ZW4gZnJvbSBJUHY2LW9ubHkgYXBw bGljYXRpb25zIG9yIGRldmljZXMgaW4gdGhlIExBTiBzaWRlLuKAnSBUaGlzIHNob3VsZCBiZSBi ZXR0ZXIgZXhwbGFpbmVkLg0KDQpOaXRzOg0KDQoqICAgICAgIEludHJvOiBBIG51bWJlciBvZiBh Y3JvbnltcyBzaG91bGQgYmUgZXhwYW5kZWQgYXQgZmlyc3QgdXNlOiBlLmcuIExBTiwgV0FOLCBI TkNQLCBJU1AuDQoqICAgICAgIEludHJvOiA64oCcVGhpcyBpcyBhIGNvbW1vbiBzaXR1YXRpb24g aW4gd2hlbiBzdWZmaWNpZW504oCm4oCdIHJlbW92ZSDigJxpbuKAnS4NCiogICAgICAgQWN0dWFs bHkgdGhlcmUgaXMgcGxlbnR5IG9mIE5pdHMuIEkgc3VnZ2VzdCBhIHNwZWxsaW5nIHBhc3MuDQoN CkJSDQpEYW5pZWxlDQoNCg== --_000_HE1PR07MB4329DDC51DFEDECDF0F99FA8F0A20HE1PR07MB4329eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5pY29uDQoJe21zby1zdHls ZS1uYW1lOmljb247fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjQwNzE5MDk4NjsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MTA4MjE4OTI0MDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlk aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo2NjMxMjI4ODE7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjIyMDI1MDcxNDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo5NTIzMjQ2MjU7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjEzNTY4NzEwNTg7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4 MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTQ4MTU3Mzg3MzsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6NDE1NTMyMzU2O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci Ow0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwzOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0DQoJe21zby1saXN0LWlkOjE4MTU0ODg4ODY7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xODI3NDk3NjU0O30NCkBsaXN0IGw0OmxldmVsMQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3 Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0 IGw0OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGw0OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0 OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlNWIiBsaW5rPSIj MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPkhlbGxvLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsO29ycGhhbnM6IDI7dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IDI7LXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4O3RleHQtZGVjb3JhdGlvbi1zdHlsZTogaW5pdGlhbDt0ZXh0 LWRlY29yYXRpb24tY29sb3I6IGluaXRpYWw7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0 aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZpZXdlciBmb3IgdGhpcyBkcmFmdC4gVGhlIFJvdXRp bmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8gcmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVs YXRlZCBkcmFmdHMgYXMgdGhleSBwYXNzIHRocm91Z2gNCiBJRVRGIGxhc3QgY2FsbCBhbmQgSUVT RyByZXZpZXcsIGFuZCBzb21ldGltZXMgb24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBv ZiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMu IEZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVh c2Ugc2VlJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PGEgaHJlZj0i aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpciI+PHNw YW4gY2xhc3M9Imljb24iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojQkIwMDAwO3RleHQtZGVjb3JhdGlvbjpu b25lIj7igIs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6I0JC MDAwMCI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0Rp cjwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlO2Zv bnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29y cGhhbnM6IDI7dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IDI7LXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4O3RleHQtZGVjb3JhdGlvbi1zdHlsZTogaW5pdGlhbDt0ZXh0LWRlY29yYXRpb24t Y29sb3I6IGluaXRpYWw7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5BbHRob3VnaCB0aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5 IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFEcywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5 b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2Fs bCBjb21tZW50cyB0aGF0IHlvdQ0KIHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVt IHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7Zm9udC12YXJpYW50LWxpZ2F0 dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogMjt0ZXh0LWFs aWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7dGV4dC1k ZWNvcmF0aW9uLXN0eWxlOiBpbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDt3 b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPkRvY3VtZW50OiBkcmFmdC1pZXRmLXY2b3BzLXRyYW5zaXRpb24taXB2NGFhcy0xMS50eHQm bmJzcDs8YnI+DQpSZXZpZXdlcjogRGFuaWVsZSBDZWNjYXJlbGxpPGJyPg0KUmV2aWV3IERhdGU6 IDIwMTgtMTItMTQ8YnI+DQpJRVRGIExDIEVuZCBEYXRlOiBkYXRlLWlmLWtub3c8YnI+DQpJbnRl bmRlZCBTdGF0dXM6IEluZm9ybWF0aW9uYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZTtmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7Zm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiAyO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiAy Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt0ZXh0LWRlY29yYXRpb24tc3R5bGU6IGlu aXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOiBpbml0aWFsO3dvcmQtc3BhY2luZzowcHgiPg0K PHN0cm9uZz48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5TdW1tYXJ5 Ojwvc3Bhbj48L3N0cm9uZz48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw0IGxldmVsMSBsZm8xO2JhY2tn cm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+SSBoYXZlIHNvbWUg bWlub3IgY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxkIGJl IHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+ DQo8cCBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPkNvbW1lbnRzOjwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzI7YmFja2dy b3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5JIGZpbmQgdGhpcyBk cmFmdCBxdWl0ZSBkaWZmaWN1bHQgdG8gcmVhZC4gUHJvYmFibHkgaXTigJlzIGR1ZSB0byBteSBs YWNrIG9mIGNvbXBldGVuY2UgaW4gdGhlIHRvcGljLiBJZiB0aGUgYWltIGlzIHRvIG1ha2UgaXQg dXNhYmxlIGJ5IGV4cGVydHMgaXQgY291bGQgYmUgb2suIFRoaXMgZG9jdW1lbnQgaXMgbm90DQog ZGVmaW5pbmcgcHJvdG9jb2xzIGV4dGVuc2lvbnMgKGhlbmNlIHRhcmdldGluZyBleHBlcnRzKSwg YnV0IHJlcXVpcmVtZW50cyBhbmQgbWVjaGFuaXNtcyZuYnNwOyBmb3IgSVB2NC1JUHY2IHRyYW5z aXRpb24gaGVuY2UgaXQgc2hvdWxkIGJlIHN0YXJ0aW5nIHBvaW50IGZvciBhIG5ld2JpZSB0byBn ZXQgdG8gdW5kZXJzdGFuZCB0aGUgdG9waWMuIFNvbWUgZHJhd2luZ3MgdG8gaGVscCB1bmRlcnN0 YW5kaW5nIHRoZSBjb250ZXh0IGFuZCBhIG1vcmUgZGV0YWlsZWQNCiBleHBsYW5hdGlvbiBpbiB0 aGUgaW50cm8gd291bGQgYmUgaGVscGZ1bC4gRS5nLiB0aGUgY29udGVudCBvZiBBbm5leCBCIGNv dWxkIGJlIGEgZ29vZCBzdGFydGluZyBwb2ludC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+ DQo8cCBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZTtmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3Jt YWw7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiAyO3RleHQtYWxpZ246c3RhcnQ7 d2lkb3dzOiAyOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt0ZXh0LWRlY29yYXRpb24t c3R5bGU6IGluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOiBpbml0aWFsO3dvcmQtc3BhY2lu ZzowcHgiPg0KPHN0cm9uZz48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5NYWpvciBJc3N1ZXM6PC9zcGFuPjwvc3Ryb25nPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxm bzM7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj4xLjEu Jm5ic3A7IFJlcXVpcmVtZW50cyBMYW5ndWFnZSAtIFNwZWNpYWwgTm90ZSDigJMgVmVyeSBwYXJ0 aWN1bGFyIHVzYWdlIG9mIHRoZSByZXF1aXJlbWVudHMgbGFuZ3VhZ2UuIEl0IHNheXMg4oCcVGhp cyBkb2N1bWVudCB1c2VzIHRoZXNlIGtleXdvcmRzIG5vdCBzdHJpY3RseSBmb3IgdGhlIHB1cnBv c2Ugb2YgaW50ZXJvcGVyYWJpbGl0eSwNCiBidXQgcmF0aGVyIGZvciB0aGUgcHVycG9zZSBvZiBl c3RhYmxpc2hpbmcgaW5kdXN0cnktY29tbW9uIGJhc2VsaW5lIGZ1bmN0aW9uYWxpdHku4oCdLiBJ IGRvbuKAmXQgc2VlIGEgYmlnIGRpZmZlcmVuY2UuIEluIGJvdGggY2FzZXMgaXQgdGVsbHMgaG93 IHRoaW5ncyBzaG91bGQgYmUgZG9uZS4gTW9yZW92ZXIgdGhlcmUgYXJlIHZhcmlvdXMgb2NjdXJy ZW5jZXMgb2YgTVVTVC9TSE9VTEQgdGhhdCByZWFsbHkgc2VlbSB0byBjb25mb3JtIFJGQzIxMTku PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7 Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 b3JwaGFuczogMjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOiBpbml0aWFsO3RleHQtZGVjb3JhdGlv bi1jb2xvcjogaW5pdGlhbDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzdHJvbmc+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+TWlub3IgSXNzdWVzOjwvc3Bhbj48L3N0cm9u Zz48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm80O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Zl cmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+QWJzdHJhY3Q6IOKAnFRoaXMgZG9jdW1lbnQgc3BlY2lm aWVzIHRoZSBJUHY0IHNlcnZpY2UgY29udGludWl0eSByZXF1aXJlbWVudHMgZm9yIGFuIElQdjYg Q3VzdG9tZXIgRWRnZSAoQ0UpIHJvdXRlciwgZWl0aGVyIHByb3ZpZGVkIGJ5IHRoZSBzZXJ2aWNl IHByb3ZpZGVyIG9yIHRocm91Z2ggdGhlIHJldGFpbCBtYXJrZXQu4oCdDQogRG8geW91IG1lYW4g 4oCcb3IgYnkgcHJvZHVjZXJzIG9mIGRldmljZXMgZm9yIHRoZSByZXRhaWwgbWFya2V04oCdID88 bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6 YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzQ7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OyxzYW5zLXNlcmlmIj5BYnN0cmFjdDogJnF1b3Q7QmFzaWMgUmVxdWlyZW1lbnRzIGZvciBJ UHY2IEN1c3RvbWVyIEVkZ2UgUm91dGVycyZxdW90Oy4gU2luY2UgdGhpcyBpcyBpbiBxdW90ZXMg SSBndWVzcyBpdCByZWZlcmVuY2VzIHNvbWV0aGluZyB3ZWxsIGtub3duLiBBZGRpbmcgdGhlIHJl ZmVyZW5jZSBjb3VsZCBiZSBoZWxwZnVsLiBGdXJ0aGVyIHJlYWRpbmcNCiBJ4oCZdmUgZm91bmQg UkZDNzA4NCBhcyByZWZlcmVuY2UuIFlvdSBjYW4gYWRkIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwv bGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEg bGZvNDtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPlRo ZSBzY29wZSBvZiB0aGUgZHJhZnQgaXMgbm90IGNsZWFyIGZyb20gdGhlIHN0YXRlbWVudCBpbiB0 aGUgaW50cm86IOKAnHNvIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50IGlzIHRvIGVuc3VyZSB0 aGUgSVB2NCAmcXVvdDtzZXJ2aWNlIGNvbnRpbnVpdHkmcXVvdDsgc3VwcG9ydCwgaW4gdGhlIExB TiBzaWRlIGFuZCB0aGUgYWNjZXNzDQogdG8gSVB2NC1vbmx5IEludGVybmV0IHNlcnZpY2VzIGZy b20gYW4gSVB2Ni1vbmx5IGFjY2VzcyBXQU4gZXZlbiBmcm9tIElQdjYtb25seSBhcHBsaWNhdGlv bnMgb3IgZGV2aWNlcyBpbiB0aGUgTEFOIHNpZGUu4oCdIFRoaXMgc2hvdWxkIGJlIGJldHRlciBl eHBsYWluZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPk5pdHM6PC9z cGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJj b2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvNTtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkludHJvOiBBIG51bWJlciBvZiBhY3JvbnltcyBzaG91bGQg YmUgZXhwYW5kZWQgYXQgZmlyc3QgdXNlOiBlLmcuIExBTiwgV0FOLCBITkNQLCBJU1AuPG86cD48 L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNr O21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwzIGxldmVsMSBsZm81O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZiI+SW50cm86IDrigJxUaGlzIGlzIGEgY29tbW9uIHNpdHVhdGlvbiBpbiB3aGVu IHN1ZmZpY2llbnTigKbigJ0gcmVtb3ZlIOKAnGlu4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+ PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZv NTtiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkFjdHVh bGx5IHRoZXJlIGlzIHBsZW50eSBvZiBOaXRzLiBJIHN1Z2dlc3QgYSBzcGVsbGluZyBwYXNzLg0K PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkJSPGJyPg0KRGFuaWVsZSZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_HE1PR07MB4329DDC51DFEDECDF0F99FA8F0A20HE1PR07MB4329eurp_-- From nobody Sat Dec 15 09:42:26 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1DB130DE8; Sat, 15 Dec 2018 09:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGQ76mGOs2lF; Sat, 15 Dec 2018 09:42:12 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBEA126F72; Sat, 15 Dec 2018 09:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1544895728; x=1545500528; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:Mime-version: Content-type; bh=nLTUcVwVK+gveas4DOiqdiEMBFxpxQAqhCDrV7lw16c=; b=tweSlxL7RUFKb30MK2MX2Bh7xr3M/PdBzlfGmgoA4fRgJLhRGFA2Z4KvSdfP4/ QqkQ7P/q/D7H2zEBABgCDS7FWEMpWDCcNb/UqmEZU+56BnzUih5JEu9tVdHmvbqI BnVw+NEkH9mOm9UeuBRm44HaAYUyOkXI7gondJi81Yjbg= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sat, 15 Dec 2018 18:42:08 +0100 X-Spam-Processed: mail.consulintel.es, Sat, 15 Dec 2018 18:42:07 +0100 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006069586.msg; Sat, 15 Dec 2018 18:42:05 +0100 X-MDRemoteIP: 2001:470:1f09:495:394d:fa8c:bf74:3ad0 X-MDHelo: [10.10.10.130] X-MDArrival-Date: Sat, 15 Dec 2018 18:42:05 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=188724d074=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Sat, 15 Dec 2018 18:42:04 +0100 From: JORDI PALET MARTINEZ To: Daniele Ceccarelli , " (rtg-ads@ietf.org)" CC: "rtg-dir@ietf.org" , "v6ops@ietf.org" , "draft-ietf-v6ops-transition-ipv4aas.all@ietf.org" Message-ID: <15C31662-D05C-4C5E-A1C3-528D1B96C9E0@consulintel.es> Thread-Topic: [v6ops] RtgDir review: draft-ietf-v6ops-transition-ipv4aas-11 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3627744124_83327266" Archived-At: Subject: Re: [v6ops] RtgDir review: draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2018 17:42:16 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3627744124_83327266 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable =EF=BB=BFHi Daniele, =20 Thanks a lot for your review. =20 Please, see my responses below, in-line. Regards, Jordi =20 =20 =20 De: v6ops en nombre de Daniele Ceccarelli Fecha: s=C3=A1bado, 15 de diciembre de 2018, 16:15 Para: " (rtg-ads@ietf.org)" CC: "rtg-dir@ietf.org" , "v6ops@ietf.org" , "draft-ietf-v6ops-transition-ipv4aas.all@ietf.org" Asunto: [v6ops] RtgDir review: draft-ietf-v6ops-transition-ipv4aas-11 =20 Hello, I have been selected as the Routing Directorate reviewer for this draft. Th= e Routing Directorate seeks to review all routing or routing-related drafts= as they pass through IETF last call and IESG review, and sometimes on spec= ial request. The purpose of the review is to provide assistance to the Rout= ing ADs. For more information about the Routing Directorate, please see =E2= =80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it wo= uld be helpful if you could consider them along with any other IETF Last Ca= ll comments that you receive, and strive to resolve them through discussion= or by updating the draft. Document: draft-ietf-v6ops-transition-ipv4aas-11.txt=20 Reviewer: Daniele Ceccarelli Review Date: 2018-12-14 IETF LC End Date: date-if-know Intended Status: Informational Summary:=20 =C2=B7 I have some minor concerns about this document that I think = should be resolved before publication. Comments: =C2=B7 I find this draft quite difficult to read. Probably it=E2=80= =99s due to my lack of competence in the topic. If the aim is to make it us= able by experts it could be ok. This document is not defining protocols ext= ensions (hence targeting experts), but requirements and mechanisms for IPv= 4-IPv6 transition hence it should be starting point for a newbie to get to = understand the topic. Some drawings to help understanding the context and a= more detailed explanation in the intro would be helpful. E.g. the content = of Annex B could be a good starting point. I guess it can help to add a comment in the line that it is expected that t= he reader has also read RFC7084. Initially the annex B was right after the intro, but the WG decided to keep= it, but make it an annex. I will make a comment in the intro to reference = the annex. Major Issues: =C2=B7 1.1. Requirements Language - Special Note =E2=80=93 Very pa= rticular usage of the requirements language. It says =E2=80=9CThis document= uses these keywords not strictly for the purpose of interoperability, but = rather for the purpose of establishing industry-common baseline functionali= ty.=E2=80=9D. I don=E2=80=99t see a big difference. In both cases it tells = how things should be done. Moreover there are various occurrences of MUST/S= HOULD that really seem to conform RFC2119. This was made also following RFC7084. Minor Issues: =C2=B7 Abstract: =E2=80=9CThis document specifies the IPv4 service = continuity requirements for an IPv6 Customer Edge (CE) router, either provi= ded by the service provider or through the retail market.=E2=80=9D Do you m= ean =E2=80=9Cor by producers of devices for the retail market=E2=80=9D ? =C2=B7 Abstract: "Basic Requirements for IPv6 Customer Edge Routers= ". Since this is in quotes I guess it references something well known. Addi= ng the reference could be helpful. Further reading I=E2=80=99ve found RFC70= 84 as reference. You can add it. =C2=B7 The scope of the draft is not clear from the statement in th= e intro: =E2=80=9Cso the scope of this document is to ensure the IPv4 "serv= ice continuity" support, in the LAN side and the access to IPv4-only Intern= et services from an IPv6-only access WAN even from IPv6-only applications o= r devices in the LAN side.=E2=80=9D This should be better explained.=20 I will clarify all those aspects. Initially I=E2=80=99d a reference to the = RFC7084 in the abstract, but it seems is not accepted by the nits checker, = so I=E2=80=99ve removed it. If someone has any suggestion on that, I=E2=80= =99m happy to follow it =E2=80=A6 Nits: =C2=B7 Intro: A number of acronyms should be expanded at first use:= e.g. LAN, WAN, HNCP, ISP. =C2=B7 Intro: :=E2=80=9CThis is a common situation in when sufficie= nt=E2=80=A6=E2=80=9D remove =E2=80=9Cin=E2=80=9D. =C2=B7 Actually there is plenty of Nits. I suggest a spelling pass.= =20 I will follow all those points as well. BR Daniele =20 _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3627744124_83327266 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

=EF= =BB=BFHi Daniele,

 

T= hanks a lot for your review.

 

Please, see my responses below, in-line.


Regards,

Jordi

 

 

 

De: v6ops <v6ops-bounc= es@ietf.org> en nombre de Daniele Ceccarelli <daniele.ceccarelli@eric= sson.com>
Fecha: s=C3=A1bado, 15 de diciembre de 2018, 16:15Para: "<rtg-ads@ietf.org> (rtg-ads@ietf.org)" <= rtg-ads@ietf.org>
CC: "rtg-dir@ietf.org" <rtg-dir= @ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>, "dra= ft-ietf-v6ops-transition-ipv4aas.all@ietf.org" <draft-ietf-v6ops-tr= ansition-ipv4aas.all@ietf.org>
Asunto: [v6ops] RtgDir review: = draft-ietf-v6ops-transition-ipv4aas-11

 

Hello,=

I have b= een selected as the Routing Directorate reviewer for this draft. The Routin= g Directorate seeks to review all routing or routing-related drafts as they= pass through IETF last call and IESG review, and sometimes on special requ= est. The purpose of the review is to provide assistance to the Routing ADs.= For more information about the Routing Directorate, please see =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDi= r

Although these comments are primarily for the use of the Routing ADs,= it would be helpful if you could consider them along with any other IETF L= ast Call comments that you receive, and strive to resolve them through disc= ussion or by updating the draft.

Document: draft-ietf-v6ops-transition-ipv4aas-11.txt 
Reviewer: D= aniele Ceccarelli
Review Date: 2018-12-14
IETF LC End Date: date-if-k= now
Intended Status: Informational

Summary: 

=C2=B7  &n= bsp;      I have some minor concerns about this document that I think should b= e resolved before publication.

Com= ments:

=C2=B7 &n= bsp;       I find this draft quite difficult to read. Probably it=E2=80= =99s due to my lack of competence in the topic. If the aim is to make it us= able by experts it could be ok. This document is not defining protocols ext= ensions (hence targeting experts), but requirements and mechanisms  fo= r IPv4-IPv6 transition hence it should be starting point for a newbie to ge= t to understand the topic. Some drawings to help understanding the context = and a more detailed explanation in the intro would be helpful. E.g. the con= tent of Annex B could be a good starting point.

I gue= ss it can help to add a comment in the line that it is expected that the re= ader has also read RFC7084.

Initially the annex B was right= after the intro, but the WG decided to keep it, but make it an annex. I wi= ll make a comment in the intro to reference the annex.

Major Issues:<= /p>

=C2=B7         1.1.  Re= quirements Language - Special Note =E2=80=93 Very particular usage of the r= equirements language. It says =E2=80=9CThis document uses these keywords no= t strictly for the purpose of interoperability, but rather for the purpose = of establishing industry-common baseline functionality.=E2=80=9D. I don=E2= =80=99t see a big difference. In both cases it tells how things should be d= one. Moreover there are various occurrences of MUST/SHOULD that really seem= to conform RFC2119.

This was made also following RFC7084.

Minor Issues:=

=C2=B7  &n= bsp;      Abstract: =E2=80=9CThis document specifies the IPv4 service continui= ty requirements for an IPv6 Customer Edge (CE) router, either provided by t= he service provider or through the retail market.=E2=80=9D Do you mean =E2= =80=9Cor by producers of devices for the retail market=E2=80=9D ?

=C2=B7         <= ![endif]>Abstract: "Basic Requirements for IPv6 Custom= er Edge Routers". Since this is in quotes I guess it references someth= ing well known. Adding the reference could be helpful. Further reading I=E2= =80=99ve found RFC7084 as reference. You can add it.

=C2=B7  = ;       The scope of the draft is not clear from the statement in the int= ro: =E2=80=9Cso the scope of this document is to ensure the IPv4 "serv= ice continuity" support, in the LAN side and the access to IPv4-only I= nternet services from an IPv6-only access WAN even from IPv6-only applicati= ons or devices in the LAN side.=E2=80=9D This should be better explained. <= /span>

I will clarify all those aspects. Initially I=E2=80= =99d a reference to the RFC7084 in the abstract, but it seems is not accepted by the nits checker, so I=E2=80=99ve removed it.= If someone has any suggestion on that, I=E2=80=99m happy to follow it =E2= =80=A6

Nits:

=C2=B7         <= ![endif]>Intro: A number of acronyms should be expanded at = first use: e.g. LAN, WAN, HNCP, ISP.

=C2= =B7    &nb= sp;    Intro:= :=E2=80=9CThis is a common situation in when sufficient=E2=80=A6=E2=80=9D = remove =E2=80=9Cin=E2=80=9D.<= /span>

=C2=B7      = ;   Actually there= is plenty of Nits. I suggest a spelling pass.

I w= ill follow all those points as well.

BR
Daniele 

____________________________________= ___________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/= listinfo/v6ops


****************************= ******************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3627744124_83327266-- From nobody Sat Dec 15 11:00:19 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D6E130E41; Sat, 15 Dec 2018 11:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qG_Cyc53uK71; Sat, 15 Dec 2018 11:00:15 -0800 (PST) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 365DB130E01; Sat, 15 Dec 2018 11:00:15 -0800 (PST) Received: by mail-pl1-x630.google.com with SMTP id u6so4227161plm.8; Sat, 15 Dec 2018 11:00:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vJh9vhqVaBV1oTd0CXzokTfoeYTxPxEjhZ8zrzLL1wk=; b=LvPvrSpuFwNzVPYDuWlMHK/mXpAhH6TIEvMU5+fqM/3xwXmtLj+BbnD4nsZGMglyvQ YK/zrJ/DxAxJuvCA7weYTxUyNQKBy9xXrNYi0UeVhS5nBnl2Yc8ke2111QP/Mxa2ja2h ST9L7rjjuWW1lJlLJHJX8Ht8D3DncgsGsHFr6X4m+Zw14ksRVc/lLuFuWDE0V+5Xc+ZN pQm1b6tpmbQNmlYYrvcoazbOZejNAhqkiGp2TRShieJhPfLGEUVPpi2igdpzE8uI5cYv MlaHb7aCJrTa3ImBlqOyBDOrvutoxmI/4LJUTW8SnMdv0cJOCFPknnNav+CMT23pmFDu bNXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vJh9vhqVaBV1oTd0CXzokTfoeYTxPxEjhZ8zrzLL1wk=; b=I3HOpBVy8rab0zAfWSFSKzNqwsANIx6X2RPOwvh/3spldlnnKVTCa4bIwD/r4CLfH5 NCK2ckgjwRfnOQGKt/Pc84mh+rbrDb4QvD4nvC32wbFzWeqfa1ZK3h1QU0IzchZlGDWH dn4hga3hKsljvH4njxNrY8H5IvZa3Rz3/i4fzePXyeR1GQ50Sqpio8GTgcw9qKc9jft2 oipncdZTzD6Xk21WNzsVnz5F5R0AKf59Tw3igGcfdACCzi/fsV8BzuLrRo6OjQUHmfZR QIuhpO/udIEwuyNkTZZiDaXrGYKbzLDNtRWhqqvpnQP5+1aUvBiYDdamckehlbxBvgog Edqw== X-Gm-Message-State: AA+aEWZL3AjfEwuYMX24Xy34XxG8wzM6CAUarUWIGfbJGLwPsHByVPnu LSCJZ5+eV4hoAC2bDq8Nn1vMcpEPA7Q= X-Google-Smtp-Source: AFSGD/UP7VNIbiJkduW0d/k9EnqBnalXM6Do+560FmIuFCyZ+lEij6HMJhTv87qIyQxxYwWMVhhIPQ== X-Received: by 2002:a17:902:654a:: with SMTP id d10mr7117240pln.324.1544900413764; Sat, 15 Dec 2018 11:00:13 -0800 (PST) Received: from [10.100.9.248] ([58.84.227.247]) by smtp.gmail.com with ESMTPSA id 125sm10722195pfx.159.2018.12.15.11.00.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Dec 2018 11:00:12 -0800 (PST) To: JORDI PALET MARTINEZ , Daniele Ceccarelli , " (rtg-ads@ietf.org)" Cc: "rtg-dir@ietf.org" , "v6ops@ietf.org" , "draft-ietf-v6ops-transition-ipv4aas.all@ietf.org" References: <15C31662-D05C-4C5E-A1C3-528D1B96C9E0@consulintel.es> From: Brian E Carpenter Message-ID: <9d6fda6b-cec0-3598-2ced-08081eb9ee8a@gmail.com> Date: Sun, 16 Dec 2018 08:00:04 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <15C31662-D05C-4C5E-A1C3-528D1B96C9E0@consulintel.es> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] RtgDir review: draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2018 19:00:18 -0000 Jordi, > I will clarify all those aspects. Initially I=E2=80=99d a reference to = the RFC7084 in the abstract, but it seems is not accepted by the nits che= cker, so I=E2=80=99ve removed it. If someone has any suggestion on that, = I=E2=80=99m happy to follow it =E2=80=A6 You can put the string "RFC7084" in the abstract but not the string "[RFC= 7084]". The style guide [RFC7322] says "Therefore, the Abstract must not = contain citations." Yes, I agree this is confusing. In any case, giving a= n RFC title in quotes will confuse anybody, I think. Regards Brian From nobody Sat Dec 15 13:08:35 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B428130E54 for ; Sat, 15 Dec 2018 13:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.76 X-Spam-Level: X-Spam-Status: No, score=-5.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=JBBdWjkB; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=ericsson.com header.b=msZoeBea Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRAhPk6kl2Kd for ; Sat, 15 Dec 2018 13:08:29 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D59130E50 for ; Sat, 15 Dec 2018 13:08:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1544908103; x=1547500103; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=L1t/iTnAY1nNvV/CrARkIq/hPMrG2HUlhWg3CnPWmaY=; b=JBBdWjkBvLABqtVqZxilsDFGoZLT01jXqmYfhmjVzxl7us20BAeXJt1cXprIXAzv J+7158sFO2votykEFzhQ6/N2USxG1x4Z8VJ82zdeqtbHeW7uxwx/AqOdnydoqXP7 FMclgIW/mbDAcsE4XxEWaaGWGs+E/k5chrAlErrAmzU=; X-AuditID: c1b4fb25-d89ff70000005ff7-a0-5c156d47af2d Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 4D.C0.24567.74D651C5; Sat, 15 Dec 2018 22:08:23 +0100 (CET) Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 15 Dec 2018 22:08:22 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sat, 15 Dec 2018 22:08:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lgi+PZtBx5qLT8KKylJrmP5SQ2lsrpIbk8QRNNx1CTA=; b=msZoeBeaFKXausGMFnsw3GSofz21bBJrSTC7R2P/g8hB577GDBkBeVTpXymJTAm8xpXunJbXY37cH6v0b0cb+1uxeha2kHuH4Q2EerNfdNAVip5Nz/c5JCEBqHm2lePQHTTM0sqpt+SJZEzuXUcDs53VuMVWLBuQYKjJK1cJJvY= Received: from HE1PR07MB4329.eurprd07.prod.outlook.com (20.176.167.14) by HE1PR07MB4236.eurprd07.prod.outlook.com (20.176.166.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.15; Sat, 15 Dec 2018 21:08:20 +0000 Received: from HE1PR07MB4329.eurprd07.prod.outlook.com ([fe80::fd45:e780:d637:a7ea]) by HE1PR07MB4329.eurprd07.prod.outlook.com ([fe80::fd45:e780:d637:a7ea%4]) with mapi id 15.20.1446.015; Sat, 15 Dec 2018 21:08:20 +0000 From: Daniele Ceccarelli To: JORDI PALET MARTINEZ , " (rtg-ads@ietf.org)" CC: "rtg-dir@ietf.org" , "v6ops@ietf.org" , "draft-ietf-v6ops-transition-ipv4aas.all@ietf.org" Thread-Topic: [v6ops] RtgDir review: draft-ietf-v6ops-transition-ipv4aas-11 Thread-Index: AQHUlJ2NqjIvDxNiM0CQp9SQ9xxm4KWASU7A Date: Sat, 15 Dec 2018 21:08:20 +0000 Message-ID: References: <15C31662-D05C-4C5E-A1C3-528D1B96C9E0@consulintel.es> In-Reply-To: <15C31662-D05C-4C5E-A1C3-528D1B96C9E0@consulintel.es> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniele.ceccarelli@ericsson.com; x-originating-ip: [93.38.67.165] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB4236; 6:kjj8vpbMbB70BawAynNxKkjA+c2jZdexLutXfiBdMvahdZfJfysTu0Yvpe2OiGh8za5HRD6Q5UdtwdmLSPPD2BGgTNjvuLp9OQY+Xj9iHS5qLRVBVGH4XF55VvXH4NmuF65zR1SRGobvDo87CQcEBbuB4d58Ff2zWliYNsfXK4fke8MPpy3LeNKG72YXH4C6y+G0Q6YhEYdA8eF/UEsuPvFheLFwNYBDVie8pG3q3hGHUBYpBCK/6ivZMdBkXNsfD3gk1RaiVBO8LG29ed8SXWrl1wU4/JGCFwbxCuqp7cy0+yiq56R1fuJVHX5g7i5uPQh4zESR0IlH0Yoo7hgmeszP84pj/jp64B5MG3/coMmT79p3nl77OT0veyrVEMTfnXNDHrRf7HaUNqkY01C9MS+1NPCHqdCelpdxwfaRwBOxKMg6sxH5QZajJekUpuWb6Wb9o9oaXxqeKioaRiBYvA==; 5:n2TNKKG6s8O0OUk3+u21G/Fqjyz7mROWmVZ8I4srmgnjRllvDr04OwiEvWJ+hPouWy1u/kTpqNIGX6GbUP1/kU0P+FJYtNkbB9RPojFE4hPGQ796sa+JlYOKRg+GwF1RPPaXHGcpfdCU3QWqejPP5B9e+XpRxqJONrFG14K1go4=; 7:9GY/d6SqI2huYjnYBlZPdqU9O3VpAvJOmvdIOROEPKanbLUP/WV0d/vq0sa9ui13nWH/ODloLz1VmXpcSst1xx8BO+jvcnI+bXDeXqET09ogA0fpH3LRL4+ah1lA8zn6HIYYXGp7hqFgI8D2hFAFqA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 634ae486-957f-461d-a0fb-08d662d17122 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:HE1PR07MB4236; x-ms-traffictypediagnostic: HE1PR07MB4236: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(102415395)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231475)(944501520)(4983020)(4982022)(52105112)(3002001)(148016)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB4236; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB4236; x-forefront-prvs: 088751B4D4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(346002)(39860400002)(376002)(136003)(189003)(199004)(14454004)(606006)(25786009)(5660300001)(97736004)(4001150100001)(33656002)(6436002)(229853002)(99936001)(110136005)(486006)(54906003)(53386004)(8676002)(316002)(53946003)(446003)(53936002)(476003)(11346002)(236005)(9686003)(6246003)(55016002)(54896002)(6306002)(4326008)(68736007)(66066001)(81156014)(105586002)(8936002)(106356001)(81166006)(44832011)(186003)(2906002)(26005)(6506007)(53546011)(478600001)(966005)(102836004)(790700001)(6116002)(3846002)(256004)(14444005)(5024004)(74316002)(7736002)(7696005)(86362001)(71200400001)(66574012)(71190400001)(99286004)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4236; H:HE1PR07MB4329.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: nUrmq1prMtgAROFZSbzGUS1O2fwUz8EW9hWqcGs5+364ZkA0ivik/xNE9xr1JKyWVpyVQ6Jh1+D6A2TbFL7QuFlqLTXjZsLcJNGJIOxUGY02v15jHOplwY3EdSLwlRY5PO56rCuf/ru7FEm6d9CFP6Wo0CAD5poSQ5l9vXcv5Iy9spFft/MtNXsmFUMLs5d5rMGdS87D9l2k9bfCh9jI757v135T2umzVh4CrjDrWt1Ya7APORUzzaX/B8Wm0bSv5pMEqGRuGQiuGdlLr1FRl099Wxohu9vAZ/c1vUS2wtJ9zfYMSytwrasFCuMV//VQ spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_08B8_01D494C2.ADFCD020" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 634ae486-957f-461d-a0fb-08d662d17122 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2018 21:08:20.4124 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4236 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSfSxVYRzHe845jkPd9riu+WEsd1RTiNJuphbVQmz+qaXuVhcnzHXpHqyU TVvWRnSV3mS7imlopca8zbwkL7FLNGKV15vQm/TC8tI991xb/fd5nu/n+e33++1hSPG8mT0T q0pi1SqFUkpbUnePV6e6H463ke/IrbWWraSXINly+zwp6yxYIGWFj/Tmsq62BnK/WeDjxrDA 4uJFIow4YekXxSpjU1i1577TljG/G9vNE5/nkOdmum8Q6ShnishEFgzgXVD94QrNsxi3Imgu BYF/IegctctElgYuJkBX9RDxBwprSNB25xJCkkdA6/u3lHAYR6CfqzMkDENjX5hsCeFLSTAH tXf6jA6JqxEsfC8n+cAaB0Nu5W2K9yX4CNz6skXwveHz0x/GlijsCsuz/TSviLAcBseChe78 Qbc8SPFsgQMgQ9dg1BF2BE39A8QziW1heFJrmlICY6+6aIFtYHpixUzwI+BJRo3J2QRVfe2U wI7Qp80yDgx4gIaKqlKT5A7fbt4kBQ6Ftok6WpCGEbQXTJskN6iZ0ZkqxcFkZqWJnaAse4wS HvwkYbH3Eq1Bnvn/dJtvXFIuAu3rJoIPRNgKOu9OUvmGDZD4JPR0OQr+NtAP6ak1Lrk/SwqK GxTlB/1/zfNe+PhyxFxgZ8jLGjOxD8y+mEOFaH0ZsuFYLiI+2nunB6uOjeS4BJWHik16hgzf r7nyj2sN6v/k34Iwg6QbRLFyG7nYTJHCnY9vQS6GOuMV5b3InlIlqFipRCROlMjFoijF+VRW nXBKnaxkuRbkwFBSW9GS2EouxtGKJDaOZRNZ9VpKMBb26UjZpNgo01/P87pGHhtR+rGL2c71 w0UuTM9wkIP8kJ6e8H2XGnAga8629MKmQKrZayDCLk2T7HPr4uhqaJr7116vzWdChrQdu6sj +04mOe+5vLSq3lp4r/aGptnurO5o75v48JFxp1aL8LmtVrraq+u6C4PEbd+dpw76dHgPqOa3 r0opLkbh5UaqOcVfrMRe5IYDAAA= Archived-At: Subject: Re: [v6ops] RtgDir review: draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2018 21:08:33 -0000 ------=_NextPart_000_08B8_01D494C2.ADFCD020 Content-Type: multipart/alternative; boundary="----=_NextPart_001_08B9_01D494C2.ADFCF730" ------=_NextPart_001_08B9_01D494C2.ADFCF730 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Jordi, =20 Please see in line for my replies, but in general I=E2=80=99d say the = draft if good to go for me. BR =20 Daniele =20 =20 From: JORDI PALET MARTINEZ =20 Sent: den 15 december 2018 18:42 To: Daniele Ceccarelli ; = (rtg-ads@ietf.org) Cc: rtg-dir@ietf.org; v6ops@ietf.org; = draft-ietf-v6ops-transition-ipv4aas.all@ietf.org Subject: Re: [v6ops] RtgDir review: = draft-ietf-v6ops-transition-ipv4aas-11 =20 =EF=BB=BFHi Daniele, =20 Thanks a lot for your review. =20 Please, see my responses below, in-line. Regards, Jordi =20 =20 =20 De: v6ops > en = nombre de Daniele Ceccarelli > Fecha: s=C3=A1bado, 15 de diciembre de 2018, 16:15 Para: " > (rtg-ads@ietf.org = )" = > CC: "rtg-dir@ietf.org" >, = "v6ops@ietf.org " >, = "draft-ietf-v6ops-transition-ipv4aas.all@ietf.org = " = > Asunto: [v6ops] RtgDir review: draft-ietf-v6ops-transition-ipv4aas-11 =20 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-v6ops-transition-ipv4aas-11.txt=20 Reviewer: Daniele Ceccarelli Review Date: 2018-12-14 IETF LC End Date: date-if-know Intended Status: Informational Summary:=20 * I have some minor concerns about this document that I think = should be resolved before publication. Comments: * I find this draft quite difficult to read. Probably it=E2=80=99s = due to my lack of competence in the topic. If the aim is to make it = usable by experts it could be ok. This document is not defining = protocols extensions (hence targeting experts), but requirements and = mechanisms for IPv4-IPv6 transition hence it should be starting point = for a newbie to get to understand the topic. Some drawings to help = understanding the context and a more detailed explanation in the intro = would be helpful. E.g. the content of Annex B could be a good starting = point. I guess it can help to add a comment in the line that it is expected = that the reader has also read RFC7084. Initially the annex B was right after the intro, but the WG decided to = keep it, but make it an annex. I will make a comment in the intro to = reference the annex. [DC] It=E2=80=99s a good solution. I=E2=80=99ll try to have a look at = RFC7084 but if that document is a good starting point and this one = references that as a pre-requirement=E2=80=A6hence it will be clear for = a newbie how to approach the topic, hence fine with me.=20 Major Issues: * 1.1. Requirements Language - Special Note =E2=80=93 Very = particular usage of the requirements language. It says =E2=80=9CThis = document uses these keywords not strictly for the purpose of = interoperability, but rather for the purpose of establishing = industry-common baseline functionality.=E2=80=9D. I don=E2=80=99t see a = big difference. In both cases it tells how things should be done. = Moreover there are various occurrences of MUST/SHOULD that really seem = to conform RFC2119. This was made also following RFC7084. [DC] I find this very strange and I had never seen it before, but if it = is included in an RFC it means the IESG is ok with that and hence I = don=E2=80=99t see why you shouldn=E2=80=99t adopt it in your draft.=20 Minor Issues: * Abstract: =E2=80=9CThis document specifies the IPv4 service = continuity requirements for an IPv6 Customer Edge (CE) router, either = provided by the service provider or through the retail market.=E2=80=9D = Do you mean =E2=80=9Cor by producers of devices for the retail = market=E2=80=9D ? * Abstract: "Basic Requirements for IPv6 Customer Edge Routers". = Since this is in quotes I guess it references something well known. = Adding the reference could be helpful. Further reading I=E2=80=99ve = found RFC7084 as reference. You can add it. * The scope of the draft is not clear from the statement in the = intro: =E2=80=9Cso the scope of this document is to ensure the IPv4 = "service continuity" support, in the LAN side and the access to = IPv4-only Internet services from an IPv6-only access WAN even from = IPv6-only applications or devices in the LAN side.=E2=80=9D This should = be better explained.=20 I will clarify all those aspects. Initially I=E2=80=99d a reference to = the RFC7084 in the abstract, but it seems is not accepted by the nits = checker, so I=E2=80=99ve removed it. If someone has any suggestion on = that, I=E2=80=99m happy to follow it =E2=80=A6 [DC] You could spell it out explicitly. Something like =E2=80=9Cthis = document augments/leverages on the previously defined basic requirements = for IPv6 customer edge routers=E2=80=A6 Nits: * Intro: A number of acronyms should be expanded at first use: = e.g. LAN, WAN, HNCP, ISP. * Intro: :=E2=80=9CThis is a common situation in when = sufficient=E2=80=A6=E2=80=9D remove =E2=80=9Cin=E2=80=9D. * Actually there is plenty of Nits. I suggest a spelling pass.=20 I will follow all those points as well. [DC] OK thanks. BR Daniele =20 _______________________________________________ v6ops mailing list = v6ops@ietf.org = https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or = confidential. The information is intended to be for the exclusive use of = the individual(s) named above and further non-explicilty authorized = disclosure, copying, distribution or use of the contents of this = information, even if partially, including attached files, is strictly = prohibited and will be considered a criminal offense. If you are not the = intended recipient be aware that any disclosure, copying, distribution = or use of the contents of this information, even if partially, including = attached files, is strictly prohibited, will be considered a criminal = offense, so you must reply to the original sender to inform about this = communication and delete it. ------=_NextPart_001_08B9_01D494C2.ADFCF730 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Jordi,

 

Please see in line for my replies, but in general = I=E2=80=99d say the draft if good to go for = me.
BR

 

Daniele=C2=A0 =

 

From: JORDI PALET MARTINEZ = <jordi.palet@consulintel.es>
Sent: den 15 december 2018 = 18:42
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; = <rtg-ads@ietf.org> (rtg-ads@ietf.org) = <rtg-ads@ietf.org>
Cc: rtg-dir@ietf.org; v6ops@ietf.org; = draft-ietf-v6ops-transition-ipv4aas.all@ietf.org
Subject: Re: = [v6ops] RtgDir review: = draft-ietf-v6ops-transition-ipv4aas-11

<= p class=3DMsoNormal> 

=EF=BB=BFHi = Daniele,

 

Thanks a lot for your review.

 

Please, see my responses below, = in-line.


R= egards,

Jordi

 

=

 

 

De: v6ops <v6ops-bounces@ietf.org> en = nombre de Daniele Ceccarelli <daniele.ceccarelli@ericss= on.com>
Fecha: s=C3=A1bado, 15 de diciembre de 2018, = 16:15
Para: "<rtg-ads@ietf.org> (rtg-ads@ietf.org)" <rtg-ads@ietf.org>
CC: = "rtg-dir@ietf.org" = <rtg-dir@ietf.org>, = "v6ops@ietf.org" <v6ops@ietf.org>, "draft-ie= tf-v6ops-transition-ipv4aas.all@ietf.org" <draft-ie= tf-v6ops-transition-ipv4aas.all@ietf.org>
Asunto: = [v6ops] RtgDir review: = draft-ietf-v6ops-transition-ipv4aas-11=

 

H= ello,

I= have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see <= a href=3D"http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir">=E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/Rtg= Dir

A= lthough these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft.

D= ocument: draft-ietf-v6ops-transition-ipv4aas-11.txt 
Reviewer: = Daniele Ceccarelli
Review Date: 2018-12-14
IETF LC End Date: = date-if-know
Intended Status: Informational

S= ummary:&= nbsp;

=C2=B7       = I= have some minor concerns about this document that I think should be = resolved before publication.

C= omments:

=C2=B7       = I= find this draft quite difficult to read. Probably it=E2=80=99s due to = my lack of competence in the topic. If the aim is to make it usable by = experts it could be ok. This document is not defining protocols = extensions (hence targeting experts), but requirements and = mechanisms  for IPv4-IPv6 transition hence it should be starting = point for a newbie to get to understand the topic. Some drawings to help = understanding the context and a more detailed explanation in the intro = would be helpful. E.g. the content of Annex B could be a good starting = point.

I guess it can help to add a comment in the line that it is = expected that the reader has also read = RFC7084.

Initially the annex B was right after the intro, but the WG = decided to keep it, but make it an annex. I will make a comment in the = intro to reference the annex.

[DC] It=E2=80=99s a good = solution. I=E2=80=99ll try to have a look at RFC7084 but if that = document is a good starting point and this one references that as a = pre-requirement=E2=80=A6hence it will be clear for a newbie how to = approach the topic, hence fine with me. = =

M= ajor Issues:

=C2=B7       = 1= .1.  Requirements Language - Special Note =E2=80=93 Very particular = usage of the requirements language. It says =E2=80=9CThis document uses = these keywords not strictly for the purpose of interoperability, but = rather for the purpose of establishing industry-common baseline = functionality.=E2=80=9D. I don=E2=80=99t see a big difference. In both = cases it tells how things should be done. Moreover there are various = occurrences of MUST/SHOULD that really seem to conform = RFC2119.

This was made also = following RFC7084.

[DC] I find this very strange and I had = never seen it before, but if it is included in an RFC it means the IESG = is ok with that and hence I don=E2=80=99t see why you shouldn=E2=80=99t = adopt it in your draft.

M= inor Issues:

=C2=B7       = A= bstract: =E2=80=9CThis document specifies the IPv4 service continuity = requirements for an IPv6 Customer Edge (CE) router, either provided by = the service provider or through the retail market.=E2=80=9D Do you mean = =E2=80=9Cor by producers of devices for the retail market=E2=80=9D = ?

=C2=B7       = A= bstract: "Basic Requirements for IPv6 Customer Edge Routers". = Since this is in quotes I guess it references something well known. = Adding the reference could be helpful. Further reading I=E2=80=99ve = found RFC7084 as reference. You can add it.

=C2=B7       = T= he scope of the draft is not clear from the statement in the intro: = =E2=80=9Cso the scope of this document is to ensure the IPv4 = "service continuity" support, in the LAN side and the access = to IPv4-only Internet services from an IPv6-only access WAN even from = IPv6-only applications or devices in the LAN side.=E2=80=9D This should = be better explained.

I will clarify all those aspects. Initially = I=E2=80=99d a reference to the RFC7084 in the abstract, but it seems is = not accepted by the nits checker, so I=E2=80=99ve removed it. If someone = has any suggestion on that, I=E2=80=99m happy to follow it = =E2=80=A6

[DC] You could spell it out explicitly. = Something like =E2=80=9Cthis document augments/leverages on the = previously defined basic requirements for IPv6 customer edge = routers=E2=80=A6

N= its:

=C2=B7       = I= ntro: A number of acronyms should be expanded at first use: e.g. LAN, = WAN, HNCP, ISP.

=C2=B7       = I= ntro: :=E2=80=9CThis is a common situation in when = sufficient=E2=80=A6=E2=80=9D remove =E2=80=9Cin=E2=80=9D.

=C2=B7       = A= ctually there is plenty of Nits. I suggest a spelling pass.

I will follow all those points as = well.

[DC] OK thanks.

BR
Daniele  =

__________________________________= _____________ v6ops mailing list v6ops@ietf.org https://www.ietf.org= /mailman/listinfo/v6ops


***********************************= ***********
IPv4 is over
Are you ready for the new Internet = ?
http://www.theipv6company.com<= br>The IPv6 Company

This electronic message contains information = which may be privileged or confidential. The information is intended to = be for the exclusive use of the individual(s) named above and further = non-explicilty authorized disclosure, copying, distribution or use of = the contents of this information, even if partially, including attached = files, is strictly prohibited and will be considered a criminal offense. = If you are not the intended recipient be aware that any disclosure, = copying, distribution or use of the contents of this information, even = if partially, including attached files, is strictly prohibited, will be = considered a criminal offense, so you must reply to the original sender = to inform about this communication and delete = it.

------=_NextPart_001_08B9_01D494C2.ADFCF730-- ------=_NextPart_000_08B8_01D494C2.ADFCD020 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVeTCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQCH7S4aKCZKxRmqOuu5DaLLMA0GCSqGSIb3DQEBCwUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMTQx MjA1MDgxOTE1WhcNMjEwNDA1MTAyOTAwWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBCwUAA4IBAQAQ1elFTM6fGkQ/aRKdkUZicO3Cb9uzBJOpOtFctw+1El0/17lsjoVvJkZB D3KnUobnrriFdAa+7FAN55KLmZeB/3Y2bG0bB4toSyaVHjOQnQY9M0dv8U852w0Q7GwchKfebLUI bh9TMt2hI3Xc6j4knFTBUo7C1WAfO51K4bn1irmX6/Ej2VTgiOFsvOAny28W6enFSEQpSHw60VhN fSttSqTOxyrRR/7kW7Y8yb/3DZDZ/dH6ZCfx/y+BNIv2NuSd85M9HXUzplXXohti4Ql/qeaMn6by Ius6XlMWZZfkdVRvTuk2PkeC7UmAJ2+/DUWOPpawaytMXVfF4Hvxk34NMIIGCjCCA/KgAwIBAgIQ PmzwpRtLuvapASEIDcQbUjANBgkqhkiG9w0BAQsFADBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwI RXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMTIy MTMwMzAxWhcNMjAxMTIyMTMwMzAwWjByMREwDwYDVQQKDAhFcmljc3NvbjEbMBkGA1UEAwwSRGFu aWVsZSBDZWNjYXJlbGxpMS4wLAYJKoZIhvcNAQkBFh9kYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdxZGFuY2VjMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 0iZOZirmwPeV3dhVB/mEPJ1V1ihyztfLo3jkAt7NGg1SuJX1/mRcLbPsyl7gxTHAMXmaoIIHeOQQ hTcty19TnKIWO+5Vbt3tD0MdxCWiGR0FeHHyOZP97jqerlnCD2fuZny3/ne02QUy8VVFSReQitgp JRcbTWlo0zfAVRNPIuQtWUxAqznJqc3l5qXIHtP/eEv7mKaaXo00f7heN9wLHtRoX6oz/NFrWLjD V4aqciCdWAVoIpuKFsDm7skNVTmwYmdVdBCekeKmv3CJyb/g0qV3pMPH+mtBRV0EnH+6BpSIXwFH Qa/PsBn3YoUzc/yMJyUqbGY/aTT/ozrOvYAgTwIDAQABo4IBxTCCAcEwSAYDVR0fBEEwPzA9oDug OYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNy bDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEu Y29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29u bmxpbmRpdmlkdWFsY2F2My5jZXIwKgYDVR0RBCMwIYEfZGFuaWVsZS5jZWNjYXJlbGxpQGVyaWNz c29uLmNvbTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFJ9SlCYOzjRVet6CA+roouqVzccUMB8GA1UdIwQYMBaAFBx7 GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOCAgEAyvE+ 6J+2LkiZ/ea8iQoubcyS/aKpuzcx/NxJPUvkJysvid/CPpvemTxZTXrEPGRX+4Qze0Jk4Fo2GUHD nnO1j+Gk7jmSXNS41HTIDgH3Hnc1cpSpNUxfWRqZvII2T6hh5COy3hY1qk1P9TnGsBmbW6WsZiR0 JWh2xgDKRXe91ciTaEZK2Nz5niQxJmQjN0i9q2eEQx9FXpXAHQua5SPrN6dTZpjaN5fR32VRpKYr Pom2jcPmGW4BDob7+tOcraqqpQULKRR8sE0V4vA/l3ZLkwypfA0Ase7dQI8gTHhyraQW3nigUjOH EFmUEVQfxdowx6hwxfGMuwi9Rakp67eW3WNOdvVjgt48kk4qk3I3iWmcVeUokYKUoDgeGsh0gIZE 2M+IbtZjCpIsiowKptMRI9q+Fnh8gAyo7+m8URaDq7aYzp5OmiPgb7whGYAdsbHJEFNkGLF+xyaE kmcRXdHyu9EAQZQmIRpTdPwCDsCXrzc5n4jLmMo2wa5CcXGcZTkg2xBh11YV3LDQK+BLGBD7JUFx 6wV47wO1AtRTV23cpuzK9hFgE560RSKI+cDLNcKW8NAc7tVKonz2dp5H82FO3oavo/HSKesqtQsx KVFpzq6s69I1+biH1iVWq+wmMfZhZT6Z044ErPFOTlMfedD2WKY/gUCvGROWVkvdOg7JPIowggbC MIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0 NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYD VQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8A MIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5v u5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ub ppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmbNJ7o 58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CXs/PVtO57 HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5lCBgUUBsbpWI XwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0VNXyz1GUOxSqw 1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zRzdYsmclT9rOd gdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U/V7oqyqx5Yd1 c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6 Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDovL3JlcG9zaXRv cnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB /wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0 cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6g PIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYx LmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1Ud DgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gT EjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q 1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8O UWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw9 6AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0rI0Ro GzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJtepti+i5CC KEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmkiLo900GITb/i 7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFBV9g8Zh5mdZ+R zPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRqYb8cqqeCaPKk veBJzqgb8ToH7WLoOzmPRCmPlpAxggMCMIIC/gIBATBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQK DAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQPmzwpRtL uvapASEIDcQbUjAJBgUrDgMCGgUAoIIBfDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xODEyMTUyMTA4MTZaMCMGCSqGSIb3DQEJBDEWBBR6Pb+23KvYkPT9npiuQesI c1lyGTBDBgkqhkiG9w0BCQ8xNjA0MAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCGjBqBgkrBgEEAYI3EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQK DAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQPmzwpRtL uvapASEIDcQbUjBsBgsqhkiG9w0BCRACCzFdoFswRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhA+bPClG0u69qkB IQgNxBtSMA0GCSqGSIb3DQEBAQUABIIBAMBmlGIx5WBe0U35faOHCAeZt2kSvnw4VBFRKdbFN0O+ F8RI0i4AddLZyJZZ8Bn46oAmQy1pvvsAbv3AxNV0qE6DZ8Y4WqK2E7Tqrx+13Ha/OJ5jO3JTc7Be Opt6+IdpaMtR+s5txeIJpHFO82ZKlP0+RXs1YK5X8A/r2OzXoiG8y1/UCwI9kuZyEzWTXKKiSElB AFJYocXWijPIEJndC7gggN7WrNqwZvztMHHl684/pMKK72Dg8Oxli/ylWZ0ZGxvjubgoaXMnNlFA UYOUDBjWwjLRaGF9l5NawFJSN3r8iu1k7jmBHhLXWii7vBPJzkvPqtW7z5e1rA/Yo+6TN98AAAAA AAA= ------=_NextPart_000_08B8_01D494C2.ADFCD020-- From nobody Sat Dec 15 14:36:16 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458AA130E3F; Sat, 15 Dec 2018 14:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hDk3a7Ju4NV; Sat, 15 Dec 2018 14:36:04 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16BF1130E5A; Sat, 15 Dec 2018 14:36:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1544913361; x=1545518161; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=Fn5kuweZjUdwhZljLRNcxuzKxJKAIVEy0J2BE3PQ1kY=; b=Fdo1Ina0OTdOT 6kbeC2ySvOYW3zzx2XtQRT/p+8udQOtZj3HeYhuPKtO0c3u2C8SMG+TwmM6dEsMy MDBasAnHY/yr2OSzdEjUnUYBgHghOg8J6PfNozNJvT4gPQCuH2iaukvMi93N1324 d0mJdAS64O3LGlj3qX2uVUVpqDw3dM= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sat, 15 Dec 2018 23:36:01 +0100 X-Spam-Processed: mail.consulintel.es, Sat, 15 Dec 2018 23:36:01 +0100 Received: from [10.10.10.130] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006070277.msg; Sat, 15 Dec 2018 23:36:00 +0100 X-MDRemoteIP: 2001:470:1f09:495:6068:a38e:34c0:2c9c X-MDHelo: [10.10.10.130] X-MDArrival-Date: Sat, 15 Dec 2018 23:36:00 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=188724d074=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Sat, 15 Dec 2018 23:35:58 +0100 From: JORDI PALET MARTINEZ To: Brian E Carpenter CC: "rtg-dir@ietf.org" , "v6ops@ietf.org" , "draft-ietf-v6ops-transition-ipv4aas.all@ietf.org" Message-ID: Thread-Topic: [v6ops] RtgDir review: draft-ietf-v6ops-transition-ipv4aas-11 References: <15C31662-D05C-4C5E-A1C3-528D1B96C9E0@consulintel.es> <9d6fda6b-cec0-3598-2ced-08081eb9ee8a@gmail.com> In-Reply-To: <9d6fda6b-cec0-3598-2ced-08081eb9ee8a@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] RtgDir review: draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2018 22:36:07 -0000 Hi Brian, Thanks a lot! Will correct using the string RFC7084. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Brian E Carpenter Fecha: s=C3=A1bado, 15 de diciembre de 2018, 20:00 Para: JORDI PALET MARTINEZ CC: "rtg-dir@ietf.org" , "v6ops@ietf.org" , "draft-ietf-v6ops-transition-ipv4aas.all@ietf.org" Asunto: Re: [v6ops] RtgDir review: draft-ietf-v6ops-transition-ipv4aas-11 Jordi, =20 > I will clarify all those aspects. Initially I=E2=80=99d a reference t= o the RFC7084 in the abstract, but it seems is not accepted by the nits che= cker, so I=E2=80=99ve removed it. If someone has any suggestion on that, I= =E2=80=99m happy to follow it =E2=80=A6 =20 You can put the string "RFC7084" in the abstract but not the string "[R= FC7084]". The style guide [RFC7322] says "Therefore, the Abstract must not = contain citations." Yes, I agree this is confusing. In any case, giving an = RFC title in quotes will confuse anybody, I think. =20 Regards Brian =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon Dec 17 07:13:04 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C42126CC7 for ; Mon, 17 Dec 2018 07:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.161 X-Spam-Level: X-Spam-Status: No, score=-4.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieL-E6TFGSaU for ; Mon, 17 Dec 2018 07:13:00 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 03906129C6A for ; Mon, 17 Dec 2018 07:12:58 -0800 (PST) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id wBHF9LJM020885 for ; Mon, 17 Dec 2018 07:12:57 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=tE0LvOoGP2s3FEu9wZDnNExgyrqn0gWOWeSG+zZSjiQ=; b=mt4tD9juxfDZA9DIC4mOoCwtp5twDXm1toCbnoDJ8+XEkWP+HInK5Pzsts3ST30SotSN cnREs44Yrk7Hs4+GFl8sFbTqe7Fd4GekF96y3Bg+gPP1j+ILolpiyhzygWgOWZwEws1m t/giWakxXRyeANdfhzzL9w7d7RmZoVGJYDhczZbWWULA4TrrN+eiBqDbwgY+v3OOYNWo 6Y343TnLbkYWoVHGGD+dWPOILPo6sXfcTBZnxUzlz5Ia0UEftZ+YiV7dF/IQoxjHyKhH kgxXEOxYj+UFggm0RtcyjfMWOamqnq4jbqV/TMkDcVPnahbfQcycFC4tzAoLGyLc21Lf Rg== Received: from nam04-sn1-obe.outbound.protection.outlook.com (mail-sn1nam04lp2057.outbound.protection.outlook.com [104.47.44.57]) by mx0b-00273201.pphosted.com with ESMTP id 2pebn3r86w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 17 Dec 2018 07:12:57 -0800 Received: from BN7PR05MB4243.namprd05.prod.outlook.com (52.133.222.152) by BN7PR05MB4052.namprd05.prod.outlook.com (52.132.219.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.9; Mon, 17 Dec 2018 15:12:55 +0000 Received: from BN7PR05MB4243.namprd05.prod.outlook.com ([fe80::c14b:3784:101:4d9a]) by BN7PR05MB4243.namprd05.prod.outlook.com ([fe80::c14b:3784:101:4d9a%2]) with mapi id 15.20.1446.015; Mon, 17 Dec 2018 15:12:55 +0000 From: Ron Bonica To: "v6ops@ietf.org list" Thread-Topic: draft-lmhp-v6ops-transition-comparison Thread-Index: AdSWGuZ9aZhE9x1qQaGRDFOaU27+fQ== Date: Mon, 17 Dec 2018 15:12:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.0.61 dlp-reaction: no-action x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN7PR05MB4052; 6:6UcuBU0o8vDBKOO4eE8HynZCc5sI9i+DtAwkRIl6GuL0aP/lLiuv2izOi2qrxenJO+/+Uw/EOZnH9FHL7sdEkDDCIUFTCscXeNy3hSkPiWsSntK3oSL/3tA/7hrNuh8+TT/0kF4MJ1R1pihUZ7mnOidO1gdy3bfddQAe/VuUyEhAuq/QnpODHvSRqOaJ1iJyxrHJVU/vMesQR7PIs6GSQL9yAIVcX53XKwvzLY+q8jHE9kuWsp55BD6dQ9+/faey//ruJCXQrBHej3H+LtUgR0Y5w9+lgA3vGTyuSxKxkuvDsfkNtDmSEKDtZFXFoatinVcSUHXQzQpnNZ2//ITuLFwRd6y2LsNO5wR3HsPwlgKqhQ0nNoOgidTy523NTK0c0E1zSSls14prLASjD6wOOxrFB8hNjLuLszPLpCH9EcOKxJpXqCwfm8teil0Ci0wsYekIwqHN5hXyM9S0TiAMXw==; 5:xnUSD8de7qdvf/fAgvLR3YKtUEu5NmeTNy2nw5umFTLDiBWRy3QjHFHyn7GwTGMmxezTgHXTJvupxnyILftfgfz1nCItGkkDrv2AqWlS4F+eTEVr7R5cdSa9aqJDdUeKaiJJiqBSgFcCCkuL+ZtKU2J0bY3ORBhInKWu0MTGZdM=; 7:4oS4VeronOfTwWCpykdMcs41sTfk+wfblmSLkHbcY0k7us/Wh8WcuXCH9ngqUXx7U5xjAXrq1900JxYOv3SmhuRjYkM7LyBTZQuBiNAvrZdm+MA5S/A6oElmuIX1tOSERBZtcX35YosdHCwA7IxvEQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: eda91488-2aef-4cec-26fe-08d664321f7c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:BN7PR05MB4052; x-ms-traffictypediagnostic: BN7PR05MB4052: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(5005006)(8121501046)(3231475)(944501520)(52105112)(93006095)(93001095)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:BN7PR05MB4052; BCL:0; PCL:0; RULEID:; SRVR:BN7PR05MB4052; x-forefront-prvs: 08897B549D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(396003)(136003)(346002)(376002)(189003)(199004)(86362001)(486006)(74316002)(81156014)(476003)(558084003)(6916009)(71190400001)(71200400001)(53936002)(6436002)(7736002)(305945005)(8936002)(5660300001)(68736007)(25786009)(14454004)(478600001)(6116002)(105586002)(55016002)(9686003)(2906002)(8676002)(102836004)(186003)(66066001)(81166006)(7696005)(26005)(99286004)(3846002)(33656002)(256004)(97736004)(106356001)(316002)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB4052; H:BN7PR05MB4243.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: 6hIhpVna5sl4NjKvOBzDs9wiBYrC3KvvwrhBgF677N7UiUdM/kuXKl/PXQpM7AyeQicVesMYFIZFhfTTKSVzhZlSsfGk70HNw5A4xb8HTeV38iMLpq+PW9s7SGeRw5OswefpShhywqFXF3R0sTYDRFllwRACnSGQctqOWYABMxB9tukCmsviFxVDeRMncVHdZBzZdV+S/jdAnYJAPa5myZhc+y9TnTIvJixUDo713b5He8JMEGPbn1W5CfbqeDFq1l6/phdqgxvngsYUhFA6FbovaQEELAa75DLtLUEvjZtQtq7hN8fDxE+EK61LWBlQ spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: eda91488-2aef-4cec-26fe-08d664321f7c X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2018 15:12:55.6845 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB4052 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-17_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=554 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812170135 Archived-At: Subject: [v6ops] draft-lmhp-v6ops-transition-comparison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 15:13:02 -0000 Folks, Each week between now and IETF 104, we will review and discuss one draft wi= th an eye towards progressing it. This week, please review and comment on draft-lmhp-v6ops-transition-compari= son. Fred and Ron From nobody Mon Dec 17 07:20:48 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5433C126CC7 for ; Mon, 17 Dec 2018 07:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvCjWiOHHlss for ; Mon, 17 Dec 2018 07:20:44 -0800 (PST) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (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 AA765129385 for ; Mon, 17 Dec 2018 07:20:43 -0800 (PST) Received: from [192.168.1.119] (host-79-121-40-54.kabelnet.hu [79.121.40.54]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id wBHFKZwe050152 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 17 Dec 2018 16:20:40 +0100 (CET) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-40-54.kabelnet.hu [79.121.40.54] claimed to be [192.168.1.119] To: v6ops@ietf.org References: From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: Date: Mon, 17 Dec 2018 16:20:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.100.1 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.40.54; helo=[192.168.1.119]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] draft-lmhp-v6ops-transition-comparison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 15:20:46 -0000 Dear Fred and Ron, I have great news. Ian Farrer has joined us as a co-author and he has made significant improvements to the draft. However, the new version is not uploaded yet, as we have not finished it. We try to clean it up and I hope to be able to upload the new version in few days. Best regards, Gábor 12/17/2018 4:12 PM keltezéssel, Ron Bonica írta: > Folks, > > Each week between now and IETF 104, we will review and discuss one draft with an eye towards progressing it. > > This week, please review and comment on draft-lmhp-v6ops-transition-comparison. > > Fred and Ron > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Dec 17 07:53:10 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7527412D4F2 for ; Mon, 17 Dec 2018 07:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.161 X-Spam-Level: X-Spam-Status: No, score=-4.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-BrzoS3IhuQ for ; Mon, 17 Dec 2018 07:53:07 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 0E66C128CF3 for ; Mon, 17 Dec 2018 07:53:06 -0800 (PST) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id wBHFOjFh009077; Mon, 17 Dec 2018 07:24:45 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=xXY7tzO3Qj6jvHemFv9BkwQxdApOV+fwXdt105KmAYM=; b=Bn5HTeTBczNohArMjJDtmavV2MjzsnE6E4nIAPnfyBiyqZiByIQqQPnRaZwkOvoecKrm M6ay8sTFMWawM9pXc4LGizxPUG1tVElz5J9iPyXZfoMyF/cN/vPkatfIg9tHWYDyUHlz M53BAXNWQ9yFf3KyIOcEXsW33fLZ0s6l1XPlNHkIIApDxtcqSdGU+6olsGrHtlepGLJd CxueTKJLU2dgaEhNPoKmlJY+RUDYRI7i24c/iRCqwCH/IdIK627A7+AgQC5jo070wxur UjUViFonPtStufV7lr8EGkd1Pxc5JsofzqPe2JsnNGu+Xa8KPAqphANKSPduFGp/aU7K BA== Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp2054.outbound.protection.outlook.com [104.47.45.54]) by mx0a-00273201.pphosted.com with ESMTP id 2pe5h88thx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 17 Dec 2018 07:24:45 -0800 Received: from BN7PR05MB4243.namprd05.prod.outlook.com (52.133.222.152) by BN7PR05MB3969.namprd05.prod.outlook.com (52.132.216.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.9; Mon, 17 Dec 2018 15:24:43 +0000 Received: from BN7PR05MB4243.namprd05.prod.outlook.com ([fe80::c14b:3784:101:4d9a]) by BN7PR05MB4243.namprd05.prod.outlook.com ([fe80::c14b:3784:101:4d9a%2]) with mapi id 15.20.1446.015; Mon, 17 Dec 2018 15:24:43 +0000 From: Ron Bonica To: =?iso-8859-1?Q?Lencse_G=E1bor?= , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-lmhp-v6ops-transition-comparison Thread-Index: AdSWGuZ9aZhE9x1qQaGRDFOaU27+fQAASU0AAAAgorA= Date: Mon, 17 Dec 2018 15:24:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.0.61 dlp-reaction: no-action x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN7PR05MB3969; 6:9W11UMLZZ1b0nRK32vpEImVF3+z9+gDQqhuij0XzA/mbO16ftdRJo/BdbiMAJXoGxNLS1LvmKucD8hPOOyxiZIywqQUkCTAOQFEQzzmNNRVtOFk2+HqSMxZCHKcXKPpN5N9wfhPt6XjrJRKCa6xRZNklZgcwrZnf9jXPV5fL7Urm3s/jYajaRJfXZ/ss75rY5jxrZ6epSftoVwSctBvtXdFIptnq/VFssCJH05kSHpaYrzYqbG9fko99301ScIvgspC8iC/LDshRUkjsorukerFp+3Jo0B11WlFvSrzC4hWS2LqElybAAZKjZcgJvD+E22kcORADt1Ykz24aZ81TAj7CKq0x81vtGeVXCC6fmA52pQcuibytfI8EsynPwZwYoXCKwWT9rSsv+hUBXSh77cjyWlZOjGi2XUAGJLVoERO+qnjd7RLUm/06MV8jFE7CrJ2ykyclNYgitGjYBhlyxQ==; 5:EY3SvupZvujph7mCxh/jj2MHKtEo3IL0yEw0EtuyXlPz+Wu6x+zWIprFJEriuf6uf3yA4m1ICPp7cap7W2bQi4dEh29LIBjvOM3GN8Bw5sL42fDzLB+6KOQS1btAUzVeLq8pnKqINlgVwG6vJSzYpsQ96dICpU5nWmeDVS6a4tQ=; 7:3bH6exoPKGq2VlEGzcsd0OzvQmULGlEx+O5zyTP6xMj6Wit9YOju1BfT2QzbbZ5aTUFPFhevoR/R1AcAf2C9lZv0pwkV7mKMEvj2xxEYk5UzRwOHsEeK1WoJrZ1kM3xnouP88SMNzsIP9RYCDRoQ0Q== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c3227c26-c8ba-413c-60a3-08d66433c53c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BN7PR05MB3969; x-ms-traffictypediagnostic: BN7PR05MB3969: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(8121501046)(5005006)(3231475)(944501520)(52105112)(93006095)(93001095)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:BN7PR05MB3969; BCL:0; PCL:0; RULEID:; SRVR:BN7PR05MB3969; x-forefront-prvs: 08897B549D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(366004)(136003)(39860400002)(346002)(13464003)(189003)(199004)(186003)(26005)(86362001)(575784001)(6116002)(6506007)(25786009)(53546011)(97736004)(3846002)(2906002)(6436002)(19627235002)(102836004)(71190400001)(76176011)(71200400001)(9686003)(6246003)(55016002)(6306002)(446003)(66066001)(53936002)(229853002)(478600001)(106356001)(105586002)(966005)(14454004)(110136005)(7736002)(74316002)(316002)(305945005)(476003)(8936002)(5660300001)(7696005)(99286004)(33656002)(486006)(256004)(81166006)(81156014)(8676002)(2501003)(68736007)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN7PR05MB3969; H:BN7PR05MB4243.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: 7434t6eEM7cRJV73ly897eYlc6AkAlGUaeETlJMOTcAiu/N+KKGOyc8IiavM8t9oAXdloPI+jh2Unn6nszHVsqEYg3g0wVCWOw4z3ybmVV3ljLMKZEpFlYOHJteyyOKh7R3bdzfPzLtmoZzOEjJmcQx8K3W0WgzSQFGcXo7OiHbSIFN5rUZQzJAVSWQ6cWl1dyMFhiscvKdqEXYZGUtIC/+eBHrWygp249OeycsRmo1g4Y09AARU6FWvnE91/FB/0+sPVIWtp0VbpWSYsJ99wUvLspD4+ZmuNuYjoS337Z9ftpD2BZiVdXr7yJtyzB/r spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: c3227c26-c8ba-413c-60a3-08d66433c53c X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2018 15:24:43.2806 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB3969 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-17_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812170137 Archived-At: Subject: Re: [v6ops] draft-lmhp-v6ops-transition-comparison X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 15:53:10 -0000 Gabor, In that case, let's defer the review until after the holidays. Ron > -----Original Message----- > From: v6ops On Behalf Of Lencse G=E1bor > Sent: Monday, December 17, 2018 10:21 AM > To: v6ops@ietf.org > Subject: Re: [v6ops] draft-lmhp-v6ops-transition-comparison >=20 > Dear Fred and Ron, >=20 > I have great news. Ian Farrer has joined us as a co-author and he has mad= e > significant improvements to the draft. >=20 > However, the new version is not uploaded yet, as we have not finished it.= We > try to clean it up and I hope to be able to upload the new version in few= days. >=20 > Best regards, >=20 > G=E1bor >=20 >=20 > 12/17/2018 4:12 PM keltez=E9ssel, Ron Bonica =EDrta: > > Folks, > > > > Each week between now and IETF 104, we will review and discuss one draf= t > with an eye towards progressing it. > > > > This week, please review and comment on draft-lmhp-v6ops-transition- > comparison. > > > > Fred and > > Ron > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= l > > man_listinfo_v6ops&d=3DDwIFBA&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWz > > oCI&r=3DFch9FQ82sir-BoLx84hKuKwl- > AWF2EfpHcAwrDThKP8&m=3DVaNlVihykArnGFq_QS > > > o3k_mRTaVfRoZGyWGMrqYZzGs&s=3DIbs7aeV9DnZtQLUb4DmV3crqAtAsDGj3 > Eao6mbwCp8 > > k&e=3D >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIFBA&c=3DHAkYuh63rsuhr6 > Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3DFch9FQ82sir-BoLx84hKuKwl- > AWF2EfpHcAwrDThKP8&m=3DVaNlVihykArnGFq_QSo3k_mRTaVfRoZGyWGMr > qYZzGs&s=3DIbs7aeV9DnZtQLUb4DmV3crqAtAsDGj3Eao6mbwCp8k&e=3D From nobody Tue Dec 18 00:13:30 2018 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 865201310BE; Tue, 18 Dec 2018 00:13:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Stiemerling To: Cc: v6ops@ietf.org, ietf@ietf.org, draft-ietf-v6ops-transition-ipv4aas.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154512080848.19310.17222140059063867521@ietfa.amsl.com> Date: Tue, 18 Dec 2018 00:13:28 -0800 Archived-At: Subject: [v6ops] Tsvart last call review of draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 08:13:29 -0000 Reviewer: Martin Stiemerling Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. General issues: - I have an issue with using RFC 2119 language in informative RFCs, as it is unclear what normative language means in informative documents. However, I understand that there is legacy from older documents in particular, but not limited to, RFC 7084. - The document is in parts hard to read, even for someone who has a background in IPv4/IPv6 transition. E.g. Section 1, 2nd paragraph, about what IP version is used where. A figure could help here. Issues: - Remove the DEFAULT word and replace it with default. It is very confusing to add capital letters normative language here. - Section 5: UPnP This section is posing requirements in an IETF document that incorporates non-IETF standards for a matter that is solely a recommendation. Can this be MUST at all? - Section 6: Code Considerations This section is a collection of unfounded points without any hard proof that the numbers are correct and tangible. Either there is a hard example on required changes and added code size or remove it. This is an engineering document and not a marketing document, isn't it? Thanks, Martin Stiemerling From nobody Tue Dec 18 01:13:26 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4310C1310B8; Tue, 18 Dec 2018 01:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVIZHxRkTaLt; Tue, 18 Dec 2018 01:13:15 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDFD130E66; Tue, 18 Dec 2018 01:13:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1545124392; x=1545729192; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=/rKgz28t5iudjllh7voBsMFnbow8RIFuypCkuqgwIgo=; b=W3eh6Ksp8M3uv obl2G/BksyJxhpQdlqdKG/aOEzwV8Szh1eaQ1sDLVpGJAfTb+OnuJStFY5wstGDR Ilzlo1iwy/4ZrCaVAkuZS7AKibs3YnCYhyAjNkW0dDtEyRSHccKhB3k2dPlz1U4D s4IQJRXXdoHneUld8I4fcARSr2knwc= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 18 Dec 2018 10:13:12 +0100 X-Spam-Processed: mail.consulintel.es, Tue, 18 Dec 2018 10:13:11 +0100 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006075533.msg; Tue, 18 Dec 2018 10:13:10 +0100 X-MDRemoteIP: 2001:470:1f09:495:50ee:6337:e540:4ee X-MDHelo: [10.10.10.139] X-MDArrival-Date: Tue, 18 Dec 2018 10:13:10 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=189008127c=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Tue, 18 Dec 2018 10:13:06 +0100 From: JORDI PALET MARTINEZ To: Martin Stiemerling , CC: , , Message-ID: <793BA514-42DC-40C3-86FD-618EB1D3590E@consulintel.es> Thread-Topic: [v6ops] Tsvart last call review of draft-ietf-v6ops-transition-ipv4aas-11 References: <154512080848.19310.17222140059063867521@ietfa.amsl.com> In-Reply-To: <154512080848.19310.17222140059063867521@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Tsvart last call review of draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 09:13:19 -0000 Hi Martin, Thanks for your review! I'm working today in a new version including the comments from the SECDIR, = OPSDIR and RTGDIR, so definitively will take care as well of your own comme= nts. Responses below, in-line. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Martin Stiemerling Fecha: martes, 18 de diciembre de 2018, 9:13 Para: CC: , , Asunto: [v6ops] Tsvart last call review of draft-ietf-v6ops-transition-ipv4= aas-11 Reviewer: Martin Stiemerling Review result: Ready with Issues =20 This document has been reviewed as part of the transport area review te= am's ongoing effort to review key IETF documents. These comments were writte= n primarily for the transport area directors, but are copied to the docum= ent's authors and WG to allow them to address any issues raised and also to t= he IETF discussion list for information. =20 When done at the time of IETF Last Call, the authors should consider th= is review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. =20 General issues: - I have an issue with using RFC 2119 language in informative RFCs, as = it is unclear what normative language means in informative documents. However, I unde= rstand that there is legacy from older documents in particular, but not limite= d to, RFC 7084. I think if we accepted this format, which in my opinion, even in an informa= tive RFC, is very clarifying about what is expected from an implementor of = this document, should not change our view now, unless we decide to review t= his in all the documents and from now on. In our case we have a "Special No= te" in the section title, to remark it. =20 - The document is in parts hard to read, even for someone who has a bac= kground in IPv4/IPv6 transition. E.g. Section 1, 2nd paragraph, about what IP vers= ion is used where. A figure could help here.=20 Good point, definitively will include a small figure. =20 Issues:=20 - Remove the DEFAULT word and replace it with default. It is very confu= sing to add capital letters normative language here.=20 As we have defined the "DEFAULT" word in the requirements language as well,= I think it is a correct usage, in order to make it easy to differentiate i= t from other usages of "default" across the document. =20 - Section 5: UPnP =20 This section is posing requirements in an IETF document that incorporat= es non-IETF standards for a matter that is solely a recommendation. Can this be MUS= T at all?=20 Not exactly, we are defining how the CE should react in a specific situatio= n, but in my understanding, this is not changing the UPnP specifications. = We had long debates on this in v6ops before reaching consensus this concret= e text. =20 - Section 6: Code Considerations This section is a collection of unfounded points without any hard proof= that the numbers are correct and tangible. Either there is a hard example on req= uired changes and added code size or remove it. This is an engineering docume= nt and not a marketing document, isn't it? I guess you meant here section 7. This is based on practical experience wit= h OpenWRT and with co-authors (vendors), so very tangible, and it can be co= nfirmed if you look at the source code. I don't think is right to have refe= rences to each of the code pieces for each transition mechanism and how the= y share "code parts", it will become a long document. Instead there is refe= rence to the OpenWRT page with all the packages which allows to check exact= code size if you start adding one or several mechanisms. =20 Thanks, =20 Martin Stiemerling =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Dec 26 09:46:46 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5102F131149 for ; Wed, 26 Dec 2018 09:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UG-ORJlpDjKT for ; Wed, 26 Dec 2018 09:46:40 -0800 (PST) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 2B6FD131148 for ; Wed, 26 Dec 2018 09:46:40 -0800 (PST) Received: by mail-wm1-x334.google.com with SMTP id m1so15025783wml.2 for ; Wed, 26 Dec 2018 09:46:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x1wVI48a2KlLDgqJbje1APrQ2gIeO+tC9Q5vErrZtX4=; b=YHe9M1KsAEqPISI9z54+F/rhHGS3pK2Hezrd5HjjpgmaEbhb9ZvhHn12QyP79jD+qs 4YKlypo1rqFvmyFloW9r8QIJx8lwoC5hCtBh5eKjk7NbvDc6omCRZnM7d4F+jYUi2dXb 7Gl4uOLOPn+3HhRhm3c+ogW0ixo6gNjiu6VABnXw4EKgnkExrda2V0GJBQkVvUUwOHzq +HOtEGLY8uvhNS4/Rqa+3bt9FbmOB2Y0KX3JgEXkFE2qoJW2/ki/Sj3/lyVfd7KMIzAL ILs7KnmWBHfx7gIq7pMB724hAkSJd6sJvWBQAvPDtkN4X3H88s5qccswLRCUpUVDHUod FFgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x1wVI48a2KlLDgqJbje1APrQ2gIeO+tC9Q5vErrZtX4=; b=k5jj8CyCiEb6ievPJiwrnIJMOGZ1VYi0/wfDY7d0/dxhcbwPuoqDKHIDyMweJozcsO 8XNfpRhgNs7LmGm2LeFKCrl0My+sGnF04wzWROBpSTjATqoO45MQ7noD/ObnTLrMGLaZ mnHyp2wk3yETQWW8zkiIWaSmpGm6iTidZ8aM1Qv6n+eh7+uPSkp1+iCwO5rzB0GCQsHl g0fKMlLCW4P9jmGUDG0fi28bNtkXJcPE4azL8oOXBZ2z/bl78V6c2ll0qXWlbxEFQ+hg BWGVwnZspBxzczXPsjA5Ih90XiknGPEOqzRYYJeUWrozTK56pu0GIlEmDf8FOFNBx6Cg Tibg== X-Gm-Message-State: AA+aEWZr+Y+kcYY4hmcu+a5naRseU7qBl14GKTtsGL7wK2Di0yGFmWlE xZXEgvv/n96/5pLy5mGvJhkwgLpyGVCllpo3CTmuCA== X-Google-Smtp-Source: ALg8bN6eJJo5Yp3BQyyiyxWfpA5m5IZsVZVurFfYfwWuH+UHN1mQCKpbfBBh9Aymqcp3OjDKkWADzC29dXv4CrxujnU= X-Received: by 2002:a1c:f112:: with SMTP id p18mr17883473wmh.83.1545846398083; Wed, 26 Dec 2018 09:46:38 -0800 (PST) MIME-Version: 1.0 References: <154512080848.19310.17222140059063867521@ietfa.amsl.com> <793BA514-42DC-40C3-86FD-618EB1D3590E@consulintel.es> In-Reply-To: <793BA514-42DC-40C3-86FD-618EB1D3590E@consulintel.es> From: Warren Kumari Date: Wed, 26 Dec 2018 12:46:02 -0500 Message-ID: To: Jordi Palet Martinez Cc: Martin Stiemerling , tsv-art@ietf.org, IPv6 Operations , draft-ietf-v6ops-transition-ipv4aas.all@ietf.org Content-Type: multipart/alternative; boundary="0000000000006f7b2e057df069e9" Archived-At: Subject: Re: [v6ops] Tsvart last call review of draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2018 17:46:44 -0000 --0000000000006f7b2e057df069e9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [ - IETF@ (for clutter) ] On Tue, Dec 18, 2018 at 4:13 AM JORDI PALET MARTINEZ < jordi.palet@consulintel.es> wrote: > Hi Martin, > > Thanks for your review! > > I'm working today in a new version including the comments from the SECDIR= , > OPSDIR and RTGDIR, so definitively will take care as well of your own > comments. > Dear Jordi / Authors, Please let me know (LOUDLY, so I don't miss it!) once you've had a chance to address these.... W > > Responses below, in-line. > > Regards, > Jordi > > > > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de Martin Stiemerling < > mls.ietf@gmail.com> > Fecha: martes, 18 de diciembre de 2018, 9:13 > Para: > CC: , , < > draft-ietf-v6ops-transition-ipv4aas.all@ietf.org> > Asunto: [v6ops] Tsvart last call review of > draft-ietf-v6ops-transition-ipv4aas-11 > > Reviewer: Martin Stiemerling > Review result: Ready with Issues > > This document has been reviewed as part of the transport area review > team's > ongoing effort to review key IETF documents. These comments were > written > primarily for the transport area directors, but are copied to the > document's > authors and WG to allow them to address any issues raised and also to > the IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider > this > review as part of the last-call comments they receive. Please always = CC > tsv-art@ietf.org if you reply to or forward this review. > > General issues: > - I have an issue with using RFC 2119 language in informative RFCs, a= s > it is unclear > what normative language means in informative documents. However, I > understand > that there is legacy from older documents in particular, but not > limited to, RFC 7084. > > I think if we accepted this format, which in my opinion, even in an > informative RFC, is very clarifying about what is expected from an > implementor of this document, should not change our view now, unless we > decide to review this in all the documents and from now on. In our case w= e > have a "Special Note" in the section title, to remark it. > > - The document is in parts hard to read, even for someone who has a > background in > IPv4/IPv6 transition. E.g. Section 1, 2nd paragraph, about what IP > version is used > where. A figure could help here. > > Good point, definitively will include a small figure. > > Issues: > - Remove the DEFAULT word and replace it with default. It is very > confusing to add > capital letters normative language here. > > As we have defined the "DEFAULT" word in the requirements language as > well, I think it is a correct usage, in order to make it easy to > differentiate it from other usages of "default" across the document. > > - Section 5: UPnP > > This section is posing requirements in an IETF document that > incorporates non-IETF > standards for a matter that is solely a recommendation. Can this be > MUST at all? > > Not exactly, we are defining how the CE should react in a specific > situation, but in my understanding, this is not changing the UPnP > specifications. We had long debates on this in v6ops before reaching > consensus this concrete text. > > - Section 6: Code Considerations > This section is a collection of unfounded points without any hard > proof that the > numbers are correct and tangible. Either there is a hard example on > required > changes and added code size or remove it. This is an engineering > document and not > a marketing document, isn't it? > > I guess you meant here section 7. This is based on practical experience > with OpenWRT and with co-authors (vendors), so very tangible, and it can = be > confirmed if you look at the source code. I don't think is right to have > references to each of the code pieces for each transition mechanism and h= ow > they share "code parts", it will become a long document. Instead there is > reference to the OpenWRT page with all the packages which allows to check > exact code size if you start adding one or several mechanisms. > > Thanks, > > Martin Stiemerling > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --0000000000006f7b2e057df069e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[ - IETF@ (for clutter) ]


On Tue, Dec 18, 2018 at 4:13 AM JORDI PALET MARTINEZ &= lt;jordi.palet@consulintel.es= > wrote:
= Hi Martin,

Thanks for your review!

I'm working today in a new version including the comments from the SECD= IR, OPSDIR and RTGDIR, so definitively will take care as well of your own c= omments.

Dear Jordi / Authors,

Please l= et me know (LOUDLY, so I don't miss it!) once you've had a chance t= o address these....

W=C2=A0

=C2=A0

Responses below, in-line.

Regards,
Jordi



=EF=BB=BF-----Mensaje original-----
De: v6ops <v= 6ops-bounces@ietf.org> en nombre de Martin Stiemerling <mls.ietf@gmail.com>=
Fecha: martes, 18 de diciembre de 2018, 9:13
Para: <tsv-art@iet= f.org>
CC: <v6ops@ietf.org<= /a>>, <ietf@ietf.o= rg>, <draft-ietf-v6ops-transition-ipv4aas.all@ietf.org= >
Asunto: [v6ops] Tsvart last call review of draft-ietf-v6ops-transition-ipv4= aas-11

=C2=A0 =C2=A0 Reviewer: Martin Stiemerling
=C2=A0 =C2=A0 Review result: Ready with Issues

=C2=A0 =C2=A0 This document has been reviewed as part of the transport area= review team's
=C2=A0 =C2=A0 ongoing effort to review key IETF documents. These comments w= ere written
=C2=A0 =C2=A0 primarily for the transport area directors, but are copied to= the document's
=C2=A0 =C2=A0 authors and WG to allow them to address any issues raised and= also to the IETF
=C2=A0 =C2=A0 discussion list for information.

=C2=A0 =C2=A0 When done at the time of IETF Last Call, the authors should c= onsider this
=C2=A0 =C2=A0 review as part of the last-call comments they receive. Please= always CC
=C2=A0 =C2=A0 tsv-art= @ietf.org if you reply to or forward this review.

=C2=A0 =C2=A0 General issues:
=C2=A0 =C2=A0 - I have an issue with using RFC 2119 language in informative= RFCs, as it is unclear
=C2=A0 =C2=A0 what normative language means in informative documents. Howev= er, I understand
=C2=A0 =C2=A0 that there is legacy from older documents in particular, but = not limited to, RFC 7084.

I think if we accepted this format, which in my opinion, even in an informa= tive RFC, is very clarifying about what is expected from an implementor of = this document, should not change our view now, unless we decide to review t= his in all the documents and from now on. In our case we have a "Speci= al Note" in the section title, to remark it.

=C2=A0 =C2=A0 - The document is in parts hard to read, even for someone who= has a background in
=C2=A0 =C2=A0 IPv4/IPv6 transition. E.g. Section 1, 2nd paragraph, about wh= at IP version is used
=C2=A0 =C2=A0 where. A figure could help here.

Good point, definitively will include a small figure.

=C2=A0 =C2=A0 Issues:
=C2=A0 =C2=A0 - Remove the DEFAULT word and replace it with default. It is = very confusing to add
=C2=A0 =C2=A0 capital letters normative language here.

As we have defined the "DEFAULT" word in the requirements languag= e as well, I think it is a correct usage, in order to make it easy to diffe= rentiate it from other usages of "default" across the document.
=C2=A0 =C2=A0 - Section 5: UPnP

=C2=A0 =C2=A0 This section is posing requirements in an IETF document that = incorporates non-IETF
=C2=A0 =C2=A0 standards for a matter that is solely a recommendation. Can t= his be MUST at all?

Not exactly, we are defining how the CE should react in a specific situatio= n, but in my understanding,=C2=A0 this is not changing the UPnP specificati= ons. We had long debates on this in v6ops before reaching consensus this co= ncrete text.

=C2=A0 =C2=A0 - Section 6: Code Considerations
=C2=A0 =C2=A0 This section is a collection of unfounded points without any = hard proof that the
=C2=A0 =C2=A0 numbers are correct and tangible. Either there is a hard exam= ple on required
=C2=A0 =C2=A0 changes and added code size or remove it. This is an engineer= ing document and not
=C2=A0 =C2=A0 a marketing document, isn't it?

I guess you meant here section 7. This is based on practical experience wit= h OpenWRT and with co-authors (vendors), so very tangible, and it can be co= nfirmed if you look at the source code. I don't think is right to have = references to each of the code pieces for each transition mechanism and how= they share "code parts", it will become a long document. Instead= there is reference to the OpenWRT page with all the packages which allows = to check exact code size if you start adding one or several mechanisms.

=C2=A0 =C2=A0 Thanks,

=C2=A0 =C2=A0 =C2=A0 Martin Stiemerling


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 v6ops mailing list
=C2=A0 =C2=A0 v6ops@iet= f.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/v6o= ps




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.





--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div>
--0000000000006f7b2e057df069e9-- From nobody Wed Dec 26 09:57:38 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7940F13115B; Wed, 26 Dec 2018 09:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhwz3tMxlDu0; Wed, 26 Dec 2018 09:57:33 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3BDB131158; Wed, 26 Dec 2018 09:57:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1545847049; x=1546451849; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type; bh=+Mpkhq4fR/9Kar4PPencEl okHulFq41YmJGL78w/wUw=; b=hg2mS46yqAKP6XlOow60Trj56TBEMYNOM/y8FR /itrKtVqde5QQjL0A2vq7jQHdVhePAyTOJYCaXBVW86p6RJr9z9xwpZrYexEKQwh 6v3Mb0HxhY64iduKRuTqs3iXxgrpgexwWVBwQoiLBBRWKH81Zzv0oOn7BWZv8gac 4gaH8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Wed, 26 Dec 2018 18:57:28 +0100 X-Spam-Processed: mail.consulintel.es, Wed, 26 Dec 2018 18:57:28 +0100 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006086776.msg; Wed, 26 Dec 2018 18:57:27 +0100 X-MDRemoteIP: 2001:470:1f09:495:2db0:3a81:617d:58b1 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Wed, 26 Dec 2018 18:57:27 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=189834e10e=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Wed, 26 Dec 2018 18:57:23 +0100 From: JORDI PALET MARTINEZ To: Warren Kumari CC: Martin Stiemerling , , IPv6 Operations , Message-ID: <8CC6AA48-0536-4978-AE8A-6C07649A2A96@consulintel.es> Thread-Topic: [v6ops] Tsvart last call review of draft-ietf-v6ops-transition-ipv4aas-11 References: <154512080848.19310.17222140059063867521@ietfa.amsl.com> <793BA514-42DC-40C3-86FD-618EB1D3590E@consulintel.es> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3628695443_1833804634" Archived-At: Subject: Re: [v6ops] Tsvart last call review of draft-ietf-v6ops-transition-ipv4aas-11 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2018 17:57:36 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3628695443_1833804634 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Warren, =20 Sorry, been too busy the last 10 days. I really hope to upload a new versio= n tomorrow. Regards, Jordi =20 =20 =20 De: Warren Kumari Fecha: mi=C3=A9rcoles, 26 de diciembre de 2018, 18:46 Para: Jordi Palet Martinez CC: Martin Stiemerling , , IPv6 Opera= tions , Asunto: Re: [v6ops] Tsvart last call review of draft-ietf-v6ops-transition-= ipv4aas-11 =20 [ - IETF@ (for clutter) ] =20 =20 On Tue, Dec 18, 2018 at 4:13 AM JORDI PALET MARTINEZ wrote: Hi Martin, Thanks for your review! I'm working today in a new version including the comments from the SECDIR, = OPSDIR and RTGDIR, so definitively will take care as well of your own comme= nts. =20 Dear Jordi / Authors, =20 Please let me know (LOUDLY, so I don't miss it!) once you've had a chance t= o address these.... =20 W=20 =20 =20 Responses below, in-line. Regards, Jordi =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Martin Stiemerling Fecha: martes, 18 de diciembre de 2018, 9:13 Para: CC: , , Asunto: [v6ops] Tsvart last call review of draft-ietf-v6ops-transition-ipv4= aas-11 Reviewer: Martin Stiemerling Review result: Ready with Issues This document has been reviewed as part of the transport area review te= am's ongoing effort to review key IETF documents. These comments were writte= n primarily for the transport area directors, but are copied to the docum= ent's authors and WG to allow them to address any issues raised and also to t= he IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider th= is review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. General issues: - I have an issue with using RFC 2119 language in informative RFCs, as = it is unclear what normative language means in informative documents. However, I unde= rstand that there is legacy from older documents in particular, but not limite= d to, RFC 7084. I think if we accepted this format, which in my opinion, even in an informa= tive RFC, is very clarifying about what is expected from an implementor of = this document, should not change our view now, unless we decide to review t= his in all the documents and from now on. In our case we have a "Special No= te" in the section title, to remark it. - The document is in parts hard to read, even for someone who has a bac= kground in IPv4/IPv6 transition. E.g. Section 1, 2nd paragraph, about what IP vers= ion is used where. A figure could help here.=20 Good point, definitively will include a small figure. Issues:=20 - Remove the DEFAULT word and replace it with default. It is very confu= sing to add capital letters normative language here.=20 As we have defined the "DEFAULT" word in the requirements language as well,= I think it is a correct usage, in order to make it easy to differentiate i= t from other usages of "default" across the document. - Section 5: UPnP This section is posing requirements in an IETF document that incorporat= es non-IETF standards for a matter that is solely a recommendation. Can this be MUS= T at all?=20 Not exactly, we are defining how the CE should react in a specific situatio= n, but in my understanding, this is not changing the UPnP specifications. = We had long debates on this in v6ops before reaching consensus this concret= e text. - Section 6: Code Considerations This section is a collection of unfounded points without any hard proof= that the numbers are correct and tangible. Either there is a hard example on req= uired changes and added code size or remove it. This is an engineering docume= nt and not a marketing document, isn't it? I guess you meant here section 7. This is based on practical experience wit= h OpenWRT and with co-authors (vendors), so very tangible, and it can be co= nfirmed if you look at the source code. I don't think is right to have refe= rences to each of the code pieces for each transition mechanism and how the= y share "code parts", it will become a long document. Instead there is refe= rence to the OpenWRT page with all the packages which allows to check exact= code size if you start adding one or several mechanisms. Thanks, Martin Stiemerling _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. =20 --=20 I don't think the execution is relevant when it was obviously a bad idea in= the first place. This is like putting rabid weasels in your pants, and later expressing regr= et at having chosen those particular rabid weasels and that pair of pants. ---maf ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3628695443_1833804634 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Warren,

 

Sorry, been too busy the last 10 days. I really hope to upload a new= version tomorrow.


Regards,

Jordi=

<= span lang=3DEN-US style=3D'font-size:10.5pt;color:black;mso-fareast-languag= e:EN-US'> 

 

<= p class=3DMsoNormal> 

De: Warren Kumari <warren@kuma= ri.net>
Fecha: mi=C3=A9rcoles, 26 de diciembre de 2018, 18:46<= br>Para: Jordi Palet Martinez <jordi.palet@consulintel.es>
= CC: Martin Stiemerling <mls.ietf@gmail.com>, <tsv-art@ietf.= org>, IPv6 Operations <v6ops@ietf.org>, <draft-ietf-v6ops-trans= ition-ipv4aas.all@ietf.org>
Asunto: Re: [v6ops] Tsvart last ca= ll review of draft-ietf-v6ops-transition-ipv4aas-11

 

[ - IETF@ (for clutter) ]=

 

 

On Tue, = Dec 18, 2018 at 4:13 AM JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:

Hi Martin,

Thanks for your review!=

I'm working today in a new version including the comments from the = SECDIR, OPSDIR and RTGDIR, so definitively will take care as well of your o= wn comments.

 

Dear Jordi / Authors,

 

Pl= ease let me know (LOUDLY, so I don't miss it!) once you've had a chance to = address these....

<= o:p> 

W <= /o:p>

 

 


Responses below, in-line.

Regards,
Jordi



=EF=BB= =BF-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de= Martin Stiemerling <mls.ietf@gmail.com>
Fecha: martes, 18 de diciembre de 2018, = 9:13
Para: <tsv= -art@ietf.org>
CC: <v6ops@ietf.org>, <ietf@ietf.org>, <draft-ietf-v6ops-tran= sition-ipv4aas.all@ietf.org>
Asunto: [v6ops] Tsvart last call rev= iew of draft-ietf-v6ops-transition-ipv4aas-11

    Reviewer= : Martin Stiemerling
    Review result: Ready with Issues
<= br>    This document has been reviewed as part of the transport a= rea review team's
    ongoing effort to review key IETF docume= nts. These comments were written
    primarily for the transpo= rt area directors, but are copied to the document's
    author= s and WG to allow them to address any issues raised and also to the IETF    discussion list for information.

    When d= one at the time of IETF Last Call, the authors should consider this
&nbs= p;   review as part of the last-call comments they receive. Please alw= ays CC
    tsv-art@ietf.org if you reply to or forward this review.

&nbs= p;   General issues:
    - I have an issue with using RFC= 2119 language in informative RFCs, as it is unclear
    what = normative language means in informative documents. However, I understand    that there is legacy from older documents in particular, but= not limited to, RFC 7084.

I think if we accepted this format, which= in my opinion, even in an informative RFC, is very clarifying about what i= s expected from an implementor of this document, should not change our view= now, unless we decide to review this in all the documents and from now on.= In our case we have a "Special Note" in the section title, to re= mark it.

    - The document is in parts hard to read, even= for someone who has a background in
    IPv4/IPv6 transition.= E.g. Section 1, 2nd paragraph, about what IP version is used
  &nb= sp; where. A figure could help here.

Good point, definitively will = include a small figure.

    Issues:
    - Re= move the DEFAULT word and replace it with default. It is very confusing to = add
    capital letters normative language here.

As we= have defined the "DEFAULT" word in the requirements language as = well, I think it is a correct usage, in order to make it easy to differenti= ate it from other usages of "default" across the document.
    - Section 5: UPnP

    This section is posin= g requirements in an IETF document that incorporates non-IETF
  &nb= sp; standards for a matter that is solely a recommendation. Can this be MUS= T at all?

Not exactly, we are defining how the CE should react in a= specific situation, but in my understanding,  this is not changing th= e UPnP specifications. We had long debates on this in v6ops before reaching= consensus this concrete text.

    - Section 6: Code Consi= derations
    This section is a collection of unfounded points= without any hard proof that the
    numbers are correct and t= angible. Either there is a hard example on required
    change= s and added code size or remove it. This is an engineering document and not=
    a marketing document, isn't it?

I guess you meant = here section 7. This is based on practical experience with OpenWRT and with= co-authors (vendors), so very tangible, and it can be confirmed if you look at= the source code. I don't think is right to have references to each of the = code pieces for each transition mechanism and how they share "code par= ts", it will become a long document. Instead there is reference to the= OpenWRT page with all the packages which allows to check exact code size i= f you start adding one or several mechanisms.

    Thanks,<= br>
      Martin Stiemerling


    ___= ____________________________________________
    v6ops mailing= list
    = v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6= ops




**********************************************IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information w= hich may be privileged or confidential. The information is intended to be f= or the exclusive use of the individual(s) named above and further non-expli= cilty authorized disclosure, copying, distribution or use of the contents o= f this information, even if partially, including attached files, is strictl= y prohibited and will be considered a criminal offense. If you are not the = intended recipient be aware that any disclosure, copying, distribution or u= se of the contents of this information, even if partially, including attach= ed files, is strictly prohibited, will be considered a criminal offense, so= you must reply to the original sender to inform about this communication a= nd delete it.



--


*************************= *********************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3628695443_1833804634-- From nobody Thu Dec 27 09:20:12 2018 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4159112008F; Thu, 27 Dec 2018 09:20:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <154593121021.11890.6631728006461726843@ietfa.amsl.com> Date: Thu, 27 Dec 2018 09:20:10 -0800 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-12.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2018 17:20:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-12.txt Pages : 24 Date : 2018-12-27 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or by vendors who sell through the retail market. Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" (RFC7084) in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS). This is necessary because there aren't sufficient IPv4 addresses available for every possible customer/device. However, devices or applications in the customer LANs (Local Area Networks) may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services at the Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-12 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4aas-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-transition-ipv4aas-12 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 Sat Dec 29 19:39:06 2018 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B57A130E6D; Thu, 27 Dec 2018 09:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RwlwJzBqP5A; Thu, 27 Dec 2018 09:25:50 -0800 (PST) Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679E8130DF3; Thu, 27 Dec 2018 09:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1545931546; x=1546536346; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=vCqnTrb61ZofF8b9ykCmX 6GiiURd8Jz64V7kl0oTXNQ=; b=WE2Z1xgc1L6wSbYjD5AKQqSYmvhuAy4lM/T1e JuEXGK1NrDk83TaR9IGyXTU3i12zGlq8ytFeuEV+AjQel18Um/S+loCeCDk46Gcr BfN7+Jih+Ci9DkOYO8lS+CJPiQroT9yMzLn3KwbKDAA2IL3RJ6lGYZkCwzztPKzs drqFmA= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 27 Dec 2018 18:25:46 +0100 X-Spam-Processed: mail.consulintel.es, Thu, 27 Dec 2018 18:25:46 +0100 Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006087948.msg; Thu, 27 Dec 2018 18:25:44 +0100 X-MDRemoteIP: 2001:470:1f09:495:9d7f:6443:49a1:e932 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Thu, 27 Dec 2018 18:25:44 +0100 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1899b4cfc8=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es User-Agent: Microsoft-MacOutlook/10.10.5.181209 Date: Thu, 27 Dec 2018 18:25:42 +0100 From: JORDI PALET MARTINEZ To: IPv6 Operations , Warren Kumari , Ron Bonica , Fred Baker CC: Dan Romascanu , , Christian Huitema , , Daniele Ceccarelli , "rtg-dir@ietf.org" , Martin Stiemerling , Message-ID: <1F8182C0-244B-4EF8-B5FD-BFA83914F2F9@consulintel.es> Thread-Topic: New Version Notification for draft-ietf-v6ops-transition-ipv4aas-12.txt Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Sat, 29 Dec 2018 19:39:05 -0800 Subject: Re: [v6ops] New Version Notification for draft-ietf-v6ops-transition-ipv4aas-12.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2018 17:25:53 -0000 Hi all, Considering the review comments from ops, sec, rtg and tsv, we just complet= ed a new version: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/?inclu= de_text=3D1 Thanks! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Fecha: jueves, 27 de diciembre de 2018, 18:20 Para: Masanobu Kawashima , "Hans M.-H. Liu" , Jordi Palet Martinez ,= Jordi Palet , Hans Liu Asunto: New Version Notification for draft-ietf-v6ops-transition-ipv4aas-12= .txt =20 A new version of I-D, draft-ietf-v6ops-transition-ipv4aas-12.txt has been successfully submitted by Jordi Palet Martinez and posted to t= he IETF repository. =20 Name: draft-ietf-v6ops-transition-ipv4aas Revision: 12 Title: Requirements for IPv6 Customer Edge Routers to Support IPv4 Con= nectivity as-a-Service Document date: 2018-12-27 Group: v6ops Pages: 24 URL: https://www.ietf.org/internet-drafts/draft-ietf-v6ops-t= ransition-ipv4aas-12.txt Status: https://datatracker.ietf.org/doc/draft-ietf-v6ops-trans= ition-ipv4aas/ Htmlized: https://tools.ietf.org/html/draft-ietf-v6ops-transition= -ipv4aas-12 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-= transition-ipv4aas Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-tr= ansition-ipv4aas-12 =20 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or by vendors who sell through the retail market. =20 Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" (RFC7084) in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS). Thi= s is necessary because there aren't sufficient IPv4 addresses availabl= e for every possible customer/device. However, devices or application= s in the customer LANs (Local Area Networks) may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services at the Internet. =20 = =20 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 The IETF Secretariat =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.