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

[Martin Huněk <[e-mail]>]

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.

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

device

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

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