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

[Gabor LENCSE <[e-mail]>]

Dear Rebecca,

Thank you very much for all your work!

I mention the following thing just because you did a lot of efforts to 
make the document perfect and consistent.

I have found the reference [NAT-SUPP] in the html version as follows:

Stewart, R. R., Tüxen, M., and I. Ruengeler, "Stream Control 
Transmission Protocol (SCTP) Network Address Translation Support", Work 
in Progress, Internet-Draft, draft-ietf-tsvwg-natsupp-23, 25 October 
2021, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-natsupp-23>.

Here the name "T*ü*xen" has a non-ASCII character, but Rüngeler is 
written as "R*ue*ngeler".

Since the non-ASCII characters were replaced with the approximate ASCII 
characters in all other cases (like: Gábor --> Gabor, Répás --> Repas, 
etc.) perhaps, the same method should be followed here, too.

But it is really very editorial, I am OK with the RFC as it is now. :-)

Best regards,

Gábor

On 9/23/2022 5:46 AM, Rebecca VanRheenen wrote:
> 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 (seehttps://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<[e-mail]>  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<[e-mail]>  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/>
>