Subject: [Rfced-future] Issue #27: do we need to update RFC 2026?

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Sep 2021 10:34:11 +0200

Well, we are really coming down to the wire.  This is one of two issues 
we haven't discussed.

Like RFCs 2028 and 2850, RFC 2026 says that the IAB oversees the RFC 
Editor.  I would have loved it if this were done in the RFC 2850 
update.  However, Brian rightly points out that these two RFCs are part 
of two different BCPs.

The simplest approach would be a one line update to 2026.  One could 
stretch the Errata process and also make the claim that 2026 shouldn't 
have delved into the IAB's relationship with the RFC Editor.  This is an 
especially thin stretch, because 2850 came after 2026, and we really 
were still figuring all of this out.

The one thing I would suggest the group take off the table is have 
draft-iab-rfcefdp-rfc-model update 2026, for the same reasons that it is 
not updating 2850.

What would people like to do?

Eliot

---

From: Scott Bradner <[email-masked]>
Date: Mon, 20 Sep 2021 07:05:06 -0400

just for history's sake

RFC 2026 took the IAB/RFC Editor relationship from RFC 1602 section 1.3.1

	"RFC publication is the direct responsibility of the RFC Editor, under the general
	direction of the IAB"

which expanded the relationship described in RFC 1310

	"The IAB views the RFC publication process to be sufficiently important to warrant
	including the RFC Editor in the IAB membership."

that said, I have no opinion on the question at hand

Scott

> On Sep 20, 2021, at 4:34 AM, Eliot Lear <[email-masked]> wrote:
> 
> Well, we are really coming down to the wire.  This is one of two issues we haven't discussed.
> 
> Like RFCs 2028 and 2850, RFC 2026 says that the IAB oversees the RFC Editor.  I would have loved it if this were done in the RFC 2850 update.  However, Brian rightly points out that these two RFCs are part of two different BCPs.
> 
> The simplest approach would be a one line update to 2026.  One could stretch the Errata process and also make the claim that 2026 shouldn't have delved into the IAB's relationship with the RFC Editor.  This is an especially thin stretch, because 2850 came after 2026, and we really were still figuring all of this out.
> 
> The one thing I would suggest the group take off the table is have draft-iab-rfcefdp-rfc-model update 2026, for the same reasons that it is not updating 2850.
> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 20 Sep 2021 14:03:28 +0000

I would report an errata against 2026, intended it be "hold for document update" and leave it at that.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Sep 2021 09:15:57 +1200

I have the advantage of an extra day's thought about this since Eliot raised it in private email, so ... 

> that said, I have no opinion on the question at hand

The text in 2026 is not catastrophic in terms of the model we are proposing. But it isn't what we would write today. In fact there's an earlier sentence that is even more in need of repair:

   RFCs can be obtained from a number of
   Internet hosts using anonymous FTP, gopher, World Wide Web, and other
   Internet document-retrieval systems.

(Amusingly, draft-danyliw-replace-ftp-pointers needs to update that sentence.)

Bottom line: I agree with Rich Salz. An erratum will suffice.

   Brian

---

From: Lars Eggert <[email-masked]>
Date: Tue, 21 Sep 2021 09:29:06 +0300

Hi,

> Bottom line: I agree with Rich Salz. An erratum will suffice.

if we believe that RFC2026 needs to be updated to reflect the change in relationship between the RFC Editor functions and the overall IETF, I don't think an erratum is an appropriate choice here (esp. not one that would be held "for document update".)

Errata are meant to fix bugs in specifications and should not be used to change what the community meant when it approved an RFC.

Thanks,
Lars

---

From: Eliot Lear <[email-masked]>
Date: Tue, 21 Sep 2021 08:37:18 +0200

Ok.

I understand that there is a volunteer to do an update, but that it is 
intended to be broader.  This leaves a question: is it ok to leave 2026 
in the state that it is in without a small update, while we await the 
big update, or should we have someone do the small update?

Eliot

---

From: Brian Carpenter <[email-masked]>
Date: Tue, 21 Sep 2021 22:54:19 +1200

IMHO this issue with 2026 is quite minor. Lars is correct that it isn't
really an erratum; but is there a better place to store it so that it can
be dealt with as part of a future update?

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

On Tue, 21 Sep 2021, 18:37 Eliot Lear, <[email-masked]> wrote:

> intended to be broader.  This leaves a question: is it ok to leave 2026 in
> the state that it is in without a small update, while we await the big
> update, or should we have someone do the small update?
>
> Eliot
> On 2021-9-21, at 0:15, Brian E Carpenter <[email-masked]> <[email-masked]> wrote:
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Sep 2021 08:30:09 +0200

Given all of this, I propose to close this issue in the issue tracker, 
but leave it with those who are already planning the 2026 update.  
Please comment by the 6th of October.

Eliot

On 21.09.21 12:54, Brian Carpenter wrote:
> IMHO this issue with 2026 is quite minor. Lars is correct that it 
> isn't really an erratum; but is there a better place to store it so 
> that it can be dealt with as part of a future update?
>
> Regards,
>     Brian Carpenter
> On Tue, 21 Sep 2021, 18:37 Eliot Lear, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Ok.
>
>     I understand that there is a volunteer to do an update, but that
>     it is intended to be broader.  This leaves a question: is it ok to
>     leave 2026 in the state that it is in without a small update,
>     while we await the big update, or should we have someone do the
>     small update?
>
>     Eliot
>
>>     On 2021-9-21, at 0:15, Brian E Carpenter<[email-masked]>  <mailto:[email-masked]>  wrote: