Subject: [Rfced-future] Fwd: I-D Action: draft-carpenter-rfc-principles-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Sat, 9 May 2020 17:12:51 +1200

Hi,

This draft is intended as background material for ongoing discussions about the role of the Request for Comments (RFC) Series Editor (the RSE). This version is purely personal opinion. I welcome comments, best sent to  [email-masked] if they concern the RFC Series in general, or to [email-masked] if they concern the role of the RSE specifically.

I advise reading the pretty HTML version since this draft is in v3 format:
https://www.ietf.org/id/draft-carpenter-rfc-principles-00.html

Regards,
    Brian

-------- Forwarded Message --------
Subject: I-D Action: draft-carpenter-rfc-principles-00.txt
Date: Fri, 08 May 2020 22:05:37 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Principles of the Request for Comments Series
        Author          : Brian Carpenter
	Filename        : draft-carpenter-rfc-principles-00.txt
	Pages           : 9
	Date            : 2020-05-08

Abstract:
   This document discusses the underlying principles of the Internet
   technical community's Request for Comments document Series.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-rfc-principles/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-carpenter-rfc-principles-00
https://datatracker.ietf.org/doc/html/draft-carpenter-rfc-principles-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 12 May 2020 12:03:48 +1000

Hi Brian,

> On 9 May 2020, at 3:12 pm, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 

Very helpful document. Some feedback on the proposed principles / suggestions on how we can use this as a springboard for work:

> 	• The RFC Series is the archival Series that documents Internet technical specifications, descriptions, and commentaries, including general contributions from the Internet research and engineering community, as well as standards documents. It also includes some organisational documents from the same community.

Clarity on what 'archival' means -- and doesn't mean -- would be immensely helpful. In particular, if there's an agreed set of properties that are desirable, that might help us / the future rfced find ways to meet the differing needs in the community without breaking 'archival'.

> 	• RFCs come from various streams, i.e. originating organisations. Each stream has its own policy on change control and copyright, with the IETF Trust generally acting as a repository for intellectual property rights that are not retained by the authors.

This begs the question of under what conditions a new stream can be created. I suspect we could write down and agree to some guidelines as part of this work.

> 	• The RFC Series is community property and must operate on behalf of the community as a whole.
> 
> 		• The exact definition of the relevant community is open for debate. One definition is: the IETF, the IRTF, the IAB and the many other people who have contributed to, or made use of, the RFC Series over the last fifty years.
> 
> 	• Major decisions about the future of the RFC Series must be taken by a rough consensus of this very broad community.
> 
> 		• How to reach out to this community and judge its consensus is in itself a big question.

I think it's widely agreed that your conclusions about the series not being 'owned' by any of the I* are correct. However, I'd suggest that we can reach out to and judge consensus of that community just like we do in any other area -- establish a venue (e.g., a WG) and make it known that if you're a stakeholder who's interested, that's the appropriate place to contribute. Doubtless some people will not choose to come, but that's their choice. Others might advocate on their behalf; we already see that with civil society organisations being involved in the IETF's work.

The difference is going to be that the oversight structure / appeal chain of that effort needs to consider that the IESG and IAB have conflicts of interest, in the sense that they're both stream owners. This is where we should focus attention; we might decide that we need a separate appeal chain, or we might decide that the sword of recall hanging over those bodies is sufficient, if we make the expectations clear.

> The RFC Series Editor is an independent professional editor, serving a much wider community than just the IETF. Given the economic and social importance of the Internet, this is a serious responsibility, comparable to the editorship of a major newspaper of record.

I've heard this asserted by a few different people, and I don't see the evidence to back it up (having been educated and employed as a journalist much, much earlier in my career).

Yes, we need someone who understands some aspects of publishing; just anointing a network engineer from our community (as we do with so many roles) is not sufficient. Much more relevant is having someone who understands project management and consensus building. 

This does not equate to "editorship of a major newspaper of record" -- if folks think that it does, we need to have a series talk about expectations, because that phrase implies the ability to hire and fire writers (document authors) and subeditors (which would be stream managers here?), give them directions, determine content, refuse publication, and so forth.

It's also not clear that they need to be independent in the sense that they have absolute control over the series. If we're able to balance the conflicts of interest mentioned above, there's no reason that they couldn't be overseen successfully by the IESG, IAB, some combination of them (or some other body if not).

I know that at one time, the RFC Editor did have significantly more power than the role has now, and this characterisation might have been appropriate. If folks honestly think that is still the case, the powers should be enumerated and put to the community, because it would be a drastic change in the nature of the IETF's work, and I don't think it would be acceptable to many.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 May 2020 03:41:09 +0100

Hiya,

Mostly just a query...

On 12/05/2020 03:03, Mark Nottingham wrote:
> Much more relevant is having someone who understands project 
> management and consensus building.

I don't understand why those features are "much more
relevant" than other things. Can you explain?

IIUC, you may be reacting to:

   "The RFC Series Editor is an independent professional
    editor, serving a much wider community than just the
    IETF. Given the economic and social importance of the
    Internet, this is a serious responsibility, comparable
    to the editorship of a major newspaper of record."

FWIW, I also figure I separately disagree with Brian's
NYT/WaPo "editor" concept - while that does seem attractive
for someone (like me) who adolesced in the post-Watergate
era, I'm very struck by a recent COVID-19 survey here in
Ireland that found that <2% got real news from print
newspapers, so the newspapers of record are also changing.
The "winning" 36% source btw was the public TV broadcaster,
and while the online equivalents of incumbent print
newspapers did figure a lot, weird Internet sources didn't
feature much.

Ta,
S.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 May 2020 17:12:08 +1200

> This does not equate to "editorship of a major newspaper of record"...

You're right, my phrase is hyperbolic. I'll think about how to make my point more accurately.

I appreciate all the comments received and I will do an update, but probably not this week.

    Brian

Regards
   Brian Carpenter

---

From: John C Klensin <[email-masked]>
Date: Tue, 12 May 2020 03:03:57 -0400

--On Tuesday, May 12, 2020 12:03 +1000 Mark Nottingham
<[email-masked]> wrote:

>> This draft is intended as background material for ongoing
>> discussions about the role of the Request for Comments (RFC)
>> Series Editor (the RSE). This version is purely personal
>> opinion. I welcome comments, best sent to
>> [email-masked] if they concern the RFC Series in
>> general, or to [email-masked] if they concern the role
>> of the RSE specifically.
>> 
> Very helpful document.

I certainly agree so far.

> Some feedback on the proposed
> principles / suggestions on how we can use this as a
> springboard for work:
 
>> 	• The RFC Series is the archival Series that documents
>> 	Internet technical specifications, descriptions, and
>> 	commentaries, including general contributions from the
>> 	Internet research and engineering community, as well as
>> 	standards documents. It also includes some organisational
>> 	documents from the same community.
 
> Clarity on what 'archival' means -- and doesn't mean -- would
> be immensely helpful. In particular, if there's an agreed set
> of properties that are desirable, that might help us / the
> future rfced find ways to meet the differing needs in the
> community without breaking 'archival'.

Mark, I fear that takes us around in a bit of a circle, albeit
an important one. I was forcefully educated (one might say
"beaten up") some years ago by an Archivist (his job title)
associated with a national repository library in the north of
Europe.   He explained that it was very hard to have a
conversation about what was "archival" or about the meaning of
the closely-related term "permanent" with people in computer
fields (especially web-related ones) because we tended to think
of "permanence" as 10 - 20 years.  He claimed that most people
he had encountered from North America or the South Pacific had
similar problems with believing permanence, in practice, could
be considered a few centuries but that he and his colleagues
needed to work in terms of at least several millennia and that
those differences put an entirely different spin on things.

That story is important in the current context for two reasons:

* While I consider the decision made and hence not part of the
current RFC Editor Futures discussion (even though I, and
apparently others, have growing doubts about how we are
implementing it), a conversation with almost any (I don't know
of exceptions, but maybe there are some) professional archivist
about treating a source format that requires considerable
compilation and reference to external sources and mechanisms to
get to a form people are comfortable reading as an archival form
will typically be greeted with laughter and/or comments to the
effect that we should come back in a hundred years and show them
that XML is still around and that it is the same, or at least
completely backward-compatible, XML.  If they, and their
considerations, are to be taken seriously as we talk about
"archival", things are broken already and comments about the
merits of continuing to dig when one finds oneself in a deep
hole may be relevant.

* There have been several discussions in recent years about
treating IETF specifications as living documents or with some
other arrangement in which issues are folded in as soon as they
are detected and at least tentative conclusions reached about
how to proceed.  I don't know whether we need to resolve those
proposals before moving forward with discussions about the
future of the RFC Series and its management and organization (I
hope we don't because the community seems quite divided to me).
However, I think we need to understand that moving in that
direction, even if we make periodic snapshots and publish them
as RFCs, would profoundly change the character of the series as
providing a clearly-identifiable (and "archival") record of the
evolution of Internet technology and standards.

>...
>> 		• The exact definition of the relevant community is open
>> 		for debate. One definition is: the IETF, the IRTF, the IAB
>> 		and the many other people who have contributed to, or made
>> 		use of, the RFC Series over the last fifty years.
>> 
>> 	• Major decisions about the future of the RFC Series must
>> 	be taken by a rough consensus of this very broad community.
>> 
> I think it's widely agreed that your conclusions about the
> series not being 'owned' by any of the I* are correct.
> However, I'd suggest that we can reach out to and judge
> consensus of that community just like we do in any other area
> -- establish a venue (e.g., a WG) and make it known that if
> you're a stakeholder who's interested, that's the appropriate
> place to contribute. Doubtless some people will not choose to
> come, but that's their choice. Others might advocate on their
> behalf; we already see that with civil society organisations
> being involved in the IETF's work.

One problem is that one important audience for the Series, or at
least the documents we claim are standards (or to which assorted
parties claim conformance) are people writing procurement
documents (RFPs, contracts, SLAs, etc.).  The odds that we will
get a reliable representation from that community even if we
could reach them are, I think, pretty small.   The odds that we
could get them to participate in a WG-like arrangement?
Probably much lower.  But, at least if one were to assume a free
market in which alternatives exist, those people are key to
determine if our standards go anywhere.  Indeed, when they write
contracts that require conformance and try to enforce them, they
are actually the closest we get to actually having a Protocol
Police.  And, by the way, they, and the kinds of documents they
are willing to work with, interact with the "living document"
ideas as well:  IMO at least, we dare not ignore them because we
cannot get their participation on our normal terms.

>...

Stopping here more because it is late here and I'm tired than
because I'm in complete agreement with all of your other
comments.

best,
   john

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 12 May 2020 17:15:43 +1000

Hi John,

> On 12 May 2020, at 5:03 pm, John C Klensin <[email-masked]> wrote:
> 

This does not shock me, but then I've interned in an art museum, where the challenges of conservatorship were painfully obvious.

> merits of continuing to dig when one finds oneself in a deep

I tend to agree; if I'd been more involved in the IETF when this decision was made, I would have fought it (based upon my early experiences with XML, more than anything).

> evolution of Internet technology and standards.

I think that people are becoming slightly absolutist when they talk about this subject, but worse, they perceive those on "the other side" as *really* absolutist.

I hope no one seriously thinks that "archival" means that we can't change _any_ aspect of the series, ever -- that it's a machine that must run on in its current form until its doom. I also hope that no one thinks that changing things means that it must be possible to change any character / bit in any RFC at any time.

If we can put those extremes safely out of the way and focus on what the needs of the archival and other communities are, we might make some progress. 

Maybe we could give some guidance here, but I agree we do have some other issues to dispose of first.

> cannot get their participation on our normal terms.

Thank you; this is exactly how things sit already in many WGs, e.g., HTTP. The decisions we make impact many people who don't even know we exist on a daily basis.

Cheers,

---

From: John C Klensin <[email-masked]>
Date: Tue, 12 May 2020 08:52:48 -0400

> newspapers did figure a lot, weird Internet sources didn't

The example I have used on a few occasions and which I like
better after thinking about the above would be the publisher
staff member or executive responsible for one or more
substantive and well-recognized professional scientific or
technical journals.  Both traditional for-profit scientific and
technical publications would count, but so would senior
editorial staff for journals of record from major professional
societies as would those responsible for publications strategy
and style at major standards bodies.  And, borrowing your words,
weird Internet sources don't count.  That change would pick up
something else, which is the need to work with and adapt to some
very specialized subject matter vocabulary.

In the case of both a definition along those lines and Brian's,
I home we could move forward without precise definitions of
terms like "major", "substantive", "well-recognized", etc.  All,
in all cases, there is a difference between responsibility for
strategy and spending one's days with the possibly-virtual
equivalent of a blue pencil.

    john

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 12 May 2020 14:00:42 +0100

FWIW, I don't like the "comparable to" formulation in any way because it
brings accidental baggage with it.
A newspaper editor sets direction for the content, decides what will and
won't be published, hires and fires writers.

Let's simply not go there. 

Describe the job for what it is, not for how it compares or doesn't compare
with other jobs.

Adrian

-----Original Message-----
From: Rfced-future <[email-masked]> On Behalf Of John C
Klensin
Sent: 12 May 2020 13:53
To: Stephen Farrell <[email-masked]>; Mark Nottingham
<[email-masked]>; Brian E Carpenter <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rfced-future] I-D Action:
draft-carpenter-rfc-principles-00.txt

    john

-- 
Rfced-future mailing list
[email-masked]
https://www.iab.org/mailman/listinfo/rfced-future

---

From: John C Klensin <[email-masked]>
Date: Tue, 12 May 2020 10:24:21 -0400

Adrian,

I actually agree.  However, I cannot speak to Brian's intent,
but I was trying to get at a skill set or desiderata for the
position, not to make a comparison.  From that perspective this
position is, IMO, very much not like a newspaper editor (for the
reasons you cite) and much more like the skills and experience
required to effectively perform a publications strategy role for
a technical publisher.  Drawing further on your newspaper editor
comment, I think we are looking for someone who has a
significant professional role (even if not a unilateral one) in
setting criteria for what is acceptable for publication but not
for making decisions about individual drafts.

thanks for your clarification.
   john

--On Tuesday, May 12, 2020 14:00 +0100 Adrian Farrel
<[email-masked]> wrote:

> FWIW, I don't like the "comparable to" formulation in any way
> because it brings accidental baggage with it.
> A newspaper editor sets direction for the content, decides
> what will and won't be published, hires and fires writers.
> 
> Describe the job for what it is, not for how it compares or
> doesn't compare with other jobs.
> 
> Adrian
> 
> From: Rfced-future <[email-masked]> On Behalf Of
> John C Klensin
> Sent: 12 May 2020 13:53
> To: Stephen Farrell <[email-masked]>; Mark
> Nottingham <[email-masked]>; Brian E Carpenter
> <[email-masked]> Cc: [email-masked]
> and style at major standards bodies.  And, borrowing your
> words, weird Internet sources don't count.  That change would
> pick up something else, which is the need to work with and
> adapt to some very specialized subject matter vocabulary.
> 
> terms like "major", "substantive", "well-recognized", etc.
> All, in all cases, there is a difference between
> responsibility for strategy and spending one's days with the
> possibly-virtual equivalent of a blue pencil.
> 
>     john
> 
> --

---

From: Michael StJohns <[email-masked]>
Date: Tue, 12 May 2020 13:55:33 -0400

> Describe the job for what it is, not for how it compares or doesn't compare

Let me slide sideways a little bit and suggest that those models are 
useful places to dig for ideas, rather than just being taken up in their 
entirety.

For example, most publication entities have a bifurcated (not - NOT 
matrix) management structure:  the business side and the editorial 
side.  At the top on the business side is usually a board of directors 
of the corporation.  They tend to approve/hire the publisher.  On the 
other side at the top is generally the editor in chief usually advised, 
assisted, collaborative with or responsible to an editorial board.  In 
some instances, the publisher is also the editor in chief.   The 
business side deals with circulation, advertising, and the process of 
bringing the material to print (printing/distribution).  The editorial 
side deals with content, format and generally look and feel.

None of these are independent in a completely unrestrained way, but each 
does have substantial independence within their own wheel house.   I 
think Brian's (and for that matter my) view of an appropriate 
independence model is that we hire the best person we can, and leave 
them alone to do the job.   We look for competence and then we honor 
it.    The existing model somehow lost track of that.

Mark (in another email) is correct that the level of independence of the 
current RSE is not the same as in the past - but I consider that a bug 
rather than a feature as it means that its possible for a small subset 
of the IETF community to affect the culture of the RFC series in ways 
that may not represent the interests of the broader community.

Later, Mike

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 May 2020 13:16:17 -0700

> that may not represent the interests of the broader community.

I want to zero in on this point, because I think it's useful to scope
out people's views of "independence".

Let me try to start with what's hopefully a simple case: suppose
that the IETF produces and the IESG approves a document to be
published as RFC that the RSE believes is harmful to the Internet
for technical reasons (it redefines IPv6 to have an 8 bit address,
say). Do you believe that the RSE should be able to refuse to
publish such a document?

-Ekr

---

From: Michael StJohns <[email-masked]>
Date: Tue, 12 May 2020 16:25:14 -0400

On 5/12/2020 4:16 PM, Eric Rescorla wrote:
> In Tue, May 12, 2020 at 10:55 AM Michael StJohns 
> <[email-masked] <mailto:[email-masked]>> wrote:

Oooh   tricky.   I'd either have the RSE refer it to the ISE as 
publication as an April Fool's RFC, or I'd probably be the first to sign 
on to a petition to recall the entire IESG.     In any case, the answer 
is probably yes, the RSE should refuse to publish the document as an 
Internet standard.   That assumes that the RSE - with the appropriate 
technical advisors - has the skillset to determine said document is 
"harmful to the Internet".

Mike

---

From: Jay Daley <[email-masked]>
Date: Wed, 13 May 2020 08:29:59 +1200

> On 13/05/2020, at 8:25 AM, Michael StJohns <[email-masked]> wrote:
> 
>> In Tue, May 12, 2020 at 10:55 AM Michael StJohns <[email-masked]> wrote:
> Oooh   tricky.   I'd either have the RSE refer it to the ISE as publication as an April Fool's RFC, or I'd probably be the first to sign on to a petition to recall the entire IESG.     In any case, the answer is probably yes, the RSE should refuse to publish       the document as an Internet standard.   That assumes that the RSE - with the appropriate technical advisors
> 

Isn't the IETF consensus by definition the appropriate technical advisors to the RSE or are you suggesting a separate and parallel structure that the RSE controls that all IETF consensus documents need to pass through?

Jay

> - has the skillset to determine said document is "harmful to the Internet".
> 
> Mike
> 
> 
> 
> -- 

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Tue, 12 May 2020 16:29:58 -0400

--On Tuesday, May 12, 2020 13:55 -0400 Michael StJohns
<[email-masked]> wrote:

>...
> None of these are independent in a completely unrestrained
> way, but each does have substantial independence within their
> own wheel house.   I think Brian's (and for that matter my)
> view of an appropriate independence model is that we hire the
> best person we can, and leave them alone to do the job.   We
> look for competence and then we honor it.    The existing
> model somehow lost track of that.

Agreed -- both the "best person" part and the existing model (or
at least it interpretation and implementation in the last couple
of years) having lost that.

> Mark (in another email) is correct that the level of
> independence of the current RSE is not the same as in the past
> - but I consider that a bug rather than a feature as it means
> that its possible for a small subset of the IETF community to
> affect the culture of the RFC series in ways that may not
> represent the interests of the broader community.

While I agree, I don't think it would be wise to go all the way
back.  I think the notion of semi-independent streams was a good
idea even though I sometimes think that we should have
established a separate stream for the RFC Editor function itself
(the IAB's having to sign off on things like style manuals and
RFC Editor Function historical materials and perspectives may be
one of the things that led to losing track of that
independence).  While I don't have any idea how often if was
formally exercised (as distinct from, e.g., being turned into
rather firm feedback), Jon clearly had the authority to reject
documents presented for publication on grounds involving
content).  I think stream approval and the RFC Editor's being
able to insist on a "published over objections" disclaimer (at
least for the IETF Stream) is an improvement 

The question is finding the right balance.  What I'm fairly sure
of is that the RSE needs much more independence and needs to be
treated much more like a professional by the community (and any
oversight or contracting bodies) than, to use an analogy I think
I used in Montreal, a function that we can procure and swap out
as we could probably procure supplies of barrels of nails.

   john

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 May 2020 13:31:49 -0700

On Tue, May 12, 2020 at 1:25 PM Michael StJohns <[email-masked]>
wrote:

> publication as an April Fool's RFC, or I'd probably be the first to sign on
> to a petition to recall the entire IESG.     In any case, the answer is
> probably yes, the RSE should refuse to publish the document as an Internet
> standard.   That assumes that the RSE - with the appropriate technical
> advisors - has the skillset to determine said document is "harmful to the
> Internet".
>
Thanks for the quick answer.

I'm thinking maybe I made this too easy in that such a document has a "is
the IESG on drugs" kind of flavor where any sane person would probably
think they should throw a flag on the play.

But let's take a case where it's not a comically wrong decision but one
that the RSE nevertheless strongly feels is harmful to the Internet. What
then?

-Ekr

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 12 May 2020 21:41:59 +0100

Jay wrote:

> Isn't the IETF consensus by definition the appropriate
> technical advisors to the RSE or are you suggesting a
> separate and parallel structure that the RSE controls
> that all IETF consensus documents need to pass through?

Not at all, Jay. The RSE listens to the stream heads for documents for
publication.
One of those stream heads gauges IETF consensus for most cases. 

I believe the RSE should be able to very strongly question publication, but
not over-rule the stream heads.
If the RSE noticed something that might be a ghastly mistake, I would expect
them to mention it. That might not be a technical thing (unlikely that the
RSE would be qualified) but might be socio-political.

And I believe that the community has mechanisms to censure/recall each
stream head.

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 12 May 2020 21:44:16 +0100

But, maybe, I should have added...

Who defines the stream heads?
Who creates new streams?
Who closes existing streams?

Adrian

-----Original Message-----
From: Adrian Farrel <[email-masked]> 
Sent: 12 May 2020 21:42
To: 'Jay Daley' <[email-masked]>; 'Michael StJohns' <[email-masked]>
Cc: [email-masked]' <[email-masked]>; 'Eric Rescorla'
<[email-masked]>
Subject: RE: [Rfced-future] I-D Action:
draft-carpenter-rfc-principles-00.txt

Thanks,
Adrian

---

From: Jay Daley <[email-masked]>
Date: Wed, 13 May 2020 08:45:10 +1200

> On 13/05/2020, at 8:41 AM, Adrian Farrel <[email-masked]> wrote:
> 
> Jay wrote:
> 

Thanks, very useful.  That does seem quite different from what Mike was suggesting, which is that the RSE could reject based on the advice of a separate set of technical advisors, thereby over-ruling the stream heads.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Michael StJohns <[email-masked]>
Date: Tue, 12 May 2020 16:46:06 -0400

On 5/12/2020 4:31 PM, Eric Rescorla wrote:
>
>
> On Tue, May 12, 2020 at 1:25 PM Michael StJohns 
>>     independence of the
>     publication as an April Fool's RFC, or I'd probably be the first
>     to sign on to a petition to recall the entire IESG.     In any
>     case, the answer is probably yes, the RSE should refuse to publish
>     the document as an Internet standard.   That assumes that the RSE
>     - with the appropriate technical advisors - has the skillset to
>     determine said document is "harmful to the Internet".
>
> I'm thinking maybe I made this too easy in that such a document has a 
> "is the IESG on drugs" kind of flavor where any sane person would 
> probably think they should throw a flag on the play.
>
> But let's take a case where it's not a comically wrong decision but 
> one that the RSE nevertheless strongly feels is harmful to the 
> Internet. What then?
>
> -Ekr
>
>
Let me refer you to an act in history where the IAB decided to make CMOT 
and SNMP co-standards.   That triggered the Kobe uprising and a complete 
reformation of the structure of the I*. Jon was on the IAB at the time, 
and for policy reasons agreed with the designation.     That's sort of 
the reverse of what you mentioned, but it's also the same.   The 
community reacted badly to a bad decision by the deciding body and took 
action.  In the above instance, the RSE is still responsible to the 
community and they're going to be the final arbiters of whether or not 
the decision not to publish should stand.

For your example you didn't give any additional details - e.g. during 
last call were the IESG strung up in effigy?  Was there sufficient 
community push back to invalidate the IESG action? Was there no last 
call?  Did the IESG refuse to add RSE directed black box warnings and text?

Basically, what you've proposed is a strawman to be knocked down.   My 
guess is that any RSE that lets through something that *is* harmful to 
the internet (rather than just thinks it might be) will not have had a 
long tenure to start with.    What I think you're asking is similar to 
the problems that editors of wide circulation publishers go through all 
the time - to print or not to print.  In their case it might be "do we 
have enough evidence that politician A has actually committed adultery 
with staffer B" or "does printing C put D and E into danger"?  The 
business side may say - Lawyers are fine with it and it will make us 
money, but no editor worth their salt will let that be the only decision 
criteria.   So yes, the RSE absolutely can prevent publication, and yes 
absolutely the community (NOT the IESG, not the IAB etc) can arrange to 
replace the RSE for cause if such cause exists.

The RSE is not a rubber stamp.  If you want one, got to a body shop and 
hire one.

Later, Mike

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 May 2020 21:48:46 +0100

> say). Do you believe that the RSE should be able to refuse to

FWIW, I think the RSE ought not be able to block
publication of IETF stream documents. The RSE could
publish a document opining that the IESG must be
on drugs I guess. I'd also be ok with other forms
of puhshback (e.g. mailing ietf@ietf asking WTF)
but I'd stop short of the RSE being able to block.

S.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 12 May 2020 22:00:53 +0100

I think you were over-reading "independent".

A

From: Jay Daley <[email-masked]> 
Sent: 12 May 2020 21:45
To: [email-masked]
Cc: Michael StJohns <[email-masked]>; [email-masked]; Eric
Rescorla <[email-masked]>
Subject: Re: [Rfced-future] I-D Action:
draft-carpenter-rfc-principles-00.txt

On 13/05/2020, at 8:41 AM, Adrian Farrel <[email-masked]
<mailto:[email-masked]> > wrote:

Jay wrote:

Thanks, very useful.  That does seem quite different from what Mike was
suggesting, which is that the RSE could reject based on the advice of a
separate set of technical advisors, thereby over-ruling the stream heads.

Jay

Thanks,
Adrian

-- 
Rfced-future mailing list
[email-masked] <mailto:[email-masked]> 
https://www.iab.org/mailman/listinfo/rfced-future

-- 
Jay Daley

IETF Executive Director
[email-masked] <mailto:[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 May 2020 09:04:57 +1200

I note that RFC7990 says:

>       Canonical format: the authorized, recognized, accepted, and
>       archived version of the document

This could well be an error. Making our XML dialect the *canonical*
format was what most of us thought about. Maybe a specified rendering
that could, in theory, be drawn on parchment should be the *archival*
format.

Since RFC7990 is a request for comments, we can choose to update it.

This should go on the next RSE's "to do" list, I think.

Regards
   Brian Carpenter

On 12-May-20 19:15, Mark Nottingham wrote:
> .

---

From: John C Klensin <[email-masked]>
Date: Tue, 12 May 2020 17:12:03 -0400

--On Tuesday, May 12, 2020 21:41 +0100 Adrian Farrel
<[email-masked]> wrote:

> Not at all, Jay. The RSE listens to the stream heads for
> documents for publication.
> I believe the RSE should be able to very strongly question
> publication, but not over-rule the stream heads.
> If the RSE noticed something that might be a ghastly mistake,
> I would expect them to mention it. That might not be a
> technical thing (unlikely that the RSE would be qualified) but
> might be socio-political.

I would expect the RSE to push back.  Especially if it were even
partially a technical issue, I would expect there would be no
restrictions (contractual or otherwise) on the RSE, as a member
of the community, pushing back either privately to the IESG or
on an appropriate IETF mailing list.  Another way to express
such pushback would be an appeal of the IESG's approval action
(and the RSE should not be barred from doing that either).
However, if the IESG believes the document should be published
as-is (and, if the community agreed with the RSE but was
unsuccessful in persuading the IESG), we already have a
mechanism for that, which is for the IESG to ask that the
document be published anyway, even if the RRE wants to insert a
note that the document was published over the objections of the
RFC Editor Function.    

While that mechanism was, IIR, designed for documents the RFC
Editor concludes are incomprehensible and/or editorially too
difficult to deal with, I don't see any reason why it could not
also be applied to a technical objection if the RSE believed
that such an objection was in order.

So, while the question is interesting, I wonder if there is a
problem in that area which is worth extensive discussion or that
needs a solution.

> And I believe that the community has mechanisms to
> censure/recall each stream head.

And that is where I disagree because the evidence is that we
have no such mechanisms that are usable in practice.  The only
mechanism we have that is of (sometimes) demonstrable
effectiveness is waiting for the next Nomcom and hoping its
membership is sufficiently representative of the community to
remove the individual(s) in question.  Presumably (and as
threatened in the past with seemingly good effect) offers to
pelt the IESG with overripe fruit during a plenary might also be
effective.  If the latter is the best mechanism we have, we need
to be working aggressively on a transport protocol for such
fruit over the Internet.   Or we might notice that
draft-moonesamy-recall-rev expired today and start thinking
about how to prioritize such work.  

best,
   john

---

From: Adam Roach <[email-masked]>
Date: Tue, 12 May 2020 16:30:35 -0500

On 5/12/2020 3:25 PM, Michael StJohns wrote:
> publication as an April Fool's RFC, or I'd probably be the first to 
> sign on to a petition to recall the entire IESG.     In any case, the 
> answer is probably yes, the RSE should refuse to publish the document 
> as an Internet standard.   That assumes that the RSE - with the 
> appropriate technical advisors - has the skillset to determine said 
> document is "harmful to the Internet".
>

I think we can appreciate that the example was chosen to be fantastical 
so as to not focus discussion on the technical matter as much as the 
degree of control the RSE is afforded over the technical contents of a 
document.

Now, I do recall a recent anecdote about Postel himself heatedly 
refusing to publish a specification he felt was technically misguided 
[1], so this authority did exist with the position at some point. 
Although never explicitly revoked, RFC 4844, section 4.1 et seq makes it 
pretty clear that the RSE has approval authority over precisely one 
stream (the Independent Submission stream). To the extent that the IAB 
had authority to publish RFC 4844, I think it makes it clear that the 
scope of authority had been pared back substantially since the "I am not 
going to publish a faulty specification as an RFC" days of 1991.

I'm not entirely sure my analysis above is all that useful, though, as 
this is the "rfced-future" discussion rather than the "rfced-history" 
discussion, and so it seems more sensible to focus on meeting the needs 
of the Internet community in 2020 and beyond than is is to lean on the 
historical narrative.

And so more to the point: I think that the IETF community writ large 
would be floored if a working group produced a document, the IETF found 
consensus on it during last call, the IESG approved it, and then the RSE 
refused to publish it (or imposed technical changes on its contents). 
Ditto for the IRTF and their documents. So, if we're matching authority 
with community expectations -- at least for a large swath of the 
relevant community -- I think the answer above of "the RSE should refuse 
to publish the document" is exactly wrong.

/a

____
[1] 
https://mailarchive.ietf.org/arch/msg/rfc-interest/eurBBcxqbTu9iAz3PogGqh970H0/

---

From: Michael StJohns <[email-masked]>
Date: Tue, 12 May 2020 17:33:18 -0400

Sorry for the top post - and Q for EKR but I started thinking about 
reverse strawman arguments.   Of the last 100-200 RFCs approved by the 
IESG, what percentage have had more than the mininum Yes votes?  I ask 
because you (EKR) framed this as the "IESG" approving a document, when 
in reality it could be that only one person is actually in favor of the 
document. Approvals require at least one yes vote and at least 2/3 of 
the non recused to vote yes or no objection.  No Objections mean:

  * I read it, and I have no problem with it.
  * _*I read the protocol action, and I trust the sponsoring AD so have
    no problem.*_
  * I listened to the discussion, and I have no problem.

So we're theoretically (at the extreme) balancing the judgement of one 
person on the IESG against one other person (the RSE). If the argument 
is "that can't happen" then that argument applies equally well to the 
RSE getting a document so poorly written or so technically flawed that 
the RSE would fall on their sword to prevent publication.

Later, Mike

On 5/12/2020 4:46 PM, Michael StJohns wrote:
>>     case, the answer is probably yes, the RSE should refuse to
>>     publish the document as an Internet standard.   That assumes that
>>     the RSE - with the appropriate technical advisors - has the
>>     skillset to determine said document is "harmful to the Internet".
>>
> Let me refer you to an act in history where the IAB decided to make 
> CMOT and SNMP co-standards.   That triggered the Kobe uprising and a 
> complete reformation of the structure of the I*.   Jon was on the IAB 
> at the time, and for policy reasons agreed with the designation.     
> That's sort of the reverse of what you mentioned, but it's also the 
> same.   The community reacted badly to a bad decision by the deciding 
> body and took action.  In the above instance, the RSE is still 
> responsible to the community and they're going to be the final 
> arbiters of whether or not the decision not to publish should stand.
>
> the problems that editors of wide circulation publishers go through 
> all the time - to print or not to print.  In their case it might be 
> "do we have enough evidence that politician A has actually committed 
> adultery with staffer B" or "does printing C put D and E into 
> danger"?  The business side may say - Lawyers are fine with it and it 
> will make us money, but no editor worth their salt will let that be 
> the only decision criteria.   So yes, the RSE absolutely can prevent 
> publication, and yes absolutely the community (NOT the IESG, not the 
> IAB etc) can arrange to replace the RSE for cause if such cause exists.
>
> The RSE is not a rubber stamp.  If you want one, got to a body shop 
> and hire one.
>
> Later, Mike
>
>
>

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 12 May 2020 14:44:57 -0700

I agree that the RSE should not be considered able to block the publication of a document that has followed the correct process for the IETF stream. The IETF has a process with many steps for a good reason, and any standards action requires IETF review, IETF Last Call, and IESG approval (which could presumably be challenged for egregious errors). If there is a technical error, then we should ensure that this process should catch it, not rely on the RSE for that function.

I’m a bit confused as to what grounds the RSE would have for blocking publication. Looking back at the RFCs that defined the standardization process, it seems pretty clear what the relationship is between the IETF and the RFC editor.

RFC 2026 explains “The Internet Standards Process”. Section 6.1.2 (https://www.rfc-editor.org/rfc/rfc2026.html#section-6.1.2) explains the role of the IESG in reviewing and approving standards. The step of publication (https://www.rfc-editor.org/rfc/rfc2026.html#section-6.1.3) is not described as a technical review, but as a simple action that the IESG requests of the editor:

If a standards action is approved, notification is sent to the RFC
   Editor and copied to the IETF with instructions to publish the
   specification as an RFC.

RFC 3932 also provides a good insight into the process. In Section 1, it lists two ways for a standards track document to be published:

   o  IETF Working Group (WG) to Standards Track: Includes WG consensus,
      review in the IETF, IETF Last Call, and IESG approval
   o  Area Director (AD) sponsored to Standards Track: Includes review
      in the IETF, IETF Last Call, and IESG approval

The majority of the document explains the change that was made to *no longer require* the IESG to sign off technically on all RFC Editor documents that did not belong to the IETF stream. However, the technical approval of IETF standard documents clearly still lies with IESG.

Thanks,
Tommy

> On May 12, 2020, at 1:48 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 
> <0x5AB2FAF17B172BEA.asc>--

---

From: Adam Roach <[email-masked]>
Date: Tue, 12 May 2020 16:45:21 -0500

On 5/12/2020 4:33 PM, Michael StJohns wrote:
> person on the IESG against one other person (the RSE)

Even if we accept this fantastically unlikely scenario (I suppose you're 
envisioning an AD sponsoring and shepherding a document they themselves 
wrote?), this is only true if you discount the last-call process. I 
haven't yet seen proposals that would allow skipping it.

/a

---

From: Michael StJohns <[email-masked]>
Date: Tue, 12 May 2020 17:57:02 -0400

On 5/12/2020 5:30 PM, Adam Roach wrote:
> I think we can appreciate that the example was chosen to be 
> fantastical so as to not focus discussion on the technical matter as 
> much as the degree of control the RSE is afforded over the technical 
> contents of a document.
>
> Although never explicitly revoked, RFC 4844, section 4.1 et seq makes 
> it pretty clear that the RSE has approval authority over precisely one 
> scope of authority had been pared back substantially since the "I am 
> not going to publish a faulty specification as an RFC" days of 1991.
>

 From RFC 4844:

        4.4.2 <https://tools.ietf.org/html/rfc4844#section-4.4.2>.
        Operational Implementation

    The RFC Editor is responsible for ensuring that the RFC Series
    guidelines are upheld within the RFC Series.

That I would argue is the grant of authority allowing an RSE to reject a 
given document. There are a number of places where documents can be sent 
back post-approval and pre-publication and are.  I'd also use "The 
*mission* of the *IETF* is to make the Internet work better by producing 
high quality, relevant technical documents that influence the way people 
design, use, and manage the Internet."

Hmm. Can anyone provide me a pointer to a document that describes the 
purpose and mission of the RFC series? Especially one without reference 
to the RSE? I went looking for a combination of "RFC" and "quality" and 
didn't find any document I'd consider normative using those terms.

Mike

> discussion, and so it seems more sensible to focus on meeting the 
> needs of the Internet community in 2020 and beyond than is is to lean 
> on the historical narrative.
>
> would be floored if a working group produced a document, the IETF 
> found consensus on it during last call, the IESG approved it, and then 
> the RSE refused to publish it (or imposed technical changes on its 
> contents). Ditto for the IRTF and their documents. So, if we're 
> matching authority with community expectations -- at least for a large 
> swath of the relevant community -- I think the answer above of "the 
> RSE should refuse to publish the document" is exactly wrong.
>
> /a
>
> ____
> [1]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 12 May 2020 17:57:19 -0400

Can we step this down?

On the one hand, no, I do not think the RSE should have the authority to 
tell the IESG that the IETF can not publish particular technical content 
on technical grounds.
On the other hand, if a technically competent RSE is that concerned 
about a document, I think we probably have a whole lot of other problems 
that need to be addressed.  Whether the RSE actually publishes that 
document or not is probably the least of our worries.

And I do think the RSE should have the authority to say to any stream 
"turn this into proper English before the RPC will process it."

Yours,
Joel

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 12 May 2020 18:00:55 -0400

Brian,

I think that is an error. In section 5, RFC 7990 also says:

   The final XML file produced by the RFC Editor will be considered the
   canonical format for RFCs; it is the lowest common denominator that
   holds all the information intended for an RFC.  PDF/A-3 will be the
   publication format offered in response to subpoenas for RFCs
   published through this new process and will be developed with an eye
   towards long-term archival storage.

So this section makes the distinction between "canonical" and "long term
archival storage"'.

Cheers,
Andy

On Tue, May 12, 2020 at 5:05 PM Brian E Carpenter <
[email-masked]> wrote:

> > This does not shock me, but then I've interned in an art museum, where
> the challenges of conservatorship were painfully obvious.
> >
> >
> > I tend to agree; if I'd been more involved in the IETF when this
> decision was made, I would have fought it (based upon my early experiences
> with XML, more than anything).
> >
> >
> > I think that people are becoming slightly absolutist when they talk
> about this subject, but worse, they perceive those on "the other side" as
> *really* absolutist.
> >
> > I hope no one seriously thinks that "archival" means that we can't
> change _any_ aspect of the series, ever -- that it's a machine that must
> run on in its current form until its doom. I also hope that no one thinks
> that changing things means that it must be possible to change any character
> / bit in any RFC at any time.
> >
> > If we can put those extremes safely out of the way and focus on what the
> needs of the archival and other communities are, we might make some
> progress.
> >
> > Thank you; this is exactly how things sit already in many WGs, e.g.,
> HTTP. The decisions we make impact many people who don't even know we exist
> on a daily basis.
> >
> > Cheers,
> >
> >
> > --

---

From: Ben Campbell <[email-masked]>
Date: Tue, 12 May 2020 17:05:11 -0500

I was mentally composing a reply to the effect of “The RSE should not be able to veto an IETF stream document approved through normal procedures on technical grounds, but could conceivably need to do so on editorial grounds.”  But Joel beat me to it.

Ben.

> On May 12, 2020, at 4:57 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> Can we step this down?
> 
> On the one hand, no, I do not think the RSE should have the authority to tell the IESG that the IETF can not publish particular technical content on technical grounds.
> On the other hand, if a technically competent RSE is that concerned about a document, I think we probably have a whole lot of other problems that need to be addressed.  Whether the RSE actually publishes that document or not is probably the least of our worries.
> 
> And I do think the RSE should have the authority to say to any stream "turn this into proper English before the RPC will process it."
> 
> Yours,
> Joel
> 
>>>> In Tue, May 12, 2020 at 10:55 AM Michael StJohns <[email-masked] <mailto:[email-masked]>> wrote:
>>> Oooh   tricky.   I'd either have the RSE refer it to the ISE as publication as an April Fool's RFC, or I'd probably be the first to sign on to a petition to recall the entire IESG.     In any case, the answer is probably yes, the RSE should refuse to publish the document as an Internet standard.   That assumes that the RSE - with the appropriate technical advisors - has the skillset to determine said document is "harmful to the Internet".
>>> 
>> I think we can appreciate that the example was chosen to be fantastical so as to not focus discussion on the technical matter as much as the degree of control the RSE is afforded over the technical contents of a document.
>> Now, I do recall a recent anecdote about Postel himself heatedly refusing to publish a specification he felt was technically misguided [1], so this authority did exist with the position at some point. Although never explicitly revoked, RFC 4844, section 4.1 et seq makes it pretty clear that the RSE has approval authority over precisely one stream (the Independent Submission stream). To the extent that the IAB had authority to publish RFC 4844, I think it makes it clear that the scope of authority had been pared back substantially since the "I am not going to publish a faulty specification as an RFC" days of 1991.
>> I'm not entirely sure my analysis above is all that useful, though, as this is the "rfced-future" discussion rather than the "rfced-history" discussion, and so it seems more sensible to focus on meeting the needs of the Internet community in 2020 and beyond than is is to lean on the historical narrative.
>> And so more to the point: I think that the IETF community writ large would be floored if a working group produced a document, the IETF found consensus on it during last call, the IESG approved it, and then the RSE refused to publish it (or imposed technical changes on its contents). Ditto for the IRTF and their documents. So, if we're matching authority with community expectations -- at least for a large swath of the relevant community -- I think the answer above of "the RSE should refuse to publish the document" is exactly wrong.
>> /a
>> ____
>> [1] https://mailarchive.ietf.org/arch/msg/rfc-interest/eurBBcxqbTu9iAz3PogGqh970H0/
> 
> --

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 May 2020 10:09:52 +1200

On 13-May-20 10:00, Andrew G. Malis wrote:
> So this section makes the distinction between "canonical" and "long term archival storage"'.

Oh, right. So that's an internal inconsistency in 7990.

   Brian

> 
> Cheers,
> Andy
> 
> 
> 
> 
> On Tue, May 12, 2020 at 5:05 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     >> On 12 May 2020, at 5:03 pm, John C Klensin <[email-masked] <mailto:[email-masked]>> wrote:
>     >>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 May 2020 23:10:41 +0100

On 12/05/2020 23:05, Ben Campbell wrote:
> I was mentally composing a reply to the effect of “The RSE should not
> be able to veto an IETF stream document approved through normal
> procedures on technical grounds, but could conceivably need to do so
> on editorial grounds.”  But Joel beat me to it.

Yeah, that's fair.

I guess I at least took it as a given that the RPC do
the copy-editing type work to fix the real cases we see
of editorial ickyness. (With careful author/AD approval
of course.) Having done 6 years on the IESG I can't
think of a single case of a document that got to auth-48
that was so bad that the current processes weren't able
to fix it sufficient for publication though, so that's
maybe as theoretical as ekr's example.

S.

>> On the one hand, no, I do not think the RSE should have the
>> authority to tell the IESG that the IETF can not publish particular
>> technical content on technical grounds. On the other hand, if a
>> technically competent RSE is that concerned about a document, I
>> think we probably have a whole lot of other problems that need to
>> be addressed.  Whether the RSE actually publishes that document or
>> not is probably the least of our worries.
>> 
>> And I do think the RSE should have the authority to say to any
>> stream "turn this into proper English before the RPC will process
>> it."
>> 
>> Yours, Joel
>> 
>>>> On 5/12/2020 3:25 PM, Michael StJohns wrote: On 5/12/2020 4:16
>>>> PM, Eric Rescorla wrote:
>>>>>> independence of the current RSE is not the same as in the
>>>>>> past - but I consider that a bug rather than a feature as
>>>>>> it means that its possible for a small subset of the IETF
>>>>>> community to affect the culture of the RFC series in ways 
>>>>> I want to zero in on this point, because I think it's useful
>>>>> to scope out people's views of "independence".
>>>>> 
>>>>> Let me try to start with what's hopefully a simple case:
>>>>> suppose that the IETF produces and the IESG approves a
>>>>> document to be published as RFC that the RSE believes is
>>>>> harmful to the Internet for technical reasons (it redefines
>>>>> IPv6 to have an 8 bit address, say). Do you believe that the
>>>>> RSE should be able to refuse to publish such a document?
>>>>> 
>>>>> -Ekr
>>>> 
>>>> publication as an April Fool's RFC, or I'd probably be the
>>>> first to sign on to a petition to recall the entire IESG.
>>>> In any case, the answer is probably yes, the RSE should refuse
>>>> to publish the document as an Internet standard.   That assumes
>>>> that the RSE - with the appropriate technical advisors - has
>>>> the skillset to determine said document is "harmful to the
>>>> Internet".
>>>> 
>>> fantastical so as to not focus discussion on the technical matter
>>> as much as the degree of control the RSE is afforded over the
>>> technical contents of a document. Now, I do recall a recent
>>> anecdote about Postel himself heatedly refusing to publish a
>>> specification he felt was technically misguided [1], so this
>>> authority did exist with the position at some point. Although
>>> never explicitly revoked, RFC 4844, section 4.1 et seq makes it
>>> pretty clear that the RSE has approval authority over precisely
>>> one stream (the Independent Submission stream). To the extent
>>> that the IAB had authority to publish RFC 4844, I think it makes
>>> it clear that the scope of authority had been pared back
>>> substantially since the "I am not going to publish a faulty
>>> specification as an RFC" days of 1991. I'm not entirely sure my
>>> analysis above is all that useful, though, as this is the
>>> "rfced-future" discussion rather than the "rfced-history"
>>> needs of the Internet community in 2020 and beyond than is is to
>>> lean on the historical narrative. And so more to the point: I
>>> think that the IETF community writ large would be floored if a
>>> working group produced a document, the IETF found consensus on it
>>> during last call, the IESG approved it, and then the RSE refused
>>> to publish it (or imposed technical changes on its contents).
>>> Ditto for the IRTF and their documents. So, if we're matching
>>> authority with community expectations -- at least for a large
>>> swath of the relevant community -- I think the answer above of
>>> "the RSE should refuse to publish the document" is exactly
>>> wrong. /a ____ [1]
-- 
>> Rfced-future mailing list [email-masked]

---

From: Adam Roach <[email-masked]>
Date: Tue, 12 May 2020 17:15:41 -0500

Right. I apologize if it was unclear that I was speaking strictly about 
the technical contents of a document. Personally, I'd be happy if the 
RSE/RPC were more liberal about sending things back as too poorly 
written to economically edit.

/a

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 May 2020 15:59:13 -0700

> Oh, right. So that's an internal inconsistency in 7990.

I have to admit, I'm a bit fuzzy on what "canonical" and "archival" mean,
so maybe we can go back to a more operational definition:

1. As I understand it, the XML is immutable (7990 S 10.2). However, the
publication formats can be regenerated as needed. Is that correct? I read
the text above as just saying that the PDF should be generated in a way
that it is suitable for long-term storage but isn't immutable.

2. In case of conflict, which version is authoritative? For instance,
suppose that the XML has a 2 in one place but the PDF renders with a 3.
What is the conformance standard? And going back to point (1), if we all
agree that we wish the value were 2, do we file an erratum on the PDF or
just regenerate it? Conversely, if we all agree that we wish it were 3 then
do we file an erratum on the XML and/or do a bis?

Would be good to get consensus on what we think these docs say and what we
think they ought to say.

-Ekr

> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >     > This does not shock me, but then I've interned in an art museum,
> where the challenges of conservatorship were painfully obvious.
> >     >
> >     >
> >     > I think that people are becoming slightly absolutist when they
> talk about this subject, but worse, they perceive those on "the other side"
> as *really* absolutist.
> >     >
> >     > If we can put those extremes safely out of the way and focus on
> what the needs of the archival and other communities are, we might make
> some progress.
> >     >
> >     > Thank you; this is exactly how things sit already in many WGs,
> e.g., HTTP. The decisions we make impact many people who don't even know we
> exist on a daily basis.
> >     >
> >     > Cheers,
> >     >
> >     >
> >     > --

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 May 2020 16:08:31 -0700

> do we file an erratum on the XML and/or do a bis?

Just to sharpen this point, when I say "we wish" I mean it's completely
clear it should be this value, for instance, the approved draft had the
agreed upon value in all formats but it got mangled somewhere in RFC
processing.

-Ekr

>> >     > I hope no one seriously thinks that "archival" means that we
>> can't change _any_ aspect of the series, ever -- that it's a machine that
>> must run on in its current form until its doom. I also hope that no one
>> thinks that changing things means that it must be possible to change any
>> character / bit in any RFC at any time.
>> >     >

---

From: Christian Huitema <[email-masked]>
Date: Tue, 12 May 2020 16:28:15 -0700

On 5/12/2020 4:08 PM, Eric Rescorla wrote:

>     1. As I understand it, the XML is immutable (7990 S 10.2).
>     However, the publication formats can be regenerated as needed. Is
>     that correct? I read the text above as just saying that the PDF
>     should be generated in a way that it is suitable for long-term
>     storage but isn't immutable.
>
>     2. In case of conflict, which version is authoritative? For
>     instance, suppose that the XML has a 2 in one place but the PDF
>     renders with a 3. What is the conformance standard? And going back
>     to point (1), if we all agree that we wish the value were 2, do we
>     file an erratum on the PDF or just regenerate it? Conversely, if
>     we all agree that we wish it were 3 then do we file an erratum on
>     the XML and/or do a bis?
>
>
> Just to sharpen this point, when I say "we wish" I mean it's
> completely clear it should be this value, for instance, the approved
> draft had the agreed upon value in all formats but it got mangled
> somewhere in RFC processing.

I am concerned that this is another example of the IETF landing on a
very complicated solution through a working group process. The theory is
that the XML is authoritative. But in practice, if the IETF has to
produce a document to a third party, the third party will insist on
something they can read. Most likely, PDF. But then, the PDF is derived
from XML by software, and that software can change over time. Imagine
two parties in a patent lawsuit arguing whether a technology was covered
by RFC XYZT, but arguing from different PDF renderings. "Page 237 says
that bla." "Oh, no, no such text on page 237." Endless fun.

-- Christian Huitema

---

From: Michael StJohns <[email-masked]>
Date: Tue, 12 May 2020 19:41:48 -0400

On 5/12/2020 7:28 PM, Christian Huitema wrote:
> very complicated solution through a working group process. The theory 
> is that the XML is authoritative. But in practice, if the IETF has to 
> something they can read. Most likely, PDF. But then, the PDF is 
> derived from XML by software, and that software can change over time. 
> Imagine two parties in a patent lawsuit arguing whether a technology 
> was covered by RFC XYZT, but arguing from different PDF renderings. 
> "Page 237 says that bla." "Oh, no, no such text on page 237." Endless fun.

Just because the legal folk insist on something they can read, doesn't 
mean that document will end up being the legal reference.   This is akin 
to the problems where you have two different languages involved in a 
lawsuit.  There's going to be a source document and a certified 
translation of some sort.  Think of the PDF as a certified translation 
between Geek and English.

In any event, XPath or something similar may end up being the way a 
lawyer refers to a paragraph or section or whatever.   We probably don't 
need to resolve the question at this point and instead leave it to the 
lawyers to deal with.  We just need to be clear in any legal service 
what the archival/canonical document actually is.

AIRC from recent discussions, any produced PDF is going to end up having 
the source XML embedded.

Later, Mike

ps - the underlying language of the more recent Word version is XML.  
I've had rendered formats of the underlying XML change pretty radically 
between versions.  It didn't actually change the meaning of the document.

pps - maybe an option on the production tools to embed XPath references 
in the PDF or HTML rendered document as hidden text or some sort of tool 
tip comment?

---

From: "John Levine" <[email-masked]>
Date: 12 May 2020 22:13:49 -0400

>>     storage but isn't immutable.

That is correct. We have already regenerated all the PDFs to fix an
error in the production process. The layout of the current PDFs is not
wonderful and I think it's likely that we'll regenerate them again as
we learn more about managing the layout.

>that bla." "Oh, no, no such text on page 237." Endless fun.

Fortunately, since the people who designed the v3 format were not
completely incompetent, they anticipated that problem. Each PDF has a
copy of the XML file embedded in it as a PDF attachment. In the
unlikely event that there is a question whether the PDF accurately
represents the contents of the XML, anyone who has the PDF can extract
the embedded XML and look at it to see what the canonical version
says. Since the XML is a stream of ordinary UTF-8 text, I'd say that
the chances that there will still be something around that can display
it several decades from now remain quite good.  Considering the kinds of
legal cases in which our RFCs tend to be used, if they can't figure out
how to use a text editor to look at the XML they have worse problems
than what's in our PDF.

I would encourage people in this discussion to remember that even
though an issue may be new to you, it doesn't mean it's new to
everyone.

R's,
John

PS: we asked our lawyers whether it would be a problem if we
rerendered the PDFs, and the answer was no. Legal processes have been
dealing with versions of documents for a very long time, and I am sure
I'm not the only one here who's been in a court case where some of the
evidence was Nth level copies of printouts of who knows what.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 May 2020 19:23:35 -0700

> we learn more about managing the layout.

Thanks. That is what I expected.

> though an issue may be new to you, it doesn't mean it's new to

I didn't think it was new to everyone, but it's not 100% clear in the RFC
(at least as I read it) so I wanted to make sure I understood correctly.

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 May 2020 14:36:08 +1200

On 13-May-20 14:23, Eric Rescorla wrote:
> 
> 
> On Tue, May 12, 2020 at 7:14 PM John Levine <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     In article <[email-masked] <mailto:[email-masked]>> you write:
> I didn't think it was new to everyone, but it's not 100% clear in the RFC (at least as I read it) so I wanted to make sure I understood correctly.

If you mean RFC7990, its initial terminology definition asserts that the canonical format is archived. That leaves the later statement about PDF/A-3 ("will be developed with an eye towards long-term archival storage") without an anchor.

I'm not losing any sleep over this.

    Brian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 13 May 2020 12:42:41 +1000

Mike,

> On 13 May 2020, at 6:46 am, Michael StJohns <[email-masked]> wrote:
> 
> Basically, what you've proposed is a strawman to be knocked down.   My guess is that any RSE that lets through something that *is* harmful to the internet (rather than just thinks it might be) will not have had a long tenure to start with.    What I think you're asking is similar to the problems that editors of wide circulation publishers go through all the time - to print or not to print.  In their case it might be "do we have enough evidence that politician A has actually committed adultery with staffer B" or "does printing C put D and E into danger"?  The business side may say - Lawyers are fine with it and it will make us money, but no editor worth their salt will let that be the only decision criteria.

I don't think it's helpful to use such a loose analogy in combination with a hypothetical to inform our discussion. It would be much more useful if we could focus on whether there's a concrete need to allow the RSE to do refuse publication -- for example, if it's intended as a counterbalance to the IESG and other stream managers' powers, let's examine that (and concurrently look at what counterbalances *that* power).

If we do think that the stream managers need such a check, it's possibly a bigger discussion; as has been mentioned, the recall process is intended to be act as a limit on the powers of the IESG and IAB. While recalls might not be perfect, fixing them indirectly through a function of the RSE shouldn't be the first thing we try, and it'd need to be coordinated.

If there are other reasons that we think it's valid for the RSE to refuse publication, let's come up with some examples and see if we can agree on some underlying principles. 

> So yes, the RSE absolutely can prevent publication, and yes absolutely the community (NOT the IESG, not the IAB etc) can arrange to replace the RSE for cause if such cause exists.

The RSE may indeed be able to mechanically prevent publication (in that they can fail to progress a document). If they did so with the intent of not allowing a stream to publish for non-editorial reasons, I suspect the community would indeed react. 

However, "the community" doesn't do the removing; n random people can't stand up and say "the RSE is hereby removed" with effect. To even get close to that being true, we'd need to accept the tyranny of whoever's able to shout the loudest. On principle, I (and I suspect others) would not accept _that_, and would endeavour to shout even louder.

Currently one can interpret the IAB has having the oversight role that would be the mechanism for this (with some amount of delegation to RSOC, and administrative function provided by the LLC); if that's removed to promote independence of the RSE, what would replace it? For example, we could assign it to:

* Nothing -> RSE as (hopefully B)DFL
* The IAB and/or RSOC, but with more specific guidance -> evolution of the status quo
* Some new body -> with the usual questions about selection, appeal, limits on power, etc.

Are there any other options?

One more thing -- at some point, I do want to return to the question of how the RSE judges and gathers the community's input, because if they're using it as input to decisions like "I should not publish this RFC", how they go about getting to that decision matters. An RSE that only engages with parts of the community isn't going to hear all of the perspectives that are relevant (especially in a community that's as fragmented as ours). Decisions where the input and deliberation aren't public are likely to be questioned, because if the RSE is the only person who sees it all, the decision won't have legitimacy. And so forth.

Cheers,

---

From: "John R. Levine" <[email-masked]>
Date: 12 May 2020 23:26:44 -0400

> I'm not losing any sleep over this.

I think it makes a lot of sense to have both.  PDF-A/3 is a bitrot 
resistant profile of PDF intended for archival purposes, which is fine for 
people who want to look at the words.  It doesn't have all of the 
semantics of the tagged stuff in the XML.

My usual example is that I e-mail a survey every month to authors of 
recent RFCs.  Starting with the XML it's about four lines of python to 
extract the <author> addresses.  Doing that from a PDF, urrgh.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 May 2020 20:31:58 -0700

On Tue, May 12, 2020 at 7:42 PM Mark Nottingham <[email-masked]> wrote:

> guess is that any RSE that lets through something that *is* harmful to the
> internet (rather than just thinks it might be) will not have had a long
> tenure to start with.    What I think you're asking is similar to the
> problems that editors of wide circulation publishers go through all the
> time - to print or not to print.  In their case it might be "do we have
> enough evidence that politician A has actually committed adultery with
> staffer B" or "does printing C put D and E into danger"?  The business side
> may say - Lawyers are fine with it and it will make us money, but no editor
> worth their salt will let that be the only decision criteria.
>
> I don't think it's helpful to use such a loose analogy in combination with
> a hypothetical to inform our discussion. It would be much more useful if we
> could focus on whether there's a concrete need to allow the RSE to do
> refuse publication -- for example, if it's intended as a counterbalance to
> the IESG and other stream managers' powers, let's examine that (and
> concurrently look at what counterbalances *that* power).
>
> If we do think that the stream managers need such a check, it's possibly a
> bigger discussion; as has been mentioned, the recall process is intended to
> be act as a limit on the powers of the IESG and IAB. While recalls might
> not be perfect, fixing them indirectly through a function of the RSE
> shouldn't be the first thing we try, and it'd need to be coordinated.
>

To draw out this hypothetical a bit it might be helpful to try to
understand what the intended semantics would be.

Specifically, if the IETF were to approve a specification [0] and the RFC
Editor were then to decline to publish it, what would be the status of the
specification under those circumstances [1]? Even if we assume ad arguendo
that the RSE is empowered to refuse publication in order to protect the
integrity of the series, it's hard to understand how that extends to the
power to generally veto IETF decisions.

-Ekr

[0] Mike, I did see your questions. We could certainly flesh out the
details of the IESG's decision procedure for the purposes of the hypo, but
I'm not sure it really matters. The IETFs rules are what they are and we
don't generally treat standards that had very rough consensus or small
numbers of IESG Yes ballots as somehow second class.

[1] Of course as often noted, we're not the protocol police so the question
of normative force is always a little fraught, but consider a document
which has side effects, either because it's a process document or results
in changes by IANA, etc.

---

From: Nevil Brownlee <[email-masked]>
Date: Wed, 13 May 2020 15:52:56 +1200

Hi all:
I reckon Joel summed up the underlying question here.  If the RSE sees
problems with a draft sent in for publication, the RSE's response is to
negotiate with the stream manager who requested it's publication  In the
worst case, the RSE can publish such an RFC with a note to say what the
RSE-perceived problems were.
In short, we already have effective answers to such a hypothetical question.
Cheers, Nevil

On Wed, May 13, 2020 at 3:32 PM Eric Rescorla <[email-masked]> wrote:

>> I don't think it's helpful to use such a loose analogy in combination
>> with a hypothetical to inform our discussion. It would be much more useful
>> if we could focus on whether there's a concrete need to allow the RSE to do
>> If we do think that the stream managers need such a check, it's possibly
>> a bigger discussion; as has been mentioned, the recall process is intended
>> to be act as a limit on the powers of the IESG and IAB. While recalls might
> [1] Of course as often noted, we're not the protocol police so the
> question of normative force is always a little fraught, but consider a
> document which has side effects, either because it's a process document or
> results in changes by IANA, etc.
> --

-- 
-----------------------------------
Nevil Brownlee, Taupo, NZ

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 13 May 2020 14:19:45 +1000

> In short, we already have effective answers to such a hypothetical 

It is clear that reasonable people will find a solution.  But the point of the exercise is to extract what we believe the principles are, and from that the extent of authority of each of the actors.

https://tools.ietf.org/html/rfc6635#section-4.3 perhaps holds the answer here:

   The RSE may make final decisions unilaterally only to assure the
   functioning of the process, and only while there is an evaluation of
   current policies to determine whether they are appropriately
   implemented in the decision or need adjustment.  In particular, it
   should be noted that final decisions about the technical content of
   individual documents are the exclusive responsibility of the stream
   approvers from which those documents originate, as shown in the
   illustration in Figure 1.

The first sentence constrains the unconstrained authority of the RSE to "the functioning of the process".  The second makes it clear that technical content is not under their control.  Though I agree that we might collectively benefit from a technically competent RSE flagging something, that's not a benefit that we should count on.

What it means to assure functioning of the process is what seems to be in question.  I'm going to suggest that "the process" in this context refers to the proper functioning of the subsystem comprised of RSE, RPC, and publisher. That puts the functioning of each of the streams out of scope: if a stream produces crap, and insists on publication, this architecture would seem to require that that crap is ultimately published.

There is a big squishy space here where we would hope that reasonable people might do better by working with others constructively, but when it comes to the bright lines needed in cases of dispute, this seems to be that bright line.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 13 May 2020 06:38:45 +0200

On 2020-05-13, at 01:28, Christian Huitema <[email-masked]> wrote:
> 
>  Imagine two parties in a patent lawsuit arguing whether a technology was covered by RFC XYZT, but arguing from different PDF renderings. "Page 237 says that bla." "Oh, no, no such text on page 237." Endless fun.

… and as a side comment on the brokenness of the discussion that led us to where we are:

Not wanting people to cite RFCs by page number was the putative reason the .TXT files are not currently paginated, decreasing their usefulness in many situations.  Of course the .PDFs are paginated, so if someone needs a page number, they can use those.  So we destroyed useful functionality (page numbers in .TXT) because we didn’t want to have that functionality at all but ignored that we need it anyway in a different place (.PDF).

I don’t want to reopen the discussion here, but just use it as a data point for my conjecture that the V3 process isn’t done yet.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Wed, 13 May 2020 10:24:12 +0200

> I don’t want to reopen the discussion here, but just use it as a data point for my conjecture that the V3 process isn’t done yet.

So what would be your proposal here? Have page numbers in plain TXT, and
require them to be in sync with the PDF rendering?

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 13 May 2020 10:44:48 +0200

Well, I said:
> 
>> I don’t want to reopen the discussion here,

> require them to be in sync with the PDF rendering?

We can discuss this over in RFC-Interest.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 May 2020 10:36:32 +1200

Hi Martin,

>  if a stream produces crap, and insists on publication, this architecture would seem to require that that crap is ultimately published.

Yes, that is the principle applied to the Independent Stream so it should probably be generalised. For the Independent Stream, the IESG has the right to insert a disclaimer; we would probably need to allow the RSE to insert a disclaimer in a similar way (and of course only in extreme circumstances).

Regards
   Brian

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 May 2020 17:55:37 -0500

On 5/13/2020 5:36 PM, Brian E Carpenter wrote:
> we would probably need to allow the RSE to insert a disclaimer in a similar way

I'd be curious to hear other people weigh in on whether this matches 
their expectations. I feel far less strongly about it than I do the 
broader issue of veto power, but it seems that adding new material 
wholly fabricated by the RSE (such as a disclaimer) is a bit beyond the 
remit that the community might reasonably expect.

/a

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 14 May 2020 09:02:29 +1000

> On 14 May 2020, at 8:55 am, Adam Roach <[email-masked]> wrote:
> 
> I'd be curious to hear other people weigh in on whether this matches their expectations. I feel far less strongly about it than I do the broader issue of veto power, but it seems that adding new material wholly fabricated by the RSE (such as a disclaimer) is a bit beyond the remit that the community might reasonably expect.

I personally don't think it's necessary, and would find it surprising and somewhat unwelcome if it happened tomorrow - mostly because I wouldn't be entirely sure if there were *other* people who could weigh in if they so chose. 

If we want to explicitly give the RSE this power, we should write it down and canvass it with the community*.

Cheers,

* Yes, yes.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 May 2020 00:08:43 +0100

On 14/05/2020 00:02, Mark Nottingham wrote:
>> I'd be curious to hear other people weigh in on whether this
>> matches their expectations. I feel far less strongly about it than
>> I do the broader issue of veto power, but it seems that adding new
>> material wholly fabricated by the RSE (such as a disclaimer) is a
>> bit beyond the remit that the community might reasonably expect.
> 
> I personally don't think it's necessary, and would find it surprising
> and somewhat unwelcome if it happened tomorrow - mostly because I
> wouldn't be entirely sure if there were *other* people who could
> weigh in if they so chose.
> 

+1, I think I'd prefer RSE push-back, if needed in
extremis, to use other methods, such as mail to
ietf@ietf complaining and explaining. Then let the
community there deal with the putative crap IETF
stream document. Something similar should also be
ok for other streams.

S.

> 
> Cheers,
> 
> * Yes, yes.
> 
> 
> -- Mark Nottingham   https://www.mnot.net/
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 13 May 2020 18:21:59 -0500

> On May 13, 2020, at 5:55 PM, Adam Roach <[email-masked]> wrote:
> 

I agree with Adam here. Circling back to the “technical” vs “editorial” grounds, I would not expect the RSE to add a disclaimer to an IETF-stream RFC on technical grounds. While less severe than a veto, it would still involve an RSE attempting to override consensus. 

And I can’t imagine a disclaimer on editorial grounds being very useful for any purpose other than perhaps washing their hands of responsibility for a poorly written document.

Ben.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 May 2020 11:23:49 +1200

> stream document. Something similar should also be

Certainly we're talking about a very low probability event, comparable
to a legislature stating that pi == 3. But would you prefer that the
RSE's only option in that case is to resign?

    Brian

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 May 2020 00:31:31 +0100

> RSE's only option in that case is to resign?

Not sure one always has to die on the hill tbh.

Sure, if it happened a few times or went badly
wrong, that might be the outcome. But overall,
yes, I think the IETF community ought win in a
case like that. In practice, I'd expect that
if the RSE were right in causing a fuss, then
there'd more likely be consequences for an AD
or WG chair or something.

Cheers,
S.

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 May 2020 18:42:14 -0500

> RSE's only option in that case is to resign?

[Insert "Well that escalated quickly" meme here]

What I understand this conversation to be trying to do is feeling out 
the scope of responsibility of the various parties in the ecosystem. My 
mental model has always been that stream managers are responsible for 
the technical content of documents [1], while the RFC Editor is 
responsible for the editorial quality of them.

Regardless of how unlikely the situation you envision is to arise, I 
think the broader point is that the output of this effort needs to make 
it very clear whether the RSE is responsible for the technical contents 
of a document; and I beleive the answer needs to unambiguously be "yes" 
or "no."

/a

____
[1] Not unilaterally, of course. They answer to the community they 
serve, and are subject to the rules that apply to their stream, but I 
think those constraints are both well-understood and out of scope of 
this effort.

---

From: "John Levine" <[email-masked]>
Date: 13 May 2020 19:43:43 -0400

>RSE's only option in that case is to resign?

Actually, yes. If the various stream managers are at such an impasse
that they can't figure out how to advance or abandon a document, I
think it's fine for things to blow up.

R's,
John

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 14 May 2020 09:44:05 +1000

> On 14 May 2020, at 9:23 am, Brian E Carpenter <[email-masked]> wrote:
> 

This is where the editor analogy gets unstuck. If you envision this role as responsible for the overall quality of the series, but don't give them the ability to select and change content, hire, fire and direct the people writing the content, etc. (as a "normal" editor does), you're setting them up to fail. Even if they can refuse to publish documents and/or add disclaimers to the top, it's a really poor and indirect form of quality control.

So, I don't think that resignation is on the cards here; it would be akin to refusing to bake a cake because you don't like the wedding. We don't expect the baker to have an opinion about what we use the cake for; we expect them to bake excellent cakes, to train their assistants well, and to assure that the cake-making business has a future. We certainly would have a problem if they started writing their opinions on the cakes.

Yes, this analogy will fall apart soon too.

This role is hard. We seem to expect it to be filled by someone who knows about publishing in general, technical publishing specifically, strategy, XML publication pipelines, indirect team management, project management, consensus building, and I'm sure much more. Adding the responsibility to know when something is "bad for the Internet" with MORE confidence than the entire IESG is a lot to push uphill. It also adds the considerable risk that a subset of the community will be able to convince this person that it's bad, but that won't reflect the entire community's consensus.

IMO we should be looking at devolving the responsibilities of this role to multiple people, rather than piling more on. I think it's much more tractable if we had, for example, one person who's in charge of finding what the consensus of the community regarding strategy is, and another to execute that strategy. I suspect those two people with different skill sets would be much easier to find than one super-human with all of them.

Cheers,

---

From: Ben Campbell <[email-masked]>
Date: Wed, 13 May 2020 19:38:01 -0500

> On May 13, 2020, at 6:24 PM, Brian E Carpenter <[email-masked]> wrote:
> 

I think we are talking about the situation where the RSE cannot in good conscious publish an approved IETF-stream document, has attempted to push back to the community using appropriate channels, but has been unable to resolve the issues. 

I can imagine 2 scenarios that might lead to that point: 1) The RSE is seriously overstepping their remit and is trying to push their own opinion over consensus, or 2) The entire IETF is so far in the weeds that no reasonable RSE could work with it. Both of those seems like resignation-appropriate scenarios. Do you imagine other scenarios?

Also, How much effort should we undertake to plan for such a low priority event? 

Ben.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 13 May 2020 21:05:07 -0400

> stream document. Something similar should also be

I'm not sure how the above differs from "I can't publish this document 
at this time for the following reasons - please fix it and until you do 
I can't publish it".

Going back to the "independence" thread, an RSE has to be able to say 
something like this without fear of retribution, or with sufficient 
protections against retribution.

Later, Mike

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 14 May 2020 11:13:58 +1000

> On 14 May 2020, at 11:05 am, Michael StJohns <[email-masked]> wrote:
> 
> an RSE has to be able to say something like this without fear of retribution, or with sufficient protections against retribution.

Why?

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 May 2020 02:22:52 +0100

Hiya,

On 14/05/2020 02:05, Michael StJohns wrote:
> I can't publish it"

I don't think we should have a written procedure for when
the RSE ought/can say the above. I do think a wise RSE
might say something like that in extremis. (Which'll not
happen I bet.)

> protections against retribution.

Fear, or the lack thereof, seems to me to be in the mind
of the RSE, and not something we can specify. So I don't
see how that's relevant other than as rhetoric.

I'm not sure what "protections against retribution" might mean, nor what
retribution could be relevant.

Basically, I think we're dancing on the head of a pin
at this point in the thread;-)

But maybe there's a concrete outcome: we should make sure
to hire an RSE that doesn't take crap from treams or I*
bodies and maybe even make some nicely-phrased equivalent
part of the job spec., without really defining what is
an attitude and expectation of independence. I'd be fine
if we had such a no-shrinking-violets clause somewhere
like that.

Cheers,
S.

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 13 May 2020 18:45:44 -0700

To the point of adding a disclaimer or similar, I agree that doing so would certainly go beyond the remit of the RSE. An RFC published on the IETF stream is not a reflection on the RSE, and thus even if the RSE had some technical quarrel with a document, for the purposes of that document the RSE would be acting as just another individual in the standards process—“no hats”, in a way.

The existing text on IETF track RFCs is *already* disclaimer/explanation enough. It does not require that the RSE has any technical opinion at all. 

===
This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

===

Thanks,

Tommy

> On May 13, 2020, at 3:55 PM, Adam Roach <[email-masked]> wrote:
>

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 13 May 2020 18:59:49 -0700

Michael StJohns <[email-masked]> writes:

> I'm not sure how the above differs from "I can't publish this document at this
> time for the following reasons - please fix it and until you do I can't publish
> it". 
> 
> Going back to the "independence" thread, an RSE has to be able to say something
> like this without fear of retribution, or with sufficient protections against
> retribution.

Let's say someone is upset about a document being published in a WG.  It
goes through last call(s), and they raise their concerns but are in the
minority (still).  They appeal to the IESG and the appeal is denied.
They appeal to the IAB and the appeal is denied.  They then appeal to
the RSE about their issue, the RSE agrees and refuses to publish it "for
the following reasons" (which came from the objection-er).

What types of issues is this acceptable under?

If we opt for entirely-independent, then this is considered acceptable.
If we only allow for non-technical changes, then we are reducing their
independence to only the other elements of publication.  If we prevent
this scenario at all, then is there any independence left?

Slide your slider somewhere along that line.

-- 
Wes Hardaker
USC/ISI

---

From: Christian Huitema <[email-masked]>
Date: Wed, 13 May 2020 19:26:19 -0700

> Slide your slider somewhere along that line.

The RSE refusing publication on editorial grounds is fine, but when it
comes to technical issues the RSE is just another individual whose
technical opinion has no more precedence than any other member of the
community. Giving the RSE power to arbitrage technical issues would just
but the placing the RSE on a collision course with the IETF. I don't
think that creating more sources of conflict would be productive in any way.

-- Christian Huitema

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 May 2020 21:51:53 -0500

On 5/13/2020 8:05 PM, Michael StJohns wrote:
> at this time for the following reasons - please fix it and until you 
> do I can't publish it".
>

Can you clarify the distinction you would make between "retribution" and 
"accountability"?

/a

---

From: Michael StJohns <[email-masked]>
Date: Wed, 13 May 2020 23:10:34 -0400

On 5/13/2020 10:51 PM, Adam Roach wrote:
>> I'm not sure how the above differs from "I can't publish this 
>> document at this time for the following reasons - please fix it and 
>> until you do I can't publish it".
>>
> Can you clarify the distinction you would make between "retribution" 
> and "accountability"?
>
> /a
>
Sure - can you tell me what you mean by accountability in this model?

Mike

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 May 2020 22:46:41 -0500

On 5/13/2020 10:10 PM, Michael StJohns wrote:
>>> Going back to the "independence" thread, an RSE has to be able to 
>>> say something like this without fear of retribution, or with 
>>> sufficient protections against retribution.
>>>
>>

Let's tease this out by making it a little less abstract.

Imagine TLS 1.3 were still under development, and that its publication 
request came under the future model we're developing. For whatever 
reason, the newly-installed RSE has decided that the various new 
security properties in TLS 1.3 are problematic for law enforcement's 
surveillance activities. They've extrapolated this to an increase in the 
chances of a terror attack to such a degree that they're willing to 
stake their professional credibility on making sure it does not get 
published in the form that the working group, the IETF at large, and the 
IESG agreed to.

So they respond to the IETF with "I can't publish this document at this 
time because it lacks interception-related features. Please fix it, and 
until you do, I can't publish it."

If you think that the system we're developing here makes this the final 
word on that technical matter -- either we insert interception-related 
features in TLS 1.3, or it simply doesn't get an RFC number -- please be 
sure to say so clearly and unambiguously.

But if the ultimate conclusion here is that the RSE is removed from 
their post (ignoring for a moment who makes the decision to perform such 
removal) and the RFC is published with the technical content generated 
by the IETF, is that retribution? Or is that holding the RSE accountable 
for failing to perform their duties?

/a

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 May 2020 16:53:16 +1200

Wow, this thread has a life of its own. Below...
On 14-May-20 14:26, Christian Huitema wrote:
> The RSE refusing publication on editorial grounds is fine, but when it comes to technical issues the RSE is just another individual whose technical opinion has no more precedence than any other member of the community. Giving the RSE power to arbitrage technical issues would just but the placing the RSE on a collision course with the IETF. I don't think that creating more sources of conflict would be productive in any way.

My feeling after reading the thread is that in such a situation, the RSE should be like any other community member: (s)he can appeal the IESG's decision to publish, and possibly escalate the appeal to the IAB. Whether the grounds for the appeal are technical (pi is actually 22/7) or more general (the lawyer says that we will be sued or prosecuted) is beside the point.

In other words, if there's a conflict, use the existing conflict-resolution mechanism.

But an actual veto on technical content seems to fundamentally break the stream model.

Regards
   Brian

---

From: John C Klensin <[email-masked]>
Date: Thu, 14 May 2020 02:49:50 -0400

--On Thursday, May 14, 2020 16:53 +1200 Brian E Carpenter
<[email-masked]> wrote:

>> The RSE refusing publication on editorial grounds is fine,
>> but when it comes to technical issues the RSE is just another
>> individual whose technical opinion has no more precedence
>> than any other member of the community. Giving the RSE power
>> to arbitrage technical issues would just but the placing the
>> RSE on a collision course with the IETF. I don't think that
>> creating more sources of conflict would be productive in any
>> way.
> 
> My feeling after reading the thread is that in such a
> situation, the RSE should be like any other community member:
> (s)he can appeal the IESG's decision to publish, and possibly
> escalate the appeal to the IAB. Whether the grounds for the
> appeal are technical (pi is actually 22/7) or more general
> (the lawyer says that we will be sued or prosecuted) is beside
> the point.
> 

I have just had occasion to read through multiple documents
trying to find the reference associated with my recollection
that there was a procedure for the RFC Editor Function to reject
a document on editorial grounds and for the IESG to say "publish
anyway, if necessary with a note indicating that the document
did not meet RFC Series Standards".  I have not been able to
find it (and may well be suffering from deteriorating memory)
but, in the process, I did run across a sentence in the fourth
paragraph of Section 4.3 of RFC 8728 (present in identical, or
nearly identical form, in RFCs 6635 and 5620).  It reads:

  "In particular, it should be noted that final decisions about
  the technical content of individual documents are the
  exclusive responsibility of the stream approvers from which
  those documents originate, as shown in the illustration in
  Figure 1."

While I understand (and anticipate) that the discussions during
this effort may lead to some fundamental changes to RFC 8728, I
would hope that we can all be sufficiently familiar with that
document (and other key documents about the RFC Series) to avoid
going around loops on issues that seem to have been settled long
ago and that do not seem to be in obvious need of reopening.

best,
   john

---

From: Eliot Lear <[email-masked]>
Date: Thu, 14 May 2020 09:06:14 +0200

Brian,

Thanks for putting out the draft.  It has really stimulated conversation, a task I prefer to not have to perform ;-).  And thanks to all who are participating.

I am trying to keep track of questions raised:

Does the RFC Editor have the authority to refuse to publish based on technical concerns?
Does the RFC Editor have the authority to add a note based on technical concerns?
Does the RFC Editor have the authority to add a note expressing concern?

The value of these questions is that they do indeed, as Adam wrote, explore the scope of authority the RFC Editor has, and they also bring into focus the skill set and experience that an RSE should/should not require.

John’s point, that these questions have already been settled long ago, is valid, but sometimes it is nice to test whether the question has a different answer after time as passed (even though very little time has passed since RFC 8728).  I see that we have done that here, and most of us are drawing the same conclusions.

One additional question that came up:

What should the RFC Editor do when she or he vehemently disagrees with a point of view expressed in a draft?

The question of retribution versus accountability has come up, and has not been fully explored.

Eliot

---

From: S Moonesamy <[email-masked]>
Date: Thu, 14 May 2020 02:55:05 -0700

Hi John,
>nearly identical form, in RFCs 6635 and 5620).  It reads:

Are you thinking about Section 4.6 of RFC 4846?  There is the 
following sentence: "Such rejection would normally be based on the 
conclusion that the submission does not meet the technical or 
editorial standards of the RFC Series or is not relevant to the areas 
that the series covers".  To keep matters simple, I would say that it 
does not apply to IETF documents.  At some point in IETF history, the 
approach was: "the RFC Editor will fix the draft".  I don't know 
whether to impact on the cost of that decision were duly considered 
or whether there was any formal decision.

There are some past decisions which made sense at that point in 
time.  For example, the concern around the time that RFC 6335 was 
written was to find a RFC Editor.  My guess is that it also 
influenced some of the changes which gained agreement at that 
time.  There was probably some administrative issues as well.

Regards,
S. Moonesamy

---

From: John C Klensin <[email-masked]>
Date: Thu, 14 May 2020 10:43:08 -0400

--On Thursday, May 14, 2020 02:55 -0700 S Moonesamy
<[email-masked]> wrote:

>> that there was a procedure for the RFC Editor Function to
>> reject a document on editorial grounds and for the IESG to
>> say "publish anyway, if necessary with a note indicating that
>> the document did not meet RFC Series Standards".  I have not
>> been able to find it (and may well be suffering from
>> deteriorating memory) but, in the process, I did run across a
>> sentence in the fourth paragraph of Section 4.3 of RFC 8728
>> (present in identical, or nearly identical form, in RFCs 6635
>> and 5620).  It reads:
> 
> following sentence: "Such rejection would normally be based on
> the conclusion that the submission does not meet the technical
> or editorial standards of the RFC Series or is not relevant to
> the areas that the series covers".  To keep matters simple, I
> would say that it does not apply to IETF documents. 

No, I was not.  The concern was strictly about the IETF stream.
In the Independent Stream, evaluation for technical quality is a
major part of the activity.

> At some
> point in IETF history, the approach was: "the RFC Editor will
> fix the draft".  I don't know whether to impact on the cost of
> that decision were duly considered or whether there was any
> formal decision.

"The RFC Editor will fix..." is still the policy.  The questions
are the limits of how good something has to be for the RFC
Editor to fix it and, potentially, the resource requirements if
many documents that require significant work come over the wall.
For the recent discussion, I think that, although other
scenarios could be made up, there are only two realistic
situations of interest (and one of them isn't very realistic).

* An I-D was written by someone with sufficiently poor written
English that the RFC Editor Function couldn't make sense or it
or determine how to edit it into acceptable English and style.
>From a slightly different perspective, such a document would
need translation, not editing, and (at least so far) that has
never been considered an RFC Editor function.  I don't consider
this realistic because I cannot imagine such a document getting
through IETF Last Call and IESG review without the IESG deciding
that the document (and maybe the author) needs help rather than
forwarding it to the RFC Editor.

* A document reaches the RPC that, in their judgment, contains
ambiguous language they cannot determine how to fix.  They
presumably go back to the author and/or IESG and say, very
politely, "what does this mean?  A or B?".  Under any
normal/sane conditions, they get a reply and everyone goes
happily on their way.  If there are many such issues, we would
hope that the IESG would pull the document and send it back to
the WG or author(s).   One would also hope that a document with
such problems, especially a high density of them, would be
caught during Last Call and never reach the RFC Editor in that
form (if it isn't, that would be, IMO, a failure in the review
process).   AFAICT, an issue of the sort we have been talking
about would arise only if the RFC Editor says "these things are
ambiguous or otherwise broken and we cannot edit it unless those
issues are resolved" and the IESG and author(s) respond
"perfectly clear to us, we are not going to change it, just
publish it".  

That raises an issue that probably belongs on our agenda as a
subpart of the "who is accountable to whom topic": RFC 5620 and
6635/8728 contain sections that describe what happens if there
is a disagreement among between one of the streams and the RFC
Editor.  After some discussion that I think can be summarized as
"everyone should behave like adults and get help from other
adults if needed", 5620 pushes thinks onto the RSAG, a body
appointed by the RSE.   6635 changed that to push things to the
RSOC, a body appointed by the IAB.  While it is probably
reasonable to assume that the RSE would appoint people to the
RSAG who have significant technical publications expertise and
other useful substantive (i.e., not purely managerial or general
interest) experience, that is not (as we have seen) a realistic
expectation of the RSOC as now constituted.   So, depending on
what we do in other areas, those sections will likely need to be
rethought.

best,
   john

---

From: Michael StJohns <[email-masked]>
Date: Thu, 14 May 2020 11:59:02 -0400

(trimming back to the list)

> My feeling after reading the thread is that in such a situation, the RSE should be like any other community member: (s)he can appeal the IESG's decision to publish, and possibly escalate the appeal…

Some folks are using "veto" and that tends to imply prohibition without 
discussion and I don't think that's what I mean.  I'm on board with a 
collaborative approach to fix things, but in the end its possible the 
stream, or author may not want to cooperate.  We ought to be able to 
find a path through, but that's not always easy.

With respect to "refusing publication on editorial grounds..." consider 
the following statement that might appear by accident in an RFC and make 
it all the way through WG and IETF last call:

"... the transmission rate can exceed the speed of light..."

This is obviously not an editorial problem, but it;s ... well ... wrong. 
Obviously, the word should be "cannot".  Under the strictest 
interpretation of "stick with editing", this would not be something the 
RSE nor the RPC could or should address - e.g. it's not editorial in 
nature - it's well structured English on a technical topic.  There are 
probably other examples (and some that have actually happened) - leading 
me to be leery  of circumscribing the RSE authority to "editorial problems".

The general rule in the IETF has been to avoid giving detailed 
instructions for policy things instead count on an ability to derive 
consensus as needed.   My main comment here is that we shouldn't overly 
circumscribe the RSE's editorial role and instead just do as we've been 
doing:  The RSE may refuse to publish as-is and will attempt to resolve 
any discovered issues with the streams, WGs and authors.  We're clear 
that changes in the RFC candidate require author approval and in some 
cases require the WG to weigh in or even the possibility of yet another 
last call.  The problem occurs when you get to an impasse where both 
sides think they're doing the right thing.  Rather than try to set hard 
and fast boundaries, I'd leave intact the notion that the RSE is 
ultimately responsible for the content of the series, and that the 
community may remove an RSE whose view of appropriate content diverges 
from the consensus.

I mostly don't disagree with anything Brian has said here, and I would 
expect technical pushback by the RSE/RPC to use internal channels first, 
(author/WG/AD/IRTF chair/ISE), but I don't think our appeal chains are 
really set up for the type of pushback by the RSE that might be 
necessary; the RSE is not - exactly - a community participant in the way 
the appeal process is laid out.

Ultimately, this is either an job with editorial control or a rubber 
stamping operation - the more constraints on decision making, the less 
this is an editorial job and more of a project management job.  I'd 
rather pick good people, tell them to shepherd and enhance the series, 
give them the mission of the series and all the various documents that 
have been written describing various processes and step back and let 
them do their job, including telling us when we're trying to publish 
something ... lacking ....

Mike

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 14 May 2020 09:13:17 -0700

> On May 14, 2020, at 8:59 AM, Michael StJohns <[email-masked]> wrote:
> 
> With respect to "refusing publication on editorial grounds..." consider the following statement that might appear by accident in an RFC and make it all the way through WG and IETF last call:
> 
> This is obviously not an editorial problem, but it;s ... well ... wrong. Obviously, the word should be "cannot".  Under the strictest interpretation of "stick with editing", this would not be something the RSE nor the RPC could or should address - e.g. it's not editorial in nature - it's well structured English on a technical topic.  There are probably other examples (and some that have actually happened) - leading me to be leery  of circumscribing the RSE authority to "editorial problems”.

I’d argue that this example is indeed an editorial problem, or at least one the RSE would be able to reasonably raise as an editorial question. The presumed cause for this error in the document was a typo that reviewers glossed over—someone meant to type “cannot” and type “can”. It is perfectly reasonable for the editor to, during the process of editing, raise that point to the authors and various interested parties. In this example, the typo can be corrected. Indeed, I would expect this question to be raised. The stream owners are then responsible for clarifying whether a perceived error is indeed an editorial error, or was intended.

Tommy

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 May 2020 12:22:33 -0500

On 5/14/2020 10:59 AM, Michael StJohns wrote:
>
> Some folks are using "veto" and that tends to imply prohibition 
> without discussion and I don't think that's what I mean.

I'm trying to figure out the line you are drawing between "please fix 
this and until you don't I can't publish it" and "veto". At this point, 
I'm baffled.

> I'm on board with a collaborative approach to fix things, but in the 
> end its possible the stream, or author may not want to cooperate. We 
> ought to be able to find a path through, but that's not always easy.

Sure. We definitely need to optimize for success, but also make sure we 
don't have some kind of constitutional crisis when failure arises. In 
the unfortunate case of a complete impasse, who ultimately owns the 
decision about the technical contents of the document?

> With respect to "refusing publication on editorial grounds..." 
> consider the following statement that might appear by accident in an 
> RFC and make it all the way through WG and IETF last call:
>
> This is obviously not an editorial problem, but it;s ... well ... 
> wrong. Obviously, the word should be "cannot".  Under the strictest 
> interpretation of "stick with editing", this would not be something 
> the RSE nor the RPC could or should address - e.g. it's not editorial 
> in nature - it's well structured English on a technical topic.  There 
> are probably other examples (and some that have actually happened) - 
> leading me to be leery  of circumscribing the RSE authority to 
> "editorial problems".

You're conflating authority with responsibility [1]. In the case you 
describe, of course the RSE and/or RPC would be responsible for flagging 
the issue to the stream manager and authors. But the ultimate authority 
over the the technical content needs to live in one place so as to 
handle those hopefully rare cases when a conflict arises.

> consensus as needed.   My main comment here is that we shouldn't 
> overly circumscribe the RSE's editorial role and instead just do as 
> we've been doing:  The RSE may refuse to publish as-is and will 
> attempt to resolve any discovered issues with the streams, WGs and 
> authors.

As before, I'm thoroughly perplexed by the distinction you believe 
you're making between "refuse" and "veto."

> We're clear that changes in the RFC candidate require author approval 
> and in some cases require the WG to weigh in or even the possibility 
> of yet another last call.  The problem occurs when you get to an 
> impasse where both sides think they're doing the right thing.  Rather 
> than try to set hard and fast boundaries, I'd leave intact the notion 
> that the RSE is ultimately responsible for the content of the series, 
> and that the community may remove an RSE whose view of appropriate 
> content diverges from the consensus.

What you're advocating here is a model that explicitly has overlapping 
spheres of authority. In my experience, that works well enough when 
things are going well, and goes catastrophically wrong when they don't.

I agree with what I infer as a major part of what you're saying: there 
is nothing more important in this model than ensuring that the 
relationship between the RSE and the stream managers is collaborative. I 
think where we're diverging is whether having clearly assigned authority 
makes this more likely or less likely.

So, for example, if the RSE decided that they wanted to make a 
transition from the Chicago Manual of Style [2] to the New York Law 
Reports Style Manual, I would expect that one or more stream managers 
would reasonably provide feedback that such a change isn't well suited 
for engineering documents (in fact, going back to the 
responsibility/authority distinction, I would argue that they would have 
a responsibility to do so). But if the RSE remains unconvinced by that 
feedback, the authority needs to reside in exactly one place so that an 
ultimate, legitimate decision can be made.

As long as this delineation of authority is clearly spelled out by the 
community in advance, this kind of disagreement doesn't escalate into a 
tussle that threatens the overall structure. Without clear lines of 
authority, that is exactly what happens every time (at least, in my 
experience).

> something ... lacking .... 

Absolutely. I think it's critical that the role have *responsibility* 
for telling the stream managers when they think something in a document 
is wrong. This is not the same thing as having *authority* on the 
technical content of the documents (again, [1]).

/a

____
[1] I'm using these terms in the sense generally used in a 
Responsibility Assignment Matrix.

[2] See RFC 7322, section 1

---

From: S Moonesamy <[email-masked]>
Date: Thu, 14 May 2020 11:23:12 -0700

Hi John,
>major part of the activity.

I don't recall reading anything related to that.  However, you have 
been around longer than I have.

>forwarding it to the RFC Editor.

I haven't been following the IETF that closely as I had to focus on 
other problems.  I haven't seen the above case arising in the IETF Stream.

>"perfectly clear to us, we are not going to change it, just

The above could arise.  My short experience of the RPC is that they 
sometimes ask very good questions.  If I am not mistaken, the 
practice in the IETF is to have an Area Director review before an 
Internet-Draft reaches Last Call.  It is useful to distinguish 
between the authors and the audience.  If everything approved by the 
IESG and the author were perfectly clear, there would not be a need 
to review any erratum.

>Editor.  After some discussion that I think can be summarized as

Yes, I spotted that yesterday.

>what we do in other areas, those sections will likely need to be

I recently commented about the RSOC: 
https://mailarchive.ietf.org/arch/msg/rfced-future/YnM22Y1kJ3xAYmifZlolwSwtM8s/

Regards,
S. Moonesamy

---

From: John C Klensin <[email-masked]>
Date: Thu, 14 May 2020 15:08:22 -0400

--On Thursday, May 14, 2020 09:13 -0700 Tommy Pauly
<tpauly=[email-masked]> wrote:

>> With respect to "refusing publication on editorial
>> grounds..." consider the following statement that might
>> appear by accident in an RFC and make it all the way through
>> WG and IETF last call:
>> 
>> This is obviously not an editorial problem, but it;s ... well
>> ... wrong. Obviously, the word should be "cannot".  Under the
>> strictest interpretation of "stick with editing", this would
>> not be something the RSE nor the RPC could or should address
>> - e.g. it's not editorial in nature - it's well structured
>> English on a technical topic.  There are probably other
>> examples (and some that have actually happened) - leading me
>> to be leery  of circumscribing the RSE authority to
>> "editorial problems".
> 
> I'd argue that this example is indeed an editorial problem,
> or at least one the RSE would be able to reasonably raise as
> an editorial question. The presumed cause for this error in
> the document was a typo that reviewers glossed over—someone
> meant to type "cannot" and type "can". It is perfectly
> reasonable for the editor to, during the process of editing,
> raise that point to the authors and various interested
> parties.

Yes.   
TL;DR Summary (skipping a lot of historical context): The
example actually isn't interesting.  Ain't broke, don't fix it.
There is a family of related examples that do raise interesting
questions (see last part of message).

   -------------

So, let's assume for a moment that we were starting from scratch
and didn't have fifty years of history with the RFC Series.
Almost any reasonable editorial process for the last few hundred
years would deal with a situation like this either by the editor
going to the author (or approving body) while the document is
being worked on and say "hey, this looks like it should have
been "cannot" to me, is that right" or having some sort of final
pre-publication review process in which the author gets to check
either the editor's markup, final prepublication proofs (aka
galley proofs for some technologies), or all three.  

Once upon a time, the RFC Editor process didn't have that
author-approval loop.  Documents would go to Jon and Joyce and
they would either edit as they thought necessary, assign
numbers, and publish or hand the draft back to the authors with
instructions to do more work.  With the first option, when they
were not very confident about the fixes, they went back to
authors with questions, but it was rare for authors to actually
see final text before publication.  Any experienced technical
(or, in this case, even non-technical) editor or publisher
probably could have told them that, eventually, they would make
an incorrect or otherwise unwanted change and it would lead to
aggravation.  However, for one reason or another (one of which
is that they did a superb job, much better than the community
had any right to expect), that worked for years.  Eventually an
unwanted and erroneous change was made and that led directly to
what we now call AUTH48.   

For the information of those who haven't written RFCs in the
last two decades and a refresher for those who have, at that
point, authors (and now for IETF Stream documents, WG Chairs,
document shepherds, and responsible ADs) have an opportunity to
review the near-final document to be sure the editing process
did not produce any unwanted changes, especially ones that would
change the meaning of anything technical.  At least in my
experience and understanding (if people from the RPC are
watching this discussion, I'd appreciate it if they stepped in
and shared their wider experience), authors generally take that
review obligation very seriously so, for Mike's example, if "can
exceed" were really intended, it would presumably be caught and
negotiated.  And, fwiw, I am not aware of any instances, in my
documents or those of others (going back to well before the turn
of the century) in which, if the author said "that change in not
correct technically" the result would not have been a discussion
and effort to agree on the right text, never a fight between the
RFC Editor and the author about who was correct.  

So, unless we feel like we have to overturn established ways of
doing things, not because there is a problem, but because we
can, I don't see the problem, at least with Mike's example.

We do have a new issue in the last year (closely connected to
the canonical vs. archival discussion), which is whether the
AUTH48 review should be about the HTML, the text, or the PDF.
One position is that authors (and other AUTH48 reviewers) should
examine and sign off on all three.  That is not only burdensome,
but violates the basic principle that authors normally do not
have expertise in presentation and layout issues and they
effectively putting them in charge of such things is basically a
waste of everyone's time and about as sensible as putting a good
technical editor with no background in network engineering in
charge of new routing protocols.  And, if those presentation
forms are mutable, then there is some question about what is
being reviewed.  However, if we cannot get an RSE (or, noting
Mark's comments, an RSE team) in place (and in place quickly
enough that we don't find ourselves with bed precedents that
cannot plausibly be undone) that can address and resolve those
sorts of issues, we are probably wasting our time in this effort.

Coming back to the example, while I would hope that any editor
with a secondary school education would spot and question "can
exceed the speed of light", I don't know what our expectations
should be about, e.g., "using this protocol, there will be no
problem with real-time two-way video communications between
earth and a moon base".  The issue about the speed of light is
ultimately the same, but whether "no" belongs in that sentence
(and hence whether it is an editorial issue) raises the bar,
perhaps significantly, about the amount of technical knowledge
we expect the RFC Editor team to have and apply... even though I
think it is an obvious editorial error and you and Mike probably
do too.

best,
   john

---

From: John C Klensin <[email-masked]>
Date: Thu, 14 May 2020 15:56:46 -0400

--On Thursday, May 14, 2020 09:06 +0200 Eliot Lear
<lear=[email-masked]> wrote:

> Brian,
> 
> Thanks for putting out the draft.  It has really stimulated
> conversation, a task I prefer to not have to perform ;-).  And
> thanks to all who are participating.
> 
> Does the RFC Editor have the authority to refuse to publish
> based on technical concerns? Does the RFC Editor have the
> authority to add a note based on technical concerns? Does the
> RFC Editor have the authority to add a note expressing concern?
> 
> The value of these questions is that they do indeed, as Adam
> wrote, explore the scope of authority the RFC Editor has, and
> they also bring into focus the skill set and experience that
> an RSE should/should not require.
> 
> John's point, that these questions have already been settled
> long ago, is valid, but sometimes it is nice to test whether
> the question has a different answer after time as passed (even
> though very little time has passed since RFC 8728).  I see
> that we have done that here, and most of us are drawing the
> same conclusions.

First, hard to blame anything on RFC 8728, since it, as far as I
can tell and remember from IASA2 WG discussions, changed almost
nothing other than what was needed for IASA-> IASA2/LLC
transitions.  If you attribute most of those "settled" issues to
RFC 6635, we've got a good eight years of experience.

Curiously, as far as I know, the "push things all the way to the
RSAG" (from RFC 5620) and "push things all the way to the RSOC"
(from RFC 6635) have, as far as I know, never actually been used
and tested, putting questions about how well they would work and
whether they are what we want into the same general category as
reexamining the Recall procedure. 

On the other hand as I hope was clear from my more recent notes,
the AUTH48 procedure for reviewing changes has been extensively
tested for decades and, while I (and, I assume, others) could
suggest ways to tune it, it has worked well enough that I can't
imagine it --and whether it is an adequate solution to the
issues that have been raised-- is a good use of this group's
high-priority time at this particular stage (although whether
the details of how it works are an RSE responsibility or not
might be).

> What should the RFC Editor do when she or he vehemently
> disagrees with a point of view expressed in a draft?

FWIW, I agree with those who think the appeals mechanism is (at
least) a good first answer.   Then there is the question of the
RSAG and then RSOC mechanisms proposed in the RFC Editor Model
docs are what we want.  And that goes, I think, directly to...
 
> and has not been fully explored.

Indeed.  But, again just IMO, aspects of that question may be
part of what got us here... and part of why several people have
suggested that the direct management of the RSE (and RFC Editor
Function more generally) by assorted I* groups is a bad idea.

   john

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 May 2020 14:58:43 -0500

> think it is an obvious editorial error and you and Mike probably

Right. I think the problem is that we're spending a lot of time talking 
about situations where the prospect of an actual conflict is basically 
zero (pi=3, 8-bit IP addresses, and violations of special relativity).

The lack of plausible conflict makes these examples far less than 
illustrative of any real principles.

What we need to explore is: when a plausible and potentially intractable 
conflict arises (e.g., the actual real-world Ethernet-MIB variable 
changes that Elliot cited elsewhere, or the theoretical but plausible 
TLS 1.3 example that I gave up-thread), what does the community expect 
should happen?

/a

---

From: John C Klensin <[email-masked]>
Date: Thu, 14 May 2020 16:48:00 -0400

--On Thursday, May 14, 2020 14:58 -0500 Adam Roach
<[email-masked]> wrote:

> Right. I think the problem is that we're spending a lot of
> time talking about situations where the prospect of an actual
> conflict is basically zero (pi=3, 8-bit IP addresses, and
> violations of special relativity).
> 
> The lack of plausible conflict makes these examples far less
> than illustrative of any real principles.
> 
> What we need to explore is: when a plausible and potentially
> intractable conflict arises (e.g., the actual real-world
> Ethernet-MIB variable changes that Elliot cited elsewhere, or
> the theoretical but plausible TLS 1.3 example that I gave
> up-thread), what does the community expect should happen?

Adam,

Let me refine that a bit further, coming back to your "basically
zero" likelihood conditions.   My expectation, and I assume the
community's, is that such problems would be caught during IETF
Last Call or, at worst, during IESG review and would never reach
the RFC Editor [1].  If documents containing those sorts of
errors reach the RFC Editor, that is already a process failure.
Indeed, I think that, if such documents reach the IESG without
the issues being observed during IETF Last Call, _that_ is a
process failure relative to the assumptions made when RFC 2026
was written.  Do we expect the RFC Editor to catch such things
and, if they do, is there are realistic possibility of the
authors and IESG pushing back on proposed changes or ignoring
questions?  I hope not.  And, if no one at all catches them, who
is to blame?  (I suggest maybe the IESG and assorted reviewers,
shepherds, etc., but not the RFC Editor.)

That is the sense in which Mike's example is more realistic: it
is not hard to imagine "not" being accidentally omitted (or
inserted) and the eyes of everyone in the in-stream review
process being sufficiently glazed over to not catch it.  But
that is an even more clear case in which the normal process (at
AUTH48 or earlier) might be expected to catch the problem with a
vanishingly small possibility of someone pushing back on the fix.

    john

[1] The number of real or imaginary problems caught during IESG
review that don't turn up during IETF LC and questions about how
they should be handled are probably more important, and more of
a threat to serious claims of IETF Consensus for a document,
than this discussion about RFC Editor detection of problems and
conflicts over them but, fortunately, are not part of this
Program's discussion and, in hope, not in its critical path.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 May 2020 22:53:14 +0200

On 2020-05-14, at 22:48, John C Klensin <[email-masked]> wrote:
> 
> “basically zero” likelihood

Brian's draft has a security considerations section.
Let me add one security consideration.

We make contracts to handle certain unlikely events.
And, actually more importantly, to make those events unlikely.

The assumption here seems to be that all actors act in good faith (even if, maybe, somewhat ignorant or misinformed).

But what about truly nefarious situations?
An actor turns bankrupt (or the company where they have their day job does), and the administration starts to make unreasonable demands?
What if the RSE’s husband is captured by a rogue country?

This all may seem unlikely, but the point of setting up relationships right is that these events *stay* unlikely, by limiting the bounty that can be had from acting nefariously.

Investing authority in someone/some entity (called “trust” in some security circles) also is a liability:
It makes that someone/entity a potentially rewarding and thus interesting target of an attack.

Another reason checks and balances are good.

Grüße, Carsten

---

From: Colin Perkins <[email-masked]>
Date: Thu, 14 May 2020 21:56:32 +0100

[Catching up on the discussion]

> On 12 May 2020, at 22:30, Adam Roach <[email-masked]> wrote:
> 

I agree – provided the correct process has been followed by a stream, and once any cross-stream conflict reviews, appeals, etc., have concluded, the RSE shouldn’t be able to refuse to publish a document. 

-- 
Colin Perkins
https://csperkins.org/

---

From: Colin Perkins <[email-masked]>
Date: Thu, 14 May 2020 21:59:23 +0100

Yes, certainly – but should the stream manager eventually be able to overrule the RSE and say “publish it, the editorial quality is good enough”?

Colin

> On 12 May 2020, at 23:15, Adam Roach <[email-masked]> wrote:
> 
> Right. I apologize if it was unclear that I was speaking strictly about the technical contents of a document. Personally, I'd be happy if the RSE/RPC were more liberal about sending things back as too poorly written to economically edit.
> 
> /a
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 May 2020 16:02:05 -0500

> vanishingly small possibility of someone pushing back on the fix.

Definitely. My point is that they're not *interesting*. We know exactly 
what's supposed to happen, and I don't think there's going to be much 
contention on that point.

Given the complete lack of engagement about the less cut-and-dried 
conflicts I've described, I'm inferring a discomfort in this group at 
even thinking about the cases where actual conflicts might arise. If all 
we do in this effort is answer the easy questions without even broaching 
the hard ones, I don't think we've achieved anything.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 May 2020 16:15:00 -0500

I believe it would be reasonable for the stream manager to make such a 
request when circumstances warrant (and I seem to recall a passage in an 
RFC that explicitly makes this suggestion at least for the IESG, but I 
can't find it on a quick search). Assuming that we agree that the RSE 
has editorial control over the series, I think the ultimate 
decision-making authority on editorial issues would lie with the RSE. As 
with the discussion about technical issues, I would hope that there 
would be a substantial, good-faith effort to reach a mutually agreeable 
conclusion in a collegial and consultative way; but ultimately, one 
single entity needs to own the decision.

/a

On 5/14/2020 3:59 PM, Colin Perkins wrote:
> Yes, certainly – but should the stream manager /eventually/ be able to 
> overrule the RSE and say “publish it, the editorial quality is good 
> enough”?
>
> Colin
>
>
>
>
>> On 12 May 2020, at 23:15, Adam Roach <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Right. I apologize if it was unclear that I was speaking strictly 
>> about the technical contents of a document. Personally, I'd be happy 
>> if the RSE/RPC were more liberal about sending things back as too 
>> poorly written to economically edit.
>>
>> /a
>>
>>> I was mentally composing a reply to the effect of “The RSE should 
>>> not be able to veto an IETF stream document approved through normal 
>>>> On May 12, 2020, at 4:57 PM, Joel M. Halpern <[email-masked] 
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>> Can we step this down?
>>>>
>>>> technical content on technical grounds.
>>>> about a document, I think we probably have a whole lot of other 
>>>> problems that need to be addressed.  Whether the RSE actually 
>>>> publishes that document or not is probably the least of our worries.
>>>>
>>>> stream "turn this into proper English before the RPC will process it."
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>>>>> <[email-masked] <mailto:[email-masked]> 
>>>>>>> <mailto:[email-masked]>> wrote:
>>>>> technical contents of a document.
>>>>> refusing to publish a specification he felt was technically 
>>>>> misguided [1], so this authority did exist with the position at 
>>>>> some point. Although never explicitly revoked, RFC 4844, section 
>>>>> 4.1 et seq makes it pretty clear that the RSE has approval 
>>>>> authority over precisely one stream (the Independent Submission 
>>>>> stream). To the extent that the IAB had authority to publish RFC 
>>>>> 4844, I think it makes it clear that the scope of authority had 
>>>>> been pared back substantially since the "I am not going to publish 
>>>>> a faulty specification as an RFC" days of 1991.
>>>>> I'm not entirely sure my analysis above is all that useful, 
>>>>> though, as this is the "rfced-future" discussion rather than the 
>>>>> "rfced-history" discussion, and so it seems more sensible to focus 
>>>>> on meeting the needs of the Internet community in 2020 and beyond 
>>>>> than is is to lean on the historical narrative.
>>>>> And so more to the point: I think that the IETF community writ 
>>>>> large would be floored if a working group produced a document, the 
>>>>> IETF found consensus on it during last call, the IESG approved it, 
>>>>> and then the RSE refused to publish it (or imposed technical 
>>>>> changes on its contents). Ditto for the IRTF and their documents. 
>>>>> So, if we're matching authority with community expectations -- at 
>>>>> least for a large swath of the relevant community -- I think the 
>>>>> answer above of "the RSE should refuse to publish the document" is 
>>>>> exactly wrong.
>>>>> /a
>>>>> ____
>>>>> [1]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 14 May 2020 17:50:15 -0400

The assumption when we did 6635 was that it was not possible to define 
resolution for all possible conflicts.  Which is why the RFC specifies a 
decision procedure for sorting out conflicts.

I do think that the rules as we have written them (streams own the 
technical content, the RSE owns the editorial content and editorial 
quality) is the right basis.  To a significant degree, given that as the 
existing definition, I can not understand why we are even discussing it 
from that angle.

Yours,
Joel

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 May 2020 16:56:36 -0500

On 5/14/2020 4:50 PM, Joel M. Halpern wrote:
> quality) is the right basis.  To a significant degree, given that as 
> the existing definition, I can not understand why we are even 
> discussing it from that angle. 

Yes! Exactly! As far as I understand this is the status quo, this is 
what is expected by the community, and this is how I think things should 
work in the future. My engagement on this topic has exclusively been in 
response to assertions that imply that the outcome of this effort is 
something other than "streams own the technical content, the RSE owns 
the editorial content and editorial quality." Like you, I'm a bit 
distressed that we're having the conversation in the first place.

/a

---

From: John C Klensin <[email-masked]>
Date: Thu, 14 May 2020 19:48:39 -0400

--On Thursday, May 14, 2020 16:15 -0500 Adam Roach
<[email-masked]> wrote:

> I believe it would be reasonable for the stream manager to
> make such a request when circumstances warrant (and I seem to
> recall a passage in an RFC that explicitly makes this
> suggestion at least for the IESG, but I can't find it on a
> quick search).

That is the text I'm quite certain I've seen too but haven't
been able to find either.   Good to have company :-)

> Assuming that we agree that the RSE has
> editorial control over the series, I think the ultimate
> decision-making authority on editorial issues would lie with
> the RSE.

But, in the passage I think I remember, the solution (at least
for the IETF Stream) was to give the IETF Stream Manager (e.g.,
the IESG) the final authority if they decided to exercise but
allow the RSE to attach a disclaimer to the effect that the
document was published unedited as requested.  Not a perfect
compromise and it would be really bad if it had to be used very
often (but it has been used approximately never, so that is
apparently not a huge problem although a different RSE might
push back harder and more firmly), but workable.

> As with the discussion about technical issues, I
> would hope that there would be a substantial, good-faith
> effort to reach a mutually agreeable conclusion in a collegial
> and consultative way; but ultimately, one single entity needs
> to own the decision.

That effort to reach such a conclusion is exactly what I read
RFCs 5620 and 6635/8728 as asking for (see Section 4.1.1 of the
former and 4.3 of the latter).  The question, which I think is
more or less the same as your "who owns the decision is whether
the provisions of those document for last-resort resolution in
those documents are both appropriate and workable.  IMO, if the
decision has to be made by a committee or panel (as is now
supposed to be the case), that body must include both
significant publications and technical expertise.  If it does
not, "appropriate" is questionable and "workable" is more so.
But, again, the number of times those mechanisms have been used
calls the priority of sorting them out into question (even
though I believe that sorting them out eventually is key to the
accountability questions and therefore important).

   john

---

From: "John Levine" <[email-masked]>
Date: 14 May 2020 21:51:17 -0400

In article <[email-masked]> you write:
>> an RSE has to be able to say something like this without fear of retribution, or with

It's increasingly clear that a mandatory attribute for an RSE is that
he or she doesn't really need the job.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 15 May 2020 12:10:45 +1000

> he or she doesn't really need the job.

If we structure this as a paid position, we'll either need to make sure that's not true, or compensate them accordingly. I note that we don't have this kind of conversation about (for example) the IETF Chair.

That said, if we have an RSE that refuses to do their job, there should be consequences.

---

From: S Moonesamy <[email-masked]>
Date: Thu, 14 May 2020 21:05:06 -0700

Hi Adam,
At 08:46 PM 13-05-2020, Adam Roach wrote:
>Imagine TLS 1.3 were still under development, and that its 
>publication request came under the future model we're developing. 
>For whatever reason, the newly-installed RSE has decided that the 
>various new security properties in TLS 1.3 are problematic for law 
>enforcement's surveillance activities. They've extrapolated this to 
>an increase in the chances of a terror attack to such a degree that 
>they're willing to stake their professional credibility on making 
>sure it does not get published in the form that the working group, 
>the IETF at large, and the IESG agreed to.
>
>So they respond to the IETF with "I can't publish this document at 
>this time because it lacks interception-related features. Please fix 
>it, and until you do, I can't publish it."
>
>If you think that the system we're developing here makes this the 
>final word on that technical matter -- either we insert 
>interception-related features in TLS 1.3, or it simply doesn't get 
>an RFC number -- please be sure to say so clearly and unambiguously.

I replaced RSE" with IETF Area Director for the above.  The case is 
either unrealistic or a sign of systemic failure.  Would an IETF Area 
Director point that out or appeal against the decision?  After 
considering the historic information available, I would say no.

>their post (ignoring for a moment who makes the decision to perform 
>such removal) and the RFC is published with the technical content 
>generated by the IETF, is that retribution? Or is that holding the 
>RSE accountable for failing to perform their duties?

It can be either option.

Regards,
S. Moonesamy

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 19 May 2020 15:14:32 +0200

I haven’t been very active yet, as I have the feeling that I can’t contribute any thing new at this point of the discussion that haven’t been said yet in order to get a common understanding of issues/the problem. However, I would like to +1 the point below because that also something I have been thinking when reading various mails (but goes more into finding a solution than describing the problem).

> On 14. May 2020, at 01:44, Mark Nottingham <[email-masked]> wrote:
>