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

[Jordi Palet Martínez <[e-mail]>]

Good caches tks!

 
 
Regards,
Jordi
@jordipalet
 

El 25/9/22, 12:16, "[e-mail]" <[e-mail]> escribió:

    Hi,

    Many thanks for your work on this. I have a few small edits. Please see below.

    Best regards,
    Ian

    Header:
    "Authors:" Should be on its own line so that all the authors can be listed without the need to wrap. (e.g., https://www.rfc-editor.org/rfc/rfc8792.pdf) 

    Section 2.1
    OLD:
    In general, keeping state in devices close to the end-user network (i.e., at the CE (Customer Edge) router) is not perceived as problematic as keeping state in the operator's network.

    NEW:
    In general, keeping state in devices close to the end-user network (i.e., at the CE (Customer Edge) router) is not perceived to be as problematic as keeping state in the operator's network.

    Section 2.1
    OLD:
    Note: In mobile networks, CLAT is commonly implemented in the user equipment (UE) or smartphone; please refer to Figure 2 in [RFC6877].

    NEW:
    Note: In mobile networks, the CLAT is commonly implemented in the user equipment (UE) or smartphone; please refer to Figure 2 in [RFC6877].

    Section 5.
    OLD:
    • Measurements procedures for Packet Delay Variation (PDV) and Inter-Packet Delay Variation (IPDV) measurements

    NEW:
    • Measurement procedures for Packet Delay Variation (PDV) and Inter-Packet Delay Variation (IPDV) measurements

    Acknowledgements:
    OLD:
    Nick Hilliard, Joel Jaeggli, Kristian McColm, Nick Hilliard, Tom Petch, Yannis Nikolopoulos,

    NEW:
    Nick Hilliard, Joel Jaeggli, Kristian McColm, Tom Petch, Yannis Nikolopoulos,



    On 13.09.22, 22:46, "[e-mail]" <[e-mail]> wrote:

        *****IMPORTANT*****

        Updated 2022/09/13

        RFC Author(s):
        --------------

        Instructions for Completing AUTH48

        Your document has now entered AUTH48.  Once it has been reviewed and 
        approved by you and all coauthors, it will be published as an RFC.  
        If an author is no longer available, there are several remedies 
        available as listed in the FAQ (https://www.rfc-editor.org/faq/).

        You and you coauthors are responsible for engaging other parties 
        (e.g., Contributors or Working Group) as necessary before providing 
        your approval.

        Planning your review 
        ---------------------

        Please review the following aspects of your document:

        *  RFC Editor questions

           Please review and resolve any questions raised by the RFC Editor 
           that have been included in the XML file as comments marked as 
           follows:

           <!-- [rfced] ... -->

           These questions will also be sent in a subsequent email.

        *  Changes submitted by coauthors 

           Please ensure that you review any changes submitted by your 
           coauthors.  We assume that if you do not speak up that you 
           agree to changes submitted by your coauthors.

        *  Content 

           Please review the full content of the document, as this cannot 
           change once the RFC is published.  Please pay particular attention to:
           - IANA considerations updates (if applicable)
           - contact information
           - references

        *  Copyright notices and legends

           Please review the copyright notice and legends as defined in
           RFC 5378 and the Trust Legal Provisions 
           (TLP – https://trustee.ietf.org/license-info/).

        *  Semantic markup

           Please review the markup in the XML file to ensure that elements of  
           content are correctly tagged.  For example, ensure that <sourcecode> 
           and <artwork> are set correctly.  See details at 
           <https://authors.ietf.org/rfcxml-vocabulary>.

        *  Formatted output

           Please review the PDF, HTML, and TXT files to ensure that the 
           formatted output, as generated from the markup in the XML file, is 
           reasonable.  Please note that the TXT will have formatting 
           limitations compared to the PDF and HTML.


        Submitting changes
        ------------------

        To submit changes, please reply to this email using ‘REPLY ALL’ as all 
        the parties CCed on this message need to see your changes. The parties 
        include:

           *  your coauthors

           *  [e-mail] (the RPC team)

           *  other document participants, depending on the stream (e.g., 
              IETF Stream participants are your working group chairs, the 
              responsible ADs, and the document shepherd).

           *  [e-mail], which is a new archival mailing list 
              to preserve AUTH48 conversations; it is not an active discussion 
              list:

             *  More info:
                https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc

             *  The archive itself:
                https://mailarchive.ietf.org/arch/browse/auth48archive/

             *  Note: If only absolutely necessary, you may temporarily opt out 
                of the archiving of messages (e.g., to discuss a sensitive matter).
                If needed, please add a note at the top of the message that you 
                have dropped the address. When the discussion is concluded, 
                [e-mail] will be re-added to the CC list and 
                its addition will be noted at the top of the message. 

        You may submit your changes in one of two ways:

        An update to the provided XML file
         — OR —
        An explicit list of changes in this format

        Section # (or indicate Global)

        OLD:
        old text

        NEW:
        new text

        You do not need to reply with both an updated XML file and an explicit 
        list of changes, as either form is sufficient.

        We will ask a stream manager to review and approve any changes that seem
        beyond editorial in nature, e.g., addition of new text, deletion of text, 
        and technical changes.  Information about stream managers can be found in 
        the FAQ.  Editorial changes do not require approval from a stream manager.


        Approving for publication
        --------------------------

        To approve your RFC for publication, please reply to this email stating
        that you approve this RFC for publication.  Please use ‘REPLY ALL’,
        as all the parties CCed on this message need to see your approval.


        Files 
        -----

        The files are available here:
           https://www.rfc-editor.org/authors/rfc9313.xml
           https://www.rfc-editor.org/authors/rfc9313.html
           https://www.rfc-editor.org/authors/rfc9313.pdf
           https://www.rfc-editor.org/authors/rfc9313.txt

        Diff file of the text:
           https://www.rfc-editor.org/authors/rfc9313-diff.html
           https://www.rfc-editor.org/authors/rfc9313-rfcdiff.html (side by side)

        Alt-diff of the text (allows you to more easily view changes 
        where text has been deleted or moved): 
           https://www.rfc-editor.org/authors/rfc9313-alt-diff.html

        Diff of the XML: 
           https://www.rfc-editor.org/authors/rfc9313-xmldiff1.html

        The following files are provided to facilitate creation of your own 
        diff files of the XML.  

        Initial XMLv3 created using XMLv2 as input:
           https://www.rfc-editor.org/authors/rfc9313.original.v2v3.xml 

        XMLv3 file that is a best effort to capture v3-related format updates 
        only: 
           https://www.rfc-editor.org/authors/rfc9313.form.xml


        Tracking progress
        -----------------

        The details of the AUTH48 status of your document are here:
           https://www.rfc-editor.org/auth48/rfc9313

        Please let us know if you have any questions.  

        Thank you for your cooperation,

        RFC Editor

        --------------------------------------
        RFC9313 (draft-ietf-v6ops-transition-comparison-04)

        Title            : Pros and Cons of IPv6 Transition Technologies for IPv4aaS
        Author(s)        : G. Lencse, J. Martinez, L. Howard, R. Patterson, I. Farrer
        WG Chair(s)      : Ron Bonica, XiPeng Xiao

        Area Director(s) : Warren Kumari, Robert Wilton






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