Re: [I18ndir] I18ndir early review of draft-schanzen-gns-10

["Schanzenbach, Martin" <[e-mail]>]

Thanks for the review!

My comments are inline below.

> On 4. Mar 2022, at 11:59, Independent Submissions Editor <[e-mail]> wrote:
> 
> Jiankang
> 
> Thank you for this review.  Please see below.
> 
> On 04.03.22 11:04, Jiankang Yao via Datatracker wrote:
>> Reviewer: Jiankang Yao
>> Review result: Not Ready
>> 
>> Some review comments below:
>> 1)This document says something about internaitonalisation, but some wording
>> related to internaitonalisation make the readers confusing. For example, in
>> section 5.2.2, there is a definition " DNS NAME  The name to continue with in
>> DNS.  The value is UTF-8 encoded and 0-terminated." It seems to indicate that
>> the DNS name can be UTF-8. If it is a DNS name, it should be in ASCII, not in
>> UTF-8 because all names including IDN stored in DNS are in ASCII or A-label
>> form.
>> 
> Did you see the note at the bottom of Section 5.2.2:
> 
> 
>>    NOTE: If an application uses DNS names obtained from GNS2DNS records
>>    in a DNS request they MUST first be converted to an IDNA compliant
>>    representation [RFC5890].
>> 
> 
> I think you may also be commenting on the text below Figure 12.  I think there are indeed some implications here about when to convert the representation.  Can the authors comment?
> 
> 

It is arguably also not true. An IDNA-compliant name may consist of U-labels: https://datatracker.ietf.org/doc/html/rfc5890#section-2.3.2.1
Anyway, there is a note which clearly states that the UTF-8 string in this field MUST be converted
to something DNS understands through the respective IDNA spec.

The field name is "DNS NAME", but the does not say that this is a "DNS name". It is the
"name to continue with in DNS" represented as an UTF-8 string.

> 
>> 2)It seems that both this system and current DNS share the same name space. So
>> it is possible that two name spaces will collide with each other in the future.
>> It may confuse the future applications when looking up for the same name. Does
>> this name belong to DNS or GNU name system?
>> 
> Could the authors respond to this?  I wonder if indeed such a clash is possible
> 
> 

I would like to refer to our previous efforts on integrating GNS into the DNS namespace via
RFC6761 here: https://mailarchive.ietf.org/arch/msg/dnsop/wu_uAtNaUieZ5Tb2imJEzW4F5vM/

A DINRG presentation also noted this: https://datatracker.ietf.org/meeting/104/session/dinrg

tl;dr: Our initial approach was to use a special-use TLD. But, RFC6761 was not followed.
We do know this also clashes with RFC8244 but what can we do?
Should there ever be a consensus or a special-use TLD which should be used for GNS
names, the document could be amended and/or a new document detailing the use
could be written.
But as it stands, our request is/was not granted (maybe Christian can be a bit clearer on the outcome
of the proposed drafts) and as such the use of GNS may clash with the DNS namespace.

The system itself is also designed in this way to circumvent censorship by
registrars as requests to do so are quite real  (ICANN, gTLD or others).
https://www.icann.org/en/system/files/correspondence/marby-to-fedorov-02mar22-en.pdf

> 
>> 
>> 3)It is interested to know that there is a section named with "GANA
>> Considerations". It seems that GANA will replace some function of IANA.
>>   If we follow the current way, the parameters produced by this document need
>>   to be managed by IANA instead of GANA.
>> 
> Can you explain why you think that is?
> 

Please also refer to the "History" section here on the origins of GANA and why we
can't use IANA: https://git.gnunet.org/gana.git/tree/README
Christian also may know more here.

> 
> 
>> 
>> 4)ICANN manages the DNS name root space. I suggest to ask some experts from
>> ICANN to review this document.
>> 
> This is a name space NOT managed by ICANN.  The issues we are concerned about are interactions with the DNS, and of course i18n.

See above?

Best
Martin

> 
> Regards,
> 
> Eliot
>