Re: [Ianaplan] control and negotiation (was Re: draft-ietf-ianaplan-icg-response-02 working group last call)

[Brian Trammell <[e-mail]>]

Greetings, all,

On 07 Nov 2014, at 23:22, Miles Fidelman <[e-mail]> wrote:

> Seun,
> 
> Seun Ojedeji wrote:
>> 
>> Miles, it think you are referencing that url as if the operating systems services are syncing off the iana.org <http://iana.org> site.
>> 
> 
> I doubt that the o/s is syncing in real time.  I wouldn't be surprised though, if, at build/packaging time, the build system does a lookup against the iana.org site.  I wouldn't be surprised if other iana.org paramter registries are used in similar ways.
> 
>> If that domain changes today, it does not take anything other than a update to reflect the new reference url does it?
>> 
> 
> If the URL changes, then auto-build systems will break - and people will end up having to figure out what happened, and fix it.  That's "disruptive" in my book.

Unless the auto-build system is linked to an auto-test system which also automates all the reports from alpha and beta testers, I'm presuming at least *one* of the humans with their hands on the tiller in the whole process is going to read theregister.co.uk or similar, and I'm going to further presume that the geek press will have at least one everything-is-ruined story. So this is one of those things that would get caught relatively early in the release cycle.

(I would also presume that any build system that automated would also be sufficiently advanced to read theregister.co.uk itself, but I digress nearly as far as the rest of this thread has.)

There may be other things which rely on certain content being at iana.org in a semi-automated fashion. I can't think of any that would reasonably be parts of processes where that URL would be hard-coded. So some extra work. But not a great deal of extra work.

>> What would be disastrous is if there happens to be 2 authoritative parameter source with different entries; as an example http referenced as port 80 and as another port on the other site.
>> 
> 
> exactly!

While there has indeed been disruption caused by the assignment of protocol parameters by parameter sources acting on their own authority, an activity referred to not particularly affectionately as "squatting", I'm having a hard time understanding the proposed method of initiation for this registry-scale mutual-squatting situation, or the disruption it is supposed to cause.

Let us assume the worst case: ICANN goes rogue and simply tries to inflict the maximum damage it can on the Internet by running an evil protocol parameters registry. It is important to note in this case that the most used protocol parameters are essentially immune even to completely malicious disruption merely by the massive inertia of the running code that makes up the Internet. Sticking 1337 in the port-number value field for "http" and "www" at will have no effect at all on the fact that all the world's webservers and browsers believe the web runs on port 80. Possession of the iana.org name confers no magic powers.

Of course, the more obscure registries have less inertia, but I suspect there is a vanishingly small set of registries where malicious reassignment would cause significant disruption to operations but the change would not be caught by people familiar with the contents first (or, if a codepoint changes and there is nobody there to care, is that really a problem?)

If an actively malicious ICANN can't break the Internet, I fail to see how an uncooperative but rational post-transition ICANN could.

Where we do get two parameter sources that perceive themselves as authoritative (i.e., one IANA, one a piece of running code that uses unassigned or otherwise-assigned codepoints for its own purposes), what generally happens is a protocol designer, equipment vendor, and/or software developer picks a codepoint, either because they don't want to bother with IANA or disagree with a decision the IETF (or IETF designated expert) made as the source of IANA policy. But this seems unrelated to this discussion, and I presume it will continue to be an irritation regardless of what happens in the transition.

>> How to avoid that is not just by locking up the name iana.org <http://iana.org> but by locking up to a single source of authority.
>> 
> 
> Currently, IETF is the source of policy and authority, iana.org, as run by ICANN is the single source of authoritative data.

IANA is the single source of authoritative data. ICANN, as the operator of the IANA function, presently serves that content from iana.org. The A in SOA does not confer actual authority, and the interia of the name itself presents a potential inconvenience but not a disaster should we be denied its use in the future.

> Seems to me that the simplest way to maintain a single source of authority is for the ownership of ietf.org to reside with IETF, to be delegated to whatever contractor is managing the data at any given time. Completely transparent to end-users of the registry.

> Do you have an alternative, simpler solution to offer?

The simplest solution in this case is "we have no actual problem at this time." I can agree that having the IETF "own" iana.org might be convenient in the case that we want to ensure we can minimize future work involved in a possible transition away from ICANN as IANA operator. I'm not sure the numbers or the names communities would agree that IETF is the natural owner of the domain, though. And I certainly do not think that asking ICANN to transfer the domain name as part of the ICG process is worth the effort, given that we do not have an actual problem at this time.

For the record, I'm okay with noting we have a dependency on the iana.org domain name in the ICG response, and John's text quoted by Eliot is good. But as far as I'm concerned that handles the issue for the scope of the ICG response.

Cheers,

Brian