[DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-22.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This Internet-Draft is a work item of the Domain Name System Operations WG of 
the IETF.

Title   : The ALT Special Use Top Level Domain
Authors : Warren Kumari
  Paul Hoffman
  Filename: draft-ietf-dnsop-alt-tld-22.txt
  Pages   : 13
  Date: 2023-03-03

Abstract:
   This document reserves a TLD label, "alt" to be used in non-DNS
   contexts.  It also provides advice and guidance to developers
   developing alternative namespaces.

   [ This document is being collaborated on in Github at
   .  The most
   recent version of the document, open issues, etc should all be
   available here.  The authors (gratefully) accept pull requests. ]


The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld-22

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-alt-tld-22


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


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

Re: [DNSOP] AD review of draft-ietf-dnsop-alt-tld-21

[Warren Kumari]

On Fri, Mar 03, 2023 at 2:53 PM, Rob Wilton  wrote:

> Hi authors, WG,
>
> Here are my AD review comments on -21 of draft-ietf-dnsop-alt-tld. They
> are all minor/nit comments, meaning that I'll leave it to the authors
> discretion as to how they want to handle these comments.
>
> Minor level comments:
>
> (1) p 3, sec 2. The alt Namespace
>
> Groups wishing to create new alternative namespaces may create their
> alternative namespace under a label that names their namespace under the
> .alt pseudo-TLD. The .alt namespace is unmanaged.
>
> This seems slightly strong given that the ISE draft is planning on setting
> up a registry somewhere. So, perhaps "The .alt namespace is not managed by
> the IETF or IANA"?
>

Good point.

Here is the original with a bit more text for context:
"The .alt namespace is unmanaged. This document does not define a registry
or governance model for the .alt namespace."

I don't really know if GNU creating a registry really counts at "managing"
the .alt namespace, but we can skip that philosophical question by
rewording it like so:

"This document defines neither a registry nor governance model for the .alt
namespace, as it is not managed by the IETF or IANA. "


(2) p 3, sec 2. The alt Namespace
>
>
> This document
> does not define a registry or governance model for the .alt namespace.
> Developers, applications and users should not expect unambiguous mappings
> from names to name resolution mechanisms.
>
>
> Is "Developers, applications, users should not expect unambiguous
> mappings" a bit strong? A possible alternative could be: "Developers,
> applications and users are not guaranteed to have unambiguous mappings from
> names to name resolution mechanisms."
>

Hmmm - I'm not sure if it is actually a bit strong, I think that the issue
is more that we cannot really tell developers or users to "expect" anything
— my auntie might well expect some.name.gns.alt to be an unambiguous
mapping, and telling her that she shouldn't expect this is silly - she
doesn't read RFCs[0]

I changed this to "There is no guarantee of unambiguous mappings from names
to name resolution mechanisms." ? I removed the "Developers, applications
and users" wording as it just opens the question of who should expect this
(cats?), or who might be guaranteed anything (chimps?).

(3) p 3, sec 2. The alt Namespace
>
> Currently deployed projects and protocols that are using pseudo-TLDs may
> choose to move under the .alt pseudo-TLD, but this is not a requirement.
>
> I was wondering whether we could we be slightly stronger here and use
> "recommended to move" rather than "may choose to move"? I.e., I think that
> the IETF position could reasonably be that we would like these to all turn
> up under alt and not squat in the root namespace.
>

This works for me - it's not a requirement, and so people can happily
ignore it. Of course, even if it were a requirement, people can still
happily ignore it… (
https://i.cbc.ca/1.3173445.1438223040!/fileImage/httpImage/image.jpg_gen/derivatives/16x9_780/winnipeg-blue-bombers.jpg
)


> Nit level comments:
>
> (4) p 6, sec Appendix A. Changes / Author Notes.
>
> * During AD review, made a few more requested changes
>
> As a minor nit, I think that these comments were during the WGLC, rather
> than AD review.
>


Fair 'nuff, fixed.

I also added some additional names to the acknowledgement section - *huge*
apologies to anyone we may have missed…

Warren.

[0]: I know this for a fact, as she doesn't actually exist :-P



On Fri, Mar 03, 2023 at 2:53 PM, Rob Wilton  wrote:

> Hi authors, WG,
>
> Here are my AD review comments on -21 of draft-ietf-dnsop-alt-tld. They
> are all minor/nit comments, meaning that I'll leave it to the authors
> discretion as to how they want to handle these comments.
>
> Minor level comments:
>
> (1) p 3, sec 2. The alt Namespace
>
> Groups wishing to create new alternative namespaces may create their
> alternative namespace under a label that names their namespace under the
> .alt pseudo-TLD. The .alt namespace is unmanaged.
>
> This seems slightly strong given that the ISE draft is planning on setting
> up a registry somewhere. So, perhaps "The .alt namespace is not managed by
> the IETF or IANA"?
>
> (2) p 3, sec 2. The alt Namespace
>
> This document
> does not define a registry or governance model for the .alt namespace.
> Developers, applications and users should not expect unambiguous mappings
> from names to name resolution mechanisms.
>
> Is "Developers, applications, users should not expect unambiguous
> mappings" a bit strong? A possible alternative could be: "Developers,
> applications and users are not guaranteed to have unambiguous mappings from
> names to name resolution mechanisms."
>
> (3) p 3, sec 2. The alt Namespace
>
> Currently deployed projects and protocols that are using pseudo-TLDs may
> choose to move under the .alt pseudo-TLD, but this is not a requirement.
>
> I was wondering whether we could we be slightly stronger here 

[DNSOP] Updated: Compact Denial of Existence

[Shumon Huque]

Thanks for your comments. We've posted an updated draft (-01):

  https://datatracker.ietf.org/doc/html/draft-huque-dnsop-compact-lies-01

Some smaller updates:

* Remove the "Lies" moniker. We now refer to this mechanism as just
  Compact Denial of Existence, or Compact Answers if you prefer pithy.
  (Renaming the draft filename is too much work - we'll do that if/when
  the WG adopts this.)
* Move the various types of responses into subsections and provide
  an expanded treatment of them.
* Update the operational implications section with the observation
  by Paul Vixie that this can cause additional queries from name
  lookup functions/methods.

But the main change is to move from the ENT distinguisher RR type
to an explicit one for NXDOMAIN (with mnemonic NXNAME).

When I originally devised the ENT distinguisher, it was because
we could use the same type bitmap pattern (NSEC RRSIG) to identify
NXDOMAIN at those implementations and also at other implementations
like Cloudflare that used a broad bit pattern of many types in ENT
responses. Secondarily, I thought this would cause less work at servers
since ENTs are far less common than NXDOMAIN (but that is likely just
in the noise compared to the crypto work to generate the response).
After chatting this through with Christian/Cloudflare, we've now
agreed that a precise distinguisher for NXDOMAIN is better. We hope
others will also agree. There are more details in Section 2.

Cloudflare colleagues also have an interest in using the NXDOMAIN
signal to allow resolvers to modify the response code from NOERROR
to NXDOMAIN back to non-validating clients. I'm not yet persuaded
that this is worth doing, but the draft enables that. Ultimately, if all
client systems run validating stubs/resolvers, they will need to fully
authenticate the contents of the DNS message (the RCODE is then
merely a hint for what to look for, and not essential to that task).

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

[DNSOP] dnsop - Requested session has been scheduled for IETF 116

["IETF Secretariat"]

Dear Tim Wicinski,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


dnsop Session 1 (2:00 requested)
Thursday, 30 March 2023, Session I 0030-0230
Room Name: G403 size: 175
-


iCalendar: https://datatracker.ietf.org/meeting/116/sessions/dnsop.ics

Request Information:


-
Working Group Name: Domain Name System Operations
Area Name: Operations and Management Area
Session Requester: Tim Wicinski


Number of Sessions: 1
Length of Session(s): 
Number of Attendees: 160
Conflicts to Avoid: 

   
 Can't meet: Tuesday early afternoon, Tuesday late afternoon, Wednesday 
morning, Wednesday early afternoon, Wednesday late afternoon, Thursday morning, 
Thursday early afternoon, Thursday late afternoon

Participants who must be present:
  Benno Overeinder
  Suzanne Woolf
  Tim Wicinski
  Warren Ace Kumari

Resources Requested:

Special Requests:
  
-


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

[DNSOP] Publication has been requested for draft-ietf-dnsop-alt-tld-21

[Tim Wicinski via Datatracker]

Tim Wicinski has requested publication of draft-ietf-dnsop-alt-tld-21 as 
Proposed Standard on behalf of the DNSOP working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/


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

[DNSOP] AD review of draft-ietf-dnsop-alt-tld-21

[Rob Wilton (rwilton)]

Hi authors, WG,

Here are my AD review comments on -21 of draft-ietf-dnsop-alt-tld.  They are 
all minor/nit comments, meaning that I'll leave it to the authors discretion as 
to how they want to handle these comments. 


Minor level comments:

(1) p 3, sec 2.  The alt Namespace

   Groups wishing to create new alternative namespaces may create their
   alternative namespace under a label that names their namespace under
   the .alt pseudo-TLD.  The .alt namespace is unmanaged.

This seems slightly strong given that the ISE draft is planning on setting up a 
registry somewhere.  So, perhaps "The .alt namespace is not managed by the IETF 
or IANA"?


(2) p 3, sec 2.  The alt Namespace

 This document
   does not define a registry or governance model for the .alt
   namespace.  Developers, applications and users should not expect
   unambiguous mappings from names to name resolution mechanisms.

Is "Developers, applications, users should not expect unambiguous mappings" a 
bit strong?  A possible alternative could be: "Developers, applications and 
users are not guaranteed to have unambiguous mappings from names to name 
resolution mechanisms."


(3) p 3, sec 2.  The alt Namespace

   Currently deployed projects and protocols that are using pseudo-TLDs
   may choose to move under the .alt pseudo-TLD, but this is not a
   requirement.

I was wondering whether we could we be slightly stronger here and use 
"recommended to move" rather than "may choose to move"?  I.e., I think that the 
IETF position could reasonably be that we would like these to all turn up under 
alt and not squat in the root namespace.



Nit level comments:

(4) p 6, sec Appendix A.  Changes / Author Notes.

   *  During AD review, made a few more requested changes

As a minor nit, I think that these comments were during the WGLC, rather than 
AD review.

Regards,
Rob

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