[discuss] Boundaries and sovereignty

John Curran jcurran at istaff.org
Mon Feb 3 17:36:46 UTC 2014


On Feb 3, 2014, at 7:23 AM, JFC Morfin <jefsey at jefsey.com> wrote:

> A. I am afraid I cannot answer your question. Because there is none. Let me explain you why.
> 
> 1. In my post, I first explain the netix general concept as the strict completion and convergence of the Tymnet/OSI/Internet/POSIX projects. "My" model is therefore the strict respect of everything existing, welded by some *additional* commands at the user place (when they are not already yet fully supported by some private environement). So, nothing to do with the Internet or the name space, just about their more intelligent use. Not a single bit being changed, not a single coma in RFC modified. Just clarifying technical/political/commercial confusions or limitations.

While I'll admit to some challenge with your terminology, I believe I've got the essence 
of your point - your model reflects use of the existing DNS technology, as opposed to 
some proposed change to today's DNS technology.)

> 2. Then, I answer the question concerning the name space. It was asked, as far as I understand, due to the netix probable simplification for the users in best managing and securing their DNS resolution process, for reasons partly given Hindenburgo Pires.
> 
> This enlights that the way the DNS is conceived, developped and deployed is:
> - adequate to the MS/globalization approach the I*coalition whishes for ICANN and IANA.
> - incorrectly supported by the ICANN current model which confuses collecting+documenting with regulating+selling.
> 
> If you do today what I document in the two lines you quote you will see that the ICANN dreamed top zone is quite different from the really active one. This explains the ICANN attitude: they deny reality to give it the least publicity and not encourage the top zone ... diversity (they prefer to sell).

Okay, I think I see your distinction; to paraphrase, you feel that a canonical single 
set of root servers (and therefore single root zone) is not a technology restriction
but an ICANN-asserted restriction.  I am not sure I agree with this viewpoint, but am 
willing to consider that it may be possible to have a _completely_ separate set of 
root servers that could theoretically support an entirely independent namespace tree
(Note - the fact that this may be possible does necessarily mean, at least to me, that 
it is desirable...)

> ...
> D. The only technical question os about propagation and buffer pollution. There is no possible buffer polution since there is no propagation.
> 
> Propagation comes from the use of the root server system and recursion. If you do not use them you do not use/pollute any buffer (anyway AJAX often implies very short TTLs). This is why the DNS model is a good and robust one, that one has to better know and fully use. It has several ways of being used.
> 
> The only possible pollution is structural and results from the classless CNAME/DNAME wording/understanding in RFCs. I suspect that practicall testing will tell a lot, and that a few "legal" or "bold" decisions (le.g. the ".su" position regarding IDNA registrations or the Chinese TLDs and keywords) will make this to be addressed one way or another. There is a need to understand first the true nature of CNAME/DNAME in several areas (technical, legale, IP, operations, etc.)

Acknowledged.

> In such a model, can I understand what you propose would happen when two name servers
>> both have TLD's of the same name but different content?
> 
> This is non possible, so it would be a configuration bug. The root you use decides of the TLD name servers you call. There is no recursion.
> 
>> I can easily see how content could
>> be aggregated when non-overlapping TLDs appear (e.g. the appearance of ".jcurranslongishTLD"
>> would not likely to appear in any other name server other than the one I inserted it into, and hence
>> it's propagation would therefore be relatively safe), but the appearance of a second ".com" whose
>> subdomains had conflicts or regional TLD and commercial TLD of the same name could be very
>> problematic.
> 
> This is the case when people can access several alternative root server systems as it is the case to day, if used root does not cooperate like ORSN, i.e. synchronized with the NTIA, and if their ISP is providing recursion. There is no technical problem otherwise. If you decide to use a kid-protection oriented ".com" in your root there is no problem.
> 
> However, some people may wish to have different visions of the name space supported/accessed (for example on a linguistic basis). Then classes bring the solution.

Your technical approach is clearer to me now; thank you.

>> Do you propose inconsistent resolution based on the user's resolver configuration
>> of region/locale/provider, or blocking of all conflicting TLDs till manual resolution, or some other
>> mechanism?
> 
> I propose nothing. I just confirm that there are ways to more intelligently use the internet resources in order to achieve more for the same money, program, etc. and less hassle. And to respect the constitution of my own country regarding the cyber part of the citizens environment. For a simple reason: this is what they have been designed for - to make the internet work better (something OpenStand tends to translate as "sell better").
> 
> Now, the question is to know if there is no flaw in RFCs or in the way developers, technical users and end-users read them.
> 
> This is why this has to be tested. This is the purpose of the "HomeRoot" project. I suppose that most will use it in copyng the "crown-root". Then adding some black list and local TLD for simplified use. Then we will see how the grassroots-files differentiate for which result. And how the use compares with the root-server-system, and how the different root data publishers may decide to cooperate.
> 
> This is true MS-IG and open globalization.

If I understand you correctly, you seek the freedom from artificial constraints such 
that you can use the existing DNS technology to run a completely independent namespace, 
with those other participants who wish to join,  via a set of namespace rules that 
your collective community establishes...  Is this correct?

/John

Disclaimer: My views alone.







More information about the discuss mailing list