Subject: [Rfced-future] On the question of a living series

From: Eliot Lear <[email-masked]>
Date: Tue, 26 May 2020 09:13:54 +0200

Hi everyone,

I am hearing several different points of view on this matter:

The series is difficult to read because one has to traipse through a large number of documents, and this is a problem the RSE should take on.
This is a problem for the IETF and the RSE shouldn’t be involved.
This is a shared problem between the RSE and the streams
This is so hard a problem we shouldn’t touch it.
What is “archival”?

I wonder if there is consensus around something close to the following view:

The RFC Series Editor is responsible for specifying editorial methods and the necessary architecture by which RFCs may be amended in a manner that is seen as useful to the various stream managers, with an eye toward readability and referential integrity (add other stuff here).  It is up to the stream owners to set policies around approving such amendments.

This isn’t all that far from what we have today with the errata process, but is more specific than what is in our documents today.  The only question is really how the rendering of changes should take place.

Some jobs may be too big to handle simple edits.  I couldn’t imagine, for instance, that TLS 1.3 would be a bunch of edits on top of TLS 1.2.  But the streams would largely need to make that call.  Interoperability concerns would also largely fall to the streams, although the RSE might need to provide mechanisms to warn about pitfalls.

Thoughts?

Eliot

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 26 May 2020 17:36:11 +1000

To me, the underlying issue here is that the unit of archiving is done by RFC number -- i.e., once you know the number, you know the octets underneath it don't change.

Perhaps the most extreme example is RFC7159, which only differs from RFC7158 in its publication date. 

That's not in itself bad, but unfortunately that same identifier has become by far the most powerful identifier for the work -- to the point where efforts to introduce new layers of identification (e.g., STD) fail because they don't have the same traction. It's as if a software project decided to version its software with commit hashes, and those hashes were used not only to represent the version of the software, but its very identity (e.g., RFC2616 instead of HTTP; b3ec76308b319c7dc660f383ccad803e365de1090c0d2858d85b29e0654f3c00 instead of Firefox or even Firefox 76).

In other words, we seem to have built a worldwide brand around a low-level revision identifier, and yet failed to introduce a normal way to refer to the product of our work at any coarser granularity -- partially *because* that brand is so successful. 

The IETF community absolutely needs to be involved in addressing this, but I can't imagine it being done without coordination with (and by?) the RSE, if we have such a function.

> On 26 May 2020, at 5:13 pm, Eliot Lear <lear=[email-masked]> wrote:
> 
> Hi everyone,
> 
> 	• The series is difficult to read because one has to traipse through a large number of documents, and this is a problem the RSE should take on.
> 	• This is a problem for the IETF and the RSE shouldn’t be involved.
> 	• This is a shared problem between the RSE and the streams
> 	• This is so hard a problem we shouldn’t touch it.
> 	• What is “archival”?
> 
> 	• The RFC Series Editor is responsible for specifying editorial methods and the necessary architecture by which RFCs may be amended in a manner that is seen as useful to the various stream managers, with an eye toward readability and referential integrity (add other stuff here).  It is up to the stream owners to set policies around approving such amendments.
> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 May 2020 09:59:56 +0200

> In other words, we seem to have built a worldwide brand around a low-level revision identifier, and yet failed to introduce a normal way to refer to the product of our work at any coarser granulari…

There is no problem that can’t be solved with another layer of indirection.

We already have RFCs that describe mutable information, such as IANA registries.

Why don’t we do the same for curated ecosystems?

We can do that experiment within the existing RFC system, and slowly migrate any successes into being core elements of the RFC system.  I’d rather do that than damage the RFC system by a period of instability (inevitably guided by process confabulation).

Again, the actual work is setting up the processes in the IETF stream, and getting the energy up to execute them.  I’m a bit more optimistic here than I probably should be — hey, we even managed to have a git WG.

Grüße, Carsten

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 May 2020 10:12:22 +0200

Hi Mark,

> On 26 May 2020, at 09:36, Mark Nottingham <[email-masked]> wrote:
> 

Perhaps this goes to what the canonical representation is, and whether the meta data can change so that editorial changes can be reflected.  What I am wondering is whether we can agree that this is something that the RSE should take responsibility for, without actually trying to solve the problem here.  It is for sure a meaty problem and goes right to the heart of a question that I know is important to you: what sort of skills would an RSE need to find a successful path here?

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 26 May 2020 11:56:45 +0100

On 26/05/2020 09:12, Eliot Lear wrote:
> what sort of skills would an RSE need to find a successful path here?

That's a good question, definitely in scope here. And the
2020 answer may differ a good bit from what it'd have been
a decade ago.

S.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 May 2020 08:18:33 -0400

I am uncomfortable with the assumption that "RFCs may be amended".  That 
opens the door to much larger changes than eratta, which is not 
something I want, nor something on which I think we have agreement.

Yours,
Joel

On 5/26/2020 3:13 AM, Eliot Lear wrote:
>   * The series is difficult to read because one has to traipse through a
>     large number of documents, and this is a problem the RSE should take on.
>   * This is a problem for the IETF and the RSE shouldn’t be involved.
>   * This is a shared problem between the RSE and the streams
>   * This is so hard a problem we shouldn’t touch it.
>   * What is “archival”?
> 
> 
>   * The RFC Series Editor is responsible for specifying editorial
>     methods and the necessary architecture by which RFCs may be amended
>     in a manner that is seen as useful to the various stream managers,
>     with an eye toward readability and referential integrity (add other
>     stuff here).  It is up to the stream owners to set policies around
>     approving such amendments.
> 
> 
> This isn’t all that far from what we have today with the errata process, 
> but is more specific than what is in our documents today.  The only 
> question is really how the rendering of changes should take place.
> 
> Some jobs may be too big to handle simple edits.  I couldn’t imagine, 
> for instance, that TLS 1.3 would be a bunch of edits on top of TLS 1.2. 
>   But the streams would largely need to make that call. 
>   Interoperability concerns would also largely fall to the streams, 
> although the RSE might need to provide mechanisms to warn about pitfalls.
> 
> Thoughts?
> 
> Eliot
> 
>

---

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

>something I want, nor something on which I think we have agreement.

I was actually thinking of version numbers or number+date, but based
on the discussion so far, we don't seem to have strong agreement
either way.

FYI, as we shake out the changes to the v3 XML vocabulary, it is
likely that we will want to republish the existing XML RFCs with
different coding to match the final vocabulary. The text wouldn't
change, just the codes.  Is that an amendment?

R's.
John

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 May 2020 13:45:24 -0400

I do not know of any procedure or agreement to change the XML for 
existing RFCs.  The agreements to date do include provisions for 
republishing rendered versions.  But if you claim to need to change the 
XML, as far as I know that would need to be a new RFC.  Could we create 
a simpler review procedure than IETF last call to confirm that you havbe 
not changed the content?  Probably.   But even a full RSE would not have 
the authority to do that unilaterally.

Yours,
Joel

---

From: "John R. Levine" <[email-masked]>
Date: 26 May 2020 13:56:28 -0400

> I do not know of any procedure or agreement to change the XML for existing 
> RFCs.  The agreements to date do include provisions for republishing rendered 
> versions.  But if you claim to need to change the XML, as far as I know that 
> would need to be a new RFC.

If that is true, we need to fix it because putting the XML changes through 
anything beyond a lightweight technical review of the XML would be a huge 
waste of everyone's time.

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: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 May 2020 14:12:31 -0400

As far as I know, what I stated is the rules.  And while creating a 
solution for the problem you face sounds reasonable, it also is outside 
the scope of this email list.  It seems that you need to talk to the 
stream heads.

Yours,
Joel

On 5/26/2020 1:56 PM, John R. Levine wrote:
>> republishing rendered versions.  But if you claim to need to change 
>> the XML, as far as I know that would need to be a new RFC.
> 
> If that is true, we need to fix it because putting the XML changes 
> through anything beyond a lightweight technical review of the XML would 
> be a huge waste of everyone's time.
> 
> Regards,

---

From: Eliot Lear <[email-masked]>
Date: Tue, 26 May 2020 20:22:06 +0200

Joel

> On 26 May 2020, at 20:12, Joel M. Halpern <[email-masked]> wrote:
> 
> As far as I know, what I stated is the rules.  And while creating a solution for the problem you face sounds reasonable, it also is outside the scope of this email list.  

Yes.

> It seems that you need to talk to the stream heads.

This group has the ability to decide who decides that in the future.  We can decide to leave it as is, or to change it.

Eliot

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 May 2020 20:30:47 +0200

On 26.05.2020 19:45, Joel M. Halpern wrote:
> ...

Disagreed.

There was no claim that RFC 7991 was the final word on v3.

See it this way: we convert to the final V3 vocabulary (7991bis), and
re-render. If the text content of the rendered output changes, something
might be wrong.

Best regards, Julian

---

From: Christian Huitema <[email-masked]>
Date: Tue, 26 May 2020 11:18:22 -0700

> On May 26, 2020, at 10:56 AM, John R. Levine <[email-masked]> wrote:
> 
> 
>> 
>> I do not know of any procedure or agreement to change the XML for existing RFCs.  The agreements to date do include provisions for republishing rendered versions.  But if you claim to need to change the XML, as far as I know that would need to be a new RFC.
> 
> If that is true, we need to fix it because putting the XML changes through anything beyond a lightweight technical review of the XML would be a huge waste of everyone's time.

Or we could finesse the rules, leave the old xml alone, and pipe it through a conversion script to the new XML before rendering. That would respect the letter of the requirements. Whether that's a good idea is another question.

-- Christian Huitema

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 May 2020 14:51:00 -0400

Actually, our statement is that the XXML form of the RFCs is the 
immutable archival form.  that does not give us any room to modify it. 
If we want a new archvial version (and once we have a new v3, I think we 
do want such) then we need to produce it properly.

For Independent Stream RFCs, I think that could be done by the ISE 
picking reviewers to confirm that there is no content change.
For the IRTF stream documents, the IRTF chair can likely figure out a 
lightweight procedure.

For the IETF stream, the IESG will have to get community agreement for 
some sensible lightweight procedure.

If John considers this necessary and important (and it sounds like he 
does) then he needs to make sure that a proposal for such gets discussed 
with the IESG, and then with the community.  Somewhere other than 
rfced-future.

(Sorry to belabor this Eliot.)

Yours,
Joel

---

From: Julian Reschke <[email-masked]>
Date: Tue, 26 May 2020 21:24:28 +0200

> do want such) then we need to produce it properly.

The XML format currently used doesn't have a spec. It adds undocumented
features, and some of what RFC 7991 says isn't implemented as specced.

This *could* be ok for archival, once it's documented.

We're currently trying to reduce the gap between reality and
implementation
(<https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis)>, but it's
hard to do lacking feedback from essentially everybody else.

Best regards, Julian

---

From: "John R. Levine" <[email-masked]>
Date: 26 May 2020 15:36:14 -0400

> Or we could finesse the rules, leave the old xml alone, and pipe it through a conversion script to the new XML before rendering. That would respect the letter of the requirements. Whether that's a…

That seems like a really bad message to send to our successors, that our 
ossified processes forced us to do a needless kludge.

Regards,

---

From: Michael StJohns <[email-masked]>
Date: Tue, 26 May 2020 15:49:53 -0400

On 5/26/2020 3:36 PM, John R. Levine wrote:
>> Or we could finesse the rules, leave the old xml alone, and pipe it 
>> through a conversion script to the new XML before rendering. That 
>> would respect the letter of the requirements. Whether that's a good 
>> idea is another question.
>
> That seems like a really bad message to send to our successors, that 
> our ossified processes forced us to do a needless kludge.
>
> Regards,

I've been watching this thread and wasn't involved in any of the current 
issue, but as I understand it:

There was a point in time where the archival format was text. And then 
at a specific date and time we declared that the XML was now the 
archival format (the transition point).  And at a later date and time we 
realized there were flaws in the XML that needed correction.

My question:  Why don't we just erase the transition point, render the 
documents in text as the archival formatbetween that point and a future 
point where we're happy with the XML,  and set a new transition point 
when we're convinced we've worked out the kinks?    No need for 
kludges.  Of course, I don't know how to estimate the work factor of 
this approach so it may be a non-starter.

Mike

---

From: "John Levine" <[email-masked]>
Date: 26 May 2020 16:47:30 -0400

In article <[email-masked]> you write:
>when we're convinced we've worked out the kinks?

There's a great deal of baby in that bathwater. The changes to the XML
we are likely to need are not large, and the semantic info in the XML
is quite useful.

Also, the v3 text output is somewhat different from the old page
images. It is not divided into 60 line pages and it's in UTF-8 with a
BOM at the top. If we're going to change something, making minor
changes in the XML is the smallest useful change.

---

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

[As an individual]

> On 26 May 2020, at 08:13, Eliot Lear <lear=[email-masked]> wrote:
> 
> Hi everyone,
> 

I do not believe allowing amendments to published RFCs is desirable (with the possible exception: to fix bugs in the XML schema, provided there’s no content change).

Having the RFC Editor develop better processes for collecting, verifying, surfacing, and displaying errata seems useful. 

Having the community develop lighter-weight processes for producing -bis RFCs seems useful. 

But I do not believe amending published RFCs is desirable.

Colin

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

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 26 May 2020 23:58:48 +0200

On 2020-05-26, at 22:47, John Levine <[email-masked]> wrote:
> it's in UTF-8 with a
> BOM at the top.

Fortunately, that doesn’t appear to be true (or we would have larger problems).

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 May 2020 00:01:30 +0200

> Fortunately, that doesn’t appear to be true (or we would have larger problems).

(Sorry, misread “it” as the XML files, which of course are in UTF-8 and not BOMmed.)

I think it would useful to have UTF-8 files of the text version as well, preferably with page breaks.

Grüße, Carsten

---

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

> hard to do lacking feedback from essentially everybody else.

If there is a decision to formally update the v3 spec (that would be
Updates: 7991) then we could decide to retroactively update the older
XML files if we wanted to. It's our choice, because the entire dogma
that RFCs are immutable is *our* dogma and we can change it if we
want to. Or we could declare a new version. But that would be a bit
weird, since as Julian points out, we aren't actually using the RFC7991
spec anyway. So all the recent RFCs have been issued in a formally
undocumented format.

(As far as I'm concerned, the current spec is always whatever the current
conversion tool accepts.)

  Brian, certified pragmatist.

---

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

>> it's in UTF-8 with a BOM at the top.
>

I can assure you that the published copies of rfc8650.txt through 
rfc8781.txt are in UTF-8 with BOMs at the top.  That's what the the spec 
in RFC 7990 says, that's what they are.

Regards,

---

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

> I think it would useful to have UTF-8 files of the text version as well, preferably with page breaks.

My experimental result is that the "v3-plaintext" format is UTF-8, has no BOM and does have pagination.

   Brian

---

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

> in RFC 7990 says, that's what they are.

import time
print("BOM remover")
fn=input('File name: ')
try:
    file1 = open(fn+".txt", "rb")
except:
    try:
        file1 = open(fn, "rb")
    except:
        print("File name error")
        time.sleep(5)
        exit()

chunk=file1.read(1024)
if chunk[0:3] == b'\xef\xbb\xbf':
    chunk=chunk[3:]
    file2=open(fn+".nob", "wb")
    while chunk:
        file2.write(chunk)
        chunk=file1.read(1024)
    file2.close()
    print("Rewritten without BOM as",fn+".nob")
else:
    print("No BOM found")    
file1.close()
time.sleep(5)

---

From: "John Levine" <[email-masked]>
Date: 26 May 2020 20:41:48 -0400

>My experimental result is that the "v3-plaintext" format is UTF-8, has no BOM and does have pagination.

For I-D's, yes, not for RFCs.

R's,
John

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 May 2020 09:49:45 +0200

> For I-D's, yes, not for RFCs.

(I’ll follow along as long we are on this tangent, which I seem to have split off accidentally:)

This is one of the interesting symptoms of the confusion of RFCXML as an authoring format and RFCXML as the archival format.  Obviously, the tool is giving the authors what they (OK, many of them) want during authoring.  For the archival RFC version, the tool then switches to a (text file) format that is less concerned about the wishes of the authors.  This might be a nice example to discuss “independence” — except I have no idea where that deviation actually originated, and who might have browbeat whom here.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Wed, 27 May 2020 09:57:58 +0200

> This is one of the interesting symptoms of the confusion of RFCXML as an authoring format and RFCXML as the archival format.  Obviously, the tool is giving the authors what they (OK, many of them)…

xml2rfc, when producing TXT RFCs, just implements what RFC 7994
("Requirements for Plain-Text RFCs") says...

Best regards, Julian

---

From: Russ Housley <[email-masked]>
Date: Thu, 28 May 2020 16:47:44 -0400

> On May 26, 2020, at 5:14 PM, Colin Perkins <[email-masked]> wrote:
> 
> [As an individual]
> 
>> On 26 May 2020, at 08:13, Eliot Lear <lear=[email-masked] <mailto:lear=[email-masked]>> wrote:
>> 
>> Hi everyone,
>> 

+1

> But I do not believe amending published RFCs is desirable.

Right.  The inline errata are an improvement, and it would be interesting to do even better.

Russ

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 29 May 2020 09:58:29 +1000

> On 29 May 2020, at 6:47 am, Russ Housley <[email-masked]> wrote:
> 

Could you give us some indication as to why you feel this way -- e.g., what would be impacted? I fear we're falling into the habit of just stating our preferences and expecting Eliot to tally the votes...

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 May 2020 13:13:33 +1200

> Could you give us some indication as to why you feel this way -- e.g., what would be impacted? I fear we're falling into the habit of just stating our preferences and expecting Eliot to tally the v…

I'd add a specific question to that: does the objection extend to a simple versioning mechanism, such as RFC8200.1 for RFC8200 plus accumulated errata? (Assuming that RFC8200 is also kept around, of course.)

     Brian

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 29 May 2020 03:15:08 +0100

Hiya,

Colin will answer himself when he does, but it strikes me
that maybe the question exposes a bit of a gap in what we
each are considering...

On 29/05/2020 02:13, Brian E Carpenter wrote:
>>>> I do not believe allowing amendments to published RFCs is
>>>> desirable (with the possible exception: to fix bugs in the XML
>>>> schema, provided there’s no content change).
>>> 
>>> +1
>> 
>> Could you give us some indication as to why you feel this way --
>> e.g., what would be impacted? I fear we're falling into the habit
>> of just stating our preferences and expecting Eliot to tally the
>> votes...
> 
> I'd add a specific question to that: does the objection extend to a
> simple versioning mechanism, such as RFC8200.1 for RFC8200 plus
> accumulated errata? (Assuming that RFC8200 is also kept around, of
> course.)

My personal impression is that the vast majority of
correctly approved errata are pedantic and no more.
Given that's what I think, I've not been motivated to
check it out in detail;-)

So I don't think analysis of the living-document-RFC
vs. immutable-text-RFC via facts-about-errata is that
useful. I reckon the "where's the DNS spec" question
is more likely to lead us in a useful direction (should
one exist, and I'm not yet convinced one does).

Cheers,
S.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 29 May 2020 12:31:24 +1000

Hi Stephen,

> On 29 May 2020, at 12:15 pm, Stephen Farrell <[email-masked]> wrote:
> 

Personally, that's my interest as well (s/DNS/HTTP/ of course).

E.g., people still widely refer to RFC2616 as the authoritative reference for HTTP, even though we obsoleted it in 2014, and have been working on something to obsolete that more recently.

The best we can do is to summarise the currently in-effect specs, like this:
  https://httpwg.org/specs/
... but that doesn't have anything close to the mindshare of an RFC number.

This is why I suggested expanding the idea of an RFC number to include tokens to identify specifications at this level -- i.e., not revisions, but conceptual documents. So we could have an RFC-HTTP that identified the core spec, and an RFC-HTTP11 to identify the in-force document for that version of the wire protocol. Currently, people conflate document versioning with protocol versioning, and that's problematic. The hope here would be that the RFC prefix would be familiar enough to let these identifiers catch on (unlike STD and the like), and moving away from a linear, numeric identifier series would help people find the right documents.

That's just an idea, and I'm not fixated on that particular solution; the problem is what deserves our attention.

Cheers,

---

From: "John Levine" <[email-masked]>
Date: 28 May 2020 22:48:20 -0400

>check it out in detail;-)

Having watched the reports go by for the past four months I agree that
most of them are nits but there are some that correct significant
technical or editorial errors in the document, to the extent that if
you do what the RFC says without also consulting the errata, you'll
get it wrong.

R's,
JOhn

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 May 2020 23:15:12 -0400

I am uncomfortable with any process where the content of the document 
with a given explicit and agreed name can change.
I don't care whether the new name is a new RFC number, or the same 
number with some modieirs, or some other new name.
I can even live with the IEEE approach where there is a base number and 
a date.  And then insistence that any formal reference has to actually 
use the date.

What I do not want is a situation where people expect "BGP" to be a 
well-defined standard which you can name that way.  (Yes, people will do 
so in conversation.  And in marketing materials.)  But as a vendor, I 
expect to ahve to be clear about exactly what I implement.  And I expect 
my customers to ahve to be clear about what they want me to support. 
Saying "supprot MPLS", or even "support SR-MPLS" does not work.

As a lesser but important matter, I do not want revision of a 
specification conflated with the problem of determining what all the 
related specs are.  Sorry, no, we can not produce a standard for 
Internet EMAIL.  I would like to see us tackle as a separate matter how 
the heck give folks that information.  But it is NOT the same problem.

And I would suggest that at least in the portions of the IETF I live in 
(primarily internet and routing) changing the way we number revisions is 
not likely to change the pace of them.  8200 took a long time because 
there were a lot of hard debates as to what it should say, not because 
it had to be a new RFC.

And the only part of this that is relevant to rfced-future is the 
question of who should be driving this.  In my personal reading, these 
topics are IETF topics.  One would hope that the RSE (or whatever we 
call the directional leadership of the RFC series) would be involved. 
But until there is IEtF rough consensus and IESG support for changes, it 
is not going to happen.

Apologies for the length of this note.  I am apparently too tired to 
write it more concisely.

Yours,
Joel

---

From: Larry Masinter <[email-masked]>
Date: Thu, 28 May 2020 20:45:37 -0700

Here's my reasoning:

The RFC series is known for being an archival format that never changes.
This is what its "brand" means, that  it serves as a unique identifier for
an explicit piece of intellectual  priority. 

there were canonical and derivative forms (TXT and PDF) 
before the format change and (XML and TXT,PDF,HTML)
after the format change, but it was done carefully enough
to not break too many things because the immutability
meant it didn't matter that the TXT was no longer canonical.

The format change damaged the brand some, but it is still
valuable.  
 
I don't think trying to "fix" RFCs is worth it because it
would damage the brand and would also break some
workflows

Establishing a new brand  for revisable, modifiable, 
easy to navigate series is actually much easier than
changing an old brand. Someone actually has to write
"DNS made EZ". Maybe someone could subsidize it.
It would make sense to make it a web site that
Linked to RFCs or applied errata as soon as the
errata was approved.

As far as old workflows, there used to be lots of
processes for replicating, distributing, analyzing RFCs
and I-Ds that assumed that their cache expiry
was infinite... you could do a fast rsync.

Changing this isn't worth the grief of finding those
assumptions in obsolete software and fixing them.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 29 May 2020 07:43:03 +0200

> On 29 May 2020, at 03:13, Brian E Carpenter <[email-masked]> wrote:
>>> 
>>> +1
>> 

I would ask that the question only be answered if it can be related to our task here.  That is- who should decide who gets to monkey with the series format?  If you can answer that one question, that is the right level for our conversation.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 May 2020 05:35:44 -0700

> an explicit piece of intellectual  priority.

Do you have any evidence that this is true outside of this fairly narrow
community? My experience is that to the extent to which people know of RFCs
they think of them as "Internet Specifications" and they don't think about
mutability at all.

-Ekr

<https://www.iab.org/mailman/listinfo/rfced-future>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 29 May 2020 09:52:38 -0400

> E.g., people still widely refer to RFC2616 as the authoritative reference for HTTP, even though we obsoleted it in 2014, and have been working on something to obsolete that more recently.

One way to immediately improve upon this would be to have a naive reference to any obsoleted document redirect to the document that replaced it, or a summary of why it’s obsolete if nothing replaced it. If someone wants to read the obsolete document specifically, a separate link could lead to that.

IOW, no need for the content of a document with a specific name to change. I don’t know if this is really an RSE thing, but it arguably could be—right now there is no definitive place to look for a document, and attempts to make one have failed due to usability issues (e.g., tools.ietf.org much more usable than datatracker). But in principle, if we decided to solve this problem, we could, and this is exactly the sort of thing I would expect an RSE to try to do.

---

From: Bob Hinden <[email-masked]>
Date: Fri, 29 May 2020 09:00:13 -0700

Stephen,

> check it out in detail;-)

It is mixed.   There are some editorial, one is a real error, and others are an attempt to change the text without going through the w.g. process.

In the case of the real error, the issue was the errata was correct in pointing out the error (actually there were three errata on specific parts of the text, but same error), but he correction was not the best way to resolve the problem.   The outcome was to reject the errata, file a new one, with a better simpler correction.

This is why I think the current errata system is broken.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Fri, 29 May 2020 09:03:04 -0700

Eric,

> On May 29, 2020, at 5:35 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> Do you have any evidence that this is true outside of this fairly narrow community? My experience is that to the extent to which people know of RFCs they think of them as "Internet Specifications" and they don't think about mutability at all.

Yes, a lot.  When an RFC is referenced in an RFP and/or product specification.   If it was changeable, these would be useless.

Bob

---

From: Larry Masinter <[email-masked]>
Date: Fri, 29 May 2020 11:32:51 -0700

RFC 2648, although Informational, reflected the consensus of the community

      Identifier persistence considerations:

            Persistence of the URNs of this namespace is independent of

            the mutability of the underlying documents.  A URN once

            assigned will never be reassigned to a different resource;

            the assignment is persistent and immutable.  Immutability of

            RFCs, STDs, FYIs and BCPs is at the discretion of the RFC

            Editor.  They may be composites of one or more RFCs and the

            set of RFCs that includes them may change with time.  It is

            important to note that this mutability of some resources is

            independent of the immutability of URN assignment to a

            resource.

From: Eric Rescorla <[email-masked]> 
Sent: Friday, May 29, 2020 5:36 AM
To: Larry Masinter <[email-masked]>
Cc: Mark Nottingham <[email-masked]>; Russ Housley <[email-masked]>; Colin Perkins <[email-masked]>; [email-masked]
Subject: Re: [Rfced-future] On the question of a living series

On Thu, May 28, 2020 at 8:45 PM Larry Masinter <[email-masked] <mailto:[email-masked]> > wrote:

Here's my reasoning:

-Ekr

---

From: Doug Royer <[email-masked]>
Date: Fri, 29 May 2020 13:36:32 -0600

How about keeping the original intact. And as errata arrive, creating extra one called

     RFC-####-errata.{txt,pdf,html}

that has the typos fixed? With all errata bundled into a single -errata as they are approved.

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

---

From: Russ Housley <[email-masked]>
Date: Fri, 29 May 2020 15:51:42 -0400

> On May 28, 2020, at 7:58 PM, Mark Nottingham <[email-masked]> wrote:
> 
> 

I find that people use the references to RFCs in many different ways.  Product planners use them as a starting point for interoperability, only deviating if there is a real need to interoperate with non-compliant peers.  Service providers and system integrators use them to name the protocols and protocol versions that then want supported.  Programmers and hardware designers use them to make products.  And so on.  In all of these cases, a stable specification is needed.

Russ

---

From: Russ Housley <[email-masked]>
Date: Fri, 29 May 2020 15:54:19 -0400

> On May 29, 2020, at 9:52 AM, Ted Lemon <[email-masked]> wrote:
> 

Yes, this is is often included in the "Changes since RFC XXXX" section.  Also, for backward compatibility reasons a programmer may need to support the old (obsolete) and the new.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 May 2020 13:52:22 -0700

On Fri, May 29, 2020 at 12:51 PM Russ Housley <[email-masked]> wrote:

> >>> I do not believe allowing amendments to published RFCs is desirable
> (with the possible exception: to fix bugs in the XML schema, provided
> there’s no content change).
> >>
> >> +1
> >
> > Could you give us some indication as to why you feel this way -- e.g.,
> what would be impacted? I fear we're falling into the habit of just stating
> our preferences and expecting Eliot to tally the votes...
>
> I find that people use the references to RFCs in many different ways.
> Product planners use them as a starting point for interoperability, only
> deviating if there is a real need to interoperate with non-compliant
> peers.  Service providers and system integrators use them to name the
> protocols and protocol versions that then want supported.  Programmers and
> hardware designers use them to make products.  And so on.  In all of these
> cases, a stable specification is needed.
>

II feel like perhaps we are talking past each other here.

At a high level, there are several levels of reference stability here:

- Bitwise identical (i.e., immutable)
- Semantically identical (editorial changes only)
- Semantically compatible (e.g., version N+1 is a superset
  of version N but the extensions are optional)

I believe that a good reference system would allow one to create all
three kinds of references and I would not be in favor of a system
which would not. However, the current system only really allows you to
create references to bitwise identical specifications, with the
mechanisms for creating references which are merely semantically
identical or semantically compatible are ad hoc at best.

It seems to me the questions at hand are:

1. Should we have mechanisms for creating all three kinds of
   references?

2. What kinds of references should we encourage people to cite
   for any given purpose?

I would note that for the purposes you are talking about, it
seems like a semantically identical reference is actually
more useful than a bitwise identical reference, because
we'd like people to refer to the clearest version of the specification.

-Ekr

---

From: "John Levine" <[email-masked]>
Date: 29 May 2020 21:30:35 -0400

>that has the typos fixed? With all errata bundled into a single -errata as they are approved.

Like this?  https://www.rfc-editor.org/rfc/inline-errata/rfc1035.html

Regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 May 2020 14:10:01 +1200

On 29-May-20 17:43, Eliot Lear wrote:
> 
> 
>> On 29 May 2020, at 03:13, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>>>> +1
>>>
> I would ask that the question only be answered *if* it can be related to our task here.  That is- who should decide who gets to monkey with the series format?  If you can answer that one question, that is the right level for our conversation.

Fair enough. So if, say, the IETF decides it wants something like RFC8200.1 or RFC8200.errata, and the IRTF is dead against, the *current* BCP39 rule is that the RSE proposes policy and the IAB [dis]approves it. Our question is presumably whether that is correct, or needs to be changed.

(Note that there is no BCP that puts the RSOC in the loop.)

    Brian

   Brian

---

From: Doug Royer <[email-masked]>
Date: Fri, 29 May 2020 22:38:53 -0600

> Like this?  https://www.rfc-editor.org/rfc/inline-errata/rfc1035.html

I had no idea that existed. Great.

So, revision control may not be needed?

---

From: Eliot Lear <[email-masked]>
Date: Sat, 30 May 2020 10:11:06 +0200

> On 29 May 2020, at 22:52, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Fri, May 29, 2020 at 12:51 PM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On May 28, 2020, at 7:58 PM, Mark Nottingham <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > 
> >> On 29 May 2020, at 6:47 am, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> >> 

My fault, but these aren’t the questions at hand for this group. The question at hand is this:

Who has the authority to answer those questions for the series?

Is it this group?  The RSE?  A committee overseeing the RSE?  The IETF community through the RFC process (I view that as the degenerative case)?

This is the level of dialog we need to have at this point.

Eliot

---

From: "John Levine" <[email-masked]>
Date: 30 May 2020 13:04:23 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-

Those merged errata are unofficial and very hard to find if you don't
know exactly where to look, which reminds us that in a sensible system
people looking for the RFC itself would find them with the fixes, too.

---

From: Larry Masinter <[email-masked]>
Date: Sat, 30 May 2020 10:19:03 -0700

Consider   changing the BCP series==turn those into “living documents” 

Or changing the STD series – that to go from Draft to Standard requires writing something that isn’t an RFC, it might cite RFCs for details but is understandable and well-written.

STDs and BCPs already have the notion of being semantically updatable.

The guarantee I think is associated with RFCs is basically the same as a HTTP weak etag. It might not be the same byte sequence, but it is equivalent for the MIME type as far as the publisher is concerned.

I don’t think the strong etag guarantee (that it’s the identical byte sequence for all renditions) is necessary, and might interfere with the kind of update recently to re-render PDFs to bring into PDF/A3 conformance.

 

*	Who has the authority to answer those questions for the series?

Eliot

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 30 May 2020 13:42:25 -0400

We were explicit as part of adopting the new format that the byte-wise 
identical guarantee applied to the XML, not to the rendered format. 
That much foresight we did manage.

Yours,
Joel

On 5/30/2020 1:19 PM, Larry Masinter wrote:
> Or changing the STD series – that to go from Draft to Standard requires 
> writing something that isn’t an RFC, it might cite RFCs for details but 
> is understandable and well-written.
> 
> The guarantee I think is associated with RFCs is basically the same as a 
> HTTP weak etag. It might not be the same byte sequence, but it is 
> equivalent for the MIME type as far as the publisher is concerned.
> 
> I don’t think the strong etag guarantee (that it’s the identical byte 
> sequence for all renditions) is necessary, and might interfere with the 
> kind of update recently to re-render PDFs to bring into PDF/A3 conformance.
> 
> Is it this group?  The RSE?  A committee overseeing the RSE?  The IETF 
> community through the RFC process (I view that as the degenerative case)?
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 30 May 2020 13:47:19 -0400

I would want to be very cautious about formally recognizing changes to 
the document which are "semantically identical" as being the same 
document.  (The current careful errata approach, assuming we make it 
more visible, is fine.)

For example, I have a document that the RPC is working on.  they noticed 
some contorted language and odd case usage.  So they fixed it.  That is 
their job.  However, it this particular case, the fix changed the 
meaning in a subtle but in my view important way.  (We are still 
discussing it.)

The point being that it is difficult to draw that line well.  As long as 
we are simultaneously careful and do not claim that the fixed document 
is the thing that the WG and IETF approved, it works for me.

Yours,
Joel

PS: As another example, someone submitted an erratum against an RFC to 
clarify the meaning of a few words.  However, the exact intended meaning 
of those few words is still a matter of WG contention, and the AD (in my 
view correctly) rejected the erratum.  But it could easily not have been 
obvious to someone not involved just how tricky the change was.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 31 May 2020 09:06:40 +1200

On 30-May-20 20:11, Eliot Lear wrote:
...
> Is it this group?  The RSE?  A committee overseeing the RSE?  The IETF community through the RFC process (I view that as the degenerative case)?

I think this is where Mike St J's idea of an RSE supported by an Editorial Board comes in. As long as the Board is in some way responsible to the wider (not just IETF) community in some way, it seems to me that the power of decision about policy should belong to the RSE in consultation with this Board.

The current setup, where the nearest thing to this is the IAB approving "general policy" and the intermediate RSOC seeming to act as if it's only a contract management committee, has been demonstrated to have a catastrophic failure mode. And the evidence from both RSOC and IAOC is that we should ban the word "oversight" from our vocabulary, because we're very bad at it.

(A subsidiary benefit of Mike's proposal is that it removes a chunk of admin stuff from the IAB's workload, which I hope the IAB will welcome.)

Regards
    Brian

---

From: Russ Housley <[email-masked]>
Date: Sat, 30 May 2020 18:34:24 -0400

> Is it this group?  The RSE?  A committee overseeing the RSE?  The IETF community through the RFC process (I view that as the degenerative case)?

We have four stream managers.  Ir seems to me that those stream managers would be a good sounding board for the RSE to use for changes that are under consideration.  If the four stream managers are satisfied, then the RSE can bring the idea to the broader technical community for further discussion, review, and refinement.  This might happen before or after a budget impact discussion with the IETF LLC, depending on the expected magnitude of the budget impact.

I think that creating a new group to do oversight will have the same pitfalls as the previous approach.

Russ

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 31 May 2020 11:48:44 +1200

> I think that creating a new group to do oversight will have the same pitfalls as the previous approach.

We agree on that. I don't see Mike's proposed Editorial Board having an oversight role, and contract management is surely an LLC job.

    Brian

---

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

the stream managers clearly have a role in the operation of the RFC 
Series.  I am concerned that putting them in charge introduces an 
inherent conflict.  The Stream managers have very specific objectives. 
Up till now, they have not been selected for a broad view, but rather, 
if I understand correctly, for a clear understanding of what their 
stream needs.  and particularly, what it needs now.

Long term planning, community responsiveness, and some form of 
management are not their tasks.

Could stream managers be selected and directed to have different 
objectives?  Presumably.  But it would make things complicated in a new 
fashion.

And it is not at all obvious that the stream managers are more 
accountable to the community.  Except in very extreme cases (lets hope 
we don't do that again) an AD who is serving as stream head is not going 
to get fired as an AD based on the quality of their management of the 
RSE.  I do not see how this is any better than the RSOC, which had many 
flaws and some benefits.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 31 May 2020 14:55:50 +1200

On 31-May-20 12:25, Joel M. Halpern wrote:
> inherent conflict.  

Indeed. But putting them in the editorial board, along with at-large
members, is not putting them in charge.

   Brian

> The Stream managers have very specific objectives.

---

From: John C Klensin <[email-masked]>
Date: Sun, 31 May 2020 18:34:04 -0400

--On Saturday, May 30, 2020 20:25 -0400 "Joel M. Halpern"
<[email-masked]> wrote:

> the stream managers clearly have a role in the operation of
> the RFC Series.  I am concerned that putting them in charge
> introduces an inherent conflict.  The Stream managers have
> very specific objectives. Up till now, they have not been
> selected for a broad view, but rather, if I understand
> correctly, for a clear understanding of what their stream
> needs.  and particularly, what it needs now.

It seems to me that there is a more fundamental issue.  In the
present setup, two of the stream managers are chosen by the
Nomcom, not as stream managers, but for some other role.  While
we often throw the "stream manager" term around, it  has never
been clear to me whether, in the case of the IETF and IAB
Streams, the title belongs to one person or to the IESG and IAB
respectively (that ambiguity probably serves us well as long as
it isn't either abused or turned into a source of paralysis or
non-accountability).  I'm guessing that no job description for
the IETF Chair, an AD, or an IAB member has ever reached the
Nomcom with "needs to have the skills and experience needed to
contribute to the design, implementation, and strategy for a
technical publications series" high on the list of
requirements... or even on the list at all.   Similarly, I'm
guessing that the Nomcom has rarely received feedback that one
candidate should be chosen over another because the first is
more qualified for the stream manager role. I'd further guess
that, if one replaced the Nomcom with the relevant appointing
body for the other two streams, it would not change the
priorities much.  Prioritizing publications knowledge and
experience over networking knowledge and experience is just not
how we choose our leadership and we would regret changing things
so that it was.

I think it would be fine to put some or all of the stream
managers on the/an editorial board, especially if it were clear
that their role was to advocate for the requirements of their
particular streams.  But, given the number of times in the last
decade or so when individuals in leadership roles have
demonstrated a lack of knowledge about what they don't know in
areas far removed from the networking skills for which they were
appointed, we'd best be such they cannot dominate the editorial
board either by outvoting everyone else or applying force of
personality and suggesting that, because of other roles, they
are naturally in charge.

> accountable to the community.  Except in very extreme cases
> (lets hope we don't do that again) an AD who is serving as
> stream head is not going to get fired as an AD based on the
> quality of their management of the RSE.  I do not see how this
> is any better than the RSOC, which had many flaws and some
> benefits.

Exactly.

best,
  john

> 
> 
> Could stream managers be selected and directed to have
> different objectives?  Presumably.  But it would make things
> complicated in a new fashion.
> 
> accountable to the community.  Except in very extreme cases
> (lets hope we don't do that again) an AD who is serving as
> stream head is not going to get fired as an AD based on the
> quality of their management of the RSE.  I do not see how this
> is any better than the RSOC, which had many flaws and some
> benefits.