IETF Logo Mail Archive

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

Tim Wicinski <tjw.ietf@gmail.com> Mon, 01 May 2023 16:19 UTC

Return-Path: <tjw.ietf@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BF0C153CBF for <dnsop@ietfa.amsl.com>; Mon, 1 May 2023 09:19:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qeGqGyElQa0 for <dnsop@ietfa.amsl.com>; Mon, 1 May 2023 09:19:07 -0700 (PDT)
Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A0C2C1524DB for <dnsop@ietf.org>; Mon, 1 May 2023 09:19:07 -0700 (PDT)
Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-94f0dd117dcso459426366b.3 for <dnsop@ietf.org>; Mon, 01 May 2023 09:19:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682957945; x=1685549945; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MgT6XR2FrECuTKGjV2amEy/OXK5BIIwifsIDhewPYsY=; b=sqYFfolvz2TY+z6bfvnPdUGqe/+mw2uCMzpAWRwa4HEKto5zTXAZ66UBEOUS1fj2Rp LtcelALj447Ox/oqUnwc+FoSiB8KKYDLEU2RH3QXJSYZz34XLB/T+SoT8jJZztgNeLOY /cfShxH0BuEKEn2HWS74EvMwGEY8qbYLcxVwSjXwdvsueoIP4E17Yc1XzYJ3ZEBHLRY3 RPh92Peujuw22ReEv510XktBICFAoSpqdUwMO3f9QgZCqWRD6uXVd5vZP7byVucrwiVM YFI49LD/jUmDBfW8CxFGjom7yYKAxT0I287cJdoi1K3TVYxYTOpYtcpNsuD5/M4ghJQS j5WQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682957945; x=1685549945; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MgT6XR2FrECuTKGjV2amEy/OXK5BIIwifsIDhewPYsY=; b=bXwigcARopJtGVw85B7hLDAL9gNfEKIiBdcGoraPzI10cHmPFgqPB+bGZ9BUtTzLEi nMdlvpUtm5vNrO7HnXREH81PIFZjH7qZBo3OPcEVeT/KCpaKKjJH3BD2FLi8hQq8/x/H caNsuwY/eyplF2zFyzyRCjZqrqH8SxxcyI1AJ+Q858kTvaN2SNk8uQbue6ZAA8Gg7Gco l4zy0sHj2G+wJ1+hGI4D8shsHYEpGyt1N68wuXk3apvF8upnUZFNAt0sOo5F1IyNCY58 9ZdcFbfmqNTnLPyI4NpB3fugeo24w2oedcwNFLZyQtPC6My6Y+d8MjX6matoPrYNo1aV cj7A==
X-Gm-Message-State: AC+VfDxNCI7eYE2Iwwsj8zZphcUZTnEb3Lb6iOotMv7KqMJZbYEr4sZs 4q98jomSnwDBO1IW6m+VMkXomWIaSoGiSnwhz7GSDmY4
X-Google-Smtp-Source: ACHHUZ4h2pMdoIsYl+yM2JnqK4HpMV/aYpwvVxNKloDEXpsI0bGKgeqUxR/kF4H8tC11r5R2nKq7pH2LVqf+FTq0ZyA=
X-Received: by 2002:a17:907:7fa1:b0:94e:fe77:3f47 with SMTP id qk33-20020a1709077fa100b0094efe773f47mr16384421ejc.67.1682957945095; Mon, 01 May 2023 09:19:05 -0700 (PDT)
MIME-Version: 1.0
References: <f5757414-dd3b-8a09-f945-d73cecf556a3@NLnetLabs.nl> <40C193AF-938C-418F-924E-94F4DD358164@icann.org>
In-Reply-To: <40C193AF-938C-418F-924E-94F4DD358164@icann.org>
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Mon, 01 May 2023 12:18:53 -0400
Message-ID: <CADyWQ+HvLwEgd8PZ4khHHAWUB_M2Xg4ZV91U5tok6rYq+zYoxA@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: DNSOP Working Group <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007d4b3d05faa42e5b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cs9jfg0W2OP6-JQdtr61-SVrMb0>
Subject: Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 May 2023 16:19:07 -0000

For the record I agree strongly with Paul here.

Tim, as co-chair but my hat hides my hair

On Mon, May 1, 2023 at 12:10 PM Paul Hoffman <paul.hoffman@icann.org> wrote:

> It would be grand if a bunch more people would speak up on this thread.
>
> --Paul Hoffman, wearing my co-author hat
>
> On Apr 27, 2023, at 1:05 PM, Benno Overeinder <benno@nlnetlabs.nl> wrote:
> >
> > Dear WG,
> >
> > The WGLC was closed for draft-ietf-dnsop-rfc8499bis, and the discussion
> > on lame delegation did not find consensus, but two specific suggestions
> > were put forward.  We would like to include one of them in rfc8499bis if
> > we can get consensus to do so.
> >
> > The chairs are seeking input on the following two suggestions:
> >
> > * Either we leave the definition of “lame delegation” as it is with the
> >  comment that no consensus could be found, or
> >
> > * alternatively, we include a shorter definition without specific
> >  examples.
> >
> > 1) Leaving the definition of lame delegation as in the current
> >   draft-ietf-dnsop-rfc8499bis, and including the addition by the
> >   authors that:
> >
> >   "These early definitions do not match current use of the term "lame
> >   delegation", but there is also no consensus on what a lame delegation
> >   is."  (Maybe change to ... no consensus what *exactly* a lame
> >   delegation is.)
> >
> > 2) Update the definition as proposed by Duane and with the agreement of
> >   some others (see mailing list
> https://mailarchive.ietf.org/arch/msg/dnsop/4E1AQKGivEHtJDB85gSNhofRuyM/):
> >
> >   "A lame delegation is said to exist when one or more authoritative
> >   servers designated by the delegating NS RRset or by the child's apex
> >   NS RRset answers non-authoritatively [or not at all] for a zone".
> >
> > The chairs ask the WG to discuss these two alternative definitions of
> > the term "lame delegation".  We close the consultation period on
> > Thursday 4 May.
> >
> > Regards,
> >
> > Benno
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

v2.23.0 | Report a Bug | By Email