Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld

[George Michaelson <[e-mail]>]

On Mon, Apr 3, 2017 at 8:13 PM, Paul Hoffman <[e-mail]> wrote:
> On 3 Apr 2017, at 18:02, George Michaelson wrote:
>
>> The only reference to ICANN delegation process is in an [Ed: note]
>> which feels to me to be wrong: its a first class issue, and should be
>> addressed directly, not as editorial.
>
>
> The note says why the ICANN delegation process is *not* used. As the
> Abstract says, these notes will be removed before publication.

Which I think is wrong. The notes are material. I think they should
uplift to the body of the document so there is a permanent RFC record
of why the decison to not go to ICANN delegation was made.

>
>> Secondly, The authors make a judgement call in this block that they
>> feel requesting delegation is not required. I don't feel the consensus
>> was that strong actually, but you know, I guess I could be wrong on
>> that.
>
>
> This is what WG Last Call is for. If you want to reverse what's in the
> current draft, you need to say so explicitly, hopefully providing text so
> that this WG doesn't end up with the sloppy text that the HOMENET WG got.
>
> FWIW, I thought that the authors got this version right. The discussion
> didn't converge on strong use cases for delegation, and there were strong
> reasons against. But this is a fair time to open that again.

No, I don't think I can demonstrate failure to converge on strong use
cases for delegation is weak consensus. If nobody comes forward with a
rock-solid reason to delegate, then I think its fair to call it 'not
delegated'


>
>> Thirdly the draft contains no language which actually explains why a
>> TLD is required, rather than a deterministic string which denotes 'not
>> in the DNS' -It may be blindingly obvious to you it has to be a TLD,
>> but given that the entry of DNS label-strings into the DNS is through
>> software, and given that at some point, the simple un-parsed string
>> 'something.alt' has to be presented, I would have expected an
>> explanation why 'alt.arpa' as a pattern match in the DNS entry can't
>> work as well as 'alt'. Bear in mind, that the argumentative text
>> states .ONION is a comparator, so poses the problem back on (future)
>> s/w authors that currently seek a TLD as a pattern match, and now have
>> to code to ONION.ALT as a pattern match (the match on ALT implies
>> parsing it off, to denote ONION as a non-DNS label, or embedding of
>> ALT in the non-DNS namespace) so the dots-parsing problem exists for
>> the s/w owners *come what may*
>
>
> If you have such proposed text, that would be useful to evaluate.

The problem is, I don't think I can, because I cannot argue strongly
FOR a TLD, because i believe the impetus for a TLD is aesthetic and
(as for homenet btw) driven by end user UI perception issues.

I believe that the behaviour here is going to drive to string
recognition inside code to switch:

Pythonic pseudocode:
    if fqdn.endswith('.alt'):
       do_non_dns_lookup(fqdn)
    else:
       gethostbyname(fqdn)

type decision. Thats what it think this document drives to. And, given
that, I think endswith('.alt') can be endswith(STUBNAME) and somewhere
else, STUBNAME='.alt.arpa' is going to work.


>
>> Lastly, I think the IAB note pretty strongly goes to 'we dont do that
>> any more'
>
>
> Please define "that". If you mean "using TLDs that are not delegated",
> please show in the IAB statement where you get that impression. I didn't see
> it, but that doesn't mean it isn't there.

Actually you're probably right. the statement says explicitly "Other
names in the Special-Use Domain Names registry are intended for
exclusion from DNS resolution. An entry in the Special-Use Domain
Names Registry that does not require DNS resolution does not require
the registrant to control the relevant name in the DNS." So the
language there goes directly to BECAUSE you intend requesting no
delegation, you make the cut.

Ie, the fact you've decided consensus wasn't reached to delegated, and
therefore decide to say NOT DELEGATE is directly relevant to the
statement from the IAB, because it goes to the language which says 'if
not in the DNS, and a TLD, put it in the SUDN'

So if you continue to maintain this HAS to be a TLD, (which btw,
requires justifying) AND if you specifically require it NOT to be in
the DNS, then the IAB statement should be cited to drive to its
inclusion in the registry.


>
>> and I think the draft at the bare minimum should say why
>> this draft is special, against that letter.  You make a compelling and
>> simple case: because its specifically NOT-DNS, not public DNS, its not
>> relevant. Ok, then say so. 'we didn't say so because it wasn't
>> relevant' feels pretty weak to me.
>>
>> I can do this as a nit in the GIT if you prefer.
>
>
> What you are proposing is not a "nit", but a fundamental change throughout
> the document.

No, I'd like to back off that. If you do language to specify why it
has to be a TLD, and if you cite the IAB, I think the document will be
integral and complete.

in other words "I was wrong" but "now I'm right"

cheers

-G

>
> --Paul Hoffman