Re: [Last-Call] [art] Artart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Mon, Sep 13, 2021 at 5:23 AM tom petch <ietfc@xxxxxxxxxxxxx> wrote:
From: art <art-bounces@xxxxxxxx> on behalf of Bob Hinden <bob.hinden@xxxxxxxxx>
Sent: 11 September 2021 17:03

Hi Warren,

> On Sep 10, 2021, at 4:19 PM, Warren Kumari <warren@xxxxxxxxxx> 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 the
> use of "Updates" (see draft-kuehlewind-update-tag); different 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 “Experimental" RFC update an RFC at “Standard”?    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.

<tp>

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 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 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

--
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux