Subject: [Rfcplusplus] Another RFC experiment

From: S Moonesamy <[email-masked]>
Date: Sun, 01 Jul 2018 10:57:58 -0700

Hello,

I searched for information about the RFC++ BoF and came across the 
"About" information for this mailing list.  Who are the BoF proponents?

The proposed experiment reminded me of RFC 6393.  Nobody within the 
IETF was enthusiastic to do the "clean up" after that experiment.  If 
I understood correctly, the purpose of the proposed RFC experiment is 
to correct the misconception that all RFCs are standards by reserving 
"RFC" for standards-related documents.  What is the meaning of 
"standards-related"?  Does it mean documents in the IETF 
Stream?  Does it include the "Informational" and "Experimental" 
documents in the IETF Stream?

Regards,
S. Moonesamy

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 1 Jul 2018 13:19:29 -0500

> "About" information for this mailing list.  Who are the BoF proponents?

https://trac.tools.ietf.org/bof/trac/wiki/WikiStart is pretty clear about
this.  (Martin Thomson and Melinda Shore)

> IETF was enthusiastic to do the "clean up" after that experiment.  If 

Sorry, I don't know what you intend to mean when you say the "clean up" for
that experiment.

> documents in the IETF Stream?

This is covered in RFC 7841. (BCP, proposed standard, internet standard)

-Ben

---

From: S Moonesamy <[email-masked]>
Date: Sun, 01 Jul 2018 11:42:38 -0700

Hi Ben,
>this.  (Martin Thomson and Melinda Shore)

Thank you for the link.

>Sorry, I don't know what you intend to mean when you say the "clean up" for

The "clean up" would entail having an I-D, a Last Call and IESG 
review.  It was not viewed as worth the effort in 2011.

>This is covered in RFC 7841. (BCP, proposed standard, internet standard)

Ok.

Regards,
S. Moonesamy

---

From: John C Klensin <[email-masked]>
Date: Sun, 01 Jul 2018 15:03:11 -0400

--On Sunday, July 1, 2018 10:57 -0700 S Moonesamy
<[email-masked]> wrote:

> Hello,
> 
> I searched for information about the RFC++ BoF and came across
> the "About" information for this mailing list.  Who are the
> BoF proponents?

The BOF proposal page
(https://trac.tools.ietf.org/bof/trac/wiki/WikiStart#TimeframeIETF102Montr%C3%A9al)
shows Martin Thomson and Melinda Shore, I presume on behalf of
the IAB, and Alissa Cooper as the Responsible AD.

I note that, while the BOF proposal identifies RFC 1786 as
identifying a problem that has not been solved, 1796 (which I
would encourage people to read before the BOF) actually explains
the reasons for a single archival series.  It also suggests that
documents that are actually standards be referred to by their
STD numbers for clarity (i.e., not by their RFC numbers).  The
problem with that approach is become quite obvious in the
subsequent 23 years -- despite several efforts to adjust things,
the Internet continues to run on Proposed Standards and Proposed
Standards do not have STD numbers.  A simple and obvious
solution to that part of the problem has been proposed, in
different forms, several times: assign STD numbers to all
Standards Track specifications from Proposed forward (or retire
"STD" and assign a new set of numbers to all standards track
documents), but the IESG has repeatedly declined to consider
those proposals. 

Because there is no agenda posted yet and there seems to be a
strong case that assigning numbers instead of RFC numbers
(rather than in addition to them, which would be the solution
derived from 1786) is not an experiment at all because there
would be no going back, I'd going to repost the most recent of
those STD proposals in the hope that the BOF can consider it as
an alternative.

 > The proposed experiment reminded me of RFC 6393.  Nobody
> within the IETF was enthusiastic to do the "clean up" after
> that experiment.  If I understood correctly, the purpose of
> the proposed RFC experiment is to correct the misconception
> that all RFCs are standards by reserving "RFC" for
> standards-related documents.  What is the meaning of
> Stream?  Does it include the "Informational" and
> "Experimental" documents in the IETF Stream?

The BOF proposal says that one purpose of the BOF is to sort out
that issue.  Of course, the two categories of BCP documents
(actual current practice documents related to protocols specs
and IETF procedural documents) are another set of questions.
Given that the proposal appears to be not allocate new RFC
numbers to non-standards, should new BCP documents not be
assigned RFC numbers either?

  john

---

From: S Moonesamy <[email-masked]>
Date: Sun, 01 Jul 2018 12:56:17 -0700

Hi John,
>the IAB, and Alissa Cooper as the Responsible AD.

Thanks, I missed that when I previously searched for information.

>documents), but the IESG has repeatedly declined to consider

The BoF is based on a RFC from "Legacy".  I found it odd that the 
discussion is about RFC number for standards while there is already a 
(STD) number for that.  Several years ago, there was the discussion 
about the categorization of "proposed standard".

The proposed experiment may end up creating another legacy.  If the 
IETF was confident about its brand, it would use another label 
instead of relying on "RFC".

>assigned RFC numbers either?

If I were to follow the "distinguishability" argument, I would say 
that the procedural documents should be separated as well.

Regards,
S. Moonesamy

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 2 Jul 2018 10:24:27 +1200

> Sorry, I don't know what you intend to mean when you say the "clean up" for

The clean-up is well described at
https://www.ietf.org/old/2009/u/iesgcontent/ions.html

Actually I think the IESG did a fairly good job of the clean-up in
that case, because the experiment was structured non-destructively,
i.e. it *added* a new document series that could be abolished quite
harmlessly. That is not true of the so-called experiment proposed
in the BOF description.

> This is covered in RFC 7841. (BCP, proposed standard, internet standard)

The alleged problem and the proposed experiment are not described in a
draft, unless I've missed something. The suggested reading doesn't include
even the recent drafts that seem relevant (still less older ones):
https://tools.ietf.org/html/draft-klensin-std-numbers
https://tools.ietf.org/html/draft-carpenter-request-for-comments

https://tools.ietf.org/html/rfc5434#section-3 seems relevant

   Brian

---

From: S Moonesamy <[email-masked]>
Date: Sun, 01 Jul 2018 16:30:02 -0700

Hi Brian,
>harmlessly. That is not true of the so-called experiment proposed

The opinion depends on whether one is looking at the matter from an 
IETF perspective or a non-IETF perspective.

>https://tools.ietf.org/html/rfc5434#section-3 seems relevant

I read the two drafts.  If I am not mistaken, the first attempt at 
numbering occurred in 1971.  Your draft mentions that one of the 
issues was about finding the latest version of the standard.  As an 
anecdote, I came across a regulation which references an I-D as a standard.

I'll leave it to the BoF to figure out the answer to "who owns the 
RFC Series?"   I suggest taking into consideration that the community 
who will be at the BoF is usually a subset of the wider audience who uses RFCs.

I like what you wrote at the end of Section 4 about "standard organisations".

The RFC which you cited is an IETF classic [1].  Is the issue about 
standardization?  Is it about people out there misrepresenting 
non-Standards Track RFCs as standards?

Regards,
S. Moonesamy

1. The questions are to the group.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 2 Jul 2018 11:22:48 -0700

On Sun, Jul 1, 2018 at 4:30 PM, S Moonesamy <[email-masked]> wrote:

>
> I'll leave it to the BoF to figure out the answer to "who owns the RFC
> Series?"   I suggest taking into consideration that the community who will
> be at the BoF is usually a subset of the wider audience who uses RFCs.
>
> Speaking personally, I do not believe this is a topic of the BoF.  The
current system has multiple streams, each with a stream manager.
Presumably, those stream managers could make a request to the RSE to mint a
new identifier (either as an addition or a replacement for RFC numbers) for
their stream.

Having a public discussion of whether that is a good idea, and whether to
run an experiment using that method, is a part of this BoF.  "ownership" is
not, at least as I see it.

Again, my personal view,

Ted

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 2 Jul 2018 14:37:28 -0400

> On Jul 1, 2018, at 3:03 PM, John C Klensin <[email-masked]> wrote:
> 
> 
> 
> the IAB,

I wouldn’t presume that the BOF proponents are acting on anyone’s behalf, just the same as any other BOF.

Alissa

---

From: John C Klensin <[email-masked]>
Date: Mon, 02 Jul 2018 15:30:27 -0400

--On Monday, July 2, 2018 14:37 -0400 Alissa Cooper
<[email-masked]> wrote:

>> The BOF proposal page
>> (https://trac.tools.ietf.org/bof/trac/wiki/WikiStart#Timefram
>> eIETF102Montr%C3%A9al) shows Martin Thomson and Melinda
>> Shore, I presume on behalf of the IAB,
> 
> I wouldn't presume that the BOF proponents are acting on
> anyone's behalf, just the same as any other BOF.

My apologies.   I have seen or heard rumors of enough other
discussions to have assumed that the IAB (and maybe the IESG)
had discussed this plan (and possibly some related ones) to have
assumed some general support for examining changes of this type
(even if not this particular change) and without any idea of
what "this type" might be beyond involving the RFC Series and
its audience(s).   If that was the case, I didn't want to, or to
encourage others to, blame individuals for a broader decision.

Conversely and borrowing from Brian's comment about priorities,
if this is just a bright idea that two individuals came up with
and have not reviewed with others beyond putting together and
submitting the BOF proposal, I have trouble understanding why we
are spending BOF time on it (although I will defend the IESG's
authority to make that decision).

In any event, if my presumption was either incorrect or
upsetting to anyone, my apologies.

   john

---

From: Melinda Shore <[email-masked]>
Date: Mon, 2 Jul 2018 11:38:37 -0800

On 7/2/18 11:30 AM, John C Klensin wrote:
> are spending BOF time on it [ ... ]

To be clear, I'm not a fan of the proposed experiment and
it wasn't my proposal.  I do think, however this is the right time to
have this discussion, assuming that it's not driven off the rails,
turns into a bikeshedding exercise, or otherwise loses its
focus.  Lack of clarity about RFC streams isn't limited to people
who write RFPs - we see it among IETF participants as well, and if
there's a way to improve signaling about distinctions between
document types, we should talk about it.

Melinda

---

From: Ted Hardie <[email-masked]>
Date: Mon, 2 Jul 2018 13:20:15 -0700

On Mon, Jul 2, 2018 at 12:30 PM, John C Klensin <[email-masked]> wrote:

> its audience(s).

The IAB has discussed related issues many times.  As an example, the IAB
and the IRTF Chair have discussed whether the current stream-based system
is understood sufficiently well by the academic community that the work in
the IRTF is getting credit for its participants in proportion to the
quality of the work.

Speaking as IAB Chair, I believe that the IAB has consensus that a public
discussion of these issues is the right step to take at this time.  That
does not mean that the framing of this in terms of this experiment has (or
needs) IAB consensus.  As a BoF in the general area, it needs proponents,
and I am grateful to Martin and Melinda for taking that on.

Speaking personally, I'm glad to have a concrete suggestion in front of the
community.  The question of what data is needed seems to be getting a
different sort of attention with that in front of the community than a more
nebulous discussion might have, and I hope that the BoF is productive as a
result.

regards,

Ted

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Jul 2018 12:09:02 +1200

Ted,

> new identifier (either as an addition or a replacement for RFC numbers) for

It seems to me that 'addition' and 'replacement' are fundamentally
different. 'Addition' is clarification and I doubt if anyone would
be against it. 'Replacement' raises all kinds of questions about what
the RFC series is for and who can decide about it.

> not, at least as I see it.

That depends on the nature of the changes proposed.

> Again, my personal view,

Understood, and ditto, of course.

    Brian

---

From: John C Klensin <[email-masked]>
Date: Tue, 03 Jul 2018 12:37:22 -0400

(Apologies in advance for the length of this -- I think this
note addresses a critical issue affecting whether the BOF will
be useful (or is even worth holding). I cannot explain it in
sufficient detail to make the issue clear without some
background and in a few short sentences.  If we were not past
the deadline, I might have considered posting this as an I-D,
but we are.)

--On Monday, July 2, 2018 11:38 -0800 Melinda Shore
<[email-masked]> wrote (with Subject Re: [Rfcplusplus]
Another RFC experiment):

> it wasn't my proposal.  I do think, however this is the right
> time to have this discussion, assuming that it's not driven
> off the rails, turns into a bikeshedding exercise, or
> otherwise loses its focus.  Lack of clarity about RFC streams
> isn't limited to people who write RFPs - we see it among IETF
> participants as well, and if there's a way to improve
> signaling about distinctions between document types, we should
> talk about it.

I think this is fair (although I still have concerns as to
whether this is our most important issue to address), but want
to focus, at least temporarily, on the the BOF description and
part of Martin's note and I-D...

--On Tuesday, July 3, 2018 17:32 +1000 Martin Thomson
<[email-masked]> wrote:

>...
> However, based on the feedback thus far, it seems like it
> might be good to examine some of the more fundamental issues:
> 
> 1. What is the problem?
> 
> I think that the problem is well understood.  The common
> perception of "RFC" encompasses a far simpler notion than the
> reality.
>...

Sure.  But, for example, the common perception of "IETF" is also
far simpler than the reality.  One could, for example, ask
whether "IETF" includes the IAB or not and, if not, just what
the relationship is and what authority the IAB actually has
because those topics are part of the answer about the IETF.  In
the early 1990s the relationships seemed clear but what could be
seen as a disagreement between the IAB and what is loosely
called "the IETF community" (which may or may not be the same as
"the IETF") led to what we call the Kobe meltdown and the POISED
process.  That ultimately ended in a re-sorting of
responsibilities but left a number of loose ends dangling, with
the main definitional documents being "charters" for the IESG
and IAB that were written by those bodies to describe their
perceptions of their roles with how much those definitions
represent community consensus, especially informed community
consensus, as an open set of questions.  FWIW, the role and
authority of the RFC Editor function was, and is, another of
those loose ends.

It can be argued that set of questions leads directly to the
bike shed.  Alternately and with equal force one could argue
they they are the critical issues.  If they are, then questions
of how one identifies documents published by the RFC Editor
Function or on behalf of a broad definition of this community is
the real triviality.  But let's look at the RFC question.  

Your explanation of "the problem" above appears to be consistent
with the abstract in the posted version of your I-D but less so
with parts of the body of that document and quite different from
the explanation in the BOF description.   Having recently been
taken to task by the IESG for writing a BOF proposal that seemed
to suggest an open-ended discussion rather than something more
focused, it would, IMO, be consistent and helpful to be more
clear about your view of the problem.  In addition, the
observation that perceptions differ is not inherently a problem
that needs to be solved or that is solvable.  The comments about
the definition of the IETF above is an example of that -- we
have twitches, and occasionally those are important, but we've
managed reasonably well for more than 20 years without stopping
to really nail those issues down.  As a more trivial example, my
neighbors probably have a general sort of agreement about
whether or not "it is really hot outside" is a correct
statement, but, if one tries to pin down the details of the
individual perceptions and the boundaries associated with them,
one would almost certainly find that perceptions differ widely,
probably very widely (and even more widely if one compared
answers in Anchorage, Oyster Bay, Boston, or Phoenix).  However,
this differences are rarely a problem in need of solution.

However, the BOF proposal and the Introduction to your I-D
appear to be talking about a more concrete problem, the one
described in RFC 1796 and often discussed in terms of lack of
clarity about the sources of RFCs causing confusion about what
is and not a Standard or, more specifically, an IETF one (given
that we have republished, with permission, the standards of
other bodies in the series).   I want to challenge that problem
view and, with it, the assertion in the draft that "Not a lot
has changed in the 23 years since that statement" because, if
that assertion is false, then there is no problem here worth
solving unless, contrary to Melinda's note, we really want to
take extensive tours of some convenient bike shed or collection
of them.

At least in my perception as someone who has been around and
sometimes very close to these issues since well before 1796 saw
the light of day, a number of things have changed, and changed
significantly, in the relevant 23 years.

In terms of the content of RFC Series documents, at least the
following changes have occurred, motivated in part by the
recommendations of 1796 but, at least in the first case, showing
significant further evolution:

(1) The "Status of this Memo" text has changed, from "This memo
provides information for the Internet community.  This memo does
not specify an Internet standard of any kind. ..." (with
different, but similar, text for BCP and Standards-track
documents) but with no distinction among document sources, to
today's far more elaborate and detailed versions.

(2) The implicit assumptions about the STD numbers in RFC 1796
(and in RFC 1311, which established that numbering system) was
that standards-track specifications that were actually worth
implementing and deploying would rapidly progress to Internet
Standard and, incidentally, that Proposed Standards might be
little more than bright ideas with little evidence of
implementability or utility.  It is probably relevant that the
provision for "automatic review for viability" after 24 months
of Proposed and Draft Standards survived into RFC 2026 and later
(even though it was ignored for years before we got around to
formally eliminating it).  That, too, has changed, but in the
direction of raising the bar for publication as Proposed
Standard and recognizing that many important specifications will
never advance past that level.  

The divergence from that assumption about standardization means
that the (experiment?) proposed for STD in RFC 1796 (using STD
numbers to exhibit distinction, which appears to me to be
slightly different from RFC 1311 which seems to be more about
grouping) has never really been carried out.  We generally think
badly of starting one experiment that builds on another without
first completing and evaluating the earlier one.  Performing
what I think of (and your I-D implies) as the experiment with
STD requires some measure, such as that proposed in 2011 and
earlier as draft-klensin-std-numbers-02 to be sure that
identifier is really on most of all standards-track documents at
any maturity level.   Until we do that, we really have no idea
about the effectiveness of overlay labels in making the
distinctions that the I-D seems to call for.  

We also haven't carried out the actions and implicit experiment
proposed in RFC 1796 until the RFC Editor (and appropriate
tooling) insist on "[STDnnnn]" citation anchors and references
rather than "[RFCnnnn]" ones except in the specific cases in
which a specific document, rather than a standard, is being
cited.  So, again, if RFC 1796 is a relevant authority, we
haven't implemented and examined its recommendations
sufficiently to know that they were inadequate.

Probably more important (and with apologies for some overlap
with Joel's recent comments), I believe we have no evidence at
all about the effectiveness (or lack thereof) of the post-1796
header information and status boilerplate in clearing up the
types of confusion that appear to have motivated RFC 1796.  It
seems to me to be worthwhile to try to understand that before
branching out in other directions, even experimentally (even
assuming a non-destructive, reversible, experiment can be
specified), particularly given an (equally unproven) hypothesis
about what has changed in the last decade:

At the time RFC 1796 was published, there was some evidence that
even well-intentioned people who were willing to try to
understand distinctions were being confused: the status
statements were not focused enough and no distinction was made
about origins or what we now call streams.  With the
understanding that the evidence I've seen is completely
anecdotal, I'm seeing a lot less of that type of confusion in
recent years than I saw decades ago.  Instead, most of the
confusion I see appears to be the result of intentional actions
on the part of those associated with documents or standing to
benefit from incorrect perceptions of their documents.   As Joel
mentioned, we've not only seen Independent Stream Informational
RFC mischaracterized as standards or "IETF documents", we've
seen many Internet Drafts characterized that way.

In particular, if a document that is attempting to mislead
includes a reference that looks like, e.g., 

	Waitzman, D., "Standard for the transmission of IP
	datagrams on avian carriers", IETF, April 1990,
	https://www.rfc-editor.org/rfc/rfc1149.txt

Only a quite astute and knowledgeable observer will be able to
deduce that this is an RFC rather than an I-D.  To figure that
out, is necessary to parse the URL.  It is not clear that
re-identifying it to, e.g., HaHa1149, also detectable only by
parsing the URL, would improve the distinction between it and a
standard either.  Whether "IETF" in that reference is a lie gets
back to the "what does IETF mean" topic that I mentioned earlier
in this note, but someone who is trying to deceive is unlikely
to look deeply into that distinction.
	
IMO, that makes a precise problem statement very important.  If
the issue is to correct, reduce, or eliminate confusion in which
everyone involved is well-intentioned, there is little evidence
that there is a significant problem left to solve (there might
be, but there is little evidence and you certainly cannot rely
on RFC 1796).  If it is to eliminate or significantly reduce
confusion that is introduced, more or less deliberately, for
marketing or other purposes, we do have evidence that the
problem may not be worth solving unless the solutoin somehow
addresses the I-D issue as well.

best,
   john