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

[Suzanne Woolf]

Dear colleagues,

After some discussion, the chairs have found we have rough consensus to advance 
draft-ietf-dnsop-alt-tld.

The authors have been considering the WGLC comments and will post a new draft 
shortly.

As we’ve mentioned before, the responsible AD for this draft will be Rob 
Wilton, as our usual AD (Warren) is a co-author on the draft.

Thanks to everyone who contributed to the discussion over the history of the 
draft.


Best,
Suzanne,  Tim, and Benno
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Eliot Lear]

Chairs,

Can we get some follow-up on this?

Thanks,

Eliot

On 13.01.23 16:56, Suzanne Woolf wrote:


Colleagues,

This WGLC is closed,  with many thanks to everyone who commented.

The chairs and editors are reviewing the comments and will summarize 
in the next few days.


Suzanne, for the chairs

*From: *Suzanne Woolf 
*Date: *Tuesday, December 13, 2022 at 3:26 PM
*To: *"dnsop@ietf.org" 
*Cc: *"dnsop-cha...@ietf.org" , "Rob Wilton 
(rwilton)" 

*Subject: *WGLC for draft-ietf-dnsop-alt-tld
*Resent-From: *
*Resent-To: *, , 
*Resent-Date: *Tuesday, December 13, 2022 at 3:26 PM

Dear colleagues,

This message will serve to start a Working Group Last Call on “The ALT 
Special Use Top Level Domain” 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ 
<https://protect-us.mimecast.com/s/aTUqCjRNX8ilAwvtWUttq?domain=datatracker.ietf.org/>). 
Due to the end-of-year holidays, we’re starting it now and will give 
it four weeks.


As you’ve seen from Paul Hoffman’s email, the authors have updated to 
version 19 based on the feedback they heard at IETF 115. Thanks Paul 
and Warren!


The WG is very familiar with this document by now, and the WGLC is to 
determine whether the document has rough consensus to progress. The 
chairs need to know whether you support it (which, for this purpose, 
includes “I can live with it”), or actively oppose publishing it.


Please also assume that any necessary liaison communications with 
ICANN will be undertaken if this document has WG consensus to move 
forward. Managing the potential for misunderstanding or differences of 
opinion among relevant organizations is the primary reason why the 
IETF has liaison relationships. The IETF liaison to the ICANN Board is 
Harald Alvestrand, who has been monitoring the conversations about 
alt-tld on the mailing list and has discussed the draft with the 
chairs and with Rob Wilton as the responsible AD.


Start date: 13 December 2022

End date:  10 January 2023

Many thanks,

Suzanne, Tim, and Benno


___
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

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

[Suzanne Woolf]

Colleagues,

This WGLC is closed,  with many thanks to everyone who commented.

The chairs and editors are reviewing the comments and will summarize in the 
next few days.


Suzanne, for the chairs

From: Suzanne Woolf 
Date: Tuesday, December 13, 2022 at 3:26 PM
To: "dnsop@ietf.org" 
Cc: "dnsop-cha...@ietf.org" , "Rob Wilton (rwilton)" 

Subject: WGLC for draft-ietf-dnsop-alt-tld
Resent-From: 
Resent-To: , , 
Resent-Date: Tuesday, December 13, 2022 at 3:26 PM


Dear colleagues,


This message will serve to start a Working Group Last Call on “The ALT Special 
Use Top Level Domain” 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/<https://protect-us.mimecast.com/s/aTUqCjRNX8ilAwvtWUttq?domain=datatracker.ietf.org/>).
 Due to the end-of-year holidays, we’re starting it now and will give it four 
weeks.


As you’ve seen from Paul Hoffman’s email, the authors have updated to version 
19 based on the feedback they heard at IETF 115. Thanks Paul and Warren!


The WG is very familiar with this document by now, and the WGLC is to determine 
whether the document has rough consensus to progress. The chairs need to know 
whether you support it (which, for this purpose, includes “I can live with 
it”), or actively oppose publishing it.


Please also assume that any necessary liaison communications with ICANN will be 
undertaken if this document has WG consensus to move forward. Managing the 
potential for misunderstanding or differences of opinion among relevant 
organizations is the primary reason why the IETF has liaison relationships. The 
IETF liaison to the ICANN Board is Harald Alvestrand, who has been monitoring 
the conversations about alt-tld on the mailing list and has discussed the draft 
with the chairs and with Rob Wilton as the responsible AD.


Start date: 13 December 2022

End date:  10 January 2023


Many thanks,

Suzanne, Tim, and Benno



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

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

[Donald Eastlake]

I support publication of this draft.

Since it has no keywords in it, Section 1.1 should be deleted.

Thanks,
Donald
===
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e...@gmail.com


>
> *From: *DNSOP  on behalf of Suzanne Woolf <
> swo...@pir.org>
> *Date: *Tuesday, December 13, 2022 at 12:26 PM
> *To: *"dnsop@ietf.org" 
> *Cc: *"dnsop-cha...@ietf.org" , "Rob Wilton
> (rwilton)" 
> *Subject: *[EXTERNAL] [DNSOP] WGLC for draft-ietf-dnsop-alt-tld
>
>
>
> *Caution:* This email originated from outside the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
> Dear colleagues,
>
>
>
> This message will serve to start a Working Group Last Call on “The ALT
> Special Use Top Level Domain” (
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/
> <https://secure-web.cisco.com/1KEyaIDN65K4VF1WFK4R1Riwh0dr0IiS4Ohj1QmijQQpkv69IFpuMx3py1dW1OEny5arBiZsIjc-LaAAFUtXJprF7f4QYr6deDXKb9-SL8SM6JFELHTwLqsFyrLHTJ6ZlKfxmaGpJivEQses0R6tIvCFQssNZ4ta0NLHQuYLnaiFmAsM369LBMpTdxOD4YfuITtUNmVnP3q-tdo5aj_xY77W6GN7Faw7R--nLoUx2U5-jltF2q9nkzGg_nW1VguvBtP4zN4A7oBDorjHjJTb_vfbhb_tkIEK9wRIv_wm6FkE/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-alt-tld%2F>).
> Due to the end-of-year holidays, we’re starting it now and will give it
> four weeks.
>
>
>
> As you’ve seen from Paul Hoffman’s email, the authors have updated to
> version 19 based on the feedback they heard at IETF 115. Thanks Paul and
> Warren!
>
>
>
> The WG is very familiar with this document by now, and the WGLC is to
> determine whether the document has rough consensus to progress. The chairs
> need to know whether you support it (which, for this purpose, includes “I
> can live with it”), or actively oppose publishing it.
>
>
>
> Please also assume that any necessary liaison communications with ICANN
> will be undertaken if this document has WG consensus to move forward.
> Managing the potential for misunderstanding or differences of opinion among
> relevant organizations is the primary reason why the IETF has liaison
> relationships. The IETF liaison to the ICANN Board is Harald Alvestrand,
> who has been monitoring the conversations about alt-tld on the mailing list
> and has discussed the draft with the chairs and with Rob Wilton as the
> responsible AD.
>
>
>
> Start date: 13 December 2022
>
> End date:  10 January 2023
>
>
>
> Many thanks,
>
> Suzanne, Tim, and Benno
>
>
>
>
>
>
> ___
> 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

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

[Paul Wouters]

> On Dec 13, 2022, at 18:50, Wessels, Duane 
>  wrote:
> 
> 
> I 
> I still think the requirements for library (stub) and caching resolver 
> behavior should be stronger.  i.e. MUST NOT put .alt queries on the wire.  
> But this is probably a minority opinion.

Earlier I had said “should use query minimalization”, but perhaps better is to 
just say “with DO set (or when this cannot be determined) should strip the 
query down to “.alt” (eg dropping anything left of the TLD) and change the type 
to  and continue the regular resolving process. If no DO is set, just 
return NXDOMAIN.


> “Caching Resolvers performing aggressive use of DNSSEC-validated caches ... 
> will not send any queries for names under .alt to the root zone.”  This 
> statement is too strong.  RFC 8198 says SHOULD, not MUST. Not to mention 
> cache misses.

I think stripping the qname is easier and preserves more privacy.


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

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

[Wessels, Duane]

I will reiterate some of my concerns with the draft:

I find the format of section 3.2 to be very strange.  As a paragraph it jumbles 
some items together.  It should be a list format like the ones in RFCs 6761 and 
7686.

Section 3.2 does not say how applications that do not use .alt should behave.

Section 3.2 does not say how APIs and libraries should behave (only that 
.alt-aware applications will probably use specialized APIs and libraries).

Section 3.2 uses “will” several times instead of BCP 14 requirements keywords.

I still think the requirements for library (stub) and caching resolver behavior 
should be stronger.  i.e. MUST NOT put .alt queries on the wire.  But this is 
probably a minority opinion.

“Caching Resolvers performing aggressive use of DNSSEC-validated caches ... 
will not send any queries for names under .alt to the root zone.”  This 
statement is too strong.  RFC 8198 says SHOULD, not MUST. Not to mention cache 
misses.

DW


From: DNSOP  on behalf of Suzanne Woolf 
Date: Tuesday, December 13, 2022 at 12:26 PM
To: "dnsop@ietf.org" 
Cc: "dnsop-cha...@ietf.org" , "Rob Wilton (rwilton)" 

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


Caution: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


Dear colleagues,


This message will serve to start a Working Group Last Call on “The ALT Special 
Use Top Level Domain” 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/<https://secure-web.cisco.com/1KEyaIDN65K4VF1WFK4R1Riwh0dr0IiS4Ohj1QmijQQpkv69IFpuMx3py1dW1OEny5arBiZsIjc-LaAAFUtXJprF7f4QYr6deDXKb9-SL8SM6JFELHTwLqsFyrLHTJ6ZlKfxmaGpJivEQses0R6tIvCFQssNZ4ta0NLHQuYLnaiFmAsM369LBMpTdxOD4YfuITtUNmVnP3q-tdo5aj_xY77W6GN7Faw7R--nLoUx2U5-jltF2q9nkzGg_nW1VguvBtP4zN4A7oBDorjHjJTb_vfbhb_tkIEK9wRIv_wm6FkE/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dnsop-alt-tld%2F>).
 Due to the end-of-year holidays, we’re starting it now and will give it four 
weeks.


As you’ve seen from Paul Hoffman’s email, the authors have updated to version 
19 based on the feedback they heard at IETF 115. Thanks Paul and Warren!


The WG is very familiar with this document by now, and the WGLC is to determine 
whether the document has rough consensus to progress. The chairs need to know 
whether you support it (which, for this purpose, includes “I can live with 
it”), or actively oppose publishing it.


Please also assume that any necessary liaison communications with ICANN will be 
undertaken if this document has WG consensus to move forward. Managing the 
potential for misunderstanding or differences of opinion among relevant 
organizations is the primary reason why the IETF has liaison relationships. The 
IETF liaison to the ICANN Board is Harald Alvestrand, who has been monitoring 
the conversations about alt-tld on the mailing list and has discussed the draft 
with the chairs and with Rob Wilton as the responsible AD.


Start date: 13 December 2022

End date:  10 January 2023


Many thanks,

Suzanne, Tim, and Benno



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

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

[Peter Thomassen]

Dear DNSOP,

I support advancing the document in its current form.

There's a broken sentence in Section 5:

"Care must be taken to ensure that the mapping of thepseudo-TLD into its 
corresponding non-DNS name resolution system inorder to get whatever security is offered 
by that system."

--> the "that" clause lacks a verb. (... ensure that the mapping ... [what]?)


At the occasion of fixing that, I'll also note two other suggestions / 
potential improvements:

- Section 2: "wastes resources": whose? Only the root servers' mentioned in the same 
sentence? Suggestion: "wastes resources on both the resolver and the root server side."

- Section 5: Amend the last sentence with something like "in particular, the risk of 
collisions with and subsequent compromise through other naming systems existing now or in 
the future should be considered". (I know the previous versions has something 
similar, but this is less strong, and I think it's worthwhile pointing out what people 
are getting into.)

Thanks,
Peter



On 12/13/22 21:26, Suzanne Woolf wrote:

Dear colleagues,

This message will serve to start a Working Group Last Call on “The ALT Special Use 
Top Level Domain” (https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ 
). Due to the 
end-of-year holidays, we’re starting it now and will give it four weeks.

As you’ve seen from Paul Hoffman’s email, the authors have updated to version 
19 based on the feedback they heard at IETF 115. Thanks Paul and Warren!

The WG is very familiar with this document by now, and the WGLC is to determine 
whether the document has rough consensus to progress. The chairs need to know 
whether you support it (which, for this purpose, includes “I can live with 
it”), or actively oppose publishing it.

Please also assume that any necessary liaison communications with ICANN will be 
undertaken if this document has WG consensus to move forward. Managing the 
potential for misunderstanding or differences of opinion among relevant 
organizations is the primary reason why the IETF has liaison relationships. The 
IETF liaison to the ICANN Board is Harald Alvestrand, who has been monitoring 
the conversations about alt-tld on the mailing list and has discussed the draft 
with the chairs and with Rob Wilton as the responsible AD.

Start date: 13 December 2022

End date:  10 January 2023



Many thanks,

Suzanne, Tim, and Benno


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


--
Like our community service? 
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

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

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

[Stephen Farrell]

Hiya,

This is good enough, so should proceed.

In terms of substantive comments, I can only think of
arguments that have already been thrashed out so won't
raise any of 'em.

A suggestion/nit which I'm fine to see ignored: the
text in section 4 (Privacy Considerations) isn't that
clear and might be helped via one or a couple of examples
e.g. by adding:

"For example, a value such as 'mumblemumble.alt'
would be a clear privacy leak."

And for bonus points, one might further add:

"In addition if a name ending in .alt is sufficiently unique,
long-lasting and frequently leaks into the global DNS, then
regardless of how the value is constructed, that value can
act like a web cookie, with all the associated downsides of
(re-)identification."

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Suzanne Woolf]

Dear colleagues,


This message will serve to start a Working Group Last Call on “The ALT Special 
Use Top Level Domain” 
(https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/). Due to the 
end-of-year holidays, we’re starting it now and will give it four weeks.


As you’ve seen from Paul Hoffman’s email, the authors have updated to version 
19 based on the feedback they heard at IETF 115. Thanks Paul and Warren!


The WG is very familiar with this document by now, and the WGLC is to determine 
whether the document has rough consensus to progress. The chairs need to know 
whether you support it (which, for this purpose, includes “I can live with 
it”), or actively oppose publishing it.


Please also assume that any necessary liaison communications with ICANN will be 
undertaken if this document has WG consensus to move forward. Managing the 
potential for misunderstanding or differences of opinion among relevant 
organizations is the primary reason why the IETF has liaison relationships. The 
IETF liaison to the ICANN Board is Harald Alvestrand, who has been monitoring 
the conversations about alt-tld on the mailing list and has discussed the draft 
with the chairs and with Rob Wilton as the responsible AD.


Start date: 13 December 2022

End date:  10 January 2023



Many thanks,

Suzanne, Tim, and Benno



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

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

[Andrew Sullivan]

Hi,

Thanks for the review.

On Sat, Apr 01, 2017 at 03:17:27PM -0500, Stephane Bortzmeyer wrote:
> Editorial :
> 
> Section 1:
> 
> "and that should not be resolved" I cannot parse it. Missing "it"?

Yes.

> 
> Section 5 :
> 
> After "and anyone watching queries along the path", add a reference to
> RFC 7626?

A good idea.  Thanks.

> Normative references:
> 
> Why is RFC 6303 a normative reference? It is no longer used.

Should be removed.  Thanks.

> Why is RFC 7686 a normative reference? It is just an example.

Yeah, we should move it.  Thanks.

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

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

[John Levine]

In article 

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

[Brian Dickson]

On Mon, Apr 3, 2017 at 7:37 PM, George Michaelson  wrote:

> I think that's a useful mail. So in that sense, I have a question:
> Would you say anything to this, were you in edit mode, on a draft
> going to LC if that draft didn't say it?
>
> If you had a draft requesting a TLD to "exist" in some sense: in or
> not in a registry; passed or not passed into the DNS; delegated or not
> delegated via ICANN; would you reference the IAB document? If not, why
> not?
>

Whether to reference the IAB document?
In DNS - no, since the draft would conflict with the IAB statement. It
would open the ICANN-IETF can of worms, which the IAB document suggests
(directs?) we not do.
Delegated or not, doesn't come into it I don't think.

Not in DNS, but in a registry? Maybe, but only to make some distinction
between what the IAB document says, and some compelling reason.

Honestly, I think the IAB statement should appear pretty much as widely as
possible.
It should be up front on the DNSOP WG page.
If it could be added to "note well", that would be cool, too.
If there was a URL shortener, make the shortened URL one of the IETF
wireless SSIDs! :-)

As far as any TLD in the DNS is concerned -- there are only two basic ways
that can explicitly happen with a signed root - a delegation (signed or
unsigned), or a DNAME.
I don't think there is a third way, except maybe with specific RRTYPE(s) in
the root zone, for which I don't think a defined mechanism exists,
procedure-wise.

Brian



>
> -George
>
> On Tue, Apr 4, 2017 at 11:26 AM, Brian Dickson
>  wrote:
> > In response to the latest comments by Paul Hoffman and George Michaelson,
> > I'd like to offer my $0.02 on the meaning and purpose of the alt TLD vs
> the
> > IAB statement.
> >
> > My read is (whether or not it is correct) that there are three
> possibilities
> > for a special name.
> >
> > The first is, a special but needs DNS resolution. This is one case the
> IAB
> > says, "register it and put it in DNS under arpa". (I don't think that is
> > controversial at all, and a wise recommendation.)
> >
> > The second is, a Very Special, but does not belong in DNS.  (IAB second
> > option.)
> >
> > The third is, a Not Very Special, and not in DNS. Not registered, FCFS.
> Not
> > covered by the IAB statement by virtue of not being registered, but IMHO
> not
> > conflicting with the IAB statement.
> >
> > Very Special: It gets its entry in the registry in order to establish its
> > uniqueness, but isn't in DNS, so no entry under arpa. This avoids the
> > possibility of multiple mechanisms for interception fighting with each
> > other, since the behavior is (or should be) name-driven. Also wise, and
> also
> > in-scope for the IAB statement.
> >
> > Not Very Special: whoever wants the name, is reasonably sure it won't be
> > exposed outside of a closed environment (e.g. a single application), and
> > doesn't want or need to go through the 6761 process to get the name
> > registered.
> >
> > Not Very Special is basically 6761 without the registry, in a first-come,
> > first-served, no guarantees kind of way.
> >
> > The "onion" thing showed the need for some way of avoiding TLDs, avoiding
> > conflicting names, and avoiding heavy process, IMHO. And I think "alt" is
> > the right answer.
> >
> > Also IMHO, making it "alt.arpa" would be very confusing; I think any time
> > someone sees "arpa" as the TLD, they should believe it exists in the DNS.
> >
> > Having "alt" be the parent name here, and not be in the DNS, keeps things
> > clear even to non-DNS folks.
> >
> > And finally, maybe there is a use case for FCFS local-use names that
> kind-of
> > are in the DNS. If such a need were to arise, then THAT would be
> something
> > where "alt.arpa" would make sense. But given the relative ease in adding
> > things under arpa, I don't see a good reason for creating non-registered
> > FCFS when registered FCFS is available, under arpa.
> >
> > Brian
> >
> > ___
> > 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

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

[George Michaelson]

I could take it either way. narrow doc is narrow purpose? don't ref it.

doc is highly visible, will be (mis)interpreted as being relevant?
disavow it (which implies ref it)

doc is highly visible, problem next door? Seek guidance.

-G

On Tue, Apr 4, 2017 at 11:40 AM, Suzanne Woolf  wrote:
> Hi,
>
> On one specific point:
>
>> On Apr 3, 2017, at 9:02 PM, George Michaelson  wrote:
>>
>> Lastly, I think the IAB note pretty strongly goes to 'we dont do that
>> any more' 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’m fine with “the draft needs to be updated with reference to the relevance 
> of .arpa” as a WGLC comment, so the below is intended as contributing to the 
> discussion, not repressing it.
>
> On the intentions and role of the IAB:
>
> An IAB statement isn’t an IETF document of any kind, never mind a standards 
> track document, and can’t tell the IETF what to do— including this WG.  So 
> the IAB certainly can’t say “We don’t do that any more” as a policy statement 
> about an IETF registry such as the special use names registry. However, RFC 
> 3172 is an IETF BCP, and provides direction to the IETF and the IAB (as admin 
> authority for .arpa) on the requirements that should be followed for a 
> delegation in .arpa. So as a WGLC comment, this suggests the addition of a 
> reference to RFC 3172 and the applicability of the .arpa policy there to the 
> justification for alt.
>
> It’s my view that, as Paul says, the IAB note was written about a different 
> case than the alt-tld draft was: the IAB was attempting to point out an 
> alternative to asking for a delegation in the root zone in the case that a 
> special use name is supposed to be resolvable in the DNS. The alt-tld draft 
> is about names that aren’t intended to be resolvable in the DNS in the first 
> place.
>
> However, since I was a contributor to the IAB document, it puts me in an 
> awkward position to be interpreting it for DNSOP on behalf of the IAB. If 
> further clarification on the IAB statement would be useful, we should 
> explicitly request it.
>
> best,
> Suzanne
>
>>
>> I can do this as a nit in the GIT if you prefer.
>>
>> -G
>>
>>
>> On Mon, Apr 3, 2017 at 7:51 PM, Paul Hoffman  wrote:
>>> On 3 Apr 2017, at 17:27, George Michaelson wrote:
>>>
 isn't this OBE and it's alt.arpa now?
>>>
>>>
>>> No.
>>>
 Serious question btw. I do not think that this document can proceed
 without significant re-drafting to a 2LD if that is the case.
>>>
>>>
>>> Are you saying that because of:
>>>
>>> https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/
>>> If so, I suspect you read it wrong. My reading is that the IAB is only
>>> saying that names that are supposed to act like DNS names (that is, to exist
>>> in the public DNS) need to be under .arpa. This draft explicitly is about
>>> non-DNS contexts.
>>>
>>> --Paul Hoffman
>>
>> ___
>> 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

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

[George Michaelson]

I think that's a useful mail. So in that sense, I have a question:
Would you say anything to this, were you in edit mode, on a draft
going to LC if that draft didn't say it?

If you had a draft requesting a TLD to "exist" in some sense: in or
not in a registry; passed or not passed into the DNS; delegated or not
delegated via ICANN; would you reference the IAB document? If not, why
not?

-George

On Tue, Apr 4, 2017 at 11:26 AM, Brian Dickson
 wrote:
> In response to the latest comments by Paul Hoffman and George Michaelson,
> I'd like to offer my $0.02 on the meaning and purpose of the alt TLD vs the
> IAB statement.
>
> My read is (whether or not it is correct) that there are three possibilities
> for a special name.
>
> The first is, a special but needs DNS resolution. This is one case the IAB
> says, "register it and put it in DNS under arpa". (I don't think that is
> controversial at all, and a wise recommendation.)
>
> The second is, a Very Special, but does not belong in DNS.  (IAB second
> option.)
>
> The third is, a Not Very Special, and not in DNS. Not registered, FCFS. Not
> covered by the IAB statement by virtue of not being registered, but IMHO not
> conflicting with the IAB statement.
>
> Very Special: It gets its entry in the registry in order to establish its
> uniqueness, but isn't in DNS, so no entry under arpa. This avoids the
> possibility of multiple mechanisms for interception fighting with each
> other, since the behavior is (or should be) name-driven. Also wise, and also
> in-scope for the IAB statement.
>
> Not Very Special: whoever wants the name, is reasonably sure it won't be
> exposed outside of a closed environment (e.g. a single application), and
> doesn't want or need to go through the 6761 process to get the name
> registered.
>
> Not Very Special is basically 6761 without the registry, in a first-come,
> first-served, no guarantees kind of way.
>
> The "onion" thing showed the need for some way of avoiding TLDs, avoiding
> conflicting names, and avoiding heavy process, IMHO. And I think "alt" is
> the right answer.
>
> Also IMHO, making it "alt.arpa" would be very confusing; I think any time
> someone sees "arpa" as the TLD, they should believe it exists in the DNS.
>
> Having "alt" be the parent name here, and not be in the DNS, keeps things
> clear even to non-DNS folks.
>
> And finally, maybe there is a use case for FCFS local-use names that kind-of
> are in the DNS. If such a need were to arise, then THAT would be something
> where "alt.arpa" would make sense. But given the relative ease in adding
> things under arpa, I don't see a good reason for creating non-registered
> FCFS when registered FCFS is available, under arpa.
>
> Brian
>
> ___
> 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

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

[George Michaelson]

On Mon, Apr 3, 2017 at 8:13 PM, Paul Hoffman  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

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

[Paul Hoffman]

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.



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.



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.


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.



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.


--Paul Hoffman

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

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

[George Michaelson]

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.

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.

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*

Lastly, I think the IAB note pretty strongly goes to 'we dont do that
any more' 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.

-G


On Mon, Apr 3, 2017 at 7:51 PM, Paul Hoffman  wrote:
> On 3 Apr 2017, at 17:27, George Michaelson wrote:
>
>> isn't this OBE and it's alt.arpa now?
>
>
> No.
>
>> Serious question btw. I do not think that this document can proceed
>> without significant re-drafting to a 2LD if that is the case.
>
>
> Are you saying that because of:
>
> https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/
> If so, I suspect you read it wrong. My reading is that the IAB is only
> saying that names that are supposed to act like DNS names (that is, to exist
> in the public DNS) need to be under .arpa. This draft explicitly is about
> non-DNS contexts.
>
> --Paul Hoffman

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

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

[Paul Hoffman]

On 3 Apr 2017, at 17:27, George Michaelson wrote:


isn't this OBE and it's alt.arpa now?


No.


Serious question btw. I do not think that this document can proceed
without significant re-drafting to a 2LD if that is the case.


Are you saying that because of:
   
https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/
If so, I suspect you read it wrong. My reading is that the IAB is only 
saying that names that are supposed to act like DNS names (that is, to 
exist in the public DNS) need to be under .arpa. This draft explicitly 
is about non-DNS contexts.


--Paul Hoffman

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

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

[George Michaelson]

isn't this OBE and it's alt.arpa now?

Serious question btw. I do not think that this document can proceed
without significant re-drafting to a 2LD if that is the case.

G

On Sat, Apr 1, 2017 at 3:17 PM, Stephane Bortzmeyer  wrote:
> On Sun, Mar 12, 2017 at 07:20:55PM -0400,
>  Suzanne Woolf  wrote
>  a message of 92 lines which said:
>
>> This message opens a Working Group Last Call for:
>>
>> "The ALT Special Use Top Level Domain"
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ 
>> 
>
> I've read -08 and I believe I understand this draft. I'm not convinced
> it's useful (most users of alternative resolution systems won't use it
> and, anyway, I'm not even sure it will be added in the Special-Use
> registry, which was wrongly frozen by the IESG) but I don't see big
> issues with the draft, it seems to me it correctly describes the new
> TLD.
>
> Editorial :
>
> Section 1:
>
> "and that should not be resolved" I cannot parse it. Missing "it"?
>
> Section 5 :
>
> After "and anyone watching queries along the path", add a reference to
> RFC 7626?
>
> Normative references:
>
> Why is RFC 6303 a normative reference? It is no longer used.
>
> Why is RFC 7686 a normative reference? It is just an example.
>
> ___
> 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

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

[Stephane Bortzmeyer]

On Sun, Mar 12, 2017 at 07:20:55PM -0400,
 Suzanne Woolf  wrote 
 a message of 92 lines which said:

> This message opens a Working Group Last Call for:
> 
> "The ALT Special Use Top Level Domain"
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ 
> 

I've read -08 and I believe I understand this draft. I'm not convinced
it's useful (most users of alternative resolution systems won't use it
and, anyway, I'm not even sure it will be added in the Special-Use
registry, which was wrongly frozen by the IESG) but I don't see big
issues with the draft, it seems to me it correctly describes the new
TLD.

Editorial :

Section 1:

"and that should not be resolved" I cannot parse it. Missing "it"?

Section 5 :

After "and anyone watching queries along the path", add a reference to
RFC 7626?

Normative references:

Why is RFC 6303 a normative reference? It is no longer used.

Why is RFC 7686 a normative reference? It is just an example.

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

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

[Paul Wouters]

On Sun, 12 Mar 2017, Suzanne Woolf wrote:


This message opens a Working Group Last Call for:
"The ALT Special Use Top Level Domain"
https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/
Intended status: Proposed Standard

Per the discussion in our interim meeting a couple of weeks ago, the editors 
have revised this document and the chairs are opening a Working Group Last 
Call. 

Please let us know, on the list, whether you support advancing 
draft-dnsop-alt-tld-08 to the IESG for publication.

The document has been stable for awhile except for one significant change in 
the new version. As discussed in the interim, it now clarifies that “.alt” is 
intended for
use with domain names intended to be resolved outside of the DNS protocol. 

With IETF 98 upon us, we’re giving this a little extra time (3 weeks).

Starts: 13 March 2017
Ends:  3 April 2017


How can we start a Last Call on this when we still have no idea within dnsop or
even within the IETF in general whether we are going to continue issuing
Special Use domains?

And aren't we still in the process of getting a problem statement
completed as RFC?

I also thought we were currently not letting anyone use the Special-Use
domains RFC 6761 for any new requests? If we are allowing this, should
we also not do additional calls for the other requests that have been
pending?

It seems the chairs are making a decision in this problem space by
starting a Last Call now, which I think is not the right continuation
of the process we started on.

Paul

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

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

[Suzanne Woolf]

This message opens a Working Group Last Call for:

"The ALT Special Use Top Level Domain"
https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ 

Intended status: Proposed Standard

Per the discussion in our interim meeting a couple of weeks ago, the editors 
have revised this document and the chairs are opening a Working Group Last 
Call. 

Please let us know, on the list, whether you support advancing 
draft-dnsop-alt-tld-08 to the IESG for publication.

The document has been stable for awhile except for one significant change in 
the new version. As discussed in the interim, it now clarifies that “.alt” is 
intended for use with domain names intended to be resolved outside of the DNS 
protocol. 

With IETF 98 upon us, we’re giving this a little extra time (3 weeks).

Starts: 13 March 2017
Ends:  3 April 2017


thanks,
Suzanne & Tim




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