Re: [v6ops] Éric Vyncke's No Objection on draft-ietf-v6ops-nat64-deployment-06: (with COMMENT)

Hi Eric,

I just posted a new version (https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/).

I believe it addresses all the issues and nits that you have raised (plus other nits that I've found as well).

Again, thanks a lot for the very detailed review!

Regards,
Jordi
@jordipalet

El 8/7/19 8:45, "Eric Vyncke (evyncke)" <evyncke@cisco.com> escribió:

    Hola Jordi,

    A couple of my comments were about lacking of references for "known to work" or "monitored by some governmental bodies and other institutions" or ""with hundreds of millions of users" which are strong statements without any factual data behind them. I make me feel uncomfortable... the document would be much stronger if there were references (external papers are fine).

    Your explanations for "ACL of clients" are clear now. I suggest that you rewrite the section to add the example given in your reply. And, use a different name to the section ;-)

    Thank you for all the fixes and for authoring the document

    -éric

    On 07/07/2019, 23:39, "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es> wrote:

            -- Section 3.1 --

            "known to work": can you add references or data backing this statement ?

        Well, those are the models being used today in cellular and broadband networks. So I can just say that?

            -- Section 3.1.1 --

            When discussing scenarii, please refer to the figure ID in the text for clarity.

        Done (I'm already editing a new version while writing this, pending on some that you can provide to my comments).

            -- Section 3.1.2 --

            It is unclear to me whether "The support of this scenario" refers to the
            UE-only or the CPE deployment.

        It is referring to the "service provider network support". Will clarify it.

            Same demand as above: please refer to the figure ID in the text for clarity.

        Done!

            -- Sectio 3.2.1 --

            I really wonder whether it is useful to describe this scenario as 'working
            under special conditions'... those 'special conditions' will probably never met
            in real life.

            More generally, I am unsure about the value of the whole section 3.2 (it is
            more like an academic thing).

        I think some of those scenarios are possible in some networks, may be not connecting to Internet, or for example, you may want to configure explicit mappings, which can be done with EAM. I just realized that I've not cited that. I will do.

            -- Section 4.1.1. --

            Can you add reference and/or data for "monitored by some governmental bodies
            and other institutions".

        I believe that was pointed out by somebody in the WG, but it is true that some regulators do that. I recall having seen something about that in France, but I'm not 100% sure right now.

            Please add a reference for the use of "ipv4only.arpa". AFAIK

        Right, this is defined by RFC7050, done!

            draft-cheshire-sudn-ipv4only-dot-arpa appears to be dormant/dead.

        This is one of the issues that I've commented with Warren, responding to IANA. I understand he is sponsoring that document. 

            -- Section 4.1.2 --

            The leading paragraph is a little confusing as it assumed that CLAT exists
            (stated in the text but not in the section title).

        Will clarify it.

            -- Section 4.1.5 --

            The section title is rather misleading "ACL of clients" and I wonder why a
            dual-stack client would use a DNS64 server as its recursive DNS server. Isn't
            it an obvious configuration mistake?

        No, I think that text is correct, but I will try to reword it to make it clearer. You may have a situation with IPv4-only servers, which are located, in the path between the dual-stack hosts and the NAT64. So, if the DNS64 is not configured to exclude those servers, it will synthetize the AAAA records and they will become unreachable. So that's why bind and other DNS64 servers provide this ACL function.

            -- Section 4.4.1 --

            Some explanations of the consequences of a foreign DNS would be welcome.

        Done!

            -- Section 4.4.2 --

            Rather than using "DNS privacy" please use "DNS request confidentiality" as the
            DNS64 will learn/glean about the client activities.

        I used this terminology as it was suggested as the common one for the different protocols in this category. I will try to confirm if is the right one just in case. May be rewording the title as "DNS Privacy/Encryption Mechanisms" ?

            -- Section 4.6 --

            Please explain why older API is a problem (or rather rephrase it into
            applications using IPv4-only API).

        Done!

            -- Section 4.10 --

            draft-ietf-tram-turnbis is also able to support IPv6-only client. It is
            currently in the same IESG status as this document.

        Definitively, will add a reference to it!

            -- Section 5 --

            Please add data/references for "with hundreds of millions of users"

        I can cite several cellular networks, but I will do in a generic way, I don't think we should mention explicit providers, right?. 

            -- Section 7 --

            Not so much about security but about privacy. I would appreciate to have some
            text around the lack of privacy when using an external DNS64 as this server
            will learn about all clients activities.

        Good point, thanks. Will do!

            == NITS ==

            Generally, please refrain from using "HEv2" in place of "Happy Eyeball version
            2".

        Done!

            -- Section 3.1.1. --

            Figure 1 shows a box containing both NAT64 and DNS64 while those functions
            could reside in different devices.

        Will clarify it.

            s/One more equivalent scenario/One additional equivalent scenario/ ?

        Done!

            -- Section 4.1 --

            s/to an IPv6-only WAN/to an IPv6-only access network/

        Done!    

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

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