On 09/30/2016 01:03 AM, George Michaelson wrote:
> Thats precisely why its NOT a false analogy: the design model in the
> IETF is that the value doesn't matter, but in the DNS, the design
> model is "follow the money"
>
> [snip]
>
> If they see inherent value in the string, then they immediately walked to
> being an applicant in ICANN gTLD space: the technical merit argument
> doesn't relate.
>
I'm sorry but you're saying that naming has a transaction value that
supersedes any other value, like historical or cultural. Your ideology
is clearly visible, and mine is clearly opposite. But you didn't
address anything technical by claiming that the market has the
totalitarian right to flatten anything that it touches.
Meanwhile, John R Levine claimed that the problem is related "to
recognize domain names that are handled in ways other than the DNS.", etc.
And Paul Wouters claimed that "IETF doesn't want [the power to suggest
names to ICANN] anymore", while Stephane Bortzemeyer claimed that no,
there's no problem with RFC 6761 since it was successfully used twice
already (RFC 6762 and RFC 7686).
I tend to agree with John and Stephane, but that doesn't make a problem
statement. If we want to make something else of our lives than arguing
eternally about "this" 'problem', we should better try to simplify the
scope a bit.
1) there's a valid RFC 6761
2) it provides a working assumption that IETF WGs need to make a decision
3) P2P Names came with a bulk request that was refused
4) other drafts followed suite and jumped on the bandwagon
5) the WG started to argue that the provisions of RFC 6761 give too much
space to WG decision (and therefore conflicting perspectives)
5.1) some argued for more measurement, but then what measurements are
pertinent? If size matters, then it discourages new networks to go
through IETF process; some things are not easily measurable; some things
have existed for a long period of time (how long is enough?); etc.
5.2) the .ALT draft was proposed to address part of the issue (e.g.,
non-exclusive, necessarily temporary 'self-assignments') but it also
uses RFC 6761 process
5.3) claim: RFC 6761 is fine, and it's on the WG! But the WG can't find
consensus!
5.4) claim: let's reform RFC 6761 and define criteria!
5.5) claim: let's abolish RFC 6761!
5.6) claim: do we even need a Special Use Domain Name Registry?
6) .onion split from P2P Names to address a time-constraint, and was
accepted using RFC 6761 process
6.1) all other requests were frozen, pending resolution of "this" 'problem'
7) let's write a problem statement!
7.1) one problem statement was proposed
7.2) another one was proposed, with a different scope
8) here we are.
I don't think we need to insist on 5.*) because these points SHOULD be
part of the problem statement: are they covered by 7.1 and 7.2? Do the
problem statements need to address a larger scope? Can we decide at this
point that 3) and/or 4) can be addressed on a case-by-case, make them
part of the problem statement, and walk through them one by one to see
what is acceptable (like .onion actually was) or not (like .corp is
likely not); from this point on, the WG can clarify by a case-by-case
study what are the underlying issues *concretely* instead of trying to
build a theoretical cathedral that's going nowhere during our lifetime.
If this approach seems sensible, I'm ready to work with a few other
people to make it into, sorry, a third problem statement and a proposal
to walk through this mess from concrete, actual use cases, with what we
already have in the *real world* queue, and figure out the real problems
contextually.
I *know* that a couple of issues were (almost) not verbalized: George
has part of it ("follow the money") and there's the sensitive ICANN-IETF
relationship because nobody on both sides wants to make a decision and
take responsibility for grinding on the other's business. But let's
leave that aside for a moment otherwise this will drift again away from
technical focus.
I want to ask three questions:
- Can the candidate name be *assigned* by an administrative third-party?
- Can the candidate name be *resolved* using the DNS tree?
- Is the candidate name *colliding* with assigned DNS names?
If we can agree that these three questions are pertinent, and they would
eliminate *some* problematic cases, we would already be left with
*technically relevant cases* to study further.
With each specific case, we'll build up a list of criteria that can fit
the bill, and then we'll be able to evaluate what to do with RFC 6761
with *working assumptions* that avoid intricacies that do not belong to
the technical work of IETF.
At the end of this process we can know:
- what type of requests *matching RFC 6761 procedure* MUST be rejected,
on technical ground (they can be assigned by a third-party and/or they
can be resolved using the DNS tree and/or they are colliding with
assigned DNS names)
- what type of *actual requests* are left to consider, and how many
- what they have in common that can characterize new criteria
It won't address (yet):
- whether to reform or abolish RFC 6761
- what strings can or cannot be accepted
- who gets to choose the strings
- what to do with upcoming requests
But at least I believe the WG will have a clearer picture of the
problem(s) left to address.
==
hk
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
