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

[John C Klensin <[e-mail]>]

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

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

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