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

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

> On 7. Mar 2022, at 18:12, Independent Submissions Editor (Eliot Lear) <[e-mail]> wrote:
> 
> Hi Christian Yiankang, and Martin:
> 
> I want to make several points:
> 
> 	• Neither Yiangkang nor I represent or are associated with the IAB.  Although I am appointed by them, my views are my own, and I have not consulted the IAB about this draft.
> 	• I agree with Christian that the comments go beyond the scope of internationalization.  However, reviewers are allowed to do that, and if they don't it is quite likely that people at the next stage will.  I would ask Yiankang to confirm that there are no other international issues to be addressed.
> 	• I think the issue that Yiangkang is demonstrating is some confusion on the part of the reader regarding the relationship between GNS and DNS.  I believe there is an architectural issue around multiple name spaces, and it may be good to hit that a bit more head on.  Neither ICANN nor the IETF can have a corner on creation of name spaces, but understanding how applications should identify which name space is in use is something that should be crystal clear.  I see two specific ways to tackle this:
> 		• How does one know, for instance, when looking at a name that one should query the GNS or the DNS?  That could be solved with a URI or a URN, for instance.  One could say that the application must assume one or another.  One could say that the application should take as an option one or another.
> 		• A bit more clarity about expected coherency (or lack thereof) between the naming systems, when mapped.
> None of this is insurmountable but a certain amount of care must be given. Christian, Martin, could you please respond directly to me on point (3) when you are ready.  Again, thank you Yiangkang for your review.

Ah I think this brings us on the right path.
I am thinking about adding a security/privacy consideration with respect to name leakage:

"""
Name Leakage

GNS names are indistiguishable from DNS names or other special-use domain names [RFC6761]. This poses a risk when trying to resolve a name through DNS when it is actually a GNS name. In such a case, the GNS name would be leaked as part of the DNS resolution. This risk is also present for special-use domain names which must be handled before starting a DNS resolution request by the application.

Any application MUST take into consideration the user configuration of resolution precedence when trying to resolve a name. One example of such a configuration which at the same time allows applications to delegate the resolution itself is the Name Service Switch (NSS) of Unix-like operating systems. It allows system administrators to configure host name resolution precedence and is integrated with the system resolver implementation.

The order of resolution mechanisms to try is under the discretion of the user or system administrator. In the absence of an explicit configuration it is RECOMMENDED that applications try to resolve a given name in GNS before any other method in order to honor potential TLD overrides in GNS by the user. If no suffix-to-zone mapping for the name exists, resolution MAY continue with other methods. If a suffix-to-zone mapping exists for the name and the query succeeds, fails or returns no results, resolution MUST NOT continue by other means.
"""

This makes it explicit that GNS names cannot be distinguished from DNS names (or special-use tlds, or any other domain name for that matter).
It also addresses the issue of potential leakage of names in another system.
Note that is leakage issue is generally a problem also for special-use names (e.g. .onion, .bit etc) but it makes sense to highlight it I think.

BR

> 
> Eliot (ISE)
> 
> 
> 
> On 07.03.22 16:24, Christian Grothoff wrote:
>> On 3/7/22 10:09, Jiankang Yao wrote:
>> 
>>>>>> 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/
>>> 
>>> <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.
>>> 
>>> 
>> Well, that has been discussed to death, with Warren Kumari even writing
>> RFC 8244 about the *discussion* that we triggered about it in 2013 (!)
>> at dnsop and beyond -- including Martin's presentation at ICANN about GNS.
>> 
>> So IMO this is very far outside of the scope of the i18n review, and
>> simply another topic that the IAB has decided to punt on (my
>> interpretation). So this is a political issue, which we cannot solve
>> anymore and will just leave as-is / unresolved / potentially
>> conflicting.  The expert reviewers (like Bortzmeyer) are also very well
>> aware of the discussion --- it triggered like 1000 e-mails on dnsop back
>> in the day...
>> 
>> My 2 cents
>> 
>> Christian
>>