Subject: [Rfced-future] Observations on issues

From: Jay Daley <[email-masked]>
Date: Wed, 15 Apr 2020 20:52:49 +1200

Given my role, before sending this I asked Eliot about both the appropriateness of me doing so and the content and his view is that it is very important that I send this, so here goes. 

I have some observations regarding issues around the RSE role which have developed from my unusual position. However, I am acutely aware that I am still very much a newcomer and so while I have tried to sanity check these with others, there is a chance I may have misunderstood something and may be misrepresenting a situation, for which I apologise in advance. 

My observations are:

1.  Over the last 1-2 years the move to the v3 XML has brought with it some very technical issues and as a result the RSE role is a far more technical than the various role specifications recognise.  The RSE currently needs to be quite technically proficient in XML and specific vocabularies such as HTML and SVG; XML schemas and translators; SDLC including versioning, testing, UX and more; and archival formats and methods.  If the trend continues then in the future they may also need to be proficient in ontologies and RDF. 

2.  There have been multiple changes proposed for the v3 XML that have led to conflict between those tasked with implementing them and members of the community who would do things differently.  This highlights a gap - there should be a process for these proposed changes to be evaluated by a larger independent group who then decide amongst the competing views on whether the change is implemented and if so how.  Possibly by default that decision making authority sits with the RSE but they do not appear to have exercised that authority and so those implementing have done the best they can. 

3.  One of the key tasks of the RSE that has been mentioned several times has been to help us end up with a strategy for the RFC Series, by whatever means are appropriate.  However there does not seem to be one, nor a process to create one (excepting this program) and there are a number of  current issues that are clearly strategic, including:

- the RFC Series is regarded by some as immutable and yet others are concerned that this means that implementers/researchers miss vital errata, which in turn has significant flow on problems.  The various solutions to this include versioning of RFCs, changing the presentation context to focus on an errata annotated version while still maintaining immutability or just dropping immutability.

- there is no easy way for people to find the current set of RFCs related to a specific technology that they wish to implement/study.

- and while we understand the concept of the "official" tool to transform the canonical XML into a readable output (xml2rfc) the position we are in is that this really is the only reliable and fully featured tool, for a variety of reasons and it’s not clear if that is understood and accepted or if we need to ensure diversity, say by a published detailed specification of the output or transformation rules so that a third party can implement an alternative.

I realise these are all quite practical compared to the loftier questions of how do we ensure the RFC Series is here in 50 years.  Also, to be clear I don’t have a view on any of these, other than a general goal of seeing this all tidied up.

Jay
-- 
Jay Daley
IETF Executive Director

---

From: Eliot Lear <[email-masked]>
Date: Wed, 15 Apr 2020 11:40:25 +0200

Thank you, Jay.  I agree that your perspective is very important and very welcome.  I ask program members to take Jay’s comments under advisement as we go forward.  He raises a number of important points about both the job qualifications and responsibilities of the RSE, and discusses the relationship between the RSE, the series, and the community.

Eliot

> On 15 Apr 2020, at 10:52, Jay Daley <[email-masked]> wrote:
> 
> 
> I have some observations regarding issues around the RSE role which have developed from my unusual position. However, I am acutely aware that I am still very much a newcomer and so while I have tried to sanity check these with others, there is a chance I may have misunderstood something and may be misrepresenting a situation, for which I apologise in advance.. 
> 
> My observations are:
> 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 15 Apr 2020 10:54:52 +0100

Hi Jay,

Your ‘newcomer’ and ‘practical’ view of this is appreciated (by me).

On your second point, I see the gap that, “There should be a process for these proposed changes to be evaluated,” but I don’t see how you arrive at, “By a larger independent group.” I’m not saying that I think having a larger group is right or wrong, but I am asking you to show your workings. For example, why would it be wrong for the RSE to make the decision?

On your third point, you say, “Help us end up with a strategy.” One could argue that there has been a strategy in place all along, and that the RSE both established and delivered that strategy. That argument might need to be accompanied by a statement that, “It was not obvious to all following the topic what the strategy was nor how it was being delivered.” 

Your bullet points that follow, raise a number of issues that come around on the rinse-and-repeat cycle. Raising these points establishes the meta point of whether the RSE sets policies / resolutions for these and similar issues, or whether the RSE is tasked to deliver on the wishes of the community (even when those wishes go against the professional opinion of the RSE). This meta point cuts, I think, to the core of the problem: whose RFC Series is it; who makes the decisions; is the RSE the owner, a consultant, or a servant?

Best,

Adrian

From: Rfced-future <[email-masked]> On Behalf Of Jay Daley
Sent: 15 April 2020 09:53
To: [email-masked]
Subject: [Rfced-future] Observations on issues

Your strategic bullet points that follow are, indeed, questions that come around on the 

My observations are:

Jay

-- 

Jay Daley
IETF Executive Director

---

From: Jay Daley <[email-masked]>
Date: Wed, 15 Apr 2020 22:30:49 +1200

Adrian

> On 15/04/2020, at 9:54 PM, Adrian Farrel <[email-masked]> wrote:
> 
> Hi Jay,
> 

Yes, I have elided some steps there.  Given that I only wanted to make observations not favour a solution, it’s best if I don’t follow-up with an explanation as to how I got there and instead leave a solution to emerge, if that issue is indeed adopted.

> On your third point, you say, “Help us end up with a strategy.” One could argue that there has been a strategy in place all along, and that the RSE both established and delivered that strategy. Tha…

Presumably it would be documented?

> Your bullet points that follow, raise a number of issues that come around on the rinse-and-repeat cycle. Raising these points establishes the meta point of whether the RSE sets policies / resolutio…

I think that last sentence significantly overcomplicates this issue.  My role is similar and I have to be the servant one day, the owner or the consultant the next, and some day all three.  If I own when I should serve then I run the risk of upsetting people, and if I serve when I should own then I run the risk of things never getting done.  If there are things that are sufficiently important to constrain the role then put a process/policy in place, but otherwise let them get on with it.  Far better to focus on what the role needs to get done and what, if any, should be the constraints and how should those be implemented than a divisive existential question which even if it were decided, would still not sort out the practicalities.

Jay

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

---

From: Eliot Lear <[email-masked]>
Date: Wed, 15 Apr 2020 12:58:34 +0200

Good afternoon Adrian,

> On 15 Apr 2020, at 11:54, Adrian Farrel <[email-masked]> wrote:
> 
> Hi Jay,
>  

I think this falls more on the solution side.  Let’s capture the problem crisply.

> On your third point, you say, “Help us end up with a strategy.” One could argue that there has been a strategy in place all along, and that the RSE both established and delivered that strategy. Tha…

That’s nearly perfectly worded for a problem statement.

> Your bullet points that follow, raise a number of issues that come around on the rinse-and-repeat cycle. Raising these points establishes the meta point of whether the RSE sets policies / resolutio…

And that too!  But Jay’s practical and concrete issues are useful to help us understand the implications whatever solutions we as a group develop.

Eliot

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 15 Apr 2020 12:30:19 +0100

> Good afternoon Adrian,

Hello to you, too.

> I think this falls more on the solution side.  Let’s capture the problem crisply.

Oh, but I agree. That might have been exactly my point were I not trying to be diplomatic with Jay whose email posited a “larger independent group” which sounds (to me) like a solution not a statement of the problem.

> That’s nearly perfectly worded for a problem statement.

We aim for perfection. 

I think documentation, transparency, and communication might be the bywords.

> And that too!  But Jay’s practical and concrete issues are useful

> to help us understand the implications whatever solutions we

> as a group develop.

Yes, but 😊

That is, as you say, solution-oriented. So maybe we leave the details and practical issues on one side until we get as far as solutions.

For now we need to try to capture the high-level scope and requirements (and stop trying to fix problems until we know what problems we need to fix).

Thanks,
Adrian

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Apr 2020 15:14:28 +0200

Hi Jay,

> On 2020-04-15, at 10:52, Jay Daley <[email-masked]> wrote:
> 
> 

This opens an interesting scope discussion.

Some of us perceive the RFC series as a series of archival publications.

Some of us would prefer to turn this into what I’ll call “a website”, for providing easy, low-threshold access to up-to-date standards documents and related information.

It is not clear to me at all that “a website” would fall under the purview of the RSE.

It is not even clear that the RSE would need to participate in “a website”; this could exist in parallel to a series of archival publications (actually, even multiple instances of “a website” could be created for different target audiences).
Clearly, providing some mutual interfacing would facilitate the parallel approach, so some form of participation is desirable.

The IETF might have processes to channel consensus information to “a website” beyond RFCs and their errata reports.

> - there is no easy way for people to find the current set of RFCs related to a specific technology that they wish to implement/study.

“A website”, that is.

> - and while we understand the concept of the "official" tool to transform the canonical XML into a readable output (xml2rfc) the position we are in is that this really is the only reliable and full…

While the fact that we use XML vocabulary right now as the canonical format does invite some desirables, I mainly view the XML format as insurance for the future.  So, again, it is not clear that the RSE needs to be part of all those desirables, but it would be useful to provide the interface from the archival series to “a website” that facilitates those desirables.  This would ultimately also inform the evolution of the XML vocabulary (or whatever replaces it in the long term).

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Wed, 15 Apr 2020 19:40:52 +0200

On 15.04.2020 10:52, Jay Daley wrote:
> 
> Given my role, before sending this I asked Eliot about both the
> appropriateness of me doing so and the content and his view is that it
> is very important that I send this, so here goes.
>
> I have some observations regarding issues around the RSE role which have
> developed from my unusual position. However, I am acutely aware that I
> am still very much a newcomer and so while I have tried to sanity check
> these with others, there is a chance I may have misunderstood something
> and may be misrepresenting a situation, for which I apologise in advance..

Looking at this with relatively fresh eyes is a good thing in any case.

> My observations are:
>
> 1.  Over the last 1-2 years the move to the v3 XML has brought with it
> some very technical issues and as a result the RSE role is a far more
> technical than the various role specifications recognise.  The RSE
> currently needs to be quite technically proficient in XML and specific
> vocabularies such as HTML and SVG; XML schemas and translators; SDLC
> including versioning, testing, UX and more; and archival formats and
> methods.  If the trend continues then in the future they may also need
> to be proficient in ontologies and RDF.

Absolutely, and actually this goes back more then 1-2 years. Or phrased
differently, we might be further ahead in the transition if that would
have been taken into account earlier on.

(Also, I'm not sure about the prediction in the last sentence, but I'd
love to hear more about that :-).

> 2.  There have been multiple changes proposed for the v3 XML that have
> led to conflict between those tasked with implementing them and members
> of the community who would do things differently.  This highlights a gap
> - there should be a process for these proposed changes to be evaluated
> by a larger independent group who then decide amongst the competing
> views on whether the change is implemented and if so how.  Possibly by
> default that decision making authority sits with the RSE but they do not
> appear to have exercised that authority and so those implementing have
> done the best they can.
> ...

Indeed. I'll add a few key points (from my perspective of "a member of
the community who would do things differently"):

- What happens right now is that we're not working on the specification
but a single implementation, and plan to describe what that does
after-the-fact - but we do not really make progress with that. Having a
single implementation driving things is not good; it makes it harder to
come up with different implementations of the formatter later on, and
also affects people who want to do *different* things with the
vocabulary (such as *generating* it, or processing it for purposes other
than formatting).

- Having a single implementation causes certain risks, and I see that
already happening: such as implementation details leaking into the
"canonical vocabulary", or relying on certain libraries that might only
be available for certain language ecosystems.

- While it's certainly necessary to debug the vocabulary, we also have
to consider the effects on related specs, such as preptool, output
format specs etc. I don't see that happening at all.

- What's new in the v3 world is that the RFC Style Guide now needs to
exactly align with what the vocabulary can express (and what the
formatters can produce). That kind of alignment was not totally
necessary in the past, when xml2rfc's output could be fine tuned before
publication, but it's absolutely critical now. It's good that John has
taken over the ownership of the RFC Style Guide, and it would be good to
clarify that he actually has the power to progress it.

Finally: the longer this takes, the more documents will be published in
a format which, after all, is not canonical or stable at all.

> ...

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 15 Apr 2020 22:02:03 +0200

I didn’t want to go into that level of detail yet, but maybe there is another scoping issue hiding here:

On 2020-04-15, at 19:40, Julian Reschke <[email-masked]> wrote:
> but a single implementation,

… which in the vast majority of cases is used with an authoring dialect of the vocabulary, and not with the publishing dialect.  Most of the authoring is done with the goal of publishing I-Ds, so different considerations apply from authoring archival documents, but there is no product owner here that would voice for this dominant use, so all the voicing is done by frustrated users.

The RSE could take over the job to be that product owner as well, but that would mean that the RSE must be extraordinarily capable of juggling the pulls of two different products at the same time.  (People like that do exist.)

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Apr 2020 10:07:27 +1200

On 15-Apr-20 22:58, Eliot Lear wrote:
...>> On your third point, you say, “Help us end up with a strategy.” One could argue that there has been a strategy in place all along, and that the RSE both established and delivered that strategy. That argument might need to be accompanied by a statement that, “It was not obvious to all following the topic what the strategy was nor how it was being delivered.” 
> That’s nearly perfectly worded for a problem statement.

It's fairly clear that there is a big difference between the technical aspects
of the RSE role, especially as complicated by the v3 roll-out, and the more abstract aspects that concern the principles of the RFC series, the non-existent charter of the series and its editor, and the non-technical strategy that the principles and charter lead to.

To be clear, IMHO neither RFC8729 nor RFC8728 comes close to defining such principles or providing a charter for the series. That being so, no RSE can be expected to develop a coherent strategy.

Whether it's this group's job to develop those principles and the charter is an open question, but their absence should IMHO be on the problem list.

   Brian

---

From: "John Levine" <[email-masked]>
Date: 15 Apr 2020 22:38:11 -0400

In article <[email-masked]> you write:
>Some of us would prefer to turn this into what I’ll call “a website”, for providing easy,
>low-threshold access to up-to-date standards documents and related information.
>

I don't see any necessary conflict between making our documents more
accessible and usable and making them archival.  If you look at the
IEEE's or ITU's publications, they use dates or version numbers, and
their naming schemes are designed to make it easier to tell what's
related to what, but if you have a particular version or date of a
document, that unambiguously identifies an archival document.  This is
not to say we should emulate their standards processes , just that
their numbering is a lot less opaque than ours.

It is infamously difficult to find all the RFCs you need to implement
any particular service.  I understand the history of why that's the
case but I certainly don't see it as a virtue.

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 15 Apr 2020 23:11:08 -0400

> case but I certainly don't see it as a virtue.
This statement right here I can not agree with more strenuously.
I wrote a rough problem statement around making our RFCs much more
living documents than the current -bis process we have now.

For example, if you've watched the effort that the TCP groups have
put in to produce 793bis, it's been many many years.
Take 1035 for example on DNS, which has been updated by over 2 dozen RFCs.
Trying to implement all the pieces is non-trivial.

I've spent time trying to scope out how much time it would take to
generate an updated 1035, and it appears to be a totally thankless
task and not very "interesting" work.

(and yes John, I'm beginning to see how I am a glutton for punishment)

tim

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 15 Apr 2020 23:11:35 -0400

Please, let's be a bit careful about mixing the issue of revision with 
the issue of the set of RFCs that you need to implement in practice to 
usefully fill a certain space.

We as a community have tried to address the latter.  I will not rehash 
or misconstrue the politics, but it was not easy, pretty, nor effective. 
  And has little or nothing to do with the numbering of our standards 
and the revisions thereof.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Apr 2020 17:10:36 +1200

> and the revisions thereof.

Exactly. And it's an *IETF* problem, so I don't see how it would be in
scope here.

   Brian

---

From: Jay Daley <[email-masked]>
Date: Thu, 16 Apr 2020 18:01:07 +1200

> On 16/04/2020, at 5:10 PM, Brian E Carpenter <[email-masked]> wrote:
> 

The point I was making is that this is a strategic issue which should be resolved by a strategy and AFAIK it is the role of the RSE to ensure that said strategy is developed somehow and yet I’m not aware there is such a strategy or a plan to develop one.  That issue I would suggest, is in scope.

Jay

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 16 Apr 2020 09:15:34 +0200

Hi Joel,

> On 16 Apr 2020, at 05:11, Joel M. Halpern <[email-masked]> wrote:
> 
> Please, let's be a bit careful about mixing the issue of revision with the issue of the set of RFCs that you need to implement in practice to usefully fill a certain space.

I think it’s good to tease these out, but in the context of the responsibilities of the RFC Editor.

> Exactly. And it's an *IETF* problem, so I don't see how it would be in

Let’s test that: are there formats that could facilitate spotting differences between revisions, or points where updates or references could occur?  For instance, today our references point to entire documents.  Could the references point to specific tags in documents?

Now… my point in asking is not to delve further into the weeds, but simply to see if we can find some useful delineations.

Eliot

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 16 Apr 2020 11:13:47 +0100

> case but I certainly don't see it as a virtue.

But this is so easy to solve by writing a "cook book" that one might wonder why it isn't solved.

The fact that no one writes such gazetteers might indicate that although the problem is infamous, it is not something that actually bothers many people. Or we might deduce that once someone has solved the puzzle they consider the solution to be secret sauce. Or whatever.

I don't believe that the solution is in metadata (which could get multi-dimensional), but in better documentation. The need for better documentation to explain our protocols and thinking is long-standing and the solution lies in the community.

Best,
Adrian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 16 Apr 2020 09:48:59 -0400

If we open the whole numbering / structuring of the series issue on this 
list, my personal guess is that we will never converge.  While my guess 
may be wrong, I am VERY confident that if we dive into that topic, we 
will not come up in the kind of time frame we have claimed we want to 
address the structure and responsibility of the RFC Series Editor.

Saying that we want an editor who can determine what community could / 
should have such a discussion, and whether the relevant community does 
want to have such a discussion, seems appropriate.  Personally, I even 
like saying that the RSE should lead such discussion (although that is a 
separable question.)

Yours,
Joel

---

From: "John R. Levine" <[email-masked]>
Date: 16 Apr 2020 09:56:18 -0400

> The fact that no one writes such gazetteers might indicate that although the problem is infamous, it is not something that actually bothers many people. Or we might deduce that once someone has sol…

Or it might tell us that it's so hard that it's impossible.  I can tell 
you from recent experience that we can't even figure out how to collect 
the ABNF for the syntax of an Authentication-Results e-mail header, 
because it is spread across a dozen documents, some of which are wrong.

I can't imagine trying to write an accurate cookbook for implementing a 
DNS server.

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: Doug Royer <[email-masked]>
Date: Thu, 16 Apr 2020 08:01:33 -0600

> I don't believe that the solution is in metadata (which could get multi-dimensional), but in better documentation. The need for better documentation to explain our protocols and thinking is long-st…

When your trying to implement a new product, it is very important. When you have already implemented, your busy and often do not reply to those questions. If it is not built into the release of the documents, it will never happen.

-- 
Doug Royer - (http://DougRoyer.US) [email-masked] 714-989-6135

---

From: Doug Royer <[email-masked]>
Date: Thu, 16 Apr 2020 08:01:43 -0600

---

From: Eliot Lear <[email-masked]>
Date: Thu, 16 Apr 2020 16:05:37 +0200

Joel,

> On 16 Apr 2020, at 15:48, Joel M. Halpern <[email-masked]> wrote:
> 
> If we open the whole numbering / structuring of the series issue on this list, my personal guess is that we will never converge.  While my guess may be wrong, I am VERY confident that if we dive into that topic, we will not come up in the kind of time frame we have claimed we want to address the structure and responsibility of the RFC Series Editor.

I don’t think we should try to do the work on this list, I agree.  I think that’s the general feel of the room, as it were.

> 
> Saying that we want an editor who can determine what community could / should have such a discussion, and whether the relevant community does want to have such a discussion, seems appropriate.  Personally, I even like saying that the RSE should lead such discussion (although that is a separable question.)

Ok

Eliot

---

From: Doug Royer <[email-masked]>
Date: Thu, 16 Apr 2020 08:08:30 -0600

On 4/16/20 7:56 AM, John R. Levine wrote:
> Or it might tell us that it's so hard that it's impossible.  I can tell you from recent experience that we can't even figure out how to collect the ABNF for the syntax of an Authentication-Results e-mail header, because it is spread across a dozen documents, some of which are wrong.
>
> I can't imagine trying to write an accurate cookbook for implementing a DNS server.

As this continues, it would seem fair to say that the IETF does not release standards, it just releases seemingly related comments. DNS and VoIP have become like trying to put fallen leaves back on the original place on a tree, only to find out later that someone cut of that branch.

It might be out of scope for this list. I think it will be very valuable over time to more protocols.

> Please consider the environment before reading this e-mail. https://jl.l

---

From: Adam Roach <[email-masked]>
Date: Thu, 16 Apr 2020 13:24:14 -0500

On 4/16/2020 5:13 AM, Adrian Farrel wrote:
> The fact that no one writes such gazetteers might indicate that although the problem is infamous, it is not something that actually bothers many people.

RFC 5411 did exactly this, but it's bound by the very issues that have 
come up in this thread about how we deal with revising the content of RFCs.

/a

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Apr 2020 11:15:00 +1200

> Now… my point in asking is not to delve further into the weeds, but simply to see if we can find some useful delineations.

Certainly, useful features could be added to the authoring toolkit, if only the IETF (an SDO that happens to use the RFC Series) would tell us (the friends of the RSE) what it wants.

BTW we already have direct section references. For example, look just below the figure at https://www.rfc-editor.org/rfc/rfc8754.html#name-segment-routing-header

I think this is an example of where the system worked.

   Brian

---

From: Larry Masinter <[email-masked]>
Date: Thu, 16 Apr 2020 17:48:56 -0700

I think some of the work of envisioning how a more up-to-date specifications could happen, 
https://tools.ietf.org/html/draft-ietf-git-github-wg-configuration-07
doesn't presume changes to the RFC series per se, but might provide better input to the archival series as well as interim dated records of (rough) consensus.
GitHub isn't "a website" because it implies a complete history of edits and versions and issues and disagreements.
--
https://LarryMasinter.net   https://going-remote.info

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 17 Apr 2020 03:32:23 +0200

On 2020-04-16, at 20:24, Adam Roach <[email-masked]> wrote:
> 
> RFC 5411 did exactly this, but it's bound by the very issues that have come up in this thread about how we deal with revising the content of RFCs.

Yes, we have had a few roadmap documents (RFC 4614/7414 comes to mind, or RFC 6071).
The TCP roadmap is the only example I can find where such a roadmap was actually published again as revised RFC.
Because of the immense effort needed to generate a consensus RFC with this information, some roadmaps never were pushed to RFC (e.g., draft-bormann-6lo-6lowpan-roadmap-00.txt, draft-bormann-core-roadmap-05.txt); others were just published as articles (the ultimate fate of the latter roadmap was https://DOI.org/10.1109/MIC.2012.29).

We never developed roadmapping into an element of our culture, but we could.

Grüße, Carsten

---

From: "John R. Levine" <[email-masked]>
Date: 16 Apr 2020 21:33:57 -0400

> doesn't presume changes to the RFC series per se, but might provide better input to the archival series as well as interim dated records of (rough) consensus.

This is fine for tracking the development of I-Ds, but there is a big 
difference between an I-D and an RFC.

Regards,