I would absolutely agree that DNSOP is the wrong place to try and
settle this problem because the problem is inherently about policy
decisions taken in a different place in process, and decided in a
different way. The IAB should be told to get the conversation rolling
on what they want, architecturally, and reflect on ICANN delegation
processes a bit more: the (apparently casual) assumption the IAB made
that a technical forum can (pretty arbitrarily) define a string in
high/top naming space is (IMHO) flawed. The technical *problem* which
desires a name may exist: the decision to delegate (or not-delegate or
reserve) is huge, as is the consequence of which label is chosen.
Thats non-technical.

If we just want to talk about it, since it reflects on DNS activity,
one can hardly say DNSOP is the wrong place to just talk. But the
likelihood of DNSOP emitting a document which bears on the problem
usefully looks low to me.

No reflection on the current draft authors intended: there is content
in both docs which I suspect the IAB is going to want to draw on.

-G


On Sat, Sep 24, 2016 at 7:41 AM, Ted Lemon <mel...@fugue.com> wrote:
> This is really well put, Ed.   Thanks.   I'm a little tempted to plagiarize
> you.
>
> On Fri, Sep 23, 2016 at 8:15 AM, Edward Lewis <edward.le...@icann.org>
> wrote:
>>
>> I have gotten the sense of a belief that IANA (the IANA functions office)
>> runs many registries for the IETF and they are not controversial and because
>> of this, the issues surrounding the Special Use Domain Name registry are all
>> fluff and no substance.  But the Special Use Domain Name registry is a
>> special case, it is not a run-of-the-mill IANA registry.
>>
>> The registry is special because the items registered are not bound in a
>> narrow scope.  The registered items (names) are used in many different
>> contexts.  This is opposed to protocol parameter registries, where the
>> registered item has a very narrow meaning.  E.g., "MX" as a mnemonic for the
>> numeric value of 15 in the registry for resource records is not treated as a
>> conflict with "MX" as the two-letter code for Mexico (not an IANA registry).
>> (Ignoring well known use problems with dig.)
>>
>> There are registries run by IANA like the Special Use Domain Name registry
>> when it comes to scope.  To name two the IPv4 and IPv6 address registries.
>> Addresses and other number parameters (AS numbers) are used in narrow
>> contexts but are also seen in other places.  The point is that these
>> registries are supported by well-developed policies for entering items into
>> registries, the Regional Internet Registries have agreed to pan-RIR, global
>> policies on these registries.
>>
>> This writing is in reaction to a rather limited set of participants in the
>> discussions on the topic.  Maybe that is appropriate, maybe that is a
>> reflection that the DNSOP WG is not the best place to cover this topic.
>> That is not an insult because there's a significant difference between the
>> function of registration (of anything) and the function of the DNS system.
>> Those two topics are often confused and I think that is happening again.
>>
>> If it seems that there is limited discussion during this two-week period
>> and the consensus is that this is not a topic for the WG, I think that it is
>> understandable.  Although many in DNSOP WG have expertise for this, the
>> roster of other work represents "time better spent" means that this work
>> could be pushed off the table.  However, the discussion ought to be resumed
>> somewhere else.  I think that the Special Use Domain Name registry is needed
>> but as it is currently defined, inadequate.
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to