Re: [auth48] Please answer to Rebecca -- Fwd: AUTH48: RFC-to-be 9313 <draft-ietf-v6ops-transition-comparison-04> for your review

Jordi Palet Martínez <jordi.palet@theipv6company.com> Thu, 06 October 2022 17:09 UTC

Return-Path: <prvs=1278fee405=jordi.palet@theipv6company.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8AAC14F746; Thu, 6 Oct 2022 10:09:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.004
X-Spam-Level:
X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=theipv6company.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zMhqPegimCJ; Thu, 6 Oct 2022 10:09:08 -0700 (PDT)
Received: from consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id C2A44C152573; Thu, 6 Oct 2022 10:09:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=theipv6company.com; s=MDaemon; t=1665076142; x=1665680942; i=jordi.palet@theipv6company.com; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type; bh=amIFdaIlvNiV/qaOifJ48l 24zN+vLB+YLHMV8fjUFls=; b=kgZgeDCAYzA1QidEHy0kfaOHk8RK9IV6noR9Ez 0mH7fItoH6kyKRs9/roqZ+eHJcxwgXRoW+FfizwoyzpOnDlF7k0iZ/BFdtjz4vyp hrkmwLDG3u7FO9XGCiXWB7/C1fQL8QGCuLPHACvcCJ3KTQDIqOkUKi6+lxa7aEC5 cw9+k=
X-MDAV-Result: clean
X-MDAV-Processed: consulintel.es, Thu, 06 Oct 2022 19:09:02 +0200
X-Spam-Processed: consulintel.es, Thu, 06 Oct 2022 19:09:01 +0200
Received: from [45.6.255.156] by consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50001040191.msg; Thu, 06 Oct 2022 19:08:56 +0200
X-MDRemoteIP: 10.8.10.10
X-MDHelo: [45.6.255.156]
X-MDArrival-Date: Thu, 06 Oct 2022 19:08:56 +0200
X-Authenticated-Sender: jordi.palet@theipv6company.com
X-Return-Path: prvs=1278fee405=jordi.palet@theipv6company.com
X-Envelope-From: jordi.palet@theipv6company.com
User-Agent: Microsoft-MacOutlook/16.65.22091101
Date: Thu, 06 Oct 2022 13:08:37 -0400
From: Jordi Palet Martínez <jordi.palet@theipv6company.com>
To: Rebecca VanRheenen <rvanrheenen@amsl.com>, auth48archive@rfc-editor.org, Warren Kumari <warren@kumari.net>, rbonica@juniper.net, v6ops-chairs@ietf.org, v6ops-ads@ietf.org, RFC Editor <rfc-editor@rfc-editor.org>
CC: "lee asgard.org" <lee@asgard.org>, Gabor LENCSE <lencse@hit.bme.hu>, richard.patterson@sky.uk, ian.farrer@telekom.de
Message-ID: <82E86021-0EF5-4124-9F86-D47C95A65E4F@theipv6company.com>
Thread-Topic: Please answer to Rebecca -- Fwd: AUTH48: RFC-to-be 9313 <draft-ietf-v6ops-transition-comparison-04> for your review
References: <F92EB604-411C-4512-B4E8-51EF05F3B817@amsl.com> <9d2b1b28-0649-7ff8-e0be-858fa8e7a944@hit.bme.hu> <1908184456.109451.1665075331075@webmail-oxcs.networksolutionsemail.com>
In-Reply-To: <1908184456.109451.1665075331075@webmail-oxcs.networksolutionsemail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3747906529_2218212046"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/2k_vq4fUfwaY5rXTp5vyna1lUcY>
Subject: Re: [auth48] Please answer to Rebecca -- Fwd: AUTH48: RFC-to-be 9313 <draft-ietf-v6ops-transition-comparison-04> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Oct 2022 17:09:13 -0000

Resending, as I see not all the relevant contacts aren’t in copy.

 

 

 

Regards,

Jordi

@jordipalet

 

 

El 6/10/22, 12:56, "lee asgard.org" <lee@asgard.org> escribió:

 

Sorry, I've been traveling a lot and failed to check this email account. 

  

Looks good to me! 

  

Lee 

On 09/22/2022 10:58 PM EDT Gabor LENCSE <lencse@hit.bme.hu> wrote: 

  

  

Dear Co-Authors,

You may be overwhelmed by the lot of long e-mails about our draft. That's why I write you that Rebecca expect all of you to approve the final version.

Please do so at your earliest convenience -- or report an error, if you find one. :-) 

  

Best regards, 

  

Gábor 
-------- Forwarded Message -------- 

Subject:Re: AUTH48: RFC-to-be 9313 <draft-ietf-v6ops-transition-comparison-04> for your review
Date:Thu, 22 Sep 2022 13:46:09 -0700
From:Rebecca VanRheenen <rvanrheenen@amsl.com>
To:Gabor LENCSE <lencse@hit.bme.hu>, Warren Kumari <warren@kumari.net>, richard.patterson@sky.uk, jordi.palet@theipv6company.com, lee@asgard.org, <ian.farrer@telekom.de> <ian.farrer@telekom.de>
CC:RFC Editor <rfc-editor@rfc-editor.org>, v6ops-ads@ietf.org, v6ops-chairs@ietf.org, rbonica@juniper.net, auth48archive@rfc-editor.org



Hi Gábor and Warren, 

We deleted “NAPT44” in Section 4.1.1 as requested by Gábor. We also noted Warren’s approval of this change on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9313). Links to the updated files are below. 

All of our questions have now been addressed. Please contact us with any further updates or with your approval of the document in its current form. We will await approvals from each author prior to moving forward in the publication process. 

__________________ 

Updated XML file: https://www.rfc-editor.org/authors/rfc9313.xml 

Updated output files: 
https://www.rfc-editor.org/authors/rfc9313.txt 
https://www.rfc-editor.org/authors/rfc9313.html 
https://www.rfc-editor.org/authors/rfc9313.pdf 

Diff file showing all changes made during AUTH48: 
https://www.rfc-editor.org/authors/rfc9313-auth48diff.html 
Diff files showing all changes: 
https://www.rfc-editor.org/authors/rfc9313-diff.html https://www.rfc-editor.org/authors/rfc9313-rfcdiff.html (side-by-side diff) 
https://www.rfc-editor.org/authors/rfc9313-alt-diff.html (this comprehensive diff makes viewing moved text easier) 

Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC. 

Please contact us with any further updates or with your approval of the document in its current form. We will await approvals from each author prior to moving forward in the publication process. 

For the AUTH48 status of this document, please see: 
https://www.rfc-editor.org/auth48/rfc9313 

Thank you, 

RFC Editor/rv 





On Sep 21, 2022, at 8:03 PM, Gabor LENCSE <lencse@hit.bme.hu> wrote: 

Dear Warren, 

Thank you very much for your approval. 

And my apologies for noticing it so late. 

Best regards, 

Gábor 

On 9/22/2022 10:55 AM, Warren Kumari wrote: 






On Wed, Sep 21, 2022 at 1:41 PM, Gabor LENCSE <lencse@hit.bme.hu> wrote: 
Dear Rebecca, 

All corrections are OK for me. 
However, I have just noticed a bug in the text above Table 3. The text is: 

"Presence or absence of NAPT44 per-flow state in the operator network." 

But NAPT44 is just WRONG here. NAPT44 indeed happens at the customer side in the case of the three other solutions. But the stateful translation that happens in the operator network is NOT NAPT44. (In the case of 464XLAT it is stateful NAT64. In the case of DS-Lite it looks like NAPT44, but also the softwire ID is a part of the tuple.) Anyway, the exact type of the translation is not interesting, the point is that there is a per-flow state. 

Could you just remove the word "NAPT44"? 

OLD: 

Presence or absence of NAPT44 per-flow state in the operator network. 

NEW: 

"Presence or absence of per-flow state in the operator network." 

Maybe this type of correction is not simply editorial, and thus it needs an AD approval? 

Warren, could please you approve the above change? 


Yes, this seems fine to me / approved. 

I do not think that it changes WG consensus, etc. 

W 


Best regards, 

Gábor 

On 9/21/2022 12:35 PM, Rebecca VanRheenen wrote: 


Hi Gábor, 

We have updated the document per your latest email. The list of files is below. We have two further comments: 





38) <!-- [rfced] Please confirm that this reference entry is correct. We ask 
because we do not see the title on the URL provided, though we do see a 
few instances of "vpp". Also, the original text that contains the [vpp] 
citation mentions "VPP/ 

fd.io 

", which we do not see at the URL. Note that 
the URL provided redirects to 
https://gerrit.fd.io/r/admin/repos/ 

(a 
repository of some sort). Please review and let us know if any updates 
are needed. 

Original: 
* VPP/ 

fd.io 

[vpp] (MAP-BR, lwAFTR, CGN, CLAT, NAT64). 
... 
[vpp] "VPP Implementations of IPv6-only with IPv4aaS", 2022, 

<https://gerrit.fd.io/r/#/admin/projects/> 

 



**********************************************
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.