Subject: Re: [Rfced-future] Alvaro Retana's No Objection on draft-rosen-rfcefdp-update-2026-01: (with COMMENT)

From: Brian Rosen <[email-masked]>
Date: Tue, 8 Mar 2022 11:44:55 -0500

<adding rfced-future>
Thank you for your review.

I will defer to whatever current practice the RFC Editor has with regard to how we indicate that a document updates a BCP. Would someone from the RFC Production center chime in here?

I personally don’t think that the reference to rfc-model should be normative, but I will defer to the wishes of the rfced-future work group. “Must be read to understand” applies to lots of informative references.  

Brian

> On Mar 8, 2022, at 7:28 AM, Alvaro Retana via Datatracker <[email-masked]> wrote:
> 
> Alvaro Retana has entered the following ballot position for
> draft-rosen-rfcefdp-update-2026-01: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-rosen-rfcefdp-update-2026/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> (1) It should be indicated somewhere that this document should be part of BCP
> 9.  I prefer an RFC Editor Note in the ballot/IESG Writeup.  I did notice that
> the header includes "Updates:...BCP 9", but (trying not to get into the meaning
> of "updates") only RFCs should be listed there.
> 
> (2) The reference to draft-iab-rfcefdp-rfced-model should be Normative because
> it must be read to understand the change being made.
> 
> 
>

---

From: Jean Mahoney <[email-masked]>
Date: Tue, 8 Mar 2022 12:54:35 -0600

Hi all,

> I will defer to whatever current practice the RFC Editor has with regard to how we indicate that a document updates a BCP. Would someone from the RFC Production center chime in here?

The IESG approval message should indicate if the document will be added 
to BCP 9.

The Updates field should say: "Updates: 2026 (if approved)"

Best regards,

Jean, chiming in from the RPC

---

From: John C Klensin <[email-masked]>
Date: Tue, 08 Mar 2022 14:12:12 -0500

--On Tuesday, March 8, 2022 11:44 -0500 Brian Rosen
<[email-masked]> wrote:

> I will defer to whatever current practice the RFC Editor has
> with regard to how we indicate that a document updates a BCP.
> Would someone from the RFC Production center chime in here?
> 
> I personally don't think that the reference to rfc-model
> should be normative, but I will defer to the wishes of the
> rfced-future work group. "Must be read to understand"
> applies to lots of informative references.  

Brian,

For whatever my opinion is worth, this is a bit more than "Must
be read to understand" because, without at least a general
understanding of what the new model is about (other than
providing the names of two entities), Section 1 gets close to
hand-waving.  It would clearly be so if those organizations were
not mentioned so maybe it would be marginal... except for (i) an
additional pragmatic reason to make it normative, which is that
such a reference binds the three documents together and requires
that they be published at the same time and (ii) the suggestion
below, which would make it even more normative.  Now the RPC
could presumably decide to treat the three documents as a
Cluster on its own initiative even though this document and
draft-carpenter-rfced-iab-charter are so short and trivial that
it might be a normal decision to just process them and get them
published and out of the queue, but why not make things a bit
more regular.  And that still doesn't address the issues below.

Another substantive issue:

In addition to the statements in Section 2.1 (sic), the end of
Section 4.2.2 requires "the concurrence of the RFC Editor".
Unless that sentence has been removed, rather than merely
adjusted, by one of the many updates to 2026, it should be
corrected as well.  Similar problems occur with 4.2.3, which I
do not believe was changed when we defined the Independent
Submission Stream and the IESG started handling more
Experimental and Informational documents, some of them as
Individual documents with AD sponsorship.  Other statements are
made about "the RFC Editor" in Section 9.1.   I hope you have
reviewed all of those --I don't remember any significant
discussion on the mailing list -- and determined that all of
them have been eliminated by other updates and that others have
carefully checked your review.   If not... well see below.

IESG: 2026, which, as you know, is our core procedural document,
has, after 14 formal updates (even if --I'm guessing-- over half
or them are IPR-related changes) and a number of "regardless of
what is says, we just don't do things that way any more"
situations, has turned into a sufficiently spaghetti-treaded
mess that figuring what it actually means and what the rules
actually are has become a significant undertaking.    Maybe time
to do something.  If that "something" is not a complete rewrite
and replacement (which has been avoided, for good reason, for
many years), perhaps it would be possible to do a roadmap that
would incorporate the substantive parts of that list of updates
and give the reader a more clear path through the collection.

Suggestion about draft-rosen-rfcefdp-update-2026: Going through
the other appearances of "RFC Editor" in 2026 and determining
and applying appropriate fixes one-by-one would, I'm guessing,
be a major undertaking especially since some of them are in
sections of the RFC that have been partially changed by those
updates.   Rather than trying to do that and derail the RFCEd
Future process, I suggest adding a second paragraph to Section 1
reading something like:

NEW:

	The term "RFC Editor" appears in several other places
	in RFC 2026.  Each of them should be read as referring
	to elements of the RFC Editor Function as defined in,
	and consistent with, responsibilities assigned by
	[I-D.iab-rfcefdp-rfced-model].
	
That does make the model document even more clearly normative
but, unless you, Brian, want to undertake the work implied
above, I don't see a better solution.

Oh, incidentally, a nit in case no one else has noticed:  There
is no Section 2.6 of RFC 2026.  Presumably the text in Section 1
of the I-D was referring to Section 2.1 of 2026.

best,
   john

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 9 Mar 2022 08:25:17 +1300

[Intentionally trimmed CCs]

> The IESG approval message should indicate if the document will be added

I will add that the kramdown (assuming that's the source) *could* include

cat: bcp
seriesNo: "9"

although that leads to a couple of tooling issues as at https://github.com/ietf-tools/ietf-at/issues/87

    Brian C