Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09

Shumon Huque <shuque@gmail.com> Mon, 18 September 2023 14:41 UTC

Return-Path: <shuque@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 58AD4C14CEFD; Mon, 18 Sep 2023 07:41:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.107 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 hRjNZezn3_H8; Mon, 18 Sep 2023 07:41:00 -0700 (PDT)
Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 AA6CBC151997; Mon, 18 Sep 2023 07:40:34 -0700 (PDT)
Received: by mail-il1-x133.google.com with SMTP id e9e14a558f8ab-34ff11dfdf2so2398165ab.0; Mon, 18 Sep 2023 07:40:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695048034; x=1695652834; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=OxzfI4Gc+zJKRXeiYzzWaM46N9XNHMx/d8mDgfdr4Ik=; b=eMsWwDCCf88tI43/K84aOZyzigbHv1C70321jv3BXMUAJSOS+IuM1piysCHyuRtJIY IDdb2m9R80zVjHAj0IsO5GS+LsOHxqUnpNRrEVd+NURaYdOo93FTN1amo61c514OyW4A riXdtmAlUwdFs6L54Pe4wCnprdtGIFVG03pjC3xw2bkkpgCclwmAoZCjYn0zliwjBJwF 3pIOVtPRG1VSwPvtTa1UEfqmWZmm73NpcV4seMvS5pbRRIlIS/yqXaADE+0Ywn0AlWe/ 9FxDEuH9L+I5y5m6y5asaCmmkJFlxe5UuT1UgEML96BYb9pQ1LJftSmwVcY7z8EbhWbn U04Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695048034; x=1695652834; 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=OxzfI4Gc+zJKRXeiYzzWaM46N9XNHMx/d8mDgfdr4Ik=; b=DZjCjIuugdezzDXeZc3yRQFkJy2MO5ihGkw/GOM1eFpAeT2B0eQfhQ3rzmWvaih2MG K8GfjIR5RNxvn0/UTHqlp7bkEkOL35Z/Z1U+B63hzKXklJAsVlnWHXlSZwSGeIrzS59E poOwm0Dx8E6wY2ZFJ+8N+CBXYL1sQKb+WS6LyfyqGnnD+MJoTGEPI0oCyP39K2++CboD z1hDgzjsgbXPR8HV7DvnNlnq61iPgFGzJN5u/x3525ahBMS85EDLg+pcN0yLVgDWrvgN DsDURxmZ62NhxzHTUL6Bndm2wL0XgtMtEt0+tM/lDB9B3D0X7LINbPE4CV+eJkvzDQdC ji7A==
X-Gm-Message-State: AOJu0YwwegxdmNAkveCmoEePQRYPO97s9Z4Tez+r1meOICAr6XTDs5VH cqXEKfQkcgUSx1qLUgOD0GcVfI85U5zCq8uwGDM=
X-Google-Smtp-Source: AGHT+IGsT1bkfdUHD/dxTEYTVdmmnBvI7SFrnxRBei7KZvKn9QBpYxtLdBmNZTuLYbGKzvlR9DAYO+QDcr96NqvBkk0=
X-Received: by 2002:a92:605:0:b0:34f:41ba:7c87 with SMTP id x5-20020a920605000000b0034f41ba7c87mr9756041ilg.4.1695048033986; Mon, 18 Sep 2023 07:40:33 -0700 (PDT)
MIME-Version: 1.0
References: <C9375D8C-CB52-4774-8B02-4802A8517EC7@akamai.com> <7502C25E-3788-43DF-B442-CF58B230D26D@icann.org> <8D4F276F-52C5-425F-B2C3-5CD772B24F7A@akamai.com> <9a9db7ec-6970-0211-d0e5-e387e3bc62fa@nohats.ca>
In-Reply-To: <9a9db7ec-6970-0211-d0e5-e387e3bc62fa@nohats.ca>
From: Shumon Huque <shuque@gmail.com>
Date: Mon, 18 Sep 2023 10:40:22 -0400
Message-ID: <CAHPuVdVtyppj0wZddsJda6_F5uTDA6yocvYQHdVH0xYAVQ=ekA@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, Paul Hoffman <paul.hoffman@icann.org>, "gen-art@ietf.org" <gen-art@ietf.org>, dnsop WG <dnsop@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f170360605a31fa2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FZRMPLXVXCjpEpfbRK33tAuKdR0>
Subject: Re: [DNSOP] [Last-Call] [Ext] Genart last call review of draft-ietf-dnsop-rfc8499bis-09
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, 18 Sep 2023 14:41:05 -0000

On Mon, Sep 18, 2023 at 9:34 AM Paul Wouters <paul@nohats.ca> wrote:

> On Sun, 17 Sep 2023, Salz, Rich wrote:
>
> [ speaking as individual only ]
>
> >>> On the other hand, spending a week or two repeating a cycle to get an
> important term in the current document seems like a better solution.
> >
> >> If the WG agrees that this is an important term, sure.
> >
> > Well, if the IETF has consensus :)  I'm raising the issue during this
> last call that "round-robin" should be in the list of defined terms.
>
> I would say that if the WG didn't think it was important at the time by
> forgetting it, it probably is not an "important term", and I can see
> this not being fixed in an IETF LC anymore as an acceptable outcome.
>
> Especially as the DNS Terminology document seems to be getting refreshed
> pretty regularly to begin with.
>
> But also, I didn't find a good definition of round robin in existing
> RFCs either. There is a mention in rfc1794 but it doesn't really define
> the term there. So I am not sure what the DNS Terminology document would
> reference?
>

I agree.

My personal experience is that it isn't a widely used term and it's been
more
than a decade since I last heard it. The fact that no-one even brought it up
at any point during the development of this doc or its predecessors seems
to
confirm that.

Back then, my recollection was there were 2 distinct meanings of round robin
DNS: the first was simply a Resource Record Set with multiple Resource
Records in it, where the DNS server returned the constituent records in the
RRset in a rotated or shuffled manner. That is in fact the typical behavior
of
many current DNS implementations, so I think that is already covered by the
inclusion of the term RRset in the document.

The second meaning was from implementations that selectively returned
one record from the RRset in the answer, and rotated the selection of that
record in response to successive queries. By spec, since RRsets are "atomic"
units where all the records have to be returned in the response, this is an
example of a non-standard DNS trick. There are many other examples of
such non-standardized response generation mechanisms (GLSB, weighted
answers, etc), and none of those are documented in the DNS terminology
BCP. It would probably not be appropriate to do so. If necessary, those
could
be documented separately in an informational document.

Shumon.