Subject: [Rfced-future] Why the RFC series is important

From: "John R Levine" <[email-masked]>
Date: 25 May 2020 16:42:02 -0400

The RFC series is two things: it's a stable archival set of documents 
about the technology and history of the Internet, and it's where you find 
Internet standards and related specs like BCPs. For the vast majority of 
people likely to look at RFCs, the latter aspect is what matters. If we 
were just publishing a series of historical papers, that would be fine but 
there's no way it would merit the amount we spend editing and publishing 
RFCs.

The problem is that the RFC series does a lousy job of publishing 
technical specs. If someone wants to write an SMTP server or a DNS server, 
there's a long list of RFCs that overlap and rewrite each other, there's a 
zillion errata not part of the RFCs that you need to know to look for and 
see if they matter, and there is a great deal of folklore to know which 
RFCs are important and which you can ignore. (For example, RFC 3865 
defines an SMTP extension that we knew nobody would ever use other than to 
make a political point.)

I believe there were two key reasons our specs have succeeded: one is that 
they do work if you can figure them out, and the other is that unlike most 
other SDOs we have always given them away for free.  Open access is now 
increasingly common, so it would be a good idea to make them easier to use 
or at the least easier to find the ones you need.

I am not proposing specific changes other than to say that the model of 
RFCs solely as independent immutable documents no longer makes sense. 
While I do not suggest we go to WHATWG style living documents, I do think 
that for our specifications we need to find a more modern way to collect 
the material into a small number of places with stable names (perhaps 
using version numbers like everyone else does), and to make discrete low 
cost updates as we find errors or make partial updates.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 25 May 2020 16:48:11 -0400

If there is anything I wish to get from this program, it is to get the IETF
to accept this position.  Once we accept this, we can start to plan on how
to get there.

tim

On Mon, May 25, 2020 at 4:42 PM John R Levine <[email-masked]> wrote:

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 25 May 2020 17:06:46 -0400

Personally, I find coupling the difficulty (real) with people finding 
the set of documents about a topic to the question of whether RFCs 
should be immutable to be a mixing of very different concepts.  As has 
been noted in other discussions, the question documents into subjects, 
and how to determine what set of RFCs go with what problem is 
non-trivial.  Is it worth addressing?  Yes.  But it is much cleaner to 
keep the bundling separate from the actual technical specifications. 
This is particularly true because in many cases the way the protocol is 
actually used turns out to be quite different from the expectations when 
it was published.  (One of the reasons it took Scott and me years to 
kill RIP, and it still came back, is that it was used very differently 
from other routing protocols.)

One can try to argue that the question of such bundling should be part 
of the RSE / RPC / ... work space.  I would find this quite surprising, 
since it turns out to be a significant technical task, and only 
secondarily a publication or editorial task.  I will grant that if the 
RSE is knoweldgable about information structuring (librarian science as 
it was once known, a skill Heather did have) they are a good source of 
input to designing the process.  But that still would not make them the 
party to execute such a process.

Net: no, I do not believe this valid question sheds light on whether 
RFCs should be immutable.  And I do not think it sheds much light on 
what we want from an RSE.

Yours,
Joel

On 5/25/2020 4:42 PM, John R Levine wrote:
> about the technology and history of the Internet, and it's where you 
> find Internet standards and related specs like BCPs. For the vast 
> majority of people likely to look at RFCs, the latter aspect is what 
> matters. If we were just publishing a series of historical papers, that 
> would be fine but there's no way it would merit the amount we spend 
> editing and publishing RFCs.
> 
> technical specs. If someone wants to write an SMTP server or a DNS 
> server, there's a long list of RFCs that overlap and rewrite each other, 
> there's a zillion errata not part of the RFCs that you need to know to 
> look for and see if they matter, and there is a great deal of folklore 
> to know which RFCs are important and which you can ignore. (For example, 
> RFC 3865 defines an SMTP extension that we knew nobody would ever use 
> other than to make a political point.)
> 
> I believe there were two key reasons our specs have succeeded: one is 
> that they do work if you can figure them out, and the other is that 
> unlike most other SDOs we have always given them away for free.  Open 
> access is now increasingly common, so it would be a good idea to make 
> them easier to use or at the least easier to find the ones you need.
> 
> While I do not suggest we go to WHATWG style living documents, I do 
> think that for our specifications we need to find a more modern way to 
> collect the material into a small number of places with stable names 
> (perhaps using version numbers like everyone else does), and to make 
> discrete low cost updates as we find errors or make partial updates.
> 
> Regards,

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 25 May 2020 14:10:02 -0700

> cost updates as we find errors or make partial updates.

I wanted to +1 this and perhaps expand upon it.

>From my perspective as a document author and consumer of documents,
there are several classes of changes one might wish to make to those
documents:

- Editorial changes. In our current system, these are basically
  impossible. People of course file errata, but it's very unlikely
  we will publish a new version of the document just to fix this
  kind of issue. This is perhaps not that big a deal for truly
  editorial issues (spelling, etc.) but it's not uncommon for
  the document to be somewhat unclear on some semantic point
  but there actually to be pretty good consensus on what the
  text is intended to mean. In the current environment, we're
  just left with ambiguity.

- Extensions. A large number of our protocols are actually frameworks
  with a pile of extensions, some of which are mostly irrelevant
  (e.g., TLS status_request_v2) and some of which are practically core
  pieces of the protocol (e.g., TLS elliptic curve cipher suites for
  TLS 1.2).  In principle, of course, one can chase through the IANA
  registries, but as a practical matter it's largely a matter of lore
  what's important and what's not. In an ideal world, we would present
  the core specification, including the important extensions, as a
  coherent whole, but the current structure gets in the way of that.

- Technical changes. Finally, there are settings in which one wishes
  to make technical changes. For instance, TLS 1.2 includes backward
  compatibility modes for versions of SSL we now prohibit. But you
  have to read some other document to find that out, as opposed to
  just reading the current recommendations in the main spec.

If we believe our objective here is to publish working technical
specifications, then addressing these points (and perhaps others)
should be a high priority.

I'd also like to briefly address the notion of "archival" here.
I see the term used a lot but at least from my perspective, it
potentially covers a set of different properties:

- Being able to be read well into the future.
- Capturing the history of the development of the protocol/document
- Being able to refer unambiguously to a specific point in the
  development of the protocol

I agree that these are valuable properties. However, I believe that
there is another valuable property, which is the ability to easily
refer to the *current* state of the protocol. This is not well served
by the existing structure. Perhaps in the past these were in tension,
however due to technological improvements (some combination of cheaper
storage and bandwidth and modern version control tools), we should be
able to preserve both the ability to easily know what the current
state is and to trace the entire history of the protocol. This
is something we routinely do for software systems and we should
be able to define a way to do so for our technical specifications
as well.

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 May 2020 09:11:09 +1200

On 26-May-20 08:42, John R Levine wrote:
...
> cost updates as we find errors or make partial updates.

Writing as one of those who bloodied their noses on this problem some
15 years ago, I completely agree, but it is an IETF problem, and the IETF
has been remarkably resistant to discussing it, let alone fixing it.

And I *think* it's orthogonal to our problem here, although if the IETF
would get its house in order, our problem might be easier.

Regards
    Brian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 25 May 2020 23:12:42 +0200

On 2020-05-25, at 22:42, John R Levine <[email-masked]> wrote:
> 
> I am not proposing specific changes other than to say that the model of RFCs solely as independent immutable documents no longer makes sense. While I do not suggest we go to WHATWG style living documents, I do think that for our specifications we need to find a more modern way to collect the material into a small number of places with stable names (perhaps using version numbers like everyone else does), and to make discrete low cost updates as we find errors or make partial updates.

The diagnosis appears to presume a therapy here.

However, most of the problems are with the high-energy approval process of the IETF stream, which makes it impractical to do actual revisions of documents without exposing previous consensus to new attacks and subjecting it to current political and technical fashions.

So we publish updates to updates to updates, and almost never do consolidated versions like they are being done in lawmaking.

We also don’t have a lot of roadmap documents (*).  Nobody gets points for writing them.  The IESG loathes having to review them as consensus documents, so informational documents of this kind are discouraged instead of encouraged.  (Really, no WG should be chartered without securing the energy to write up how its output works together with existing specifications!)

Not much of that is a consequence of the RFC process, it is really a stream issue.

(We could try to repair the stream by exerting pressure from the output end, but I’m not sure that would work very well.  **We need to be able to actually do the work**, first!)

Grüße, Carsten

(*) On 2020-04-17, I wrote:
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.

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 25 May 2020 17:13:21 -0400

Brian

While it is an IETF problem, I would like to see an RFC Editor function
that is empowered to tackle this problem.

tim

On Mon, May 25, 2020 at 5:11 PM Brian E Carpenter <
[email-masked]> wrote:

> ....
> think

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 25 May 2020 14:19:19 -0700

I think whether this is an IETF problem depends on one's priors.

At a high level, it seems likely that we need some kind of
two-layer system of references:

- A reference that points to the current state (e.g., "TLS
  with all the recommended extensions, etc.").

- A reference that points to a specific historical state
  (in version control, we'd call this a hash or a version
  number depending on the system).

Now, if you assume that RFC #s are the lower layer (i.e., that RFC
XXXX always points to the same content), then yes, it seems like the
IETF would need to layer something new on top and this becomes an IETF
problem. However, if one treats RFC #s as the higher layer (perhaps
with a version number suffix as the lower layer) then this becomes
an RFC series problem.

-Ekr

On Mon, May 25, 2020 at 2:13 PM Tim Wicinski <[email-masked]> wrote:

>> .....

---

From: Jay Daley <[email-masked]>
Date: Tue, 26 May 2020 09:21:33 +1200

> On 26/05/2020, at 9:13 AM, Tim Wicinski <[email-masked]> wrote:
> 
> 
> Brian
> 

As I understand it the RSE is empowered to tackle that as per this from RFC 8728: "Leads the community in the design of improvements to the RFC Series.  The question perhaps ought to be - what happens if the RSE firmly wants feature X of the RFC Series to stay as it is and doesn’t want to open up a process that might change that?

Jay

> 
> tim
> 
> 
> On Mon, May 25, 2020 at 5:11 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.iab.org/mailman/listinfo/rfced-future <https://www.iab.org/mailman/listinfo/rfced-future>
> -- 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 May 2020 09:56:26 +1200

Let me challenge that with a question.

What would really be better if RFC8200 was actually called RFC1883.3?

Or if RFC8446 was RFC2246.4?

I think the problem is much deeper (see the newtrk archive).

Regards
   Brian Carpenter

On 26-May-20 09:19, Eric Rescorla wrote:
> On Mon, May 25, 2020 at 2:13 PM Tim Wicinski <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     Brian
>

---

From: "John R Levine" <[email-masked]>
Date: 25 May 2020 18:04:14 -0400

> Or if RFC8446 was RFC2246.4?

Without a better way to do minor updates, I agree that changing the names 
isn't likely to make any difference.  I note that it took 19 years to 
update RFC 2460 to RFC 8200 which perhaps suggests some underlying issues.

RFC 5321 needs an update but we are reluctant to do it because as soon as 
you open the can even a little bit, all the worms swarm out and bite you.

Regards,

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 25 May 2020 15:05:22 -0700

> What would really be better if RFC8200 was actually called RFC1883.3?

I don't understand v6 well enough, but quite possibly.

No, I think that TLS 1.2 is a specific thing and so is TLS 1.3.

However, I think that it would be better if the bazillion documents that
you actually needed to implement TLS 1.2 were referred to by the name "RFC
2246" and that most people never had to engage with the specific
differences between RFC 2246.5 and RFC 2246.6.

Similarly, I think that it would be better if TLS 1.3 + the already filed
errata plus the various update documents currently in process (ESNI,
importers, ...) were referred to as RCC 8446.

Just to make sure we are on the same page, my thesis is that people would
generally not reference specific RFC dot versions. This is what happens in
the Web platform, for instance: one can in principle refer to specific
versions of the HTML5 spec, but as a practical matter, people do not need
to do so.

-Ekr

Regards
> [email-masked] <mailto:[email-masked]>> wrote:
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 25 May 2020 18:12:43 -0400

I have to strongly agree with Brian on this.

Yours,
Joel

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 25 May 2020 15:13:39 -0700

On Mon, May 25, 2020 at 3:04 PM John R Levine <[email-masked]> wrote:

> isn't likely to make any difference.
>

This is a really important point, and in fact it's a positive feedback
loop. Because everyone knows it is super-expensive to make version N+1,
making version N becomes really expensive as people try to make it perfect.
If it were easier to make small changes (especially editorial ones) then we
could make AUTH48 much faster because people would know they could fix it
later.

-Ekr

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 25 May 2020 18:15:51 -0400

A good data point on how ineffective the IETF is at updating our larger
technical specifications is the work involved in RFC793-bis coming out
of tcpm.   Wes started this in 2013, and ugh, still moving along.

I look at RFC1035 and I see a similar timeline.
tim

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 25 May 2020 18:16:44 -0400

Agree with Eric and John on the importance of better way to do minor
updates.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 25 May 2020 18:17:41 -0400

I have to disagree with this.

In almost every case that I know of, it is important to be clear as to 
what content one is referring to.  In a vendor describing a product, or 
a purhcaser requesting a product, or a PM laying out a feature plan, or 
... it is critical that the target be stable.

If I advertise support for "OSPF", that may be good enough for marketing 
collateral, but if someone is going to use it they need to know exactly 
what version of the protocols they care about I have implemented  (which 
is why operator RFPs are long and detailed. )

In fact, if I put aside the minor issue of the rare case where we make a 
substantive error in the RFC, I can see no case where it is important to 
refer to "the most current version of BGP" even if that were a 
well-defined thing.

Wanting to know  what the set of things I should consider for 
implementing (or using) BGP is reasonable.  But that is not addressed by 
giving a simple name to a vast collection of specification.  Whether 
that is roadmaps, IONs, or other descriptions, it is not the specifications.

Yours,
Joel

On 5/25/2020 6:05 PM, Eric Rescorla wrote:
> 
> 
> On Mon, May 25, 2020 at 2:56 PM Brian E Carpenter 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> you actually needed to implement TLS 1.2 were referred to by the name 
> "RFC 2246" and that most people never had to engage with the specific 
> Similarly, I think that it would be better if TLS 1.3 + the already 
> filed errata plus the various update documents currently in process 
> (ESNI, importers, ...) were referred to as RCC 8446.
> Just to make sure we are on the same page, my thesis is that people 
> would generally not reference specific RFC dot versions. This is what 
> happens in the Web platform, for instance: one can in principle refer to 
> specific versions of the HTML5 spec, but as a practical matter, people 
> do not need to do so.
> 
> -Ekr
> 
> 
>     Regards
>         Brian Carpenter
> 
>      > On Mon, May 25, 2020 at 2:13 PM Tim Wicinski <[email-masked]
>     <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >
>      >     Brian
>      >
>      >     On Mon, May 25, 2020 at 5:11 PM Brian E Carpenter
>     <[email-masked] <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >         > I am not proposing specific changes other than to say
>     that the model of
>      >         > RFCs solely as independent immutable documents no
>     longer makes sense.
>      >         > While I do not suggest we go to WHATWG style living
>     documents, I do think
>      >         > that for our specifications we need to find a more
>     modern way to collect
>      >         > the material into a small number of places with stable
>     names (perhaps
>      >         > using version numbers like everyone else does), and to
>     make discrete low
>      >         > cost updates as we find errors or make partial updates.
>      >
>     <mailto:[email-masked] <mailto:[email-masked]>>
>     <mailto:[email-masked] <mailto:[email-masked]>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 25 May 2020 18:28:16 -0400

Tim, I think that there are two different (related, but different) 
problems here.

We do have difficulty updating documents.  In my experience this is 
caused by folks needing to relitigate the contentious agreements that 
led to the previous document.  The whole point of standards is to reach 
those agreements.  So yes, it is painful when they get re-opened.  There 
may be ways to improve that.  While there are problems with it, Adam had 
an interesting proposal to try to enable re-opening part of a document. 
We couldn't even figure out how to usefully discuss that.

The other problem is the one John pointed to initially.  We do not ahve 
good guides to have to use sets of our documents to solve problems.  How 
do you build a set of good software for any specific kind of protocol 
participant.  From history this has two different hard pieces itself. 
First, we do not actually have agreements on how to package these things 
up, and what the actual requirements are.  The efforts it took to 
produce the old Host Requirements and Router Requirements RFCs reflect 
this.  (I suspect Fred Baker still has scars from the later.)  And the 
second is that actual packaging is not as trivial as it looks.  Should 
we have a package for BGP, one for OSPF, one of IS-IS, ..?  Or should we 
have one for VPNs, one for TE, one for ...?  Or should we have a good 
indexing system that lets you ask the question either way?

Yours,
Joel

On 5/25/2020 6:16 PM, Tim Wicinski wrote:
> updates..
> On Mon, May 25, 2020 at 6:14 PM Eric Rescorla <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
> 
>     On Mon, May 25, 2020 at 3:04 PM John R Levine <[email-masked]
>     <mailto:johnl@taugh..com>> wrote:
> 
>     This is a really important point, and in fact it's a positive
>     feedback loop. Because everyone knows it is super-expensive to make
>     version N+1, making version N becomes really expensive as people try
>     to make it perfect. If it were easier to make small changes
>     (especially editorial ones) then we could make AUTH48 much faster
>     because people would know they could fix it later.
> 
>     -Ekr
> 
>     --

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 25 May 2020 15:30:14 -0700

I agree that it's important to be able to refer to the precise
functionality that is implemented, however, I don't think that
necessarily means a specific set of documents. In the specifications I
am most familiar with (TLS, QUIC, HTML), we strive for stability of
features once they are built and the ability to negotiate/detect
certain features.

For instance, one might say one implemented TLS 1.3 with the Encrypted
Client Hello feature but not PSK Importers. Similarly, one might say
that one implemented HTML5 and localStorage but not Web Workers.
(Hence my answer to Brian that I don't think you would refer to TLS
1.3 with the same basic RFC # as TLS 1.2, because 1.3 is not an
extension of 1.2). And note that in these specifications, even
"extensions" in the main spec are not always mandatory.

Again, I don't have a problem with referring to concrete versions
of the RFCs, but in my experience the vast majority of the changes
(as before, editorial changes or optional extensions) actually
do not benefit from this treatment, and in fact are made much
harder by it.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 25 May 2020 23:47:02 +0100

Hiya,

Without taking a position on any solution to the
"point me at the DNS spec" problem (which is real)...

> could make AUTH48 much faster because people would know they could fix it

AUTH48 is not where we suffer delays. Nor is IESG
processing, in general. Documents being very slowly
processed by RGs or WGs or in finding/creating a WG is
where the long delays happen. (I recall someone doing
stats on that a few years back but don't have a ref,
sorry.)

If that is true (and I think it is), I think it's
safe to conclude that the too-hard-to-update problem,
which is very real, manifests inside the IETF really,
so I find it hard to see how the RSE can be the source
of the fix for that. An RSE could I guess in theory
make it harder to fix, but I reckon the impetus to fix
this needs to come from the IETF community. And ISTM
one amongst many barriers to that kind of ease-of-update
is that it'd need a level of tolerance for things with
which we disagree that I've not really seen be a feature
of the IETF community (myself included;-)

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 25 May 2020 15:54:02 -0700

On Mon, May 25, 2020 at 3:47 PM Stephen Farrell <[email-masked]>
wrote:

> AUTH48 is not where we suffer delays.

Well, it's not the only place, but for instance TLS 1.3 spent 2 months in
AUTH48 in part because we felt we had to go through every word.

Nor is IESG
> of the IETF community (myself included;-)

I think this conflates a bunch of different kinds of updates. To take the
easiest example right now we have an errata system in which the errata are
approved without WG intervention, IESG ballots, etc., but then they just
kind of go into space. If each approved erratum updated the existing
document, that in itself would be an improvement in clarity.

-Ekr

---

From: Michael StJohns <[email-masked]>
Date: Mon, 25 May 2020 18:57:09 -0400

On 5/25/2020 6:13 PM, Eric Rescorla wrote:
> <mailto:[email-masked]>> wrote:
>
> loop. Because everyone knows it is super-expensive to make version 
> N+1, making version N becomes really expensive as people try to make 
> it perfect. If it were easier to make small changes (especially 
> editorial ones) then we could make AUTH48 much faster because people 
> would know they could fix it later.

Um - wasn't that the point of the ID series?  (I actually know the 
answer - it was - it was specifically the reason that series was 
created).    There's always going to be the question of "what's an 
editorial change that doesn't require re-approval of the authors/WG 
chairs/WG/IESG?"  I'm not sure that this is an RFC Series Editor problem 
so much as it is perhaps a standards stream problem.

How would you differentiate between RFC9001 and RFC9001oops? Would 
RFC9001 just cease to exist?  Would there need to be some sort of 
rev/diff mechanism similar to GIT or SVN or Mecurial? Which version 
would the secretariat send out to the lawyers (I don't really care - but 
its a question that would need to be answered).

My take on this is that its probably as RFC 2026 revision that is needed 
to address your concerns and that's probably not directly tied to how 
the RFC editor is constituted.  That could come from a WG, or from a 
design team or even an IAB area.

Alternately, we can add this to the task list of things you want from 
the RFC Editor and figure out how to write SOW language that covers it.

I do understand there is a problem - what I'm not seeing are good 
proposals for resolving the problem.

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Mon, 25 May 2020 19:04:21 -0400

On 5/25/2020 6:28 PM, Joel M. Halpern wrote:
> The efforts it took to produce the old Host Requirements and Router 
> Requirements RFCs reflect this.  (I suspect Fred Baker still has scars 
> from the later.)

Me too.

The arguments about whether a device with interfaces on two different 
networks was allowed to accept packets for an address tied to interface 
B but received on interface A were harrowing and painful.  Host 
requirements still holds the record as the longest sitting of a working 
group in one session (approx 9am to 2am with bathroom breaks and sending 
out for pizza).

> And the second is that actual packaging is not as trivial as it 
> looks.  Should we have a package for BGP, one for OSPF, one of IS-IS, 
> ..?  Or should we have one for VPNs, one for TE, one for ...?  Or 
> should we have a good indexing system that lets you ask the question 
> either way?

This turns out to be very complicated.   Using the example, trying to 
keep Host and Router requirements "pure" enough to not be interfering 
with each other was almost a sisyphean task.  And to be blunt, you're 
going to spend a lot more time that you anticipated ensuring consistency 
across the whole document set.

Later, Mike

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 May 2020 00:36:00 +0100

Hiya,

> AUTH48 in part because we felt we had to go through every word.

Well, that's vs. 4 years in the WG though. [1] TLSv1.3
was important and tricky enough that I can easily see 2
(or even 3) of those years really being needed in that
case, but nonetheless the significant delays (and blockages
to doing minor updates) are in the WGs, be those justified
delays or not.

IESG, RFC editor queue and auth-48 delays are annoying
as hell after you've already jumped through a crap-load
of hoops, but they still aren't where we see the bigger
delays. And I'm not at all sure elapsed time is what
causes it to be too hard to do minor updates.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/rfc8446/

---

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

>> Requirements RFCs reflect this.  (I suspect Fred Baker still has scars 

Although not comparable with that, IPv6 Node Requirements has been a
saga too. RFC4294 -> RFC6434 -> RFC8504, all of which were out of date
soon after publication.

Also not comparable, https://www.ietf.org/standards/process/informal/
is the direct result of an attempt back in 2005 to catalogue IETF process
documents in one place. Also almost instantly out of date after every
update.

I do want to reiterate: this is a known problem that the IETF has
carefully ducked for many years.

   Brian

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 26 May 2020 10:22:17 +1000

On Tue, May 26, 2020, at 08:57, Michael StJohns wrote:
> My take on this is that its probably as RFC 2026 revision that is 
> needed to address your concerns and that's probably not directly tied 
> to how the RFC editor is constituted. That could come from a WG, or 
> from a design team or even an IAB area.

I can see why it is appealing to say that this is a problem for the streams.

But part of evolution of the series means adapting to the needs of its consumers.  Maybe that means a little bit of a concession toward making it easier/better/etc... for the primary source of RFCs to produce RFCs.

To me, it is clear that the structural constraints imposed by the RFC series - such as immutability - has had a material effect on the way that the inputs to the system are produced.  And of course this is intimately tied up with the choices the IETF makes with respect to things like the stages on the standards track and whatnot.

It is also linked to the way that the formality of the IESG process has evolved over time.

The methods of production for documents also are tied into this.  Those too have changed considerably.

My reading of this is that we do agree that there is a problem here.  What seems in contention is whether the RFC series needs to care; and whether the RFC series might need to be part of any solution.  It is maybe true that some of the problem lies outside of the charter of this group, but I don't think we get to ignore that in the hopes that things will improve by doing so.

---

From: Doug Royer <[email-masked]>
Date: Mon, 25 May 2020 18:23:29 -0600

YES! Not sure how much of this is in scope for this group... maybe my head is in the cloud...

And I would, as mostly an observer and user of the RFC's, it almost appears to me that many are released as theoretical exercises in possibilities, or to get the paper published. I have also wondered if some that author documents that are part of complex sets to go out of their way to keep the clear path to implementations obscure. Why not copy/paste unchanged text from "updates" RFC's? Many do not look like "updates", they look like "replaces except random paragraphs referred to in the most obscure way possible"

For references that are required and separate from the draft specifics, provide a URL to a persistent reference page. Example, rather than referencing TLS RFC #xyz, it would say say something like, https://ietf.org/protocol/TLS/latest.html that points to the latest accepted RFC. I personally do not want to have to become an expert in what the best or deprecated TLS encryption is in order to say "use it". I would think this would reduce both author and editing check times and errors. (My code just links to the latest released lib-openssl, whatever it has, and I do not compare it to TLS RFC's).

I would also like to see "Standards Track" renamed to "Proposal". Until adopted as a standard. I think the word "standard" confuses many. Especially with the complex sets.

I would like each RFC release to be required to include in the document a URL to a persistent page for errata, updates, and updated.  That page would be updated by the authors of the RFC and WG's and a requirement for publication. And they would be required to update the RFC related page with sufficient information to redirect them to the new document. Then the RFC would be persistent and immutable. And people could track the history and latest, whichever they needed.

It would include interrelationship diagrams or descriptions on how they relate, conflict, complement, or compete with other already released RFC's as a separate living document at the time the RFC was published. And could be updated by a similar RFC/WG/individual process. To be updated by errata or the release of related RFC's. I would like this to be a requirement for publication. I am not talking about extending the references. Provide a persistent link, released inside the document. That when looked at, give the entire list on one external page. It should not be hard for authors that are aware of the interrelationships at the time of release to produce that information.

Eliminate, when possible text and references like "foo: like used in RFC-#old paragraph 16.3" when a copy/paste would work. Reduces the documents that need to be read.

On 5/25/20 2:42 PM, John R Levine wrote:
> The RFC series is two things: it's a stable archival set of documents about the technology and history of the Internet, and it's where you find Internet standards and related specs like BCPs. For the vast majority of people likely to look at RFCs, the latter aspect is what matters. If we were just publishing a series of historical papers, that would be fine but there's no way it would merit the amount we spend editing and publishing RFCs.
>
> The problem is that the RFC series does a lousy job of publishing technical specs. If someone wants to write an SMTP server or a DNS server, there's a long list of RFCs that overlap and rewrite each other, there's a zillion errata not part of the RFCs that you need to know to look for and see if they matter, and there is a great deal of folklore to know which RFCs are important and which you can ignore. (For example, RFC 3865 defines an SMTP extension that we knew nobody would ever use other than to make a political point.)
>
> I believe there were two key reasons our specs have succeeded: one is that they do work if you can figure them out, and the other is that unlike most other SDOs we have always given them away for free.  Open access is now increasingly common, so it would be a good idea to make them easier to use or at the least easier to find the ones you need.
>

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 25 May 2020 20:30:41 -0400

I do not think anyone is saying that things will improve (in any regard) 
if we just ignore any specific problem.

However, equally, one of the things that we do know is that if we try to 
solve all problems at once, we get nowhere.  And this group has a 
specific charter.  Which does not include most of the things that you 
listed in the note below.

We all have guesses as to the relationships among causes and effects. 
So?  We could spend a year arguing about that instead of figuring out 
what we want for an RSE and how to get one.  That does not sound like a 
good plan to me.

Yours,
Joel

---

From: Bob Hinden <[email-masked]>
Date: Mon, 25 May 2020 17:43:26 -0700

Brian,

> On May 25, 2020, at 2:56 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Having lived through the process of what became RFC8200, doing RFC1883.3 might solve the easy part of the problem, but I agree that the hard parts are more related to how the IETF standardization process work.    There are a lot of related issues, including:

 - The Errata process is broken (it doesn’t separate the problem and a solution, easy to abuse).
 - Many bis updating document don’t describe the changes very clearly.
 - It’s easier to block something in the IETF than to get it approved.
 - We don’t charter w.g.’s to do maintenance of protocols (with a few exceptions).

I think most of this is out of scope of the rfced-future.   Improving the Errata system would be a good thing for a new RSE to work on.  The rest belongs to the IESG.

Bob

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 May 2020 01:55:05 +0100

On 26/05/2020 01:43, Bob Hinden wrote:
> - The Errata process is broken (it doesn’t separate the problem and a
> solution, easy to abuse). - Many bis updating document don’t describe
> the changes very clearly. - It’s easier to block something in the
> IETF than to get it approved. - We don’t charter w.g.’s to do
> maintenance of protocols (with a few exceptions).
> 
> I think most of this is out of scope of the rfced-future.   Improving
> the Errata system would be a good thing for a new RSE to work on.
> The rest belongs to the IESG.

+0.9, (0.1 being an element of uncertainty:-)

S.

---

From: "John R Levine" <[email-masked]>
Date: 25 May 2020 22:20:00 -0400

> +0.9, (0.1 being an element of uncertainty:-)

If we're considering version numbers or updates by section or applying 
errata, it has to be coordinated by both.

Regards,

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 May 2020 08:16:12 +0200

> Eliminate, when possible text and references like "foo: like used in RFC-#old paragraph 16.3" when a copy/paste would work. Reduces the documents that need to be read.

Beautiful example for why this problem is so hard.

People executing on something like the recommendation above is a big source of interoperability problems.  Because the copy/paste didn’t contain all the information referenced, was rephrased in the editorial process etc., doesn’t get updated together with the original, it tends to create a subculture that is different from the original.
(Read up on software clones to know why this is a such a bad idea in general.)

No, don’t copy/paste, unless the original really only is an inspiration and not a reference.

I note that the discussion here also conflates revisions of documents with “versions” of a specification, which in many cases really are collections of “features”.  Long story that comes up more forcibly when one wants to employ formal description techniques.  My summary of that story is well known to be “versions are stupid”.  (Which we partially seem to know: RFC 8200 does not create IP version 12.)

Which features are “core” to a specification ecosystem is not always decided at the time the features are defined.  Deployment experience, the market, emerging (often unfounded) perceptions etc. also play a role here.  I don’t think we (as an organization) have even started to understand our role in ecosystem management as different from that of a specification writer, even though the successful shepherds of ecosystems certainly have.

I don’t think the RFC editor can even remotely be the person pushing all this evolution forward.

Grüße, Carsten

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 26 May 2020 18:21:09 +0900

> So we publish updates to updates to updates, and almost never do consolidated versions like they are being done in lawmaking.

Yes, true, but in order to do what they do in lawmaking, we would have 
to write the original stuff way differently. In law, at least in the 
jurisdictions I'm familiar with (which is an extremely limited set, and 
by the way, IANAL), every article, and for bigger articles, its 
subarticles, is labeled carefully. There is also a system to insert new 
paragraphs between between existing ones (to insert a new article 
between article 22 and article 23, label it e.g. article 22.bis,...).

Laws that update an existing law are written with exact instructions 
(insert the following article as article X,...), not just a general 
"updates RFC XXXX". Editing a law for a new publication requires great 
care, but not really any kind of judgement like "should extension foo be 
recommended for protocol BAR or not?".

And lots of laws are full of completely outdated stuff, not only the 
language but also in terms of content. Most legislatures don't have the 
time and energy to clean out old stuff, because that doesn't get you 
reelected.

So I don't think we will be able to learn too much from lawmaking.

Regards,   Martin.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 May 2020 01:06:01 +1000

> On 26 May 2020, at 7:21 pm, Martin J. Dürst <[email-masked]> wrote:
> 
> Yes, true, but in order to do what they do in lawmaking, we would have to write the original stuff way differently. In law, at least in the jurisdictions I'm familiar with (which is an extremely limited set, and by the way, IANAL), every article, and for bigger articles, its subarticles, is labeled carefully. There is also a system to insert new paragraphs between between existing ones (to insert a new article between article 22 and article 23, label it e.g. article 22.bis,...).
> 
> Laws that update an existing law are written with exact instructions (insert the following article as article X,...), not just a general "updates RFC XXXX". Editing a law for a new publication requires great care, but not really any kind of judgement like "should extension foo be recommended for protocol BAR or not?".
> 
> And lots of laws are full of completely outdated stuff, not only the language but also in terms of content. Most legislatures don't have the time and energy to clean out old stuff, because that doesn't get you reelected.
> 

Oh, I disagree. Statutory drafting is a beautiful thing to see (at least in some jurisdictions), and we could learn a lot.

Consolidated legislation is merely that which incorporates amendments since it was originally enacted; a Consolidated Act is a piece of legislation that does that with the express intent of combining Acts in a subject area without updating them. No special notation is required, although the legislature does need to do the work (just as we do during a bis, etc.).

Even without action by the legislature, you still have reprinted acts, which the government printer re-issues each time there's an amendment. Their authority varies; in some jurisdictions, they're considered authoritative, whereas in others the primary acts have precedence in case of disagreement.

So, for example, you can see the Biosecurity Act 2015 (Cth) has been amended several times, and each time was reprinted with the appropriate updates.[1]

Yes, this requires some editorial discipline, but it also requires conventions for the editors to follow -- and that's precisely what one should expect the RSE to provide. They need not be pinpoints like section numbers (indeed there are several styles in different jurisdictions); it could be contextual diffs, or xpaths, etc.

In fact, there's some well-founded criticism of legal norms here; Matthew Butterick (both a lawyer and a typographer) urges legal drafters to follow best practice from technical writing in identifying sections.[2]

Cheers,

1. https://www.legislation.gov.au/Series/C2015A00061
2. https://practicaltypography.com/hierarchical-headings.html

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

---

From: "John R Levine" <[email-masked]>
Date: 26 May 2020 11:23:19 -0400

>> So we publish updates to updates to updates, and almost never do 
>> consolidated versions like they are being done in lawmaking.
>
> Yes, true, but in order to do what they do in lawmaking, we would have to 
> write the original stuff way differently. In law, at least in the 
> jurisdictions I'm familiar with (which is an extremely limited set, and by 
> the way, IANAL), every article, and for bigger articles, its subarticles, is 
> labeled carefully. There is also a system to insert new paragraphs between 
> between existing ones (to insert a new article between article 22 and article 
> 23, label it e.g. article 22.bis,...).

Legislatures have an entire staff dedicated to organizing and codifying 
the laws, who have extensive legal experience so they can do so while 
keeping the sense of the laws.

It would be nice if the IETF could do that, but it seems rather unlikely.

Regards,

---

From: "John R Levine" <[email-masked]>
Date: 26 May 2020 11:39:18 -0400

> Oh, I disagree. Statutory drafting is a beautiful thing to see (at least in some jurisdictions), and we could learn a lot.

Take a look at the Consitution of the State of Alabama in the southern US. 
It was enacted in 1901, and has been amended 946 times.  It is 310,000 
words long, of which 90% is the amendments.  It centralizes authority in 
the legislature and gives almost no power to counties which might 
otherwise vote for, you know, inappropriate people.  Much of what would be 
state law in other places is written into the constitution so requires the 
tedious amendment process to change.  (Amendment 946 sets the salary of 
the sheriff of one county.)

I wish this reminded me less of the IETF.

http://alisondb.legislature.state.al.us/alison/codeofalabama/constitution/1901/toc.htm

Regards,

---

From: Doug Royer <[email-masked]>
Date: Tue, 26 May 2020 10:36:43 -0600

> No, don’t copy/paste, unless the original really only is an inspiration and not a reference.

Yes, Until RFC-#old is updated, then the ambiguities double. Must I link to old library? Or when the library I link to is updated, will it use the RFC-#new definition and will my implementation break?

I am not proposing the editor creates them, I am proposing the editor questions them before publication, especially if they seem to be confusing. If the editor or someone in the publication loop knows knows that RFC-#old is being updated, or has an active WG or draft, or when it really should have been a copy/paste.

And yes - what a mess.

There is *no* DNS specification, and that is critical and core to the Internet. Same with SMTP, IMAP, and VoIP, ...

At some point, this is going to be a big problem. And yep, no one is responsible now. But maybe, deliberate questioning some of this practice in drafts before publication will help the WG that will eventually fix it.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 26 May 2020 09:54:08 -0700

John,

> On May 26, 2020, at 8:23 AM, John R Levine <[email-masked]> wrote:
> 
> Legislatures have an entire staff dedicated to organizing and codifying the laws, who have extensive legal experience so they can do so while keeping the sense of the laws.
> 

Don’t forget that you also get police to enforce the laws, and lawyers and courts to interpret them.    Though, I have been in some debates lately on IETF lists that look a lot like the latter :-(

Bob

---

From: Larry Masinter <[email-masked]>
Date: Tue, 26 May 2020 12:21:27 -0700

A little searching turned up:

ISO https://www.iso.org/developing-standards.html
W3C https://www.w3.org/2019/Process-20190301/
IEEE https://standards.ieee.org/develop/index.html
ITU-T https://en.wikipedia.org/wiki/ITU-T
WHATWG https://whatwg.org/workstream-policy

I chose SDOs that I think IETF specs interact with (citations both ways)
I'm sure there are others but these 5 span a range.

None have a role like the RSE in duties and responsibilities.
Each has a notion of what a series and a version is.
They all have some safeguards and document formatting issues and restrictions.

I think before changing the RFC series to be different, it might be worthwhile 
to understand what other SDOs do and the rationale for the differences.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 26 May 2020 22:03:07 +0100

> On 25 May 2020, at 21:42, John R Levine <[email-masked]> wrote:
> 
> I am not proposing specific changes other than to say that the model of RFCs solely as independent immutable documents no longer makes sense.

I strongly disagree.

> While I do not suggest we go to WHATWG style living documents, I do think that for our specifications we need to find a more modern way to collect the material into a small number of places with stable names (perhaps using version numbers like everyone else does), and to make discrete low cost updates as we find errors or make partial updates.

The RFC series provides stable reference documents. The IETF stream does a very bad job of using that series to publish new versions of specifications with consolidated sets of changes.

That is, I agree there’s a problem, but I think that problem is with the way the standards process is managed, not with the RFC series.

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 26 May 2020 22:05:40 +0100

> On 25 May 2020, at 22:12, Carsten Bormann <[email-masked]> wrote:

+1

This is the real problem – not whether the revision to RFC XXXX is called RFC YYYY or RFC XXXX.v2.

Colin

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

---

From: "John R Levine" <[email-masked]>
Date: 26 May 2020 17:09:09 -0400

> This is the real problem – not whether the revision to RFC XXXX is called RFC YYYY or RFC XXXX.v2.

The specs for a mail server or a DNS server are spread across dozens of 
RFCs and errata.

Do you foresee an approval process lightweight enough that we could sweep 
all of the DNS specs into 1034bis or all of the mail specs into 5321bis 
and 5322bis?

Regards,

---

From: Colin Perkins <[email-masked]>
Date: Tue, 26 May 2020 22:24:12 +0100

> On 26 May 2020, at 22:09, John R Levine <[email-masked]> wrote:
> The specs for a mail server or a DNS server are spread across dozens of RFCs and errata.
> 
> Do you foresee an approval process lightweight enough that we could sweep all of the DNS specs into 1034bis or all of the mail specs into 5321bis and 5322bis?

Can we magically solve all the problems with existing documents? No, of course not. To do that would involve a significant effort to either rewrite and consolidate the text into a new document, or to publish a roadmap document (e.g., as was done with RFCs 4614 and 7414). I don’t see how allowing RFCs to be versioned changes that effort in any way.

I believe the IETF could develop a process that would allow us to evolve new specifications in a way that avoids these problems in future, by making it easier to publish -bis RFCs. 

Again: I agree that there is a problem that needs to be solved. I do not agree that mutable RFCs are the right solution.

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

---

From: Adam Roach <[email-masked]>
Date: Tue, 26 May 2020 16:25:22 -0500

> None have a role like the RSE in duties and responsibilities.

That's a really interesting observation. I agree that it's worth teasing 
out what we gain (and what those SDOs miss out on) by having such a 
role. Given that we've seen some proposals for relatively large changes 
(e.g., splitting the RSE's "editorial" role from its "managerial" role), 
I think we're likely to have a hard time preserving those benefits 
unless we have some common understanding of what they are.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 26 May 2020 16:31:37 -0500

> I believe the IETF could develop a process that would allow us to evolve new specifications in a way that avoids these problems in future, by making it easier to publish -bis RFCs.

As a short-term solution, I agree this is something the IETF could do 
unilaterally by producing and approving -bis documents with fewer 
barriers -- this is why I've proposed such a process. I'm not sure this 
is an ideal end-state, though. My proposal is offered as an improvement, 
and one that I would hope would eventually evolve to something more 
sustainable. There's a good chance that any better longer-term solution 
has implications for the RFC series.

/a

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 May 2020 10:40:31 +1200

> all of the DNS specs into 1034bis or all of the mail specs into 5321bis 

This really was addressed in depth quite some years ago:
https://tools.ietf.org/html/draft-ietf-newtrk-repurposing-isd-04

The short answer is no, the process would not be lightweight, and no, the IETF would not sweep all the specs for a complex system into a couple of RFCs. But the IETF would attempt to document the complexity.

And there are examples, which happen to cover part of the mail system:
https://tools.ietf.org/html/draft-ietf-newtrk-sample-isd-00

For our present purposes, IMHO the RFC Series should be willing to support such a mechanism, if and only if the IETF is willing to make the effort.

    Brian

---

From: Doug Royer <[email-masked]>
Date: Tue, 26 May 2020 20:09:13 -0600

> Do you foresee an approval process lightweight enough that we could sweep all of the DNS specs into 1034bis or all of the mail specs into 5321bis and 5322bis? 

As they are spread out across dozens of RFCs, it is not possible to give an accurate answer.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 May 2020 12:40:29 +1000

> It would be nice if the IETF could do that, but it seems rather unlikely.

Let's dig a bit to get a better idea.

In Australia, that function is performed by the Office of Parliamentary Counsel.[1] They currently have a staff of 118,[2] and a budget of AU$17,298,000 (currently just under US$11,500,000; I don't include external revenue because AFAICT that's for services to those other than the legislature).[3] OPC drafted 5,218 pages last year.[4]

However, we have to keep in mind that OPC does much more than edit and publish the legislation; they actually _draft_ it, based upon instructions from lawmakers and in consultation with the relevant government departments. The rough equivalent would be the RFC Editor paying staff to act as editors for WGs.

The relevant part of the OPC for this discussion is their Publications group. They are responsible for:

"""
* publishing policy, including preparation of sunsetting and bulk repeal lists and managing the Legislation Register Helpdesk;

* preparing compilations, operating the Legislation Register, and publishing and making arrangements for the printing of Commonwealth legislation Gazettes;

* proofreading and editorial checking of all draft legislation drafted in OPC; and

* the development and operation of the Legislation Register website.
"""[7]

This sounds very analogous to what the RFC Editor does, with some additions like providing compilations. 

The Publications group published 30,756 pages of legislative instruments and 287,116 pages of Act compilations last year, along with approximately 70,000 pages of other document types.[8]

Apparently, this group has about 40 staff.[9] While that's 34% of the staff in OPC, they're not legally trained drafters (50 staff), so at a rough guess they account for 20% of the budget -- say, US$2,300,000.

In comparison, we currently spend over US$1,350,000[10] to edit and publish just under 7,000 pages last year[11], although it previous years it was closer to 5,000 pages.

So their budget for that role is about 75% greater than ours, and they publish more than 50x the number of pages.

This is all back-of-an-envelope, of course, and you have to account for things like the level of effort required to edit a document from a professional drafter vs. one of our WG participants. That said, considering that they also provide consolidated legislation, have a helpdesk and, well, it's a _country_, I think that's pretty good value.

Based upon that very rough estimate, I don't think it's outside the realm of possibility that this sort of service could be provided. The question is defining what we want and how much resource we're willing to devote to it; as has been said before, other SDOs get by without any RFC Editor-like function, and don't have any dedicated budget for it. If we can find US$1,300,000 for the services we currently consume, maybe spending a bit more to get truely "full" service is the right thing to do. Or maybe refocusing to get what we want from it is the right thing. 

These are the kinds of conversations I'd expect an RSE to be leading the community through.

Cheers,

P.S. If you look at nothing else, I'd encourage folks to look at the OPC annual report;[12] I'd love to see this level of detail from future RFC Editors.

1. <https://www.opc.gov.au>
2. <https://budget.gov.au/2019-20/content/bp4/download/bp4_10_staffing.pdf> pg 170
3. <https://budget.gov.au/2019-20/content/bp4/download/bp4_05_art.pdf>pg 46
4. <https://www.opc.gov.au/sites/default/files/s19tq106.v07_11.pdf> pg 2
7. <https://www.opc.gov.au/sites/default/files/s19tq106.v07_11.pdf> pg 10
8. <https://www.opc.gov.au/sites/default/files/s19tq106.v07_11.pdf> pg 35
9. <https://www.opc.gov.au/about-opc/our-staff>
10. <https://ietf.org/media/documents/IETF_2020_Public_Budget.pdf>
11. <https://www.rfc-editor.org/in-notes/IETFreports/ietf107.pdf>
12. <https://www.opc.gov.au/sites/default/files/s19tq106.v07_11.pdf>

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 May 2020 01:36:14 -0400

--On Monday, May 25, 2020 16:42 -0400 John R Levine
<[email-masked]> wrote:

>...
> The problem is that the RFC series does a lousy job of
> publishing technical specs. If someone wants to write an SMTP
> server or a DNS server, there's a long list of RFCs that
> overlap and rewrite each other, there's a zillion errata not
> part of the RFCs that you need to know to look for and see if
> they matter, and there is a great deal of folklore to know
> which RFCs are important and which you can ignore. (For
> example, RFC 3865 defines an SMTP extension that we knew
> nobody would ever use other than to make a political point.)
> 
> I believe there were two key reasons our specs have succeeded:
> one is that they do work if you can figure them out, and the
> other is that unlike most other SDOs we have always given them
> away for free.  Open access is now increasingly common, so it
> would be a good idea to make them easier to use or at the
> least easier to find the ones you need.
> 
> I am not proposing specific changes other than to say that the
> model of RFCs solely as independent immutable documents no
> longer makes sense. While I do not suggest we go to WHATWG
> style living documents, I do think that for our specifications
> we need to find a more modern way to collect the material into
> a small number of places with stable names (perhaps using
> version numbers like everyone else does), and to make discrete
> low cost updates as we find errors or make partial updates.

Disclaimer: I have not been able to read this list between the
beginning of the weekend and the last hour or so, have not read
all of every thread (and doing so and still getting on the call
is hopeless).  However because I have a slightly different
perspective than others who have posted, even those I agree
with, some comments that may be helpful.

First, what I recall from conversations with Jon Postel a _very_
long time ago, is that when the IETF started thinking of itself
as a standards body in addition to (or rather than) an
engineering one (it is not accidental that we are not the
"Internet Standards Task Force" or even the "Internet Standards
Organization")  it was not completely obvious that standards
should be published in the RFC Series.  The obvious choice,
perhaps, but not the only possible one.  If I correctly recall
what Jon said during those conversations, at least one of the
issues was whether an archival document series that had evolved
to document the evolutionary history of the Internet and its
protocols was the right place to publish standards.  That does
not prove much today but it identifies several things that may
be worth keeping mind in addition to this being a very old
topic, not a new one: One is that even if the decision to
publish IETF standards-track products in the RFC Series was the
right one then, it may not be the right decision today.  A
second was that it was an IETF decision, not an RFC Editor one.
In principle, the IETF could reverse that decision at any time
or, for example, decide that only exceptionally stable
specifications, perhaps at Internet Standard level, should be
published as RFCs and everything else should live as an I-D,
perhaps with some I-Ds being officially designed as "IETF
endorsed" or "WG endorsed" rather than documents that can be
posted by anyone with no requirement for community review.
While I would hope the RSE would be given the opportunity to
voice an opinion, it is clear to me that the IETF could make any
decision of that type on its own (modulo a consultation with the
IETF Trust if that were needed), whether the RSE liked it or not.

Finally, we've been down this path before.  Once upon a time,
the RFC Editor had authority to group documents by assignment of
BCP and STD (and FYI) numbers.  The IESG took that away (IMO for
good reason).  In chartering NEWTRK, the IESG and the IETF
community concluded (and it seemed obvious at the time) that
building roadmaps among related standards, making Applicability
Statements in the tradition of RFC 1122 and 1123, or grouping
documents, especially standards track documents, in other ways
were an IETF responsibility.  For whatever it is worth, there
were discussions at the time as to whether roadmap documents
that would explain relationship and tell people what they needed
to read and how things fit together belonged in the RFC Series.
Given comments others have made about how much work it takes to
build and reach consensus on such documents, it is perhaps also
worth noting that, IIR, one of the reasons the IESG at the time
gave for refusing to consider the primary NEWTRK outputs was
that developing and, especially maintaining, such documents
would just be too much work (other NEWTRK efforts, including the
successful activity described as getting rid of the cruft (see
RFC 4450), further reinforce the sense that this is a discussion
about IETF issues, not RFC Editor ones -- the days in which the
RFC Editor could, on their own, reclassify a document as
Historic are decades in the past.

So, while I would love to see the IETF start an effort along the
lines of NEWTRK (or restart that one with the work that was
abandoned), and, ideally, expand its charter to make finer
distinctions about what IETF materials should, or should not, be
in the RFC Series, there is only one, very narrow, sense in
which I can imagine its being an appropriate topic for this
group.  That sense is that, if all or some IETF standards track
documents were pulled out of the Series, the workload and scope
of the RFC Editor Function would go down considerably.  Even
then, that would be more of an issue for the staffing required
in the Production Center than something that would change the
RSE's job description or the RFC Editor model significantly.

best,
  john

p.s. I'm not going to go into it because it would make this note
much longer and I think this is the wrong forum.  However there
is lots of experience with the advantages and disadvantages of
standards documents that are altered or updated rapidly and as
issues are discovered.  If that is a discussion the community
wants to have, it would be good to study the experiences enough
that we don't need to replicate the mistakes and learning
experiences of others.  As one example, without some special
adaptations they work very well when the "standards" are really
evolving memoranda of understanding among all of the
implementers (or all of the implementers who are deemed to
count) but less well when the target is interoperability between
independently-developed implementations.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 27 May 2020 09:54:29 +0200

It seems to me that in this conversation there are two groups we want to optimize for:

The people who are attempting to update the document
The readers

Thus far, the conversation has focused on the first group.  Earlier, it was pointed out that to implement a standard like DNS or TCP requires reading quite a lot of RFCs.  This was indeed what NEWTRK set out to address.  If we recreate NEWTRK without understanding why it failed, we are very likely to get the same results.  This raises several other questions:

Is this just a stream problem?  I don’t see how the answer to this question could be “yes”.  How we group information has to be in some way reflected in how the information is presented to the user- its editorial form.
If is not just a stream problem, then who initiates change?  Who approves change?  This idea of a working group is an interesting one, but there must be a caution: our typical working group structure could allow filibustering.  Is that desirable?  Stability says yes, ability to evolve says no (when viewed from extremes).

Eliot

> On 26 May 2020, at 23:09, John R Levine <[email-masked]> wrote:
> 
> Please consider the environment before reading this e-mail. https://jl.ly--

---

From: "John R Levine" <[email-masked]>
Date: 27 May 2020 10:53:07 -0400

On Wed, 27 May 2020, Mark Nottingham wrote:
> In Australia, that function is performed by the Office of Parliamentary Counsel. ...

In the US it's the Office of the Law Revision Counsel in the House of 
Representatives, with a budget of $3.4 million.  Each state has a similar 
office.

The idea of paying someone to codify RFC standards is intriguing.  I see 
two main challenges: one is to find someone with the combination of 
technical and editing skills to do the work, the other is whether the IESG 
and WGs would accept it.

Regards,

---

From: Doug Royer <[email-masked]>
Date: Wed, 27 May 2020 16:07:36 -0600

On 5/27/20 1:54 AM, Eliot Lear wrote:
>   * The people who are attempting to update the document
>   * The readers
>
The standard is becoming the existing implementations, not the documents, as almost no one can read the DNS (and some others) documents in any succinct way. You find open source code and then look for any RFC that describes each feature.

Some discussion on this list has been about paying for it. Perhaps for just complex sets, it could be time to consolidate them into one (or few) documents. Unless you can get some volunteers.

Not really an editor function. And no WG tasked with this kind of thing.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 28 May 2020 10:35:41 +1000

> On 28 May 2020, at 12:53 am, John R Levine <[email-masked]> wrote:
> 
> The idea of paying someone to codify RFC standards is intriguing.  I see two main challenges: one is to find someone with the combination of technical and editing skills to do the work, the other is whether the IESG and WGs would accept it.

I think at least at first, it'd need to be opt-in. And the RFC Editor would need to provide guidelines, along the lines of "if you want your RFC to be consolidated, do it like _this_..." We'd also need to figure out how they'd be presented / identified, and what takes precedence in case of disagreements. Provided that it's well-thought-out, I'd think that the RPC could do this to a large degree (predicated mostly upon reasonable inputs).

My main point, though, was that if we have an RSE role, this is the sort of thing they should be looking at, talking to the community about, and potentially doing.

Cheers,

---

From: Russ Housley <[email-masked]>
Date: Fri, 29 May 2020 16:03:27 -0400

> On May 26, 2020, at 3:21 PM, Larry Masinter <[email-masked]> wrote:
> 

My IEEE experience shows otherwise.

They have a style guide: https://mentor.ieee.org/myproject/Public/mytools/draft/styleman.pdf <https://mentor.ieee.org/myproject/Public/mytools/draft/styleman.pdf>

When the draft standard finishes the ballot process, it goes to a professional editor, and then back to the authors to make sure the meaning did not change (very similar to AUTH48).

So, while there not be a named individual performing an  RSE-like role, all of the tasks are happening within the process.

Russ

---

From: Adam Roach <[email-masked]>
Date: Fri, 29 May 2020 15:14:35 -0500

On 5/29/2020 3:03 PM, Russ Housley wrote:
> They have a style guide: 
> https://mentor.ieee.org/myproject/Public/mytools/draft/styleman..pdf 
> <https://mentor.ieee.org/myproject/Public/mytools/draft/styleman.pdf>
>
> When the draft standard finishes the ballot process, it goes to a 
> professional editor, and then back to the authors to make sure the 
> meaning did not change (very similar to AUTH48).
>
> So, while there not be a named individual performing an  RSE-like 
> role, all of the tasks are happening within the process.

What you've described is an RPC role. I don't see an RSE role in your 
description. The presence of a style guide implies that there might be 
some entity that does RSE-ish things (and that guide does seem to 
parallel RFC 7322 in its function) -- do you know how it was created and 
how it is maintained?

/a

---

From: Michael StJohns <[email-masked]>
Date: Fri, 29 May 2020 16:15:53 -0400

On 5/29/2020 4:03 PM, Russ Housley wrote:
>
>
>> On May 26, 2020, at 3:21 PM, Larry Masinter <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
To expand on this - the RFC series - for better or worse - contains 
quite a lot of non-standards track documents: IAB reports, IAB policy 
statements, IRTF research and standards-lite documents, Independent 
stream republications, alternate protocols, and the odd policy screed, 
as well as the April fools RFCs.   If - as some people have argued for - 
this was only a standards series, then we might get away with just a 
professional editor with a style guide.  Personally I think we need an 
identified RSE to balance competing interests amongst all of the various 
author sources,  and I don't think that you can do that mechanically 
with fungible professional editors.

Mike

---

From: Russ Housley <[email-masked]>
Date: Fri, 29 May 2020 16:32:45 -0400

> On May 29, 2020, at 4:14 PM, Adam Roach <[email-masked]> wrote:
> 
> What you've described is an RPC role. I don't see an RSE role in your description. The presence of a style guide implies that there might be some entity that does RSE-ish things (and that guide does seem to parallel RFC 7322 in its function) -- do you know how it was created and how it is maintained?
> 
I think it is a mix, bit just RPC.

The style guide is clear maintained.  It lists updates since the previous version.  I do not know the process that is used, but there is a consistency across the IEEE standards produced by this style guide.

Russ

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 May 2020 11:49:29 +1200

On 30-May-20 08:32, Russ Housley wrote:
> 
> 
>> On May 29, 2020, at 4:14 PM, Adam Roach <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>> They have a style guide: https://mentor.ieee.org/myproject/Public/mytools/draft/styleman.pdf
>>>

As it happens, I've just gone through the IEEE process for a journal article, which is of course quite distinct from their standards publication process. So I've had to deal with the journal's editor and anonymous reviewers (rather like dealing with the ISE) and then with the copy-editing function (rather like dealing with the RPC), all mediated by some monstrosities called the "Author Center" on "ScholarOne Manuscripts", and later the "IEEE Author Gateway", both of which were much more complicated than the IETF datatracker. These are clearly IEEE-wide mechansims. There *must* be a presiding intelligence above this system, but Google seems unable to find it.

    Brian