Subject: [Rfced-future] Trust versus accountability [Was: Where is the expertise? (was: Re: My hard constraints]

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 16 Sep 2020 10:35:27 +0100

I think this debate is evolving into a somewhat old conversation about trust
versus accountability.

On the one hand, an advisor's advice might be summarily ignored by our
decision-makers.
On the other hand, a person with delegated authority might not deliver what
we want.

I don't see how these two situations are markedly different. In the first
case, the community replaces the decision-makers. In the second case, the
contract of the person is terminated. Both risk us wasting some time, having
to unpick decisions, and expending some angst to get back on track. Both
situations can be properly managed through oversight from the community and
through proper and respectful communication.

On which side of the choice an individual falls seems (to me) to depend on
where their paranoia is rooted: do you trust the I* to mainly follow expert
advice, or do you trust an expert with well-defined directives to deliver?

But there are other things that should influence this choice. The principal
one that should concern us is the level of commitment to the IETF that we
get from a consultant/employee/contractor in the different cases. How much
control over their destiny does someone feel they have; how easy is it for
them to throw up their hands and walk away; how strongly do they remain
motivated to continue doing their absolute best?

Those factors may also significantly influence the number and type of person
who applies.

Best,
Adrian

-----Original Message-----
From: Rfced-future <[email-masked]> On Behalf Of Martin
Thomson
Sent: 16 September 2020 01:59
To: John C Klensin <[email-masked]>; [email-masked]
Subject: Re: [Rfced-future] Where is the expertise? (was: Re: My hard
constraints)

Hi John,

I had a little trouble following the thread here, but to answer your most
direct question...

On Wed, Sep 16, 2020, at 08:25, John C Klensin wrote:
> So my confusion about your hard constraints and many of the
> other discussions on this list is that we want high quality and
> long-lived documents but, at the same time, we apparently want
> to rely on the expertise and authority of the community rather
> than finding actual experts and giving them authority.   I don't
> see how those fit nicely together.  Perhaps some of us really
> don't care about much of what I'm lumping together as quality
> and longevity.  Others clearly do.  If so, just as your note
> suggests, we should be having a clearer and more focused
> discussion of that specific issue.  Similarly, the authority can
> subject to oversight of various sorts but having the collective
> wisdom of the community override expert judgment may be no more
> sensible than believing that a committee of brain surgeons would
> be good designers of network protocols even if one of them were
> not.  We can insist that the expert(s) educate us, but only if
> we have the time and inclination to be educated -- something of
> which I've seen little evidence in this topic area or even in
> the discussions on this list.
> 
> So, which is it?

So I did put the question of vesting authority in an individual as a hard
constraint.  But only because one person is the ultimate closed board, where
making internal communications open to public engagement or scrutiny is
maximally difficult.

If there is something we need then yes, we need to know that we need it.
You and others have amply demonstrated that people are willing to agitate
for contracting specialized expertise, so I'm not concerned about that
aspect.  We then need to then source that expertise.  I have suggested this
be ad-hoc, Brian suggests something like having someone on retainer (with
some other duties that ensure they stay engaged).  I don't see that latter
distinction as being as important relative to the key distinction: expertise
is sought as advice.

Then finally we need to listen (and this seems to be your pivotal point).
You assert that future incarnations of some open group might either not seek
advice when necessary, or might ignore such advice if it does not have some
authoritative impetus.

Yes, we have numerous examples where individuals reject well-considered
input from experts.  That might be more acute when advise is outside of the
expertise of the group (in a general sense, I'm constantly impressed by the
diversity of expertise represented in this community).  It's a threat we can
acknowledge, but I don't think that the cost of the defense you propose is
anywhere near worth paying.

---

From: Adam Roach <[email-masked]>
Date: Wed, 16 Sep 2020 05:09:22 -0500

On 9/16/2020 4:35 AM, Adrian Farrel wrote:
> contract of the person is terminated.

I think there is *absolutely* a marked difference: in a structure where 
continuous leadership change is part of the expected order of things, 
the former is business as usual, while the latter is clearly a traumatic 
event for the community.

(This is assuming that the replacement happens on a normal nomcom cycle 
in the former case, and on a normal contract renewal cycle in the 
latter. If you're talking about out-of-cycle replacements: as John is 
fond of pointing out, mid-term recall process has never been successful; 
and mid-contract termination would be legally dicey except in the most 
egregious of violations.)

/a

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 16 Sep 2020 11:20:24 +0100

Hi Adam,

Most contracts I sign with customers give them the ability to cancel with 30 days' notice and no reason given. That is the nature of the beast. (I believe in the US employment contracts are not typically better than this.)

I think it is absolutely the case that people retained in consultancy or contracting roles also expect to be on a continuous re-hiring cycle, so I can't see the difference you are making. That makes me reassert that how one sees this problem depends on where you are coming from not where you want to get to.

Since you refer to the NomCom cycle, you seem to agree that replacing wrong-doers up to two years after the event is acceptable. So a two-year renewable contract would be of a similar form. But, of course, more flexibility can be achieved using a one-year renewable contract.

I* recall is roughly in the same bracket as contract termination for contract violation. It rarely happens and is subject to all sorts of checks and balances.

Best,
Adrian

---

From: Adam Roach <[email-masked]>
Date: Wed, 16 Sep 2020 14:27:42 -0500

On 9/16/2020 5:20 AM, Adrian Farrel wrote:
> I think it is absolutely the case that people retained in consultancy or contracting roles also expect to be on a continuous re-hiring cycle, so I can't see the difference you are making.

I'd like to enter into evidence that Spencer (to pick a random person) 
is no longer on the IESG, and no one felt the need to spin up an IAB 
program in response to his departure. There are very different 
presumptions in the community about the likelihood of renewal between 
the two arrangements.

If this distinction isn't obvious to you at this point, I'm not sure 
there's much more I can say on the topic to help you understand the 
point I'm making. I'm going to stop responding now under the assumption 
that other participants can.

/a

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 16 Sep 2020 16:07:14 -0400

Yes, I have a very different expectation about persistence and retention.

The RSE (or whatever we rename such a person if we keep the role) 
provides skills that this community does not have.  They provide skills 
that we are demonstrably not good at recruiting.  Based on the learning 
curve for outsiders to learn the job, it is also a job with a 
significant amount of context.  Replacing that person every 4 years 
would be a bad thing for the community (if you assume we agree that we 
should have such a person).

I have been trying to figure out what compromises in approach I can live 
with, and what points from various proposals seem to make sense to me, 
and if there is any way to put them together.    I am quite sympathetic 
to the view that the community needs a stronger voice in the long term 
strategic direction of the RFC series.  I am very concerned by the 
proposals which remove the role of a publication expert in providing 
guidance to the RPC (AMS provides direct line management.  They do not 
provide publication expertise in the sense we mean it.  Heck, although 
they provide the web publication service, that is not their primary 
expertise.)

I am wondering if there is some middle ground on this.  Keep the RSE as 
a person in charge of the tactical and hybrid (between tactical and 
strategic) direction, with an explicit role of providing advise on the 
strategic direction.  And somehow craft a community body to own the true 
strategic direction (roughly, things where if it takes 2 years to work 
out an agreement, that's okay.  But not looking at the quesiton is a bad 
idea.)

I am not sure how to set up the chairing and reporting of this body.

Yours,
Joel

On 9/16/2020 3:27 PM, Adam Roach wrote:
>> I think it is absolutely the case that people retained in consultancy 
>> or contracting roles also expect to be on a continuous re-hiring 
>> cycle, so I can't see the difference you are making.
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Sep 2020 09:19:19 +1200

> should have such a person).

Yes. The analogy with our pro bono counsel is a good one (except that
I have no expectation of finding a pro bono RFC Series Advisor). Our 
previous pro bono counsel was with the IETF for at least 18 years. He
got to know us fairly well.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Sep 2020 09:31:29 +1200

> On the one hand, an advisor's advice might be summarily ignored by our

I want to focus on that. At least in my mind, the decision maker is an open WG operating by rough consensus. Yes, that could lead to explicitly ignoring expert advice. Isn't that exactly how the IETF works? Why is it more broken in this case than it is in the IETF?

In any case it makes it clear that the WG is accountable for its own mistakes, and that's a WG that is open to the entire community. So any mistakes are made by (the interested parties in) the community itself. And people who didn't participate have only themselves to blame.

Regards
    Brian

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Sep 2020 17:41:04 -0400

--On Wednesday, September 16, 2020 14:27 -0500 Adam Roach
<[email-masked]> wrote:

>> I think it is absolutely the case that people retained in
>> consultancy or contracting roles also expect to be on a
>> continuous re-hiring cycle, so I can't see the difference you
>> are making.
> 
> 
> I'd like to enter into evidence that Spencer (to pick a random
> person) is no longer on the IESG, and no one felt the need to
> spin up an IAB program in response to his departure. There are
> very different presumptions in the community about the
> likelihood of renewal between the two arrangements.

Yes, but one of the problems with that analogy is that Spencer,
IIR, stepped down voluntarily (at least as far as the IETF is
concerned).   Better analogies would be someone who was willing
to serve again but was not given another term by the Nomcom.
Even then, we don't spin up IAB programs (and the community
would almost certainly consider it the height of arrogance for
the IAB to even consider doing so).  I suggest that a
significant fraction of the community believes that turnover on
the IESG is actually helpful and that people serving more than,
say, six or eight years would be a problem (I haven't looked at
the statistics lately, but suspect the mode is still four
years).    

Now, by contrast, if we are trying to obtain and retain a
professional-type expert (see Joel's (I think) comment about
finding lawyers only when one needs advice and then finding
another one the next time), there had better be an expectation
of both long tenure (even if on nominally short-term contract
with routine renewals) and that the community will mostly
respect that person's expertise rather than, e.g., regularly
second-guessing them because we assume we (or the IESG, or the
IAB, or the LLC, or even some committee drawn from our community
are smarter and/or more knowledgeable than said expert.  Should
"we" end up behaving that way --regardless of the organizational
structure-- whether the individual leaves in frustration or the
contract is terminated (whether at renewal time or before that)
is just a matter of time (and probably not long).  And, since
every professional community has its own informal "grapevine"
communications, it will likely get harder to find and
successfully recruit the next such person we would go looking
for as a replacement.

> If this distinction isn't obvious to you at this point, I'm
> not sure there's much more I can say on the topic to help you
> understand the point I'm making. I'm going to stop responding
> now under the assumption that other participants can.

I don't know whether the above helps or not, because I'm not
sure we are asking the same question.

Response to Martin's note soon.

 best,
    john

---

From: "John Levine" <[email-masked]>
Date: 16 Sep 2020 17:44:11 -0400

>got to know us fairly well.

FYI, our lawyers are not pro bono, they're on retainer as was our
prior lawyer. I agree with you that it is a good thing in these
specialized jobs to have people stay long enough to learn what we do
and how we work.

FWIW, I've been around for quite a while but in my new role as tRSE
I'm still learning all sorts of stuff about the process, the history,
and the stuff we have yet to do.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Sep 2020 17:48:53 -0400

--On Thursday, September 17, 2020 09:19 +1200 Brian E Carpenter
<[email-masked]> wrote:

> Yes. The analogy with our pro bono counsel is a good one
> (except that I have no expectation of finding a pro bono RFC
> Series Advisor). 

And my expectation is that, if we found such a person to do the
work for free and he or she were not named, e.g., "Postel", the
community would behave as is free advise is worth what one pays
for it that the expert/advisor would soon get frustrated and
resign.

    john

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 16 Sep 2020 21:51:45 +0000

>   I want to focus on that. At least in my mind, the decision maker is an open WG operating by rough consensus. Yes, that could lead to explicitly ignoring expert advice. Isn't that exactly how the…

I believe that, unlike Internet protocol design, many people here recognize that we are not experts in the field, and there is concern about well-meaning amateurs getting it horribly wrong

---

From: John C Klensin <[email-masked]>
Date: Wed, 16 Sep 2020 18:08:08 -0400

--On Thursday, September 17, 2020 09:31 +1200 Brian E Carpenter
<[email-masked]> wrote:

>> I think this debate is evolving into a somewhat old
>> conversation about trust versus accountability.
>> 
>> On the one hand, an advisor's advice might be summarily
>> ignored by our decision-makers.
> 
> I want to focus on that. At least in my mind, the decision
> maker is an open WG operating by rough consensus. Yes, that
> could lead to explicitly ignoring expert advice. Isn't that
> exactly how the IETF works? Why is it more broken in this case
> than it is in the IETF?

Because, in the case of the IETF, there is a strong assumption,
almost always justified, that a significant fraction of the
people in the WG are expert in the subject matter the WG is
considering.  I am not yet convinced that, if we put together
something WG-like, we will be able to populate it sufficiently
that we can have a reasonable expectation of expertise in that
group or, to put it differently, that any consensus reached
(rough or otherwise), will actually be informed consensus.

> In any case it makes it clear that the WG is accountable for
> its own mistakes, and that's a WG that is open to the entire
> community. So any mistakes are made by (the interested parties
> in) the community itself. And people who didn't participate
> have only themselves to blame.

Sure, but the damage is to the series and its users and that is
much more important than blame.  And, were the word to get
around the professional technical publications community that
whomever takes the position (no matter how we characterize it)
will be reporting to, and subject to the whims of, a collection
of ignorant fools, then the intersection between the set of
people one would want to recruit and the set willing to take the
position will rapidly trend toward zero.

best,
     john

---

From: "Scott O. Bradner" <[email-masked]>
Date: Wed, 16 Sep 2020 18:36:40 -0400

fwiw - our “prior lawyer” was pro bono (other than expenses) for more than a decade before he left the law firm that 
was supporting his pro bono work and the IETF started to pay him

Scott

> On Sep 16, 2020, at 5:44 PM, John Levine <[email-masked]> wrote:
> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Sep 2020 11:22:11 +1200

> was supporting his pro bono work and the IETF started to pay him

Yes, I knew that he switched to a retainer at some point, but that
actually corresponds better to what we are discussing here. Either way,
we had one expert advisor for the best part of two decades.

   Brian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Sep 2020 15:30:16 +1000

Hi Joel,

> On 17 Sep 2020, at 6:07 am, Joel M. Halpern <[email-masked]> wrote:
> 
> I am very concerned by the proposals which remove the role of a publication expert in providing guidance to the RPC (AMS provides direct line management.  They do not provide publication expertise in the sense we mean it.  Heck, although they provide the web publication service, that is not their primary expertise.)

This statement made me wonder why we assume it's necessary to separate the function of the RSE and the RPC -- in other words, why can't AMS provide publication expertise, as an expansion of their contract? After all, they go through a process to hire people with specialised skills (editors) to meet the terms of the contract; what makes providing advice about publication different?

That may or may not be a good thing for us to actually do, but if we could articulate the reason(s) for that separation (or determine that isn't not necessary), it might shed more light on our options.

Cheers,

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

---

From: Jay Daley <[email-masked]>
Date: Thu, 17 Sep 2020 17:35:29 +1200

> On 17/09/2020, at 5:30 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Joel,
> 

I can ask.

Jay

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 17 Sep 2020 09:38:25 +0200

Hi Mark,

> On 17 Sep 2020, at 07:30, Mark Nottingham <[email-masked]> wrote:
> 

I would take some care when considering things in this light to distinguish what one views as strategic to the organization versus operational.  Joel’s point as I understand it is that one should be wary of short term contracts for strategic aspects, lest all of that context walks out the door.

However, you also are highlighting that the IETF’s split of responsibilities is unique.  That is, most organizations house both strategic/planning and operational functions vertically and integrally.  None of the current proposals recombine these aspects, although Martin’s sort-of angles in that direction.  

Where organizations vary is whether the strategic function is represented at executive levels.  That is the case with the IEEE and SMTPE, for instance, but not so with ISO, ETSI or the ITU.  And you know more than I do about how this works at the W3C or WHATWG.  

Eliot

---

From: John C Klensin <[email-masked]>
Date: Thu, 17 Sep 2020 07:10:07 -0400

TL;DR summary: if we are going to make comparisons to other
organizations that might influence our decisions, those
comparisons should be accurate and sometimes are not.

--On Thursday, September 17, 2020 09:38 +0200 Eliot Lear
<lear=[email-masked]> wrote:

>> This statement made me wonder why we assume it's necessary to
>> separate the function of the RSE and the RPC -- in other
>> words, why can't AMS provide publication expertise, as an
>> expansion of their contract? After all, they go through a
>> process to hire people with specialised skills (editors) to
>> meet the terms of the contract; what makes providing advice
>> about publication different?
> 
> I would take some care when considering things in this light
> to distinguish what one views as strategic to the organization
> versus operational.  Joel's point as I understand it is that
> one should be wary of short term contracts for strategic
> aspects, lest all of that context walks out the door.

FWIW, while we start from different places, my concern about
respecting expertise and understanding that having rough
consensus in some IETF body may not constitute informed
consensus lead to nearly the same conclusions. 

> However, you also are highlighting that the IETF's split of
> responsibilities is unique.  That is, most organizations house
> both strategic/planning and operational functions vertically
> and integrally.  None of the current proposals recombine these
> aspects, although Martin's sort-of angles in that direction.

> Where organizations vary is whether the strategic function is
> represented at executive levels.  That is the case with the
> IEEE and SMTPE, for instance, but not so with ISO, ETSI or the
> ITU. 

I don't know much about ETSI, but the situation with ISO
(outside the special circumstances of ISO/IEC JTC1 which, btw,
are becoming less special) and ITU are different enough that the
dichotomy you suggest is not quite right.   Those two differ
but, to oversimplify, the "volunteer" groups that determine
policy are official representatives of National Member Bodies
and governments respectively, not the technical experts (and,
btw, there are qualifications and vetting for those experts
unlike the IETF's "all welcome as long as you don't behave
really badly" policies). In addition, they both operate on
"strong secretariat" and "edit first, vote later" models.  Again
oversimplifying, the secretariats have subject matter and
publications expertise [1] and can, in practice, kill a proposal
for standardization or a document.   And, as discussed earlier
on  this list, having only final-form documents go through the
final public review and approval processes changes this
discussion enough that comparisons are difficult.

> And you know more than I do about how this works at the
> W3C or WHATWG. 

I will mostly defer to Mark on that, but again note that W3C has
a professional staff with considerable technical subject matter
expertise and ability to overrule the volunteers on
standardization matters _and_ that they tend more toward living
and incremental documents with snapshot than the more fixed (and
hence potential of being archival) approach used by the IETF [2].

thanks, 
   john

[1] Ours have more than we often recognize, but "we" discourage
them from even expressing those views in substantive
discussions, much less making decisions that can override
participant community consensus.

[2] I think which is better and what we should be doing is
another of the issues about which there are very fundamental
differences of opinion on this list and probably in the IETf
community, differences that, along with the questions of
expertise and ones of whether it is actually important to get
publications right from an editorial and technical clarity
standpoint, probably go on any list of areas in which there are
fundamental enough differences of opinion to make reaching
consensus difficult.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Sep 2020 09:30:35 -0400

> This statement made me wonder why we assume it's necessary to separate the function of the RSE and the RPC -- in other words, why can't AMS provide publication expertise, as an expansion of their c…

Another thing to say about this, which perhaps has been considered already, is that the existing RPC staff, whether AMS should hire the RSE or not, are definitely qualified to help think about the problem of hiring a good RSE, and should be able to spend time on the steering committee. That is, if finding a qualified set of people to help oversee or search for RSEs is challenging for the IETF, here is a pool which contains perhaps not the exact experience set we need, but definitely a more related experience set than would be typical of an IETF standards geek.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 17 Sep 2020 10:58:13 -0400

We could have tasked AMS with hiring the person.
While way outside their wheelhouse, I presume they would do so if asked.

But this person is making day-to-day judgment calls tied closely to 
community agreements.  More so even than Jay as far as I can tell.  Even 
if we remove the long term strategic component from the job, I would 
think we would want them closely tied to the community.  Adding an extra 
level of indirection (Community->Jay->AMS->RPC Lead) seems like making 
things more complicated.  For little or no benefit.

Yours,
Joel

---

From: Michael StJohns <[email-masked]>
Date: Thu, 17 Sep 2020 12:33:15 -0400

+1.  There's also the problem of having all of our eggs in one basket.  
If for example AMS decided to get out of the IETF business, or the IETF 
behaved badly enough that AMS felt the relationship was no longer 
viable, we'd lose ALL of our publication expertise and especially the 
hard earned IETF specific parts of that.  I would suggest that a small 
bit of redundancy in this space is warranted.

Mike

On 9/17/2020 10:58 AM, Joel M. Halpern wrote:
> community agreements.  More so even than Jay as far as I can tell.  
> Even if we remove the long term strategic component from the job, I 
> would think we would want them closely tied to the community.  Adding 
> an extra level of indirection (Community->Jay->AMS->RPC Lead) seems 
> like making things more complicated.  For little or no benefit.
>
> Yours,
> Joel
>
>>> I am very concerned by the proposals which remove the role of a 
>>> publication expert in providing guidance to the RPC (AMS provides 
>>> direct line management.  They do not provide publication expertise 
>>> in the sense we mean it.  Heck, although they provide the web 
>>> publication service, that is not their primary expertise.)
>>
>> separate the function of the RSE and the RPC -- in other words, why 
>> can't AMS provide publication expertise, as an expansion of their 
>> contract? After all, they go through a process to hire people with 
>> specialised skills (editors) to meet the terms of the contract; what 
>> makes providing advice about publication different?
>>
>> That may or may not be a good thing for us to actually do, but if we 
>> could articulate the reason(s) for that separation (or determine that 
>> isn't not necessary), it might shed more light on our options.
>>
>> Cheers,
>>
>> --

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 18 Sep 2020 09:46:10 +1000

On Thu, Sep 17, 2020, at 17:38, Eliot Lear wrote:
> However, you also are highlighting that the IETF’s split of 
> responsibilities is unique.  That is, most organizations house both 
> strategic/planning and operational functions vertically and integrally. 
>  None of the current proposals recombine these aspects, although 
> Martin’s sort-of angles in that direction.  

I want to understand your point better here, because I don't think that I was suggesting the sort of integration you suggested.  What aspects do you believe that I am proposing be recombined?

I did envisage that the short-term, tactical decisions would be made by the editing/publishing house.  But only to the extent that they are necessary to ensure operational continuity.  That is, if you need a decision to finalize a document, then it is tactical and a decision can be made.  (I've seen this many times in AUTH48 recently and for the most part, sensible proposals are made by RPC staff and those are what gets enacted, other times I or another editor have made suggestions, a few cases have involved John.)  But strategic direction needs to be set outside of that process[*].

[*] My expectation is that we will need processes to ensure that a pattern of tactical decisions don't turn into decisions about strategic direction.  That process is not something I've developed more, because it's a relatively unimportant detail, but I have some ideas.

---

From: John C Klensin <[email-masked]>
Date: Thu, 17 Sep 2020 22:08:45 -0400

+1 to both this and Joel's comment.   

It again seems to me that this is another symptom of one of
those fundamental differences in perspective, preferences, and
assumptions.  I don't know if I can state this in a way that is
fair to both sides but it seems to me that, at the extremes:

One set of assumptions is that most of our documents are close
to ok when they get through the IESG (or equivalent for other
streams); that only light copy editing is needed (if that); that
if authors are not comfortable in American English, implications
of that should be sorted out long before their document leaves
the Stream and enters production;  that some stylistic
inconsistencies are ok (especially if it saves time) and that we
really should not be insisting on stylistic and layout issues
that go much beyond those required for consistency with RFC 7841
and assorted IPR documents; and that, if some issues in the
language used in a specification are later identified as
ambiguous or otherwise problematic, it will be fine to issue
errata, assume everyone will find them, and treat them as
authoritative changes.    One consequence of those assumptions
is that we don't need anything equivalent to an RSE at all
except maybe as a source of occasional advice (and probably not
that) and that the RPC can do anything that is needed and that
the RPC staff may actually be overqualified and intervening in
documents too much.

At the other extreme, the assumptions are that we want a highly
professional series (a series, not just a collection of
documents we found a way to number), a consistent and
professional style, an editorial team that is expected to have
enough subject matter to work with the terminology and issues of
technical clarity (not just pure copy-editing), and documents
that are archival not only in the physical preservation sense
but also of providing a record of the evolution of thinking
about the technical properties and protocols of the Internet.

IT seems to me that, unless we can figure out how to discuss the
differences among those points of view (and points in between)
and decide, meetings that end in "not ready yet" may be
inevitable because the issues we are discussing may be largely
just symptoms.

    john

--On Thursday, September 17, 2020 12:33 -0400 Michael StJohns
<[email-masked]> wrote:

> +1.  There's also the problem of having all of our eggs in
> one basket.  If for example AMS decided to get out of the
> IETF business, or the IETF behaved badly enough that AMS felt
> the relationship was no longer viable, we'd lose ALL of our
> publication expertise and especially the hard earned IETF
> specific parts of that.  I would suggest that a small bit of
> redundancy in this space is warranted.
> 
> Mike
> 
>> But this person is making day-to-day judgment calls tied
>> closely to  community agreements.  More so even than Jay as
>> far as I can tell.   Even if we remove the long term
>> strategic component from the job, I  would think we would
>> want them closely tied to the community.  Adding  an extra
>> level of indirection (Community->Jay->AMS->RPC Lead) seems 
>>>> I am very concerned by the proposals which remove the role
>>>> of a  publication expert in providing guidance to the RPC
>>>> (AMS provides  direct line management.  They do not
>>>> provide publication expertise  in the sense we mean it. 
>>>> Heck, although they provide the web  publication service,
>>>> that is not their primary expertise.)
>>> 
>>> This statement made me wonder why we assume it's necessary
>>> to  separate the function of the RSE and the RPC -- in other
>>> That may or may not be a good thing for us to actually do,
>>> but if we  could articulate the reason(s) for that
>>> separation (or determine that  isn't not necessary), it
>>> might shed more light on our options.
>>> 
>>> Cheers,
>>> 
>>> --

---

From: Adam Roach <[email-masked]>
Date: Thu, 17 Sep 2020 22:52:11 -0500

On 9/17/2020 9:08 PM, John C Klensin wrote:
> authoritative changes.

I think this misrepresents the position of the folks who want a 
consultative RSE instead of an executive RSE. Nearly all of the 
functions you describe above are, and have for a long time been, in the 
remit of the RPC, not the RSE. I'm not even sure whether it would be 
within the charter of this effort to change them.

For example, I think that publication strategy would be better off with 
a community-led process and a consultative RSE; while, at the same time, 
I disagree with almost everything about your foregoing characterization. 
What I would support (although I'd be probably be happy with 
alternatives) is a model that devolves the non-strategic aspects of the 
historic RSE role to an employee of the RPC (either selected from their 
current staff or hired, as they see fit), with the expectation that the 
RPC would continue to leverage their domain knowledge to ensure 
consistent, clearly-written, professional documents.

/a

---

From: Eliot Lear <[email-masked]>
Date: Fri, 18 Sep 2020 11:46:24 +0200

Hi Martin,

> On 18 Sep 2020, at 01:46, Martin Thomson <[email-masked]> wrote:
> 

The angling I was thinking of was as you described below.  I believe you intended either through your comments or the proposal itself to expand the authority of the RPC, but by what degree I could not surmise.  mm? km?  Somewhere in between?

> [*] My expectation is that we will need processes to ensure that a pattern of tactical decisions don't turn into decisions about strategic direction.  That process is not something I've developed m…

I would encourage that discussion now, so that everyone understands what you and the others are proposing, and agrees on what is and is not strategic.  That might be something upon which we can find more common ground across the proposals.  I would hope that John Levine and perhaps others like Nevil could help a little by discussing what is being done by the RSE and what has been done in the past, and whether you would see those tasks as strategic or tactical.

Eliot

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Sep 2020 08:33:58 -0400

--On Thursday, September 17, 2020 22:52 -0500 Adam Roach
<[email-masked]> wrote:

>> streams); that only light copy editing is needed (if that);
>> that if authors are not comfortable in American English,
>> implications of that should be sorted out long before their
>> document leaves the Stream and enters production;  that some
>> stylistic inconsistencies are ok (especially if it saves
>> time) and that we really should not be insisting on stylistic
>> and layout issues that go much beyond those required for
>> consistency with RFC 7841 and assorted IPR documents; and
>> that, if some issues in the language used in a specification
>> are later identified as ambiguous or otherwise problematic,
>> it will be fine to issue errata, assume everyone will find
>> them, and treat them as authoritative changes.
> 
> 
> I think this misrepresents the position of the folks who want
> a consultative RSE instead of an executive RSE. Nearly all of
> the functions you describe above are, and have for a long time
> been, in the remit of the RPC, not the RSE. I'm not even sure
> whether it would be within the charter of this effort to
> change them.
> 
> For example, I think that publication strategy would be better
> off with a community-led process and a consultative RSE;
> while, at the same time, I disagree with almost everything
> about your foregoing characterization. What I would support
> (although I'd be probably be happy with alternatives) is a
> model that devolves the non-strategic aspects of the historic
> RSE role to an employee of the RPC (either selected from their
> current staff or hired, as they see fit), with the expectation
> that the RPC would continue to leverage their domain knowledge
> to ensure consistent, clearly-written, professional documents.

Adam,

As I said, those were deliberately stated as extremes.   At the
same time, I continue to be concerned about two things that were
a large fraction of what caused me to write that note: (1)
community-driven process is a fine idea except that we have
problems defining, and then capturing the wishes of, the
relevant community for the RFC Series (or Collection).   If it
really means "IETF WG", "IAB Program", or even, "The IETF LLC
ExecDir" then that isn't the community for the RFC Series and,
more important, assumes types of knowledge that are not among
the criteria for which those people are selected or self-select.
(2) From my point of view, this whole problem [1] started
because of a transition of the RSE from "respected senior
colleague" to "just another contractor".  While I have the
highest confidence in AMS, making that role an employee of a
contractor could make that problem even worse, discouraging the
individual from speaking out on important issues. Part of the
concern is that I don't think there is nearly as clear a line
between "strategic" and "operational" as many people have
assumed [2].

best,
   john

[1] Or maybe it isn't a problem, just an opportunity to fix a
system that, despite three major adjustments, had been working
well for about 48 years: (i) replacing a staff that was highly
skilled in the substantive technical content of Internet
protocols with an editorial staff whose skill level is such that
referring to them a "copy editors" is demeaning (and might even
be considered oppressive or exclusionary language), (ii)
switching to an explicit "streams" model and making the ISE a
separate role, and (iii) separating the RSE role from direct
production management and leadership.

[2] part of the problem is that we have a long history of "you
let them do that, therefore, not only do I get to do so too, but
it is now policy" in this area.

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Sep 2020 10:57:07 -0500

On 9/18/2020 7:33 AM, John C Klensin wrote:
> relevant community for the RFC Series (or Collection).

I understand and admire the problem of not being able to clearly 
delineate the relevant community of interest. However, if the concern is 
that we might define a process that excludes their participation because 
they don't know about it, then moving instead to a model where they 
can't participate even if they do must be a step in the wrong direction.

/a

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 18 Sep 2020 18:12:36 +0200

On 2020-09-18, at 17:57, Adam Roach <[email-masked]> wrote:
> can't participate

Is that a property of one of the two drafts we are discussing?
If yes, we should fix that.

Grüße, Carsten

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Sep 2020 11:17:30 -0500

> If yes, we should fix that.

You've left off the context here ("participating in what?"). John and I 
are discussing:

  * Participating in a community-driven process, or
  * Not participating in a community-driven process

Any model that opts for an executive RSE instead of a community-driven 
process necessarily excludes participation in a community-driven process.

/a

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 18 Sep 2020 12:26:42 -0400

I hope that is not as strict a dichotomy as you describe.  While the 
approach I described may not work, it seems like there ought to be some 
approach that allows for an effective leader of the series and effective 
and respected community input.

Yours,
Joel

On 9/18/2020 12:17 PM, Adam Roach wrote:
>> On 2020-09-18, at 17:57, Adam Roach<[email-masked]>  wrote:
>>> can't participate

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Sep 2020 11:35:16 -0500

On 9/18/2020 11:26 AM, Joel M. Halpern wrote:
> approach I described may not work, it seems like there ought to be 
> some approach that allows for an effective leader of the series and 
> effective and respected community input.
>

Again,  you're losing the context here. I was specifically responding to 

> relevant community for the RFC Series (or Collection). 

...which implicitly dismisses the notion of a community-driven process 
under the premise that some people might be excluded. My point -- and 
I'm trying to make a very narrowly-focused point here -- is that this 
specific line of argumentation is flawed inasmuch as you can't fix 
unintentional disenfranchisement by replacing it with intentional 
disenfranchisement.

That's it. That's the point. That's the whole point.

/a

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 18 Sep 2020 18:47:01 +0200

OK, maybe I need a definition of a community-driven process first.

Also, why is that desirable?

Grüße, Carsten

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Sep 2020 12:08:55 -0500

> OK, maybe I need a definition of a community-driven process first.

While there are a lot of details left to be discussed, the general 
skeleton of this idea is described in 
https://tools.ietf.org/html/draft-thomson-rfced-model-00#section-5

> Also, why is that desirable?

We reject kings, presidents, and voting?

/a

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 18 Sep 2020 21:06:42 +0200

On 2020-09-18, at 19:08, Adam Roach <[email-masked]> wrote:
> While there are a lot of details left to be discussed, the general skeleton of this idea is described in https://tools.ietf.org/html/draft-thomson-rfced-model-00#section-5

OK, I was looking for some discriminators that allow me to tell when a process is community-driven and when not.
In particular in contrast to the adjective “participatory”, which would be the more natural adjective for me to look for.

> We reject kings, presidents, and voting?

I just had dinner, and that included two slices of German rye bread.
No kings, presidents, or voting were involved in creating these slices.
As far as I can tell, the creation process wasn’t community-driven either.
But they were quite delicious.
(And I can’t really say that about some more "community-driven" food creation processes I experienced in the 1970s.)

Grüße, Carsten

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Sep 2020 17:19:40 -0400

--On Friday, September 18, 2020 10:57 -0500 Adam Roach
<[email-masked]> wrote:

> I understand and admire the problem of not being able to
> clearly delineate the relevant community of interest. However,
> if the concern is that we might define a process that excludes
> their participation because they don't know about it, then
> moving instead to a model where they can't participate even if
> they do must be a step in the wrong direction.

Having read your subsequent exchanges with Joel and Carsten, I
think I finally understand where we disagree.  Like the IETF in
many cases, interested and affected outside parties are rarely
heard from until something goes wrong and then they turn out to
be good at complaining.  I know that Jon (who was, for most of
his tenure, not accountable to the IETF all all) got many such
complaints and examples of feedback and that, in several cases,
the series changed as a result.  I know of at least one during
Bob Braden's tenure and have no reason to believe there weren't
others.  I don't know about Heather's term other than the case
that turned up in which someone outside the community discovered
that had two RFCs with the same number.   My point is that
having an independent, visible, RSE (or equivalent) actually
facilitates such communication in ways that an advisor who is on
the staff of (or consultant to) a contractor may not.  That
distinction is especially important given the IETF's long
tradition of telling people who show up with complaints or
alternate ideas to go write drafts and participate in WGs
because that is the only effective way to have their problems
attended to.  We certainly don't do that always, but we do it
often enough to be a troubling example for cases like this.

Later, in response to Carsten, you wrote...

> We reject kings, presidents, and voting?

When Dave Clark make that comment, he was very clearly referring
to our decisions about technical protocol work about the
Internet.  For this situation, it is a false analogy both
because of the expertise issues discussed in this  thread and
because we rather often handle work for the IETF that is not
directly network protocol or operational work in a way that
might be construed as kings or presidents.  IASA, and then to
some degree IASA2, arose precisely out of realizations that the
IETF community was not good at that sort of administrative work
and that, if (and when) we tried to do it by community
consensus, the people who were actively involved (by
self-selection) were not representative of the broader
community, not necessarily experts in the work area, etc.  In
the particular (and intentionally narrow) scope of his work, Jay
is rather close to a President or at least a Prime Minister --
the LLC Board is an oversight body, not a management body and,
while we would prefer it, not necessarily all experts in the
substance of the management, administration, and finance parts
of the work. 

Does the community get input? Certainly and none of the
proposals I've seen so far prevent that even if "employee of a
contractor" might actually be the worst option.  Does the
community make the decisions by informed consensus?  Continuing
the analogy it is noteworthy that he asks for consultation
and/or feedback but then he, and the bodies he is working with
make decisions that no one really pretends are made by community
consensus.  And it would be unwise to rely on community
consensus for the RFC Editor Function because the IETF community
doesn't have the expertise, because a self-selected WG is
unlikely to accurately represent the preferences of the IETF
community, and because the community for the RFC Series is
larger than the IETF.

  best,
   john

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Sep 2020 16:43:14 -0500

On 9/18/2020 4:19 PM, John C Klensin wrote:
> And it would be unwise to rely on community

The "lack of expertise" you cite is precisely why this wouldn't work 
without a expert consultant.

In terms of the other issues -- the IETF has always operated such that 
those who bother to show up to do the work are the ones who get a voice, 
and we seem to think that's okay. You have indicated a belief in a 
bright line between technical and non-technical matters in this regard; 
but note, e.g., that IASA2 was run as a working group with this exact 
set of caveats. (If I missed your congruent objections in the formation 
of that effort, I apologize for the oversight.)

/a

---

From: John C Klensin <[email-masked]>
Date: Sun, 20 Sep 2020 10:47:34 -0400

--On Friday, 18 September, 2020 16:43 -0500 Adam Roach
<[email-masked]> wrote:

>> consensus for the RFC Editor Function because the IETF
>> community doesn't have the expertise, because a self-selected
>> WG is unlikely to accurately represent the preferences of the
>> IETF community, and because the community for the RFC Series
>> is larger than the IETF.
> 
> 
> The "lack of expertise" you cite is precisely why this
> wouldn't work without a expert consultant.

Or at least an expert something or other.  But an expert would
be useful only if a WG decided to pay attention to someone who
would almost certain be perceived as an outsider (at least
initially).  Not only does the IETF have a poor track record in
that area [1], but I interpret several comments on this list,
including some of yours and Martin's, as preferring the wisdom
of the [IETF] crowd to expert input even when said crowd lacks
relevant expertise.  I don't think that is what you actually
intend (but maybe I'm wrong -- that is much of what I was trying
to clarify with Martin) but it certainly feels that way from
here [2].

> In terms of the other issues -- the IETF has always operated
> such that those who bother to show up to do the work are the
> ones who get a voice, and we seem to think that's okay.

Some of us have often been nervous about it.  The community
seems to be nervous about it when "show up" really means "hang
in after all those who disagree with the relevant leadership or
strong personalities have been driven off" [3].  So "ok" needs
to be somewhat qualified.

> You
> have indicated a belief in a bright line between technical and
> non-technical matters in this regard;

First, while others have claimed that there was a bright line, I
don't think I have.   Indeed, I think some of the
publications-related issues I'm concerned about actually are
technical.  The distinction I'm trying to draw is between topics
that are clearly within the IETF's _Internet_ technical scope
and, perhaps as a definition of that, about which there is
fairly wide knowledge and understanding among IETF participants
including sufficient knowledge to understand when someone,
despite strong opinions, doesn't know what they are talking
about and topics that do not meet those criteria.

> but note, e.g., that
> IASA2 was run as a working group with this exact set of
> caveats. (If I missed your congruent objections in the
> formation of that effort, I apologize for the oversight.)

If you look back far enough, you will notice that I objected,
fairly loudly, to several of the provisions of the IETF
Administration LLC arrangements.  I was told that I couldn't
object to most of those, including what should have been small
but important terminology ones, because they were already fixed
by a legal document that could not be altered by IETF decisions.
When I raised objections to the way that document's approval had
been managed and the lack of an IETF consensus call before it
was set in stone, I was told it was too late (and some other
things).  At that point, it seemed to me there were two choices.
(i) Generate an appeal which would certainly be rejected on the
grounds that it was a done deal and/or that it fell within the
purview of LLC contracts and hence could not be appealed and
then, if I felt really obnoxious and destructive, hire an
attorney and try to figure out a way to challenge the LLC
registration.   Or (b) I could try to be constructive and
participate in the WG to see if things could be defined as well
as possible, even editing documents when that became
appropriate.  I'd hope IETF participants who find their
preferred positions blocked or in the rough in a fair consensus
call would behave in a similar fashion.  If you disagree and
think that my being consistent would require the first choice, I
guess we just need to disagree.

    john

[1[ We've even managed to perceive people who laid the
foundations for the Internet as outsiders and declined to
carefully consider their suggestions.

[2] And that may lead back to another one or two of those
fundamental disagreements about the importance of stability and
comprehensiveness (or obvious relationships) in specifications.
But, unless you have changed you mind, I know we disagree about
that.

[3] General issues of ethics and humane behavior aside, the
community's deciding that driving people away because of
reasonably argued dissenting opinions or demographics is, at
least IMO, the reason why our development of anti-harrassment
and related policies is important.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 20 Sep 2020 17:16:36 +0000

I'm not going to quote John's long note, but I read it all (something I don't normally do; I blame MTV) and I think the concerns he raises are valid.

I tried to state this more pithily when I said that some are concerned that well-meaning amateurs will make really bad decisions.

Typography and the production of printed material has expertise determined over the course of centuries, and we shouldn't play at it, any more than we should play at writing laws.

---

From: Adam Roach <[email-masked]>
Date: Sun, 20 Sep 2020 14:28:14 -0500

I think we understand each other fairly well, and continuing to hash 
through our philosophical differences here isn't likely to move the 
other one in any meaningful way. I hope our dialog has helped others 
work though their own thoughts on the subject, and I look forward to 
hearing input from voices other than the two of us and the four draft 
authors on this specific topic, as I suspect that our various positions 
are well-expressed at this point.

One minor comment below, since your comment indicates to me that one of 
us did misunderstand the other about the distinction between community 
participation in technical and non-technical matters.

On 9/20/2020 9:47 AM, John C Klensin wrote:
> don't think I have.

To be clear, I was referring to a message just barely upthread where you 
say:

> Internet.

/a

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 21 Sep 2020 08:54:23 +1000

On Fri, Sep 18, 2020, at 19:46, Eliot Lear wrote:
> I would encourage that discussion now, so that everyone understands 
> what you and the others are proposing, and agrees on what is and is not 
> strategic.

To give a concrete example, in a recent AUTH48, the editor and I were faced with a decision between two reference forms:

>    ... (see the "Origins" section
>    (https://html.spec.whatwg.org/#origin) of [HTML5])
>
>    [HTML5]    WHATWG, "HTML", Living Standard, May 2020,
>               <https://html.spec.whatwg.org/>.

... and

>    ... (see the "Origins" section of [HTML5]).
>
>    [HTML5]    WHATWG, "HTML", Section 5.3, Living Standard, May 2020,
>               <https://html.spec.whatwg.org/#origin>.

This is obviously important, but minor.  We asked John for help in deciding in line with his role.

There are specifics of the case that we could go into, but I think there are abstract aspects of this that are relevant to what this group is debating.  Any answer is better than no answer, at least in the short term.  There are lots of cases like this in documents and it is easy to let little decisions get in the way.

What I would suggest is that these issues are logged in a public tracker.  Then a decision is made by the RPC so that the current document can proceed.  That decision can be logged also.

Then we have the usual issue management stuff: issues or patterns of issues that indicate a need for new systems or policies require action.  My guess is that most of this stuff will be logged and closed with a note.  In that way the log becomes a resource to help with other similar issues.  Some will result in tweaks to tools or procedures that are internal to the RPC. Some might result in changes to the style guide.  Most of that can be managed internally.  Of interest here though, some issues might indicate a need for strategic input.

The information in this log could be one input to a strategy process.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 21 Sep 2020 00:00:25 +0100

Hiya,

On 20/09/2020 23:54, Martin Thomson wrote:
> Any answer is better than no answer, at least in the short term.

I'm not sure I agree. References go stale, so ISTM only
answers likely to be stable for the duration for which
the to-be-RFC is expected to be useful could rise to the
level of "better." There's an awful lot of judgement
needed there I think and an issue-tracker approach could
well lead to way to much emphasis on the short-term is
my guess.

S.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 21 Sep 2020 09:28:52 +1000

> well lead to way to much emphasis on the short-term is

So you have correctly identified the principle that allowed us to decide what the right answer was in this particular case.  But that too wasn't the problem: the editor knew that this was the principle, but wasn't sure in this specific case which of the two options best fit that principle.

So I disagree that this is about judgment.  This is about learning what the principles are (long term reference stability in this case) and applying them.  What I think an issue tracker is good at is: placing these cases in a record that can be examined.

People can always turn that into a piecemeal approach with a short-term focus.  That's not my experience with the people in this community though.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 20 Sep 2020 20:06:45 -0400

Hmmm.  From where I sit, an issue tracker is a lousy way to place things 
in a record for examination.  Issue trackers are great for issues that 
need to be tracked and resolved.

Yours,
Joel

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 21 Sep 2020 11:03:06 +1000

> need to be tracked and resolved.

As I said, I think that this is a minor point, but I've used several issue trackers that have become an important resource for making strategic decisions.  For instance, Mozilla tracks regressions and looks for areas that need additional focus on proactive treatment.  But you seem to be inferring from this that this is the only mechanism by which strategy would be informed.

As I said before Eliot asked me to expand on this point, I think that this is a minor point.  I would expect there to be other inputs to strategic decision-making that are more heavily relied upon.

---

From: John C Klensin <[email-masked]>
Date: Sun, 20 Sep 2020 22:54:43 -0400

--On Monday, September 21, 2020 09:28 +1000 Martin Thomson
<[email-masked]> wrote:

> So you have correctly identified the principle that allowed us
> to decide what the right answer was in this particular case.
> But that too wasn't the problem: the editor knew that this was
> the principle, but wasn't sure in this specific case which of
> the two options best fit that principle.
> 
> So I disagree that this is about judgment.  This is about
> learning what the principles are (long term reference
> stability in this case) and applying them.  What I think an
> issue tracker is good at is: placing these cases in a record
> that can be examined.

But I'm not sure what principle you are appealing to because, at
least if the reference is normative, I can see two separate
issues:

(1) There is a very long-standing publications principle that
references are references and should be kept integral.   To the
best of my knowledge, every style manual about formal
publications in English, on both sides of the pond, is
consistent about it.  It has often been ignored in the RFC
Series, but that doesn't make it less of a principle.  So,
although there are variations in layout,

Doe, J., "Flowers Bloom in the Spring", Chapter 5 of Boggs, P.,
_Events of the Year_, 1984, pp. 666-700,...

and

Dijkstra, E.W., "Go To Statement Considered Harmful",
_Communications of the ACM_, Vol. 11, No. 3, March 1968, pp.
147-148.

and 

Flanagan, H. and Ginoza, S., "RFC Style Guide", RFC 7322,
September 2014, Section 4.8.6.2, ...

work while, traditionally, running text containing

... the discussion of flowers blooming in [Doe1984] Chapter 6...
... [Dijkstra1968] page 147...
... discussion of URIs in RFCs [RFC7322] Section 4.8.6.2...
  or even
... discussion of URIs in RFCs [RFC7322, Section 4.8.6.2]...

is considered obnoxious or worse.

(2) For citations to documents that contain definitions or other
information that is necessary to understand the present
document, there has been a rule in the RFC Series since at least
the mid-1980s that both the reference and the target must be
stable, i.e., that one must be able to use the reference to find
the target _and_ the definitions (or whatever) in the target
must not change -- preferably not at all, ever, but at least not
in any way that might substantively change the meaning or
interpretation of the specification in the RFC.  For that
purpose, the syntax of the reference (including what information
is actually put in the reference and what information is placed
inline in the text as above) makes no difference -- it is the
principle that is important and, IMO, any change to that
principle definitely has strategic implications.

This second issue (obviously, I hope) goes to the questions of
what "archival" and "stable specification" mean and is hence one
that is intertwined with some others.

Now, which of those issues were you and John discussing?

thanks,
   john

> People can always turn that into a piecemeal approach with a
> short-term focus.  That's not my experience with the people in
> this community though.