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

Martin Huněk <martin.hunek@tul.cz> Tue, 14 May 2019 22:40 UTC

Return-Path: <martin.hunek@tul.cz>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA19120227 for <v6ops@ietfa.amsl.com>; Tue, 14 May 2019 15:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.92
X-Spam-Level:
X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4lowk047iQf for <v6ops@ietfa.amsl.com>; Tue, 14 May 2019 15:40:12 -0700 (PDT)
Received: from bubo.tul.cz (bubo.tul.cz [IPv6:2001:718:1c01:16::aa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FBED1201D8 for <v6ops@ietf.org>; Tue, 14 May 2019 15:40:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at tul.cz
Received: from asclepius.localnet (unknown [IPv6:2001:718:1c01:260:73fc:b828:6ebf:30fa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bubo.tul.cz (Postfix) with ESMTPSA id C02E0180651EA for <v6ops@ietf.org>; Wed, 15 May 2019 00:40:08 +0200 (CEST)
From: Martin Huněk <martin.hunek@tul.cz>
To: v6ops@ietf.org
Date: Wed, 15 May 2019 00:40:02 +0200
Message-ID: <1838337.UxxuEd2et2@asclepius>
Organization: Technická univerzita v Liberci
In-Reply-To: <75A4A2B3-8A52-408E-B4EC-448C7C185994@consulintel.es>
References: <BYAPR05MB4245A78BEC3D7E3622A38395AE0F0@BYAPR05MB4245.namprd05.prod.outlook.com> <1612259.PqNLWoFupM@asclepius> <75A4A2B3-8A52-408E-B4EC-448C7C185994@consulintel.es>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2119368.hOZkoO4SBg"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/jlXnQ0SveJNqTfh-X--y4rb5KsU>
Subject: Re: [v6ops] draft-ietf-v6ops-nat64-srv
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 May 2019 22:40:15 -0000

Hi Jordi,

reply in-line.

Dne úterý 14. května 2019 14:10:57 CEST, JORDI PALET MARTINEZ napsal(a):
> Hi Martin,
> 
> If you use Word or similar, copy and paste your draft txt as a blank new
> document, select all the text, then choose English language. It is not
> proof safe 100%, but it may help!
> 
> See below in-line.
> 
> Regards,
> Jordi
> 
> 
> 
> El 14/5/19 13:25, "v6ops en nombre de Martin Huněk" <v6ops-bounces@ietf.org
> en nombre de martin.hunek@tul.cz> escribió:
> 
>     Hi Jordi,
> 
>     thank you for a review, I will try to address those issues and I will
> try to get someone to look at grammar (I'm bit struggling with it).
> 
>     A reply inline (when there in none, than I agree with that assessment).
> 
>     Thanks,
>     Martin
> 
>     Dne úterý 14. května 2019 11:59:34 CEST, JORDI PALET MARTINEZ napsal(a):
>     > Hi Martin,
>     > 
>     > Re-reading this document now, I found a few clarification/nits that I
>     > think
>     > should be addressed.
>     > 
>     > 1) The document is reusing 192.0.0.170/171, but in the terminology
>     > section
>     > it refers for that to the RFC6052, while those addresses where
>     > actually
>     > defined by RFC7050.
>     > 
>     > 2) Same for the definition of WKA.
>     > 
>     > 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.
>     > 
>     > 4) I think you need to also consider, in addition to DNS over HTTPS,
>     > DNS
>     > over TLS, over DTLS and DOQ.
> 
>     DNS over DTLS, DoT or DoQ should not really matter for NAT64/DNS64
> detection as it allows to use "global" DNS to discover it. Any transport
> protocol should do the trick as long as the records are signed and their
> signature is valid.
> 
> I don't think so, applications use that bypassing the OS.

Sure, but then they act as stub resolver and as such should act according to 
this document. They are then an end nodes. I'm considering end node to be a 
resolver (DNS over whatever).

>     > 5) local area network or station. Not sure what it means "station"
>     > here.
> 
>     device
> 
> I will then suggest to use device across the text. Even better "node" or
> "host".

Think is that end node doesn't have to be a same as host/device. I would 
consider a web browser using DoH to be a separate end node to the DNS anyway, 
as we are talking DNS64 anyway.

>     > 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.
>     > 
>     > 7) Server provided / Servers provided
>     > 
>     > 8) In early stage / In the initial stage ?
>     > 
>     > 9) Method of obtaining such information is / The method to obtain ...
>     > 
>     > 10) but it might contain ... / but some possible choices are ...
>     > 
>     > 11) MUST ask / MUST query
>     > 
>     > 12) do have a same values of / do have equal values of ?
>     > 
>     > 13) is not capable of record synthesis / is not capable to perform
>     > AAAA
>     > record synthesis
>     > 
>     > 14) Method proposed / The method proposed
>     > 
>     > Further to that, it looks to me that the port definition should be
>     > better
>     > defined in section 3, either as 0 or prefix length (I will not say
>     > mask,
>     > because in IPv6 it doesn't exist).
>     > 
>     > I think it may be interesting to have a section stating why this
>     > method is
>     > better than others, pros/cons, etc. May be update RFC7051?
> 
>     I wanted to point that out in mailing list rather then in document
> itself as it might get easily outdated and incomplete. But if you think it
> should be there, than I guess I should add it into document.
> 
> I think the document should be self-contained. People that will read it in
> the future, will not read the mailing list, so references should be to the
> right document.

Fair enough.

>     > Last but not least, I will suggest a grammar/orthography pass. I'm not
>     > native English, so probably not the best to do it, but I spotted (some
>     > of
>     > them repeated in several parts of the document):
>     > 
>     > a) asignment / assignment
>     > b) diferent / different
>     > c) decadicaly / ?
>     > d) graylist / gray-list ? same for other similar words
>     > e) A such pool / Such pool ?
>     > f) For example when ISP / For example, when an ISP
> 
>     Will do. And c) should be decimally.
>     _______________________________________________
>     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.
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops