Subject: [Rfcplusplus] Fwd: I-D Action: draft-carpenter-request-for-comments-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 6 Jun 2018 15:19:21 +1200

-------- Forwarded Message --------
Subject: I-D Action: draft-carpenter-request-for-comments-00.txt
Date: Tue, 05 Jun 2018 20:16:12 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Request for Comments
        Author          : Brian Carpenter
	Filename        : draft-carpenter-request-for-comments-00.txt
	Pages           : 7
	Date            : 2018-06-05

Abstract:
   This document discusses the Internet technical community's common
   document series.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-request-for-comments/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-carpenter-request-for-comments-00
https://datatracker.ietf.org/doc/html/draft-carpenter-request-for-comments-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Barry Leiba <[email-masked]>
Date: Wed, 6 Jun 2018 06:24:13 -0400

Brian, the draft appears to be saying, essentially, that we shouldn't
make the sorts of changes to the RFC series that we've proposed to
discuss here because the RFC series is an old and venerable thing and
shouldn't be changed.  I don't buy it.

The primary thing I don't buy is that "RFC" still means "request for
comments".  At some level, sure, it does, because people can and will
comment on RFCs, submit errata reports, and so on.  But most of the
world thinks of RFCs as IETF standards, with some subset understanding
that the series also contains informational and experimental stuff.
The comment period, really, is during the development of the Internet
Drafts.  One only needs to look at the strict scrutiny performed by
the IESG to see that the bar for getting to RFC is well beyond that
warranted for the publication of a request for comments.

As to ownership, I agree that the series is owned by "the community",
and it's exactly that community we're calling on for discussion of
proposed changes.  If we think that, for example, the IRTF is being
short-changed here, we have only to publicize this discussion to the
IRTF an ask them to come be part of it.  The same goes for any other
sub-community we think isn't adequately represented.

Apart from that, I see little substance in the draft about your
objection to considering the sort of change proposed here (apart from
the "request for comments" part).  Can you be clearer, not about the
history of the RFC series, but about specifically why you think such a
change would be bad?

Barry

On Tue, Jun 5, 2018 at 11:19 PM, Brian E Carpenter
<[email-masked]> wrote:
> Rfcplusplus mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rfcplusplus

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 7 Jun 2018 08:33:11 +1200

I'm out of time at this moment, but no, that isn't the argument.

The argument is that having a single document series that is specifically
named as not being dogma is the right thing to do.

Better labels are a good idea, within that series, for sure.

Regards
   Brian

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 6 Jun 2018 17:26:50 -0400

I could also use some clarification, Brian. My take away from the
draft was, "we have a bunch of ongoing experiments, it would not be
wise to start another one until those have completed". What am I
missing?

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Barry Leiba <[email-masked]>
Date: Wed, 6 Jun 2018 19:20:50 -0400

> named as not being dogma is the right thing to do.

OK, I got that; thanks.
Unfortunately, that's a matter of opinion that we differ on, and I
think it's likely that neither of us is going to convince the other.

Barry

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 7 Jun 2018 17:13:24 +1200

> wise to start another one until those have completed". What am I

That is one of the takeaways. Let's figure out why past attempts,
especially the STD designation, haven't fixed a problem that was
first documented in 1994. Probably the problem is deeper than
just document labels, so let's figure out the problem too.

This can't be very urgent, because we've managed for the last 24 years.

There are at least two other points too:

1. The RFC series belongs to everybody, not just to the IETF.
So we can't unilaterally decide for everbody.

2. It is good for the IETF to be fundamentally modest and open
to feedback about its work. Calling all our documents "request for
comments" is therefore highly appropriate.

Regards
   Brian

---

From: Adam Roach <[email-masked]>
Date: Thu, 7 Jun 2018 00:22:54 -0500

> Better labels are a good idea, within that series, for sure.

As a thought experiment (and taking care to note that I am not proposing 
this, merely laying it out as a hypothetical): Would you be opposed to 
the prospect of issuing no further documents with designations of 
RFCXXXX, and instead starting the numbering over with, say, RFC-S0001, 
RFC-B0001, RFC-N0001, RFC-I0001, RFC-E0001, RFC-R0001, and RFC-A0001 for 
"standard", "BCP", "informational", "ISE", "experimental", "IRTF", and 
"IAB", respectively?

/a

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 7 Jun 2018 17:44:24 +1200

> "standard", "BCP", "informational", "ISE", "experimental", "IRTF", and 

a) I'm sure the details of that could stand a great deal of bike-shedding,
but let's ignore that for now.

b) I don't want to form a firm opinion instantly, but I think this
is the sort of re-labelling exercise that might bridge the gap.
Certainly it's worth discussion (but I stick to the idea that we
need to be clear about the problems we're trying to solve).

   Brian

---

From: Adam Roach <[email-masked]>
Date: Thu, 7 Jun 2018 00:51:43 -0500

> need to be clear about the problems we're trying to solve).

Thanks. I was hoping to see if I could tease some of your concerns 
apart, and I think your reaction -- that is, the fact that you didn't 
reply with "that has largely the same problems as the existing proposal" 
-- is very helpful in understanding your primary objections.

/a

---

From: Melinda Shore <[email-masked]>
Date: Wed, 6 Jun 2018 22:38:41 -0800

I think there's this fundamental question that perhaps
drove the initial discussion leading to the BOF proposal,
which is whether or not there are distinctions between
categories of RFCs that matter.  One that does seem
consequential, for example, is the difference between
documents that reflect IETF consensus and documents that do
not reflect IETF consensus.  If these are distinctions we
care about, should that be reflected in how they're published?

I'm not really in love with the proposed experiment but I
do think that we're at a point in the maturity process of
both the IETF and the internet more broadly that it's a
discussion worth having.  (I'm a little concerned that
we'll end up rat-holing on the proposal, but I'm also hopeful
about a well-managed discussion).

Melinda

---

From: Barry Leiba <[email-masked]>
Date: Thu, 7 Jun 2018 10:49:15 +0200

> One that does seem

> not reflect IETF consensus.

Necessary, but not sufficient.  In current usage, all IETF stream documents
get IETF consensus (they all go through last call), but we do need to
distinguish standards track from experimental, and both of those from
informational.

Barry

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 7 Jun 2018 04:31:46 -0500

I'm doing my best to listen before speaking ...

On Thu, Jun 7, 2018 at 12:13 AM Brian E Carpenter <
[email-masked]> wrote:

> first documented in 1994.

The IETF Problem Statement RFC from 2004 talks about this in
https://tools.ietf.org/html/rfc3774#section-2.4, but the high-order bit was
that STDs only help specifications at the penultimate level of the
hierarchy ("Internet Standard"). So this is way less mysterious than some
other issues under discussion.

Fixing the STD designation might, or might not, be orthogonal to the
experiment being proposed here.

Spencer

> Probably the problem is deeper than

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 7 Jun 2018 04:42:18 -0500

And, just to avoid confusing more people than I've already confused ...

On Thu, Jun 7, 2018 at 4:31 AM Spencer Dawkins at IETF <
[email-masked]> wrote:

> https://tools.ietf.org/html/rfc3774#section-2.4, but the high-order bit
> was that STDs only help specifications at the penultimate level of the

"... the ultimate level of the hierarchy".

("Must not send e-mail about process BOFs while watching the QUIC interim
meeting. Must not send e-mail about process BOFs while watching the QUIC
interim meeting ...")

Thanks, Barry, for poking me about this.

Spencer

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 7 Jun 2018 10:02:19 -0500

> get IETF consensus (they all go through last call), but we do need to

At risk of picking nits (and inflaming old arguments), we did
approve draft-mm-wg-effect-encrypt in the IETF stream with
'consensus: no".

-Benjamin

---

From: Ted Hardie <[email-masked]>
Date: Thu, 7 Jun 2018 15:51:20 -0700

> So we can't unilaterally decide for everbody.
Since RFC 4844, the RFC series has had a pretty clear concept of "streams"
and "stream managers".  So I don't think we actually need to poll
"everybody" to work out whether something is acceptable--we already have
designated managers, each of which has a pretty strong sense of
accountability to both the broader technical community and the health of
the Internet.

While this BoF lays out the question in terms of RFC 1796, a different way
of asking this question would be:

"We've had streams with different managers and characteristics since RFC
4844, but that doesn't seem to translate into public understanding of their
differences despite the internal markings.  Should we try an experiment
that adjusts the external labels as a new step in making the streams
identifiable?"

regards,

Ted

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 8 Jun 2018 15:07:42 +1200

> that adjusts the external labels as a new step in making the streams

It's worth a discussion. But I think there are two problems closely linked
to that one, which are actually more important:

1. That people, with the best will in the world, cannot reliably find
the *latest* version of a standard, which I'm sure most of them expect
STDnnnn to lead them to, if they know at all that STD numbers exist.

2. That people cannot find a reliable guide to all the documents
of all categories that cover a given topic.

Proposals for solving these problems have been made in the past,
but our users (readers of RFCs) still have them.

   Brian

---

From: Adam Roach <[email-masked]>
Date: Thu, 7 Jun 2018 22:56:47 -0500

On 6/7/18 10:07 PM, Brian E Carpenter wrote:
> It's worth a discussion. But I think there are two problems closely 
> linked to that one, which are actually more important...

Relative importance is somewhat subjective. I have seen very little pain 
from the first one you describe, mostly due to the ready availability of 
"obsoleted" information in both the datatracker and on tools.ietf.org. 
The second is definitely an issue, but it seems rather unrelated to the 
problem this BOF claims to address. Perhaps a separate effort with its 
own proponents and proposals would be in order for it.

In any case, the proposed experiment certainly leaves a number of 
problems unsolved, and I suspect that's by design. I don't believe a 
grand unified theory of how to fix everything about the IETF's documents 
would be manageable.

/a

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 8 Jun 2018 16:33:21 +1200

> "obsoleted" information in both the datatracker and on tools.ietf.org. 

And on the RFC Editor site. But not, unfortunately when you use an
arbitrary search tool. That's probably an issue we can't solve anyway,
but it seems to me I see it at least as often as experimental RFCs being
mistaken for standards.

> own proponents and proposals would be in order for it.

That's been tried before, and the proposal did include a new document
series. Consensus did not occur in the IESG, for which I share the
blame.
 
> grand unified theory of how to fix everything about the IETF's documents 

Agreed. But selecting one problem whose importance is contested
seems a bit arbitrary.

   Brian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 8 Jun 2018 00:13:30 -0500

> "obsoleted" information in both the datatracker and on tools.ietf.org.

What follows may be the only relevant experience I have with this, but it
was both hilarious and terrifying.

In the early 2000s, I worked for "a large-scale network monitoring vendor"
who had been very successful in noticing and alarming for network
performance problems in SS7 networks, GSM networks (which had a lot of
overlap), GPRS networks, and UMTS networks, and was adding performance
analysis for TCP (not for applications, I was already talking to them about
not being able to do that reliably, and HTTPS was already a thing).

They cracked open the TCP standard, which is STD 7, and implemented
Standard TCP. So, basically, RFC 793 (not even the new material in RFC
1122, because they didn't find that, it's part of a different STD, STD 3,
and this was all before Updates in headers - you can find that STD 3
updates STD 7 in the datatracker now, but stay with me here, because it
wouldn't have mattered if they'd done STD 3 as well).

They came to me with traces of what they were actually seeing on live
traffic, and it was LOADS of TCP mechanisms that aren't in RFC 793, and
weren't in RFC 1122, because, heck, yes, people deployed Proposed Standards.

I explained what they were looking at, told them that STDs didn't mean what
one might think, and we all had a good laugh, because it was harmless fun -
at least at the time, passive network monitors on optical networks didn't
have transmit leads, so you couldn't really shoot anything except your own
foot.

I was talking about this at the next IETF meeting (probably at Newtrk,
because that was still going on), and someone from "one of the largest cell
phone manufacturers in the world" told me his company had done the same
thing, except on cell phones that DID transmit packets, and would have been
using the finest congestion control available in RFC 793, which predated
Slow Start ... and he wasn't laughing.

That's my story. Mileage may vary for other people. I have no idea how
unique it was, or whether anything like that will ever happen again.

But sometimes it stinks that nobody except maybe us knows what standards
actually are ...

I'm back to lurking. Enjoy your Fridays, all.

Spencer

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 9 Jun 2018 15:12:50 +1200

> experiment being proposed here.

I don't think it's orthogonal. I think this is part of the confusion in
the "market", exemplified by the ancient comment that "The Internet runs
on Proposed Standards." [Fred Baker, I think, said that first.] If you
aren't doing the right thing by implemementing an "STD", because it's
been superseded by a mere RFC, why are you going to believe that the
label matters at all?

If RFC-PS9876 supersedes RFC-STD8200, how is a reader of 8200 supposed
to know that? The label doesn't help in the least; rather the opposite,
since STD is clearly superior to PS.

And how is the implementer supposed to know that the real list of IPv6
"conformance" requirements is to be found in draft-ietf-6man-rfc6434-bis-23 ?

There are, IMHO, simply no easy and cheap solutions here. Solving
a small corner of a complex problem seems like a distraction to me.

   Brian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 11 Jun 2018 09:42:45 -0500

I feel bad for pointing this out, but ...

On Fri, Jun 8, 2018 at 10:12 PM Brian E Carpenter <
[email-masked]> wrote:

> was

Yeah, based on my experience and John Loughney's experience, we proposed
https://tools.ietf.org/html/draft-loughney-newtrk-one-size-fits-all-01.

I think there's a variation of Godwin's Law that applies, when that draft
is mentioned during an e-mail discussion ...

Spencer

> >>>>>>         Filename        :
> draft-carpenter-request-for-comments-00.txt
> >>>>>>         Pages           : 7
> >>>>>>         Date            : 2018-06-05
> >>>>>>
> >>>>>> Abstract:

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Jun 2018 09:55:45 -0600

On 06/07/2018 09:07 PM, Brian E Carpenter wrote:
>...

And I would add a much more difficult "it would be nice" item of:

   3. What are people really using, or getting ready to implement?

A nice web page listing: protocol, latest standard, proposed standards, 
hopeful document(s), and with a big bold "X" indicating that someone 
implemented this, and maybe a little 'x' if they are planning to in the 
near future.

Because I really don't like evaluating a document, digging in deep, only 
to find that no one cares to use the latest neat idea.

-- 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jun 2018 08:29:37 +1200

On 12/06/2018 02:42, Spencer Dawkins at IETF wrote:
...
> https://tools.ietf.org/html/draft-loughney-newtrk-one-size-fits-all-01.

I should have cited that in my draft, too. I still think it was the best
proposal around at that time.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jun 2018 11:38:40 -0400

> "standard", "BCP", "informational", "ISE", "experimental", "IRTF", and 

I think that this has some merit.

I don't think it solves the STD 7 vs STD 3 problem that Spencer 
mentioned, which I think perhaps is a more fundamental problem that we 
haven't solved yet.

It does solve the RFC9999 problem :-)