Subject: [Rfced-future] Side idea

From: Michael StJohns <[email-masked]>
Date: Mon, 8 Mar 2021 18:44:50 -0500

Hi -

This is certainly not something for long discussion related to the 
model, just something that I thought of that might be a useful set of 
deliverables for the future RSE/A/whatever.

In a long ago discussion, we had various discussion/rants about the 
spaghetti like nature of certain of the standards families (TLS and DNS 
spring to mind) and the difficulty for someone reading RFCs without IETF 
experience to figure out which RFCs are actually necessary to build a 
working protocol engine.

Perhaps one of the great services an RSE might do is to write a series 
of "Welcome to the DNS protocol suite - would you like instructions?" 
RFCs that actually attempt to describe how a particular group of RFCs 
relate to each other.  As has been noted elsewhere, these are probably 
not documents that would attract enough volunteer hours to create.  They 
would also be somewhat formulaic, and ideally more an annotated 
bibilography than a new set of standards documents.

As I noted above, this is just a side idea to be ruminated on rather 
than anything to feed into the endless maw of the current discussion.

Mike

---

From: John C Klensin <[email-masked]>
Date: Mon, 08 Mar 2021 23:00:12 -0500

--On Monday, March 8, 2021 18:44 -0500 Michael StJohns
<[email-masked]> wrote:

> Hi -
> 
> This is certainly not something for long discussion related to
> the model, just something that I thought of that might be a
> useful set of deliverables for the future RSE/A/whatever.
> 
> In a long ago discussion, we had various discussion/rants
> about the spaghetti like nature of certain of the standards
> families (TLS and DNS spring to mind) and the difficulty for
> someone reading RFCs without IETF experience to figure out
> which RFCs are actually necessary to build a working protocol
> engine.
> 
> Perhaps one of the great services an RSE might do is to write
> a series of "Welcome to the DNS protocol suite - would you
> like instructions?" RFCs that actually attempt to describe how
> a particular group of RFCs relate to each other.  As has been
> noted elsewhere, these are probably not documents that would
> attract enough volunteer hours to create.  They would also be
> somewhat formulaic, and ideally more an annotated bibilography
> than a new set of standards documents.
> 
> As I noted above, this is just a side idea to be ruminated on
> rather than anything to feed into the endless maw of the
> current discussion.

Mike,

While I would very much like to see something along those lines,
history suggests it would not be easy, as least without some
rather basic changes in how the IETF does business.  In
particular...

* The original purpose for assigning STD numbers (IIR, an RFC
Editor initiative at the beginning) was to bind multiple
specifications that, together, comprised a standard as well as
to provide a stable reference as specifications were replaced.
That idea largely failed despite because the number assignments
were bound to documents at the Internet Standard maturity level
and we have never been as good at getting things to that level
as RFC 2026 and then RFC 6410 anticipated.  Assorted proposals
to work around that part of the problem by assigning STD numbers
to Proposed Standards have been unable to get enough traction
with the IESG to even turn into good discussions.  (If anything
thinks that attitude has changed, I'd be happy to re-post an
ancient I-D.)

* One of the main objectives of the late Newtrk WG as its work
evolved was to create a framework for documents that would
describe the standards for particular topic areas and tie the
relevant documents together with some explanation as to how they
would fit together.  IIR, annotated bibliographies were one of
the options Newtrk considered although it rapidly concluded that
more would be need.  IMO, there were two lessons from that
experience.  One was that the IESG felt that it needed firm
control over what such documents might say and what documents to
link together (there are lots of edge cases where documents
overlap into different areas as we discovered again for
procedural documents during the IASA2 WG work).  The other was
that the IESG concluded that would require more effort than the
results would justify and therefore declined to let the WG
output documents go into IETF Last Call.

So, yes.  And yes it is a problem.  But, unless things have
changed more than I think they have (and for the better), I
cannot imagine the IESG allowing an independent person (and LLC
contractor or employee) to do that job, at least without Last
Call and extensive final nit-picking and expressions of personal
preferences on each document.  I'm not even sure they would be
wrong if they took that position as such things probably should
represent community consensus.

best,
   john

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 9 Mar 2021 14:47:37 +0900

Hello Michael, others,

To add to what John said, there are additional problems with your idea. 
One is that even for people quite familiar with some area such as TLS 
and DNS, it's difficult to figure out the exact boundaries (that's maybe 
a different way of expressing what John mentioned below when explaining 
that one would expect the IESG to want to be involved).

Second, such documents wouldn't have such a long lifespan, because they 
have to be updated as soon as something changes (and both TLS and DNS 
are definitely still being worked on). That would also include the 
danger that a first version of such a document was successful, but there 
wasn't enough energy for updates. This could be even more confusing than 
the situation we have now.

Third, and most important in the context of this mailing list, is that I 
think we have (something close to) consensus that the RSE/A/whatever 
should/will have expertise in technical publishing. However, my personal 
guess would be that such a person would have close to zero experience 
e.g. about TLS or DNS, which would not make them very qualified for the 
job you propose. Speaking even more generally, I think the job of 
technical publishing (starting with the editing of technical documents 
up to strategic functions) is quite different from the job of authoring 
technical documents (such as RFCs).

Regards,   Martin.

-- 
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan

---

From: Lars Eggert <[email-masked]>
Date: Tue, 9 Mar 2021 10:01:18 +0200

Hi,

On 2021-3-9, at 1:44, Michael StJohns <[email-masked]> wrote:
> Perhaps one of the great services an RSE might do is to write a series of "Welcome to the DNS protocol suite - would you like instructions?" RFCs that actually attempt to describe how a particular group of RFCs relate to each other.

I'm not sure an RSE would be best qualified to author such a document. But a WG certainly can, like TCPM did for TCP: https://datatracker.ietf.org/doc/html/rfc7414

Thanks,
Lars

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Mar 2021 09:23:36 +0100

> I'm not sure an RSE would be best qualified to author such a document. But a WG certainly can, like TCPM did for TCP: https://datatracker.ietf.org/doc/html/rfc7414

But they rarely do (*).

So I think it is an interesting question how this can be encouraged/helped with by providing/organizing additional resources; not sure the RSE would play a big role in such a process but they might have a coordinating one.
(Recently, the RPC has recruited some rather technically savvy copy editors…)

Grüße, Carsten

(*) yeah…

draft-bormann-6lo-6lowpan-roadmap-00
6LoWPAN Roadmap and Implementation Guide
2013-10-21
9 pages	Expired		

draft-bormann-core-roadmap-05
CoRE Roadmap and Implementation Guide
2013-10-21
22 pages	Expired

---

From: Lars Eggert <[email-masked]>
Date: Tue, 9 Mar 2021 10:32:55 +0200

Hi,

> (Recently, the RPC has recruited some rather technically savvy copy editors…)

based on the experience in TCPM, I really think such documents need to be written and reviewed by the technical community. The cases where a - technically savvy - outsider could produce such a document are probably exactly those cases where one isn't really needed.

Thanks,
Lars

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Mar 2021 10:20:56 +0100

> based on the experience in TCPM, I really think such documents need to be written and reviewed by the technical community. The cases where a - technically savvy - outsider could produce such a docu…

The best way to get an answer on the Internet is to put out the wrong answer.

If there is a threat that a roadmap will be produced, that will unleash unprecedented energy(*)…

Grüße, Carsten

(*) Yeah, I hope not all of that will be destructive.

---

From: John C Klensin <[email-masked]>
Date: Tue, 09 Mar 2021 06:55:11 -0500

--On Tuesday, March 9, 2021 10:32 +0200 Lars Eggert
<[email-masked]> wrote:

>> So I think it is an interesting question how this can be
>> encouraged/helped with by providing/organizing additional
>> resources; not sure the RSE would play a big role in such a
>> process but they might have a coordinating one. (Recently,
>> the RPC has recruited some rather technically savvy copy
>> editors…)
> 
> based on the experience in TCPM, I really think such documents
> need to be written and reviewed by the technical community.
> The cases where a - technically savvy - outsider could produce
> such a document are probably exactly those cases where one
> isn't really needed.

FWIW, I agree.  Nut, as has been pointed out, while there have
been exceptions, motivating WGs to do to the work and then keep
up with it -- and motivating those who support people-s
participation in WGs to support it-- has often proven quite
difficult.  So, as Martin mentioned (and that was discussed at
length in Newtrk with the same conclusion) such documents need
to be actively maintained and therefore may not be suitable for
the RFC Series.

There may be other ways around the problems but those I have
seen are not consistent with the current IETF culture.  One
interacts with an issue that has come up many time in the
context of the RFC Editor Function, which is whether IETF Stream
documents should undergo final, or at least preliminary, editing
prior to IETF Last Call.

    john

---

From: Bob Hinden <[email-masked]>
Date: Tue, 9 Mar 2021 06:19:50 -0800

> On Mar 9, 2021, at 12:01 AM, Lars Eggert <[email-masked]> wrote:
> 
> Signed PGP part
> Hi,
> 

I agree.

Another possibility is for an area directorate to hold the pen.   I also wonder if this should be an RFC or a web page.

Bob

---

From: Jay Daley <[email-masked]>
Date: Wed, 10 Mar 2021 08:14:23 +1300

> On 9/03/2021, at 12:44 PM, Michael StJohns <[email-masked]> wrote:
> 
> Hi -
> 
> This is certainly not something for long discussion related to the model, just something that I thought of that might be a useful set of deliverables for the future RSE/A/whatever.
> 
> In a long ago discussion, we had various discussion/rants about the spaghetti like nature of certain of the standards families (TLS and DNS spring to mind) and the difficulty for someone reading RFCs without IETF experience to figure out which RFCs are actually necessary to build a working protocol engine.
> 
> Perhaps one of the great services an RSE might do is to write a series of "Welcome to the DNS protocol suite - would you like instructions?" RFCs that actually attempt to describe how a particular group of RFCs relate to each other.  As has been noted elsewhere, these are probably not documents that would attract enough volunteer hours to create.  They would also be somewhat formulaic, and ideally more an annotated bibilography than a new set of standards documents.
> 
> As I noted above, this is just a side idea to be ruminated on rather than anything to feed into the endless maw of the current discussion.

I have a naive question - has any thought been given to doing this bottom up not top down, say by defining a fixed set of technology tags (DNS, TLS etc) and having the authors apply those to their documents?

Jay

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Mar 2021 08:42:26 +1300

On 10-Mar-21 08:14, Jay Daley wrote:
> 
> 
>> On 9/03/2021, at 12:44 PM, Michael StJohns <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi -
>>

If (and that is not a trivial "if") authors have consistently got the normative references right, the normative dependency graphs that are already around will have that effect. (For that matter, the "cluster" mechanism used by the RFC Editor has much the same effect, but it's lost when the RFCs are published and the cluster dissolves.)

However, exercises like RFC 8504 show that it's hard work to get these things right, and they are out of date almost instantly.

This is a problem area the IETF has been dancing around for years. I believe that Lars is correct that in the end it's only subject matter experts (typically the WG) that can get it right, but automatically generated dependency graphs should certainly help. draft-kuehlewind-update-tag is also relevant.

But above all, encouragement from the IESG and WG Chairs to write such documents is needed. Whether they are published as RFCs or web pages is a bit secondary.

Regards
   Brian

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 9 Mar 2021 21:17:44 +0100

> However, exercises like RFC 8504 show that it's hard work to get these things right, and they are out of date almost instantly.

I think we can all agree that node requirements, roadmaps, etc. are a class of documents that our current processes are not prepared to put out consistently.

We can say that this is hard and we need to try harder, but I don’t believe that will work.

Instead, we will need to think about ways to encourage this that go way beyond an occasional nag mail.  Of course, I’m thinking about ways to create an organizational responsibility, but I’m also aware that that’s not a cakewalk.

> This is a problem area the IETF has been dancing around for years. I believe that Lars is correct that in the end it's only subject matter experts (typically the WG) that can get it right, but auto…

All for all the tools help we can get.
But we also need people that can keep these candles lit, even if these may not be able to create all the content that needs to go in there.

> But above all, encouragement from the IESG and WG Chairs to write such documents is needed. Whether they are published as RFCs or web pages is a bit secondary.

Actually, no.  There is no way to get this done as a web page (~ wiki).
Publishing them as an RFC is the only way they will have high quality (or happen in the first place).
But we need to get there, and encouragement only takes us so far.

Grüße, Carsten

---

From: John C Klensin <[email-masked]>
Date: Tue, 09 Mar 2021 15:29:57 -0500

--On Wednesday, March 10, 2021 08:14 +1300 Jay Daley
<[email-masked]> wrote:

>...
>> like instructions?" RFCs that actually attempt to describe
>> how a particular group of RFCs relate to each other.  As has
>> been noted elsewhere, these are probably not documents that
>> would attract enough volunteer hours to create.  They would
>> also be somewhat formulaic, and ideally more an annotated
>...

> I have a naive question - has any thought been given to doing
> this bottom up not top down, say by defining a fixed set of
> technology tags (DNS, TLS etc) and having the authors apply
> those to their documents?

Yes.  There have long been provisions for assigning keywords
(aka "tags") to documents, with either authors or the RFC Editor
staff putting them in.  What has not happened is standardization
on a vocabulary for those tags that would get them assigned in
the right places and no where else.   Similar to my earlier
comments, at least one reason has been IESG disinterest in
having the extra work done and then checking it.

    john

---

From: Michael StJohns <[email-masked]>
Date: Tue, 9 Mar 2021 15:47:33 -0500

> Instead, we will need to think about ways to encourage this that go way beyond an occasional nag mail.  Of course, I’m thinking about ways to create an organizational responsibility, but I’m also a…

Hence my thought to throw paid resources at it.

> But we need to get there, and encouragement only takes us so far.
My thought here is that while the RSE/A might not be the final author on 
the document, they certainly can be the facilitator and nag.  I'm 
thinking back to the DOCSIS security standards where our facilitator was 
not the primary driving force for technical content, but was for getting 
to a conclusion with actual written text and was hired for that specific 
purpose.

I think these documents  should probably be RFCs mainly because RFCs are 
a snapshot in time that an implementer can look at and say - hmm, 
published in March of 2021, so I need to see if there are other 
documents that I care about that have been written later.

And last, I don't actually think this is a standards type thing that the 
IESG should necessarily care about/push, but a document series thing 
that provides explanatory meta material that really helps frame the 
specifications.

Mike

---

From: Nico Williams <[email-masked]>
Date: Tue, 9 Mar 2021 15:36:36 -0600

On Tue, Mar 09, 2021 at 03:47:33PM -0500, Michael StJohns wrote:
> > Instead, we will need to think about ways to encourage this that go
> > way beyond an occasional nag mail.  Of course, I’m thinking about
> > ways to create an organizational responsibility, but I’m also aware
> > that that’s not a cakewalk.
> 

Yes.  The ITU-T produces very high-quality documents, most likely
because it's not a volunteer organization and they (must? I think?) have
tech writers on staff.

I'm not suggesting that the IETF go that way in general, but for putting
together series of RFCs as RFCs for the community to review, I think
this would be great.  One FTE could probably get us all the series we
care about in a few years.

Nico
--

---

From: "John Levine" <[email-masked]>
Date: 9 Mar 2021 18:20:05 -0500

In article <[email-masked]> you write:
>-=-=-=-=-=-
>> Perhaps one of the great services an RSE might do is to write a series of "Welcome to the DNS protocol suite - would
>you like instructions?" RFCs that actually attempt to describe how a particular group of RFCs relate to each other.
>
>I'm not sure an RSE would be best qualified to author such a document. But a WG certainly can, like TCPM did for TCP:
>https://datatracker.ietf.org/doc/html/rfc7414

I have a technical background and could write stuff like that, but Heather's background is different and I
doubt she could have, at least not without a lot of technical help.  (Editing it into coherent readable shape
is a different issue.)

I think the pile of requirements here already makes it unlikely that we will find a qualified candidate
who wants the job, so I would doubly not count on the unlikely person writing technical material.  If we
think this sort of roadmap is valuable, put it in the budget and put it out for bid as a separate thing.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Tue, 09 Mar 2021 22:12:44 -0500

--On Tuesday, March 9, 2021 15:36 -0600 Nico Williams
<[email-masked]> wrote:

>> > Instead, we will need to think about ways to encourage this
>> > that go way beyond an occasional nag mail.  Of course,
>> > I'm thinking about ways to create an organizational
>> > responsibility, but I'm also aware that that's not a
>> > cakewalk.
>> 
> Yes.  The ITU-T produces very high-quality documents, most
> likely because it's not a volunteer organization and they
> (must? I think?) have tech writers on staff.

Nico, please be careful about this sort of comparison.   THey
not only have tech writers (to get back to a distinct made early
in this group, not copy editors), but tech writers who are
skilled in the subject matter and staff members assigned to each
SG who are presumed to be skilled in the subject matter.  They
also do almost all of the editing before documents go out for
final review by the national members so, at the time that review
starts, the documents are expected to be in their final states
both technically and editorially.  ISO, at the TC level, is very
similar.

Once a specification becomes a standard, it is assigned an
identifier that stays with it forever.  For example, to know
which version of X.509 or ISO 3166 is being referenced, one
needs to have the adoption year.  And, when a document is forked
or supplemented in some way, the norm is to split subset the
numbering scheme, e.g., ISO 3166 started out as a single spec
but when identifiers for non-country entities were added, we
ended up with ISO 3166-1, ISO 3166-2, and ISO 3166-3, with the
current versions formally known as ISO 3166-1:2020, ISO
3166-2:2020, and ISO 3166-3:2020.

Both bodies, but especially ISO, also have fixed periods after
which a standard must be reviewed and then reaffirmed, revised
(i.e., replaced), or withdrawen.  None of our pattern of
incremental "update" documents, forks and side branches, and
documents that are not opened for decades are consistent with
that way of doing things.  If we tried to apply their system to
TCP, we might have had IETF 793:1981, been forced to formally
review and reaffirm it around 1984 or 1985 (producing something
that might be formally known as IETF:1981R1985) with a new
version, IETF 793:1989, incorporating the RFC 1123 updates; then
IETF 793:1989R1992, IETF 793:1989R1995, and so on until IETF
793:2001 incorporating the additions of RFc 3168, and...

In the ITU, technical standards (aka "Recommendations") are also
identified by a subseries classification, e.g., X.509 but E.123.
That is a technical decision that has, IIR, occasionally be the
subject of debate about, e.g., scope of Study Groups.  That can
help understand what documents go together too.... or not.

Systems like that have many attractions as does getting
documents into what is expected to be final form before the
equivalent of our Last Call.  In addition to the high-quality
documents you mention, the model eliminates any risk that
documents may change in ways that some might consider
substantive after the fact by private agreements between the
IESG (or particular ADs) and authors after Last Call ends and
without verification by the community.  The numbering systems
largely eliminate the "which documents do I need to look at to
know what the standard actually is" problem.  There is also no
opportunity for confusion about whether BCPs override Proposed
Standards, the meaning of verified errata, and so on: when those
organizations publish documents that are not what we would call
standards track, they use completely different terminology.  For
example, ISO used to have three categories of Technical Reports,
one of which was used for things that seemed to be good ideas
but that could not achieve sufficient consensus and were
affectionately known as "substandards".

There are disadvantages as well.  They have nothing equivalent
to an individual submission.  Editing before final
general/public review works because, by the time a document gets
to that stage, it has been through enough layers of review that
changes that would require significant re-editing are quite
rare. By contrast, our Last Call process is often the first time
at document has been seen by anyone outside the WG that
developed it so editing before Last Call would result in the RFC
Editor Function needing to process many documents twice and some
more times than that.

For many years, we also used to claim (and could document) that
our process was much faster than theirs and that the
rapidly-developing ARPANET and Internet needed "fast".  There
are enough complicating factors and exogenous variables that
valid statistical comparisons would be nearly impossible, but
many of us believe that is no longer true.

> I'm not suggesting that the IETF go that way in general, but
> for putting together series of RFCs as RFCs for the community
> to review, I think this would be great.  One FTE could
> probably get us all the series we care about in a few years

Depending on how we define what we care about (agreement on that
subject could, itself, take a few years).  The people doing the
work would need to be technical experts in the subject matter
(not "just" technical editors).  And, because there are few (if
any) people expert in all of the IETF's work areas, you might
need different people per Area and maybe different people within
some areas.

So, yes... but everything is connected to everything else and be
careful what you wish for.

    john

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Mar 2021 14:13:22 +1100

FWIW, I prototyped this here:
  https://rfc.fyi/

... but haven't seen much in the way of contributed tags. I'm considering writing a bot of some sort to facilitate that (Twitter? Jabber? Dunno).

Cheers,

> On 10 Mar 2021, at 6:14 am, Jay Daley <[email-masked]> wrote:
> 
> 
> 

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

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 11 Mar 2021 13:29:21 +1100

And even without much in the way of contributed tags - it's the first place I go when I'm looking for related specs these days, because it's fast and it's easy to use.

Thanks Mark for prototyping :)

Cheers,

Bron.

On Wed, Mar 10, 2021, at 14:13, Mark Nottingham wrote:
> > On 10 Mar 2021, at 6:14 am, Jay Daley <[email-masked] <mailto:jay%40ietf.org>> wrote:
> > 
> > 
> > 
> >> On 9/03/2021, at 12:44 PM, Michael StJohns <[email-masked] <mailto:msj%40nthpermutation.com>> wrote:
> >> 
> >> Hi -
> >> 
> >> [email-masked] <mailto:Rfced-future%40iab.org>
> > [email-masked] <mailto:jay%40ietf.org>
> > 
> > -- 
> > [email-masked] <mailto:Rfced-future%40iab.org>
> [email-masked] <mailto:Rfced-future%40iab.org>

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Wed, 10 Mar 2021 21:58:28 -0600

> need different people per Area and maybe different people within

I am indeed assuming that curating a set of sets of RFCs is less work,
and requires less skill and expertise, than writing those RFCs took to
begin with, though obviously it would require more skill and expertise
than most tech writers.

If your point is that the floor on skill and expertise required would
make the person in question too valuable to industry, and too capable of
more interesting work, to bother working for ISOC to do this work for
whatever ISOC would pay...  Well, I think you might be right, but still,
we might be able to find such a person, and if we did, it might be worth
the effort and money.

> careful what you wish for.

I'm pretty darned sure I can't wish the IETF into an ITU-T/ISO style
organization :)  And I wouldn't wish that anyways.

Nico
--

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 15 Mar 2021 10:39:20 +0100

We also have this on a per-wg level:

https://www.ietf.org/topics/keywords/

> On 10. Mar 2021, at 04:13, Mark Nottingham <[email-masked]> wrote:
>