Subject: [Rfced-future] Issues 26, 27, 28, 29, 30, 32, 33, and 35 on updates to various RFCs

From: Eliot Lear <[email-masked]>
Date: Tue, 18 May 2021 11:20:23 +0200

This goes to the work that John Klensin did in his review.  As you may recall, John gave recommendations in each case.  Some of these recommendations are probably beyond the scope of this group (RFC 2028 is a good example).

The guidance I think we should give Peter regarding all of these issues is that he should review these issues, and apply an “Updates” to relevant RFCs in terms of any changes that would vary from what they say.  This will keep us from boiling the ocean.  Following what I like to call the “Barry Leiba Rule”, if Peter does insert an Updates for a document, he should explain why in the document.

Rather than close these issues, they will simply serve as placeholders as the document gets fleshed out, and I propose to leave them open for now.

Eliot

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 20 May 2021 16:36:53 -0600

On 5/18/21 3:20 AM, Eliot Lear wrote:
> This goes to the work that John Klensin did in his review.  As you may
> recall, John gave recommendations in each case.  Some of these
> recommendations are probably beyond the scope of this group (RFC 2028 is
> a good example).

Thanks to John for his recommendations.

As a general point, I'll note that neither RFC 5620 (RFC Editor Model
Version 1) nor RFC 6635 (RFC Editor Model Version 2) formally updated
the RFCs and BCPs in question. Although perhaps the authors and
reviewers of the earlier models missed something, the conservative
approach would be for Version 3 to not update documents that Version 1
and Version 2 didn't.

> The guidance I think we should give Peter regarding all of these issues
> is that he should review these issues, and apply an “Updates” to
> *relevant* RFCs in terms of any changes that would vary from what they
> say.  This will keep us from boiling the ocean.  Following what I like
> to call the “Barry Leiba Rule”, if Peter does insert an Updates for a
> document, he should explain why in the document.

Acknowledged.

> Rather than close these issues, they will simply serve as placeholders
> as the document gets fleshed out, and I propose to leave them open for now.

Sure, that works.

Peter

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 20 May 2021 18:44:41 -0400

Peter, I do not follow your reasoning.  As I understand it, 5620 and 
6635 did not update 2028 et. al. because the RFC Editor documents did 
not modify IETF procedure.

The point John made is that the RSWG can not simply use the IETF 
procedures verbatim.  Whether it needs to rewrite them or say "those, 
but with this understanding", we can not simply ignore the quesitons if 
we want procedures that apply to the RSWG.

Also, John had ntoed that 2026 et. al. have some problems in their 
relationship to reality.  That was not an issue 5620 / 6638 would or 
could address.  It is also not an issue we can or should address here.

Yours,
Joel

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 20 May 2021 16:55:42 -0600

> we want procedures that apply to the RSWG.

If (and I do say if) what we're doing here is defining Version 3 of the
RFC Editor Model to replace Version 2 (RFC 6635), which itself replaced
Version 1 (RFC 5620), then it could be argued that readers can follow
the chain of "Obsoletes" to understand how Version 3 operationalizes the
concept of an RFC Editor "function". The fact that policy will now be
set not by an individual but by the RSWG/RSAB doesn't *necessarily*
modify IETF procedure (and of course policies and procedures for the RFC
Series are not quite IETF procedures in the first place).

To get down to cases, I tend to agree with John's suggestions that the
RFC Editor Model Version 3 does not need to formally update RFCs 2026,
2028, 8729, and 8730 nor BCPs 39, 78, and 79. If we need to have
separate threads about each of those, we can certainly do so.

> could address.  It is also not an issue we can or should address here.

Very much agreed - if IAB or others wish to align those documents with
current reality, they're free to do so, but that's well beyond the remit
of the RFC Editor Future Development Program.

Peter

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 20 May 2021 18:58:39 -0400

As far as I can tell, we are defining something broader than a revision 
of the RFC Editor model.  We are defining an entire community process.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 May 2021 11:57:01 +1200

> of the RFC Editor model.  We are defining an entire community process.

That's true. So we are inevitably updating the previous RFC Series and RSE
documents issued by the IAB, but we are at most *referring to* IETF process
documents. It's a question for the IETF whether it cares to update its
out of date process documents; this group has to take them as given.

I'm not really seeing any disagreements here about what Peter should
put in our document.

    Brian