[DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-refer-00.txt

[Joe Abley <[e-mail]>]

Hi all,

I have discovered that without liberal access to bars and hallways at in-person IETF meetings, I no longer know how to tell the difference between ambition and insanity when it comes to technical proposals. I am quite prepared to find out that in this case the needle is at the crazy end of the scale.

Happy Friday!


Joe

> Begin forwarded message:
> 
> From: [e-mail]
> Subject: New Version Notification for draft-jabley-dnsop-refer-00.txt
> Date: 12 February 2021 at 10:52:38 EST
> To: "Joe Abley" <[e-mail]>
> 
> 
> A new version of I-D, draft-jabley-dnsop-refer-00.txt
> has been successfully submitted by Joe Abley and posted to the
> IETF repository.
> 
> Name:		draft-jabley-dnsop-refer
> Revision:	00
> Title:		REFER: A New Referral Mechanism for the DNS
> Document date:	2021-02-12
> Group:		Individual Submission
> Pages:		14
> URL:            https://www.ietf.org/archive/id/draft-jabley-dnsop-refer-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-jabley-dnsop-refer/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-jabley-dnsop-refer
> Htmlized:       https://tools.ietf.org/html/draft-jabley-dnsop-refer-00
> 
> 
> Abstract:
>   The Domain Name System (DNS) incorporates a namespace that is
>   comprised, in practice, of multiple so-called zones.  Each zone is,
>   in principal, a finite tree structure which can be administered
>   autonomously, and is connected to exactly one parent zone and zero or
>   more child zones.  These connection points are known as zone cuts; a
>   parent zone contains information that allows the servers responsible
>   for the child zone to be found.
> 
>   The current DNS specification encodes that information about child
>   zones using an "NS" resource record set in the parent zone, and a
>   corresponding "NS" resource record set in the child zone.  These two
>   resource record sets have identical owner names, class, and resource
>   record type but can differ in other respects such as the time-to-live
>   (TTL) attribute, the resource record data associated with each set
>   and the availability of cryptographic signatures.  This property of
>   being similar, related but potentially different has led to
>   operational complexity.
> 
>   This document proposes a change to how zone cuts are encoded in the
>   parent zone, allowing the resource records in the parent and the
>   child zone to be more clearly distinguished and protected separately
>   using cryptographic signatures.
> 
>   It is not at all clear that this is a good idea.  To restate in
>   stronger terms, the goal of the experiment described in this document
>   is to determine just how bad an idea this is.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
>