Re: [v6ops] draft-ietf-v6ops-nat64-srv

[JORDI PALET MARTINEZ <[e-mail]>]

Hi Fred, all,


El 14/5/19 22:00, "v6ops en nombre de Fred Baker" <[e-mail] en nombre de [e-mail]> escribió:

    
    
    On May 14, 2019, at 2:59 AM, JORDI PALET MARTINEZ <jordi.palet=[e-mail]> wrote:
    > 
    > 3) Intro: This document specifies ... the way of ... / a mechanism for.  As this is not the only way (the/a). You use the same expression in several parts of the document.
    
    So you are asking him to change "the" to "a"?

I was trying to point out several changes in a single line, that are repeated (some of them) across the text. Because this is not the only way for the discovery I think it should be "a" instead of "the" and also replace way with "mechanism":

Actual:
This document specifies the way of discovering the NAT64 pools in

Suggested:
This document specifies a mechanism for discovering the NAT64 pools in
    
    > 5) local area network or station. Not sure what it means "station" here.
    
    I presume you're referring to the definition of an "end node".

Yeah,  I may be wrong, but in IETF I think we use node or host or device, but not so much station.

    Things that are attached to local area networks are referred to by various names. People from a telephony background often call them "terminals", for example, and people thinking of mobile telephones or things that look/act like them might call them "handsets". People with an ISO background might call them "end stations", and people from an Internet background might call them "hosts". "Station", which is half of "end station", is one of a number of words used in the same vein.
    
    I do find the definition odd; when it is a "resolver" serving a "station", I would presume that it is the resolver software in a host, the bit of software that gethostbyname() asks for an IP address. That said, the *resolver* software is not the "end node"; the chunk of software that terminates sessions, which includes at least IP and the means by which it communicates with its client (often TCP or UDP, or maybe another instance of IP) and its services (a tunnel SNDCF, or a driver in most cases), and might possibly include such a resolver, is the end node.
    
Available instead of "serving" ? anyway, yes, the definition is a bit strange.

    > 6) The one for NAT64 prefix which validation end node MUST implement / end-nodes? Actually I think you should use end-nodes across all the document, but others may disagree here.
    
    I'm not entirely sure what text change you're requesting.

"end-nodes" (plural) instead of end node (singular)
    
    
    I ran the thing through my spell-checker; it came up with the following diff. I wasn't sure what construction was intended by "9632". On "graylist", I have seen it as "greylist", "grey-list" and "grey list".

I understood 9632 as 96 bits / 32 bits, using decimal notation.
    
    On the mention of an "IPv6 prefix mask" with attached decadic "IPv4 prefix mask", you're correct that we don't use prefix masks in IPv6; I would go a step further and say we would find the construct distinctly unusual. It is probably derived from the "alternative form" mentioned in the third bullet of section 2.2 from RFC 4291, but has no counterpart in section 2.3, which describes address prefixes. Since IPv4 and IPv6 both use CIDR notation, I would suggest simply using CIDR notation: if I have a prefix 2001:dba::/96 mashed up with 192.0.5.0/26, I might describe it using the IPv6 prefix 2001:dba::c000:500/122.
    
    *** draft-ietf-v6ops-nat64-srv-00.txt	2019-03-11 01:56:27.000000000 -0700
    --- draft-ietf-v6ops-nat64-srv-00-1.txt	2019-05-14 12:40:30.000000000 -0700
    ***************
    *** 11,17 ****
         This document specifies the way of discovering the NAT64 pools in
         use as well as DNS servers providing DNS64 service to the local
         clients. The discovery is done via SRV records, which also allows
    !    asignment of priorities to the NAT64 pools as well as DNS64 servers.
         It also allows clients to have diferent DNS providers than NAT64
         provider, while providing a secure way via DNSSEC validation of
         provided SRV records. This way, it provides DNS64 service even in
    --- 11,17 ----
         This document specifies the way of discovering the NAT64 pools in
         use as well as DNS servers providing DNS64 service to the local
         clients. The discovery is done via SRV records, which also allows
    !    assignment of priorities to the NAT64 pools as well as DNS64 servers.
         It also allows clients to have diferent DNS providers than NAT64
         provider, while providing a secure way via DNSSEC validation of
         provided SRV records. This way, it provides DNS64 service even in
    ***************
    *** 120,133 ****
         Port: IPv6 as L3 protocol doesn't use port numbers. Because of that
         this field SHOULD be either set to zero, or SHOULD be used to
         indicate length of network prefix mask in both IPv6 and IPv4
    !    protocol, used NAT64. In such case the port 16b integer MUST be
         constructed by directly appending IPv4 pool prefix mask after the
    
      Martin Hunek          Expires September 11, 2019               [Page 3]
    
    
      INTERNET-DRAFT    NAT64/DNS64 detection via SRV Records     March, 2019
    
    !    IPv6 prefix mask decadicaly. Usually this would mean 9632 stating
         that IPv6 prefix with mask /96 is translated into single IPv4
         address (/32).
    
    --- 120,133 ----
         Port: IPv6 as L3 protocol doesn't use port numbers. Because of that
         this field SHOULD be either set to zero, or SHOULD be used to
         indicate length of network prefix mask in both IPv6 and IPv4
    !    protocol, used NAT64. In such case the port 16 bit integer MUST be
         constructed by directly appending IPv4 pool prefix mask after the
    
      Martin Hunek          Expires September 11, 2019               [Page 3]
    
    
      INTERNET-DRAFT    NAT64/DNS64 detection via SRV Records     March, 2019
    
    !    IPv6 prefix mask decadically. Usually this would mean ?9632? stating
         that IPv6 prefix with mask /96 is translated into single IPv4
         address (/32).
    
    
    
    _______________________________________________
    v6ops mailing list
    [e-mail]
    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.