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

[Jiankang Yao <[e-mail]>]

 

 
From: Schanzenbach, Martin
Date: 2022-03-04 19:36
To: Independent Submissions Editor
CC: Jiankang Yao; draft-schanzen-gns.all; i18ndir
Subject: Re: I18ndir early review of draft-schanzen-gns-10

Thanks.
Some comments inline below.

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

Your explaination is clear. But the definition of "DNS NAME" belongs to the DNS protocols.
If your document is not part of DNS protocols, it is better not to define or redefine some DNS terminlogy.
If possible, I suggest that you rename "DNS NAME" to other name in your GNU name system.
Otherwise, it might cause some confusiton to the DNS guys.
 

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

If the use of GNS may clash with the DNS namespace, it might cause some problems in future.
That is why I suggest that this document should get some review from IETFer affiliated with ICANN.

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

If RFC-ISE is ok with the GANA, no objection is from me.

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

Yes, it is NOT managed by ICANN, but "the use of GNS may clash with the DNS namespace".

The DNS name space (common global identfiers) is very important to Internet success. https://www.internetsociety.org/issues/internet-way-of-networking/ 

So before moving this document to the next step, I suggest to get some comments from IETFer affiliated with ICANN.


Best Regards
Jiankang Yao

> See above?
> 
> Best
> Martin
> 
> > 
> > Regards,
> > 
> > Eliot
> > 
>