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: [email protected] > Subject: New Version Notification for draft-jabley-dnsop-refer-00.txt > Date: 12 February 2021 at 10:52:38 EST > To: "Joe Abley" <[email protected]> > > > 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 > >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
