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

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Tue, 14 May 2019 09:59 UTC

Return-Path: <prvs=1037410fe8=jordi.palet@consulintel.es>
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 5E7131200F8 for <v6ops@ietfa.amsl.com>; Tue, 14 May 2019 02:59:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
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 Cgr4-Y29HZbJ for <v6ops@ietfa.amsl.com>; Tue, 14 May 2019 02:59:43 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D48B120091 for <v6ops@ietf.org>; Tue, 14 May 2019 02:59:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1557827980; x=1558432780; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=ku2Eq0mG OyenNEPD6KD3uCHGwTPjWQs1TcvUGsUW03U=; b=H2fa1CYlWnTSoxHJzWwTCv9z YCi5GDY11AuDPogvUUNChJUodQhGNcX1PpvJQFPZ0Hh0G9tG83j6txOGZP+TzSoT y7ExOQq38x+neRO4Cv5gzNvn73ldcVpfR+wQ0z1J0lKuRlSnWBktVYumrJcCCpBn obQ0cnAR41plHjsXJlo=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Tue, 14 May 2019 11:59:40 +0200
X-Spam-Processed: mail.consulintel.es, Tue, 14 May 2019 11:59:39 +0200
Received: from [10.10.10.139] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006245389.msg for <v6ops@ietf.org>; Tue, 14 May 2019 11:59:39 +0200
X-MDRemoteIP: 2001:470:1f09:495:d82f:857d:4bc2:8955
X-MDHelo: [10.10.10.139]
X-MDArrival-Date: Tue, 14 May 2019 11:59:39 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=1037410fe8=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.10.9.190412
Date: Tue, 14 May 2019 11:59:34 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: v6ops@ietf.org
Message-ID: <EA467725-AFD8-4C9E-883A-AECA410E643A@consulintel.es>
Thread-Topic: [v6ops] draft-ietf-v6ops-nat64-srv
References: <BYAPR05MB4245A78BEC3D7E3622A38395AE0F0@BYAPR05MB4245.namprd05.prod.outlook.com> <alpine.DEB.2.20.1905131848190.1824@uplift.swm.pp.se> <129843806.b7yKE7hP11@hunator-ntb.local>
In-Reply-To: <129843806.b7yKE7hP11@hunator-ntb.local>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/bU4ByoGWueQl_ovT2bK1D56Qn3w>
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 09:59:46 -0000

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.

5) local area network or station. Not sure what it means "station" here.

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?

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

Regards,
Jordi
 
 

El 14/5/19 0:15, "v6ops en nombre de Martin Huněk" <v6ops-bounces@ietf.org en nombre de martin.hunek@tul.cz> escribió:

    Hi thank you for a review.
    
    Dne pondělí 13. května 2019 19:04:07 CEST, Mikael Abrahamsson napsal(a):
    > On Mon, 13 May 2019, Ron Bonica wrote:
    > > This week, please review and comment on draft-ietf-v6ops-nat64-sr .
    > 
    > I'm generally sympathetic to the problem space this draft tries to solve.
    > 
    > I'm struggling a bit with the different states that the device can end up
    > in over time, and also if these lookups should only be done at connect
    > time, or do they continue frequently in case the operator changes the
    > information? Is there a lifetime to them? If not, why?
    
    Sure, the SRV record does have the TTL value after which would had to be 
    renewed. This way it would keep in line with updated settings. It is not 
    explicitly written there, I guess it should be.
    
    Question is if the "local domain" should be renewed as well. I think not due 
    to security precaution (domain could be received for example from unsecured RA 
    so it might be good to wait for expiration), but I would probably let this 
    open as the draft doesn't specify domain detection mechanisms.
    
    > Think of a device that is connected for months, how are changes performed?
    > What triggers a refresh? The word "time" or "life" (as in lifecycle)
    > doesn't exist in the draft.
    
    As above, I would mention it in new version, something like: SRV record in use 
    must be valid and kept updated according to its TTL value.
    > 
    > Perhaps the built in TTL in DNS can be used and lookups are done per
    > normal DNS procedures and if the information changes then the settings are
    > updated accordingly?
    
    Yes, that is the idea.
    
    Thanks again for review, I would appreciate any other thoughts.
    
    Regards,
    Martin
    _______________________________________________
    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.