Subject: [Rfced-future] Notes on documents affected by the changes we are discussing... (long, with exec summary)

From: John C Klensin <[email-masked]>
Date: Mon, 25 Jan 2021 19:13:05 -0500

Hi.

When I volunteered to do this, I had a different, and far
smaller, task in mind. While it did not slow down the schedule
because I just went ahead (I apologize for that -- delays due
to non-IETF reasons), I also note that the 13 January Action
Item (AI) list indicated there would be further clarification
in the minutes which, AFAICT, have still not appeared.

Executive Summary:

Trying to trace through the IPR and behavior (anti-harrassment,
etc.) implications of our work and any potential new entity we
might create leads, not only from one document to the others,
but uncovers references to documents that are not obviously
related, with references to other documents, some of which have
not been updated to reflect changes in the RFC Editor function
since the mid-1990s or earlier and some of which do not exist
at all. It is not clear to me that we need to pump out and
drain that cesspool (and there is one particular recommendation
below about a better way to handle the problem) but we will not
have a firm foundation for a new setup until the issues are
further identified and at least a plan is in place for
remedying them.

Some of the comments and suggestions below overlap with
existing Issues in the Program/WG. After getting thoroughly
bogged down, I decided to view this exercise as a separate
activity and cross-check rather than going carefully through
the Issues list and trying to reconcile the two.

Documents and comments:

Documents are in no particular order.  If this and the
inter-document relationships were part of a program,
some of us would be making nasty comments about spaghetti.
Also forgive small differences in formatting and style -- this
was developed over multiple days and I concluded it was better
to send it than to spend more time sorting those things out.

BCP 11/ RFC 2028 thread  (RFCs 2028, 3668, 3979, 8717)

   Summary: RFC 2028, "The Organizations Involved in the IETF
   Standards Process" actually describes organizations.  The
   three updates are about IPR issues, not organizations or
   structures (see below).  The RFC Editor is discussed in
   Section 2.1 but all that section really does is to point to
   the definition of the Series in RFC 2026 (see below) and to
   a definition of functions and selection procedures in a
   document cited as "The RFC Editor Charter [G]". Reference
   [G] reads "Work in Progress".

   Action required: A review of 2028 indicates that it is badly
   outdated and in need of work. It cites documents as "in
   progress" for which no progress has been made in close to a
   quarter-century. In some cases, documents that change its
   contents have been published but without any identification
   of their updating 2028. For example, RFC 4844 (and hence the
   later 8729) rather clearly updated the substance of 2028
   even though they are not the "RFC Editor Charter" to which
   2028 refers. A quick scan of the IPR documents as
   specifically related to 2028 does not seem to indicate
   anything this group would need to adjust or change but see
   the separate discussion of RFC 8717 (BCP 101) below. Another
   example, while not our problem, is that 2028 still claims
   that the IAB appoints the IETF Chair, text that has never
   been updated.

   At minimum for us, RFC 2028 should be updated by pointing to
   new structure or charter documents or by pointing to a
   successor for RFC 8729. Preferably, we should convince the
   IESG that an overhaul of 2028 is needed and then just
   incorporate new/ better RFC Editor function references into
   it. For that "overhaul the whole thing" option, I sent a
   summary to the gendispatch mailing list over the weekend,

https://mailarchive.ietf.org/arch/msg/gendispatch/NZ6QfxWlFvkh7jkHvBwNxKd7TR8/

BCP 9/ RFC 2026

    Summary: RFC 2026 Section 2.1 describes the RFC Series. It
    is one of the places were "archival" appears (i.e., if we
    intend to change that, further work will be required). If
    we are doing a cleanup, the sentence explaining how to
    obtain RFCs is probably in need of updating, probably to
    point to an RFC Editor-maintained document. The sentence
    "RFC publication is the direct responsibility of the RFC
    Editor, under the general direction of the IAB." will
    almost certainly require modification depending on what we
    decide to do. A number of references, including those to
    what is now the style guide, the assertion that the ASCII
    form is definitive for standards-track documents, and the
    pointers to documents we are no longer maintaining
    ("Internet Official Protocol Standards" was dealt with in
    RFC 7100), are probably in need of explicit updating.

    Action required: If things continue on their current path,
    remove or update the comment about general direction by the
    IAB.  As with 2028 above and several other documents
    described below, some general cleaning-up should be
    performed by someone.  See the "Job Description" comments
    at the end.

Intellectual Property Rights in IETF Technology (RFC8179/BCP79)
(while IETF-specific, also adopted by the IRTF
(https://irtf.org/policies/ipr)

   Summary: This document/BCP is essentially about patents
   which, as far as I can tell, have not in the past and
   should not in the future impact the RFC Editor.

   Action required: Probably not, but requiring conformance
   along the lines of the IRTF policy would not be harmful.

Rights Contributors Provide to the IETF Trust (RFC5378/BCP78)
And Rights in documentation more generally
   (RFC 5744 - Independent Stream; RFC 5745 - IAB Stream; RFC
   8721 (and predecessor 5377)- Advice to Trustees)

   Summary: RFC 5738, Section 1, points to RFC 2028 for a
   definition of "RFC Editor". See rant above. Section 3.6 (and
   the somewhat redundant Section 5.9) implies that the IETF
   Trust need not (and perhaps does not or should not) own the
   copyrights to Informational RFCs and "RFCs submitted as RFC
   Editor Contributions" (not our problem, but, I believe,
   inconsistent with contemporary practice) and suggests (in
   terminology of today's structure) that the authority of the
   Trust is limited to documents "in the RFC format used by the
   IETF". Probably not our problem either, but, in the current
   "only the XML is the canonical/ archival form" model, it is
   not clear what "the format used by the IETF" means. RFC
   8721 sheds no light on this other than noting the
   long-standing tradition of allowing translations and
   suggesting it continue. Terms such as "published by the RFC
   Editor" appear in other places, such as Section 4 of RFC
   5378, and points to the "RFC Editor web page" for more
   information, where there is no sign of any such information
   (see "Job Description" below).

   Action required: Probably none unless we need the new entity
   to endorse the BCP 78 policies either as an entity
   independent of other IETF-related bodies or as part of an
   RFC Editor Stream should we decide to create one, probably
   following the IAB model outlined in Section 11. Note,
   however, that the other streams have been much more careful
   to apply BCP 79 than they have been about BCP 78 (e.g., as
   I read the IRTF summary cited above, it is entirely about
   BCP 79 and disclosures -- BCP 78 is not cited or
   mentioned), a problem that is further complicated by the
   slightly convoluted language in RFC 5378 about non-IETF
   documents. In addition, if one were to endorse/ require
   conformance along the lines of BCP 78, it is not clear that
   its definition of "Contribution" would work for the sort of
   discussions I think we are assuming would occur in the
   working group or oversight body.

Charter of the Internet Architecture Board (IAB) (RFC
2850/BCP0039)

   Summary: Mentions responsibility for the RFC Editor. It also
   specifies that the RFC Editor is an liaison member of the
   IAB. Depending on what other decisions we make, that may no
   longer be appropriate and we may need to sort out whether
   the RSE/A, RPC, or both, should have liaisons to the IESG.
   It also occurs to me that having the RSE/A be an ex-officio
   member of the LLC Board might improve communications,
   facilitate discussion of tradeoffs about possibly courses of
   action that would require money or other resources, and
   provide a barrier against treating the RSE/A and/or the
   entire RFC Editor Function as "just contractors".

   Action required: If we continue on what I think is our
   current path, the IAB responsibility for the RFC Editor
   will need to come out.   And we need to sort the liaison
   issues out.

RFC Editor Model (Version 2) (RFC 8728 and the earlier 6635)
    We know this is going to need to be reworked; no summary
    here.

The RFC Series and RFC Editor (RFC 8729 and the earlier 4844)

    Summary: Like RFC 2850, mentions a liaison from the RFC
    Editor to the IAB, which we might want to review in the
    context of whatever we figure out (see above). Section 2.d
    discusses the RFC Editor function but in general enough
    terms to probably be ok.

    Action required: Probably none unless we conclude that the
    new structure eliminates the need or desire for a liaison
    from the RFC Editor to the IAB or that we need to move new
	liaison or ex-officio member role into this (see above).

RFC Streams, Headers, and Boilerplates (RFC 7841 and the
earlier 5741)

   Summary: The document does not appear to need modification
   as a side-effect of our work.  Of course the question of who
   would have the authority to modify it is key to many of our
   conversations.

   Action required: Probably none.

Independent Submission Editor Model (RFC 8730 and the earlier
RFC 5620 and 6548)

   Summary: Mentions interactions with the RSE and appointment
   by the IAB.  If we create a new oversight mechanism,
   decouple the RSE/A function, and/or RSE/A appointment from
   the IAB, we may want to review whether having the IAB
   appoint the ISE is still appropriate.  The text does
   mention the RSOC in section 2, so, if we are eliminating
   that body (and possibly replacing it with something else),
   that sentence would need adjustment.

   Action: Probably remove comment about the RSE in Section 2.
   Depending on what else we decide, possibly adjust text about
   appointment by the IAB and/or being responsible to the IAB.

IETF Anti-Harassment Procedures (RFC 7776/RFC 8716)

   Summary: this document is veryfocused on the IETF.  If
   the strategic and policy activities of the RFC Editor
   Function are going to be treated as a new and separate body,
   similar rules, ideally tracking the IETF ones as they
   evolve, are probably in order.  It would seem sensible to
   piggyback on the IETF process, including using the IETF
   Ombudsteam structure, advisors, and membership if the IETF
   is willing, but there could be bad optics if someone
   associated with a non-IETF interest in the series got into a
   harrassment dispute with people active in the IETF and
   apparently trying to advocate its interests against those of
   other groups.

   Action required: Decide whether we are concerned about the
   risks of using an IETF process and team.   If we decide we
   are nor (or that the risks are acceptable), work out details
   with the IESG and create documentation incorporating their
   rule and system.  If not, we would need to figure out
   whether the RFC Editor Function or its strategic and policy
   components need their own policy and build and document
   that.

IESG Procedures for Handling of Independent and IRTF Stream
Submissions (RFC 5742)

   Summary: This document discusses the relationship between
   the IESG and documents from the Independent and IRTF
   Streams.  If we are going to create a separate "RFC Editor"
   Stream (under some name), we need to address whether the
   IESG and/or the IAB should be requested to perform reviews
   similar to these, a question that is probably independent
   of ones about representation from the Streams in any
   oversight body or process.

   Action required: Once we determine whether there will be a
   separate stream and how it is managed, come back to the
   question of whether there should be formal documents reviews
   by the IESG, IAB, and/or some other body or bodies.

Finally...
Job Description:

If we had discovered the connections (or disconnections) and
inconsistencies among these various documents a couple of years
ago, it would have been entirely reasonable to go to the RSE
and say "go sort that out, recommend fixes, draw others in as
needed, and make recommendations to the IESG, IAB, and/or IAOC
as needed.  How we would get that done under the new system?
Indeed, trying to figure out how we would expect many of the
problems identified above --ones that we should be able to
dodge as too low-level to be addressed by the Program/WG-- may
raise another interesting challenge for the "who is
responsible for what" discussions.  And, before someone
suggests it, several of the issues involved are sufficiently 
intimately entangled with the standards process to put them
into the area where the LLC is forbidden to go.

best,
   john

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 Jan 2021 08:37:12 +0100

Thank you, John, for this comprehensive review.  You accomplished two tasks, both of which are important:

Where we got hung up in our last interim meeting was understanding precisely what it would mean to apply WG procedures to this new WG that does not report into the IESG.  You discussed the ramifications of this.  Thank you.  I believe the intent of the group (and people should be free to disagree) is that we do a pass on BCP 25 that includes RFCs 2418, 3934, 7776 (and 7437 by extension), and 8716, to see if we can substitute roles of area directors for some other people.  I will add this to the issue tracker, but I wonder if you would like to make an attempt at just that activity?

The other thing you did was that you spotted places where other sets of documents relating to the function of the RFC Editor and various other roles would need to be updated.  To me, these seem like good things (text and all) to go into the issue tracker, so that they get covered in our output documents.

Thanks again,

Eliot

---

From: John C Klensin <[email-masked]>
Date: Fri, 29 Jan 2021 00:18:17 -0500

--On Tuesday, January 26, 2021 08:37 +0100 Eliot Lear
<[email-masked]> wrote:

> Thank you, John, for this comprehensive review.  You
> accomplished two tasks, both of which are important:
> 
> Where we got hung up in our last interim meeting was
> understanding precisely what it would mean to apply WG
> procedures to this new WG that does not report into the IESG.
> You discussed the ramifications of this.  Thank you.  I
> believe the intent of the group (and people should be free to
> disagree) is that we do a pass on BCP 25 that includes RFCs
> 2418, 3934, 7776 (and 7437 by extension), and 8716, to see if
> we can substitute roles of area directors for some other
> people.  I will add this to the issue tracker, but I wonder if
> you would like to make an attempt at just that activity?

I think this proves the adage that no good deed goes unpunished.
I left most of the BCP 25 thread out of my previous discussion
because, after a quick look, I concluded that little of it
(other than the anti-harassment material) would be helpful.

More complete discussion below but my quick summary after going
through the documents again and more carefully is that IETF WGs
may actually not be a good model for the body we are discussing
(referred to as the "WG", in quotes, below) because of the
rather complex set of structures that surround them.  Perhaps
IRTF RGs or the IAB itself might be better models.   In
principle, another possibility would be some of our various
"teams" but, AFAIK, we have no consensus specification about
what those are and how they work.

References to the "previous document", "earlier note", or
similar language below are to the first posting in this thread,
https://mailarchive.ietf.org/arch/msg/rfced-future/URQPy34rGCWF5k-yU-xvXkTNY-I

>... 

Executive Summary and Conclusion:  Unlike the previous effort
(the first in this thread), this did not prove to be a
particularly helpful exercise and there is reason to believe
that trying to adapt the IETF WG model may not be fruitful.

   --------

Discussion of specific documents...

IETF Working Group Guidelines and Procedures (RFC 2818):

	Summary:   This document is very specific to IETF WGs,
	especially WGs involved with developing specifications that
	are intended to become standards.   It goes into great
	detail about the specifics of WG structure, how WGs are
	formed and charters are specified (including criteria that
	we arguably no longer use and provisions that we sometimes
	ignore although this document makes no provision for doing
	so), the role of BOFs, WG termination, and so on, none of
	which appear to be directly applicable to our needs.

	Parts of Section 3, "Working Group Operation" might be
	adapted to our needs, but even there, there are enough
	specific references to IETF management structures, issues,
	meeting arrangements, etc., to require significant
	editing.  It may be worth noting in that context that RFC
	2418 refers to RFC 2028 for a discussion of conflict of
	interest issues and there is no such discussion in 2028
	(see lengthy discussion of that document in my earlier
	note)

	The document also discusses appeals and points to RFC 2026.

	Action required/Conclusion: If we need a document to
	describe how the new "WG" functions, a new document will
	need to be written.  That document should be much shorter
	and complex than 2418 because the RFC Editor Function group
	(aka "WG") will presumably start with a charter written by
	this group; the new document will need, at most, text about
	how to amend and evolve it.  It may be possible to
	appropriate and adapt some text from RFC 2418, but far less
  text and with more difficulty 	than I think we have been 
  assuming.  And we still need to sort out relationships to 
  other bodies, appeals of decisions (if any), and so on.

  To respond to Eliot's question in particular, there does
	not appear to be any obvious and plausible way to replace
	the role of the Area Director (AD) with something/ someone
	else, both because the AD role is too entangled with other
	functions and roles in 2418 and because we give ADs
	(selected by the Nomcom specifically for the purpose of
	managing WGs) vast discretionary authority.   The only way
	I can see to get to that type of relationship with the RFC
	Editor function would be to either create a very strong
	RSE, probably stronger than even those of us who advocate
	going in that direction believe to be desirable, or to
	define an RFT (RFC Series Tsar) and figure out how to get
	one selected.

Updates to RFC 2418 Regarding the Management of IETF Mailing
Lists (RFC 3934) 

	Summary: Gives WG Chairs explicit responsibility for WG
	mailing lists including authority to temporarily suspend
	posting privileges.  If also limits the ability of the
	Chair to suspend posting privileges to a maximum of 30
	days at a time.

  Action required: If we are going to follow the WG model,
	we'd presumably need a new document in which most of this
	was duplicated or incorporated by reference, explicitly
	assigning those responsibilities.  We would also need to
	review the 30 day limit and the point at which major
	Posting Rights actions would be required (see RFC 3683,
	below).

	Comment: Not entirely clear to me that having those
	responsibilities rest with the "WG" Chair would be a good
	idea, so we should at least discuss who to assign to one or
	both.

A Practice for Revoking Posting Rights to IETF Mailing Lists
(RFC 3683) 

	Summary: Included here because RFC 3934 references it, as
	does the discussion of that document, above. Interestingly,
	it is written to apply to "IETF Mailing Lists" and it has
	never been clear whether an IESG Posting Rights action
	under its provisions would apply to the IAB mailing list
	(presumably including rfc-interest, the RFC Advisory Board
	list, IAB Program lists, and the IAB list itself), lists
	that are part of the ISE function, IRTF lists, LLC lists 
  and anything else that is not a strictly IETF list that 
  I've forgotten.

	Action required: Clarify whether an RFC 3683 posting rights
	action would apply to open lists associated with the RFC
	Editor Function (and/or the "WG" specifically) and/or
	whether there should be a mechanism for semi-permanently
	revoking Posting Rights for people posting to some of all
	lists associated with the RFC Editor Function.

Increasing the Number of Area Directors in an IETF Area (RFC
7475)

	Summary: Not relevant

IETF Anti-Harassment Procedures (RFC 7776, 8716)

   Discussed in previous (2021-01-25) note.

IETF Administrative Support Activity 2.0: Consolidated Updates to
IETF Administrative Terminology. (RFC 8717)

	Summary: This just makes the "IETF Executive Director" ->
	"Managing Director, IETF Secretariat" change.

	Action required: Probably none because the paragraph that
	is changed is IESG-specific.  See RFC 2418 above. 

best,
    john