From nobody Mon Sep 13 18:25:23 2021 Return-Path: X-Original-To: art@ietfa.amsl.com Delivered-To: art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625C23A07F2 for ; Mon, 13 Sep 2021 18:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6H1N_uov-2J for ; Mon, 13 Sep 2021 18:25:16 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5E73A07DB for ; Mon, 13 Sep 2021 18:25:15 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id l9so10298467vsb.8 for ; Mon, 13 Sep 2021 18:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BN6JlIMMpLhvXk15P/RHE+IVZaVycvKfErGkomIQdkg=; b=S4+LeJNyycnmaQjiNmghTK09DcQv5udTHuq2AL4dPHC8+8+WeNR1ZM+zFaE0RRR2jt w8HKJJUl8iZnbs1ZqhASfgetdudwH/N768k6FZB3GRm44R8/i1eIfUbenpB3jr2Z+B+/ toCux8I7XMBxAxfBdFZw87IjO2H8LlkGFbWRguSaUGM/tfx9JnNs/egfK59ucz4xsG5P HCy7r2IAsQG4urT/ScJUlPOZALBGO2bsiYdaq7gvY6ulzbPkKZ/iVOhbYjkFpqYWOJkS +ix1+9bCxp3O7yO12AMKLdINsyl0ca2khdLuAd7fQYmnNoenDobMfdxxAaL5ewF7QHnD N6eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BN6JlIMMpLhvXk15P/RHE+IVZaVycvKfErGkomIQdkg=; b=4/QyoF4OZ2i69ZmcgczjO/yE+vMOluiU8pqg8leCJD7DpTYm7Ua7E3tOztqv/6EmiD xX+XLIx53eGUvUmcQKhVSS7YyKJ77E90OtOHy7YZklqU9KIdAov87St/A/RDZrEQGJp/ pa+88t79dFipggMVSRVUng+1rPHmFI2MNDutoxNIniDkj7/DXQddbCpF+Q87h/G53Q31 KmkGptGnmITWJqhuaIfmn313HgH4qxgvokQUvK6gPW6o4A24DgOGDUV8XzhM3rDDst0y uD1n/l8EQEKFPolxrdppmjot7CdIjiozdSt/AITo0QBWTfX2ihSJ7aTsTndljJD/KKu1 fbNA== X-Gm-Message-State: AOAM5324X5nUBoVOJifBfi2mOJFzZMH9Gn8MrV3szGd2AkU8uvI69h/A NSnXmcfzsvLbp8ZtusTcWUYo1k98HgZdP3Ac8eqy/g== X-Google-Smtp-Source: ABdhPJwQCsDCB4XTw676nKyVWUPLviAXVBO8B6kXhSOJxNX7jvXDz9++Wu5W7dNMoRKE2K6Nhb3iWvrcyz2Ggh1XfQ8= X-Received: by 2002:a67:334d:: with SMTP id z74mr903119vsz.37.1631582713652; Mon, 13 Sep 2021 18:25:13 -0700 (PDT) MIME-Version: 1.0 References: <163071535768.12872.16291782186298428894@ietfa.amsl.com> <7A0EC9A6-AF64-40F0-A229-C56E93CCE8DE@verisign.com> <18ba445b-e768-2c33-fca3-76c4aa102b20@nostrum.com> In-Reply-To: From: Warren Kumari Date: Mon, 13 Sep 2021 21:24:37 -0400 Message-ID: To: tom petch Cc: Bob Hinden , "draft-ietf-dnsop-dns-tcp-requirements.all@ietf.org" , "art@ietf.org" , "dnsop@ietf.org" , "last-call@ietf.org" Content-Type: multipart/alternative; boundary="00000000000011f89f05cbea7449" Archived-At: Subject: Re: [art] [Last-Call] Artart last call review of draft-ietf-dnsop-dns-tcp-requirements-12 X-BeenThere: art@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications and Real-Time Area Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2021 01:25:22 -0000 --00000000000011f89f05cbea7449 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Sep 13, 2021 at 5:23 AM tom petch wrote: > From: art on behalf of Bob Hinden < > bob.hinden@gmail.com> > Sent: 11 September 2021 17:03 > > Hi Warren, > > > On Sep 10, 2021, at 4:19 PM, Warren Kumari wrote: > > > > > Seems reasonable to consider, assuming a BCP can update an > Informational RFC? > > > > Any RFC can update any previous RFC? There are some questions about th= e > > use of "Updates" (see draft-kuehlewind-update-tag); different WGs use i= t > > for different things. If you are trying to catch the eye of > > implementers, maybe it would help, but perhaps ask your AD. > > > > Yup, it should be able to. > > W > > Are you sure? > > For example, can an =E2=80=9CExperimental" RFC update an RFC at =E2=80=9C= Standard=E2=80=9D? Can > an RFC from one Stream update an RFC in another Stream? Lots of other > cases come to mind. > > This seems a lot more subtle than any RFC can update any other RFC. > > > > I agree. A case in point is RFC8966 which deprecates TLS1.0 and TLS1.1 > and updates rather a lot of RFC in doing so. Some of these are ISE and t= he > permission of the ISE Editor was sought, and obtained, before going ahead > so I do not think that any I-D from one stream can update any I-D from > another. > > Tom Petch > > Bob > > It seems that some set of lists got dropped from some set of replies. As Robert Sparks helpfully pointed out on last-call list, I was only talking about this "particular potential BCP updating a particular Informational RFC both in the IETF stream.". Mirja, Suresh, and others have tried addressing what exactly Updates actually means (e.g https://datatracker.ietf.org/doc/draft-kuehlewind-update-tag/ ), and the answer is currently still murky and unclear. I can, however, confidently say that this particular potential BCP can very probably update this particular Informational RFC. Probably.... It somewhat depends on how much other ADs think that it is useful that readers of RFC1536 know about this other document. The text in RFC1536 isn't incredibly specific, and different people have different interpretations on "Updates:" -- I personally fall on the side of "Updates/Updates by..." is close to "other related important documents that you should really read to avoid foot canons". Other people feel that Updates is more "Replace text A with text B" or "Skip step 23 if bit 1 is set". One of the best things about the IETF is that we prefer pragmatism and Spencer's "Do the Right Thing" creed over strict rules,regulations and policy. One of the worst things about the IETF is that we prefer pragmatism and Spencer's "Do the Right Thing" creed over strict rules,regulations and policy. W --=20 The computing scientist=E2=80=99s main challenge is not to get confused by = the complexities of his own making. -- E. W. Dijkstra --00000000000011f89f05cbea7449 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Sep 13, 2021 at 5:23 AM tom p= etch <ietfc@btc= onnect.com> wrote:
From: art <art-bounces@ietf.org> on behalf of Bob Hinden <bob.hinden@gmail.com>= ;
Sent: 11 September 2021 17:03

Hi Warren,

> On Sep 10, 2021, at 4:19 PM, Warren Kumari <warren@kumari.net> wrote:
>
> > Seems reasonable to consider, assuming a BCP can update an Inform= ational RFC?
>
> Any RFC can update any previous RFC?=C2=A0 There are some questions ab= out the
> use of "Updates" (see draft-kuehlewind-update-tag); differen= t WGs use it
> for different things. If you are trying to catch the eye of
> implementers, maybe it would help, but perhaps ask your AD.
>
> Yup, it should be able to.
> W

Are you sure?

For example, can an =E2=80=9CExperimental" RFC update an RFC at =E2=80= =9CStandard=E2=80=9D?=C2=A0 =C2=A0 Can an RFC from one Stream update an RFC= in another Stream?=C2=A0 =C2=A0Lots of other cases come to mind.

This seems a lot more subtle than any RFC can update any other RFC.

<tp>

I agree.=C2=A0 A case in point is RFC8966 which deprecates TLS1.0 and TLS1.= 1 and updates rather a lot of RFC in doing so.=C2=A0 Some of these are ISE = and the permission of the ISE Editor was sought, and obtained, before going= ahead so I do not think that any I-D from one stream can update any I-D fr= om another.

Tom Petch

Bob


It seems that some set of lists g= ot dropped from some=C2=A0set of replies.=C2=A0

As= Robert Sparks helpfully pointed out on=C2=A0last-call list, I was only tal= king about this "particular potential BCP updating a particular Inform= ational RFC both in the IETF stream.".
Mirja, Suresh, and ot= hers have tried addressing what exactly Updates actually means (e.g https://datatracker.ietf.org/doc/draft-kuehlewind-update-tag/ ), and the answer is currently still murky and unclear.=C2=A0
--00000000000011f89f05cbea7449--