Subject: Re: [IAB] New proposal/New SOW comment period

From: John C Klensin <[email-masked]>
Date: Thu, 03 Oct 2019 15:28:25 -0400

Christian,

I just noticed that I had never responded to your note below.
It deserves an answer, particularly because I think you have
identified a key reason why various of us keep talking past each
other.

Briefly and I hope correctly interpreting your comments, many of
us believe the RFC Series is an Internet Community resource and
publication series and that, when ISOC and the IETF took on
responsibility for it in several stages from the early 1990s
through 2007, it was doing so as, to use Jon Postel's language
form quite a different document, a trustee for that larger
community.  It is obviously reasonable to question that role and
its ongoing appropriateness and to assert that, e.g., the IESG
should have control over what is published.  I can certainly
remember discussions of that issue in 1994.  We had them again
leading up to the publication of RFCs 4844 through 4846 in 2007,
and several times in between and subsequently.  I think it is
safe to say that the community has never been in complete
agreement since the RFC Editor Function was separately and
directly funded by the US Government and probably not even
before then.  I do not, however, see that discussion as "some
people believe one thing and others believe something else" or
"whether the RSOC (and, to some extent, the IAB) agrees with my
understanding of the role and function of the RFC Series".  From
my point of view, the community was asked that question as part
of the "RFC++" discussion of somewhat over a year ago and there
was a fairly clear answer of "not just about the IETF" (both in
terms of the series and what things were called).  If we
disagree about that conclusion, then we have another problem.
But, even if you (and others) believe the outcome of the July
2018 discussions was unclear with regard to the function of the
RFC Series, I think we end up with two issues:

(1) Where the RFC Editor Function is concerned, are the RSOC and
IAB responsible for fairly interpreting community consensus
(even if only EITF community consensus) and following it, or can
they reasonably go off in other directions without any
accountability to the community?

(2) Given that the RFC++ effort was an attempt to redefine the
RFC Editor Function at least with regard to how documents are
named and that it clearly did not get [even] IETF community
consensus, is it reasonable to use Heather's decision to step
down at the end of the year (whether that decision came as a
surprise or was deliberately or accidentally induced) as an
excuse or mechanism for opening the question of the role of the
RFC Editor Function again in such a short time?   And, if it is,
should that question be posed in a balanced way and asked openly
and specifically rather than partially hidden in the plans for
replacing Heather (whether temporarily or permanent, etc.).

FWIW, there are many other questions about the RFC Editor
Function and the RFC Series about which assumptions have been
made for many years but that sensible people can argue are
obsolete.  One that has been raised repeatedly (and that the
RFC++ effort certainly touched on) was whether Independent
Submissions are still necessary and appropriate given all of the
other ways by which information that comes out of the IETF can
be published.   Another is whether the whole idea of archival
documents is necessary any more.  Recent threads on the
rfc-interest list lead me to believe that there are several
members of the community who believe the answer to the latter
question is "no" or perhaps that the IETF model for
authoritative clarifications to standards-track documents is in
need of reopening and reconsideration.

best,
   john

--On Friday, September 13, 2019 11:00 -0700 Christian Huitema
<[email-masked]> wrote:

> On 9/13/2019 7:44 AM, John C Klensin wrote:
> 
>> The difficulty, which several people tried to get a
>> focus on (before IETF 105, at the plenary, and thereafter),
>> was the question of whether the RSOC (and, to some extent,
>> the IAB) understood (generally and consistent with community
>> understanding) the role and function of the RFC Series, the
>> relationship of the RSE to that function, the appropriate
>> interpretation of "oversight", some important management and
>> procurement differences between hiring and management of
>> high-level professional and, procurement of
>> easily-substitutable commodity items.
> 
> John,
> 
> The way you phrase it, there is an eminent understanding of
> the role and function of the RFC series and the RSE that
> everybody should agree on, and you suspect the IAB does not.
> That why you use the word "understood" in the quoted text. I
> think that vocabulary presumes the outcome of the ongoing
> discussion. For example, you and several others including Mike
> and Brian hold it as obvious that "the RFC series is bigger
> than the IETF". That was certainly true in 1981, but I am sure
> there are people who don't believe that in 2019 -- and those
> people are indeed part of "the community".
> 
> You may believe that you have a superior understanding, but
> the correct phrasing would be "the question of whether the
> RSOC (and, to some extent, the IAB) agrees with my
> understanding of the role and function of the RFC Series".

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Oct 2019 21:13:05 +0100

Hi John,

A question and a comment below.

On 03/10/2019 20:28, John C Klensin wrote:
> community.  

On the "larger community" (than IETF/IRTF) aspect, do we have
any definition of how that community might be characterised?

Personally, I can easily see including RFC readers in that,
(otherwise why'd we bother make 'em?) but beyond that, I don't
know what else may be meant. Can you (or someone) clarify?

> It is obviously reasonable to question that role and

Again, speaking personally, I do see two rough positions that
people in the IETF seem to have, and ISTM that divergence is
also reflected in the subset of us currently in IETF leadership
positions. One position might roughly revolve around ideas
that we ought cherish the independence of the RSE and the
longevity of the series, another might be said to revolve around
ways that we should change the series to better reflect
today's reality. (I don't mean that to be in any way a precise
characterisation and once one tried to be precise there
would of course be more than two different positions.) My
take is that both positions seem sincerely held and each has
some merit. (Though I admit I'd be more inclined to cherishing
than changing, as my own starting point.)

In any case, I do think we ought have a community discussion
now about that, given that Heather is (regretfully) moving on
and given the changes to 6635 that seem obvious (to me at
least) now we have the LLC setup.

Cheers,
S.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Oct 2019 09:24:35 +1300

Hi Stephen,
> know what else may be meant. Can you (or someone) clarify?

Not in a few words, but may I point to
https://tools.ietf.org/html/draft-carpenter-request-for-comments ?
The most relevant text is:

   The reasonable conclusion from the above is that none of the I*
   organisations (IETF Trust, IETF LLC, IETF, IESG, IAB or ISOC) can
   claim exclusivity of ownership or control over the RFC series.  It is
   community property and must operate on behalf of the community as a
   whole.

   A first important consequence is that major decisions about the
   future of the RFC Series must be taken by a consensus of a very broad
   community.  That doesn't mean the IETF or the IAB.  It means the IETF
   and IAB, plus the IRTF, plus many other people who have contributed
   to, or made use of, the RFC Series over the last fifty years.  How to
   reach out to this community is in itself a big question.

   A second important consequence is that the position of RFC Series
   Editor answers to the community as a whole, not narrowly to the IAB.
   In particular the RFC Series Editor has considerable independence (in
   addition to the obvious independence of the Independent Series
   Editor).
 
> today's reality. 

I'd rather say "change the IETF standards process to better reflect
today's reality, including how that process interacts with the RFC
series." IMHO it would be a serious mistake to try to fix the IETF's
process only by fiddling with the RFC series.

> (I don't mean that to be in any way a precise

Indeed. 

   Brian

>> _______________________________________________
>> rfc-interest mailing list
>> [email-masked]
>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 3 Oct 2019 21:40:17 +0100

(Changing the subject, hope that's ok)

Hi Brian,

> https://tools.ietf.org/html/draft-carpenter-request-for-comments ?

Sure. I recall reading that before.

>    community property and must operate on behalf of the community as a

I'm not sure that considering this in terms of who owns or
controls what is our best bet TBH, even though that is partly
in contention I guess. It may be easier to first roughly
define what is meant by a "larger community" (though I may
be wrong about that as I often am;-).

>    reach out to this community is in itself a big question.

Do you think that's a different set of people than "RFC
readers"? If so, how?

I guess one could extend it to people affected by the RFC
series, but then you're up to 7.7 billion and counting
which doesn't seem right really.

FWIW, I'm not seeing much in the middle that could be
usefully characterised, although I'm sure there are many
programmers out there who don't read RFCs but who work on
code that includes implementations of RFCs.

Cheers,
S.

PS: Your riff on my rough description of positions below
seems pretty reasonable but not that related to the specific
question above.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Oct 2019 11:40:40 +1300

> (Changing the subject, hope that's ok)

More than OK, thanks.

> be wrong about that as I often am;-).

I agree.
 
> Do you think that's a different set of people than "RFC

As you hint below, implementors may in effect be part of the 
RFC user community even if they don't actually read the text.
And other such as lobbyists and politicians in some cases.
And consumer advocates. So the boundary is bound to be fuzzy.
I don't think there's any point in trying to define it precisely;
we just have to recognise that it's not just "us" for any
reasonable definition of "us", so we have a broad responsibility.

   Brian

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Oct 2019 19:22:36 -0400

Stephen,

> (Changing the subject, hope that's ok)

Probably overdue although I wanted my note to reflect the
subject line Christian used.  So thanks.

General comment: I think Brian's I-D is a very important
contribution to what I increasingly see as the key discussion.
I think (at least) the three of us agree that discussion is due
or overdue (except insofar as we see the core issues as having
been settled in July 2018).  From my personal standpoint,
whatever the IAB or RSOC decide to do to be sure there isn't a
break in the RFC Editor Function on Heather's departure is very
nearly irrelevant except insofar as those decisions foreclose or
preempt options for the future of the RFC Series.
Unfortunately, I see a very real risk of such foreclosure or
preemption occurring, whether by accident or intentionally.

>...
>>    The reasonable conclusion from the above is that none of
>>    the I* organisations (IETF Trust, IETF LLC, IETF, IESG,
>>    IAB or ISOC) can claim exclusivity of ownership or control
>>    over the RFC series.  It is community property and must
>>    operate on behalf of the community as a whole.
> 

I would suggest that it implies not only "readers of RFCs" (your
categorization later in your note) but everyone who is dependent
on them.  To the extent to which we want to be even partially as
an engineering body rather than a recorder of common industry
practices (a long note I wrote about that some time ago, but was
assured that no one had read, might be relevant here) that means
publication, not only of documents that describe the IETF's
conclusions but documents that explain why the IETF might be
wrong under some circumstances and what should be done instead.
It includes procurement people who want to be sure that whatever
they buy conforms to some standard.  That implies that the
standard has to be clear and stable but not that they will ever
read it (if things don't work and they call in the lawyers, it
may imply that the latter, and experts they hire, would need to
read it carefully).  That, in turn, raises some issues about
what "the standard" for a particular topic or protocol really
is, which segues into the Newtrk work that the IESG at the time
blew off but the underlying issues are as significant now as
ever.   

>From my point of view, very few of those issues are actually
separable from each other and, as Brian points out, it "would be
a serious mistake to try to fix the IETF's process only by
fiddling with the RFC series".  I'd actually go a bit further
and suggest that it is hard to think clearly about the RFC
Editor Function without understanding what the IETF --and those
who are, or should be, dependent on its work-- actually need and
want.  If, for example, the IETF were to go significantly in the
direction of turning technical specifications into living
documents, then a different publication model might be needed
(it may be helpful to remember that Newtrk never anticipated
ISDs or other summary documents being part if the RFC Series and
subject to its constraints.  On the other hand, if the IETF were
to move in the direction of 5 year review cycles and completely
replacing earlier documents, that would also force large changes
in the relationship between IETF technical specs and the RFC
Series.

> which doesn't seem right really.

See above.  I think that, wrt the RFC Series and the RFC Editor
function, it would help a lot if the IETF and IAB assumed the
role of trustees for that broader community, thought carefully
about what that would mean, shared those thoughts as widely as
possible, and opened them for discussion.

>...

best,
   john

---

From: Christian Huitema <[email-masked]>
Date: Fri, 4 Oct 2019 00:51:15 -0700

John,

Your note deserves a longer reply, but I can start with a brief answer.

Starting from your last point, I do believe that the Independent Stream
and its Editor provide an important function in the standard process,
both for checks and balance, so that independent contributions can be
published in the RFC series without endorsement or agreement from IETF
Working Groups or the IESG, and for providing an avenue for publication
of specification created outside of the IETF. I have all reasons to
believe that this process is working quite well, and no desire to change
that. The principles of RFC 1796 are still relevant.

I also believe that the RFC series is today pretty much centered on the
IETF. Over 80% of the publications are in the IETF stream, 15% in the
Independent stream, with IRTF and IAB sharing the reminder. But then,
these last three streams are in practice just as focused on the IETF as
the IETF stream itself. The overwhelming majority of the document
authors also participate in the IETF, contribute to WG, write drafts,
etc. The document themselves are generally part of the IETF discussion,
even if they are research pieces or independent publication. These
observations make me extremely skeptical about the supposed Internet
Community that would contribute to the RFC series independently of the
IETF. In practice, I don't see any evidence that such an independent
Internet Community exists today.

I have heard Brian Carpenter's argument that if there is not an
authorship community, there is a readership community. That leaves me
skeptical. Clearly, authors and publishers should care about their
readership, and I wish we had better ways to assess the impact of our
publications. But passive readership does not create a community, no
more than me reading ITU publications makes me part of the ITU
community. What creates a community is engagement, contributions and
sharing. I see that happening in the IETF and the IRTF. I wish more
people would participate, but in practice this means increased openness
of the IETF, recruiting existing communities and open source projects, etc.

The RFC series are part of our history and our tradition. Our tradition
is based on solid principles, such as open standards, openly documented,
easy to access, easy to read, well archived. Our tradition also gives us
the strong "RFC" brand, which we would be silly to jeopardize with some
kind of "new Coke" effort. Heather has done a lot of work to modernize
the format, the reference tools and the archival tools without breaking
too much from that tradition. That's great.

At the same time, there is a tension between the tradition and the need
to serve and recruit a wider community. Our document production time is
counted in years, and that does not help convincing open source projects
to work with us. Our documents are cast for eternity, errors included,
which does not help the part the part of the readership who wants to
implement standards. Implementing our standards involves a treasure hunt
to find how many RFC have to be read before understanding the whole
picture. And that's before we even consider the potential of confusion
between standards, experiments, independent efforts, and drafts. The
IETF community will need to solve that over time. I assume that this
will imply some sharing of the work between the RFC Editor and the
"superstructure" of the IETF, and I wait to see the discussion happening
in the ad hoc working group. And yes, of course the discussion process
should be open and fair.

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Oct 2019 10:31:49 +0100

Hiya,

Answers to Brian, John, and Christian (from the other
thread) below...

> reasonable definition of "us", so we have a broad responsibility.

I think I disagree about the level of fuzziness that's ok here.
If we extend to all 7.7 billion people then there's no way in
the world anyone could really consult the non-IETF bits of the
community. So I think I'd argue that a direct connection to the
RFC series (e.g. being a reader) is needed if we're to get a
common understanding of this bigger community.

Yes, that'd omit some who implement from stackexchange but that
might be good enough. Personally, I have absolutely no problem
not including lobbyists in our description of that community. (But
note that this need not be exclusionary - all that lobbyist has
to do is read an RFC to get back in:-)

On 04/10/2019 00:22, John C Klensin wrote:
> I would suggest that it implies not only "readers of RFCs"
> (your categorization later in your note) but everyone who
> is dependent on them.

But that is basically the entire planet, right? (So same point
as I made above seems to me to apply.) But if I'm wrong, can
you help me understand (e.g. via examples) who you think is in,
and not in, the community as you envisage it?

On 04/10/2019 08:51, Christian Huitema wrote:
> sharing.

I guess I disagree with you there Christian - ISTM that
at the very least, people who read RFCs and write related
code that is part of many network stacks, but who do not
engage with the IETF or RFC editor at all, do deserve more
consideration than you imply. I can see arguments for a
bigger set of people deserving consideration but omitting
the above example set seems just broken to me.

Cheers,
S.

---

From: Michael StJohns <[email-masked]>
Date: Fri, 4 Oct 2019 12:11:30 -0400

Hi Christian - I thought I'd dive down into some of your specific 
comments on the standardization process.  Subject changed appropriately.

On 10/4/2019 3:51 AM, Christian Huitema wrote:
> to work with us.

To be clear, it's not (only?) the actual document production that takes 
time, but the authoring, and then getting through WG, then various 
twiddles by the IESG, and then finally IETF last call, all before it 
ever gets to the RFC editor for publication.

A while back I managed to move RFC5011 from Proposed to Standard without 
a document action.  From Last Call to the announcement of the standards 
action was about 6 months.   Let me repeat that - 6 months.  And there 
were no RFC editor actions AFAICT.   I think it was most of a year from 
the time I requested the upgrade until it was done.

WRT to Open Source projects:  I keep running afoul of these in that the 
code tends to be where the standard is documented. That's not what we do 
here.   I do understand we need to work with this community, but we also 
need to avoid being captured by any one community.  We also need to have 
people willing to do the hard part of writing the documents and 
shepherding them through the system.

> Our documents are cast for eternity, errors included,
> implement standards.

Generically, erratas cover non-interoperable errors (and the occasional 
error of a constant or a value).  It's pretty rare that not implementing 
an errata will break something AFAICT.   Or do you have a few counter 
examples with implementation experience?

> Implementing our standards involves a treasure hunt
> picture.
This is problematic, but inherent, not so much in the RFC series, but in 
the way we've chosen to do our standards process.  We extend, we rarely 
amend, and we run into problems when we amend.  DNS being the most 
egregious example of this (amend -> DNSSEC, extend -> more RFCs than I 
care to think about) that I can think of with possibly TLS a close 
second.   I think that's more of a standards discussion than an RFC 
series discussion.  Also, it is possible (and has been done) to write a 
"here's what you need to do to implement" RFC.   Perhaps we  (the IETF - 
at some cost) might think of paying someone to do that for a few of the 
more extensive cases?
>   And that's before we even consider the potential of confusion
> between standards, experiments, independent efforts, and drafts.

I rarely have a problem differentiating between the relative values and 
quality of each of these, although I'm getting a little concerned with 
the Informational RFCs coming out of the CFRG that are actually 
cryptographic standards of first publication.   Each and every RFC (or 
at least in the last 10-15 years or so) has the disclaimer to "go check 
XXX to find out what the status of this document is and what 
'informational' or 'experimental' actually means".

Note that this is NOT specific to the IETF.  Every time I delve into the 
worlds of ANSI, IEEE or ISO standards I have to refresh my memory on 
their various varieties of document markings.

> The

Nothing I've seen above really has an impact on the RFC editor as an 
separate institution.  Perhaps I'm misreading this, but perhaps what 
you're implying is that more attention to cleaning up (and speeding up) 
the standards process pre-submission-to-the RFC Editor is warranted?  
What do you see as the RFC Series Editor's role in that?

Later, Mike

---

From: Nico Williams <[email-masked]>
Date: Fri, 4 Oct 2019 11:48:16 -0500

On Fri, Oct 04, 2019 at 12:11:30PM -0400, Michael StJohns wrote:
> time, but the authoring, and then getting through WG, then various twiddles
> by the IESG, and then finally IETF last call, all before it ever gets to the
> RFC editor for publication.

Indeed.  Time spent by I-Ds on the RFC-Editor queue or in AUTH48 is not
_the_ problem, though it can sometimes be _a_ problem.

_The_ problem is that review by _volunteers_ is a time-consuming thing.
To get others (volunteers!) to review _your_ work you have to... also
volunteer to review _theirs_.  Reviewing others' work who are not also
employees of the same org is difficult to justify and/or account for
correctly.

As well, authors of I-Ds are almost never professional writers, and
they're usually not paid to write those I-Ds except as a side aspect of
a larger project.

The cost and value, of review is unaccounted, thus treated as an
intangible, thus difficult to arrange.

Authoring I-Ds, finding homes for them (WGs, maybe having to spin one
up), getting a volunteer community to step up and review your work,
getting past all the process (WG & IETF LC, IESG review) requires a lot
of energy.

> > which does not help the part the part of the readership who wants to

RFC numbers tend to become meaningless as we have more and more of them.

The ITU-T has a much better document naming scheme, and they too have an
immutability property.  Thus ASN.1 is the x.680 document series (x.680,
x.681, x.682) and the encoding rules for ASN.1 are the x.690 series,
and each document gets a "version number" in the form of publication
year and month, and old versions remain accessible and unchanged.

We kinda sorta try to keep RFC numbers rhyming... but it doesn't always
work.  E.g., RFCs 2459 -> 3280 -> 5280.  TLS is another example of the
same thing.

We would do much better to start having series identifiers for related
RFCs.  All the LDAP ones, all the SSHv2 ones, all the PKIX ones, ... -
all related RFCs should be easy to find under one prefix.

We could design such a naming scheme and bolt it onto the existing RFCs,
much like STDs have distinct (and stable) numbers from the RFCs that
back them.

E.g., we could have names like:

  STD-DNS-xx
  RFC-DNS-xx-vv

  STD-PKIX-xxx
  RFC-PKIX-xxx-vv

  ...

Where <xx> or <xxx> is a document number in the series and <vv> is a
version number.

Each of these would resolve, ultimately, to an old-style RFC number for
as long as we continue to assign RFC numbers from the flat RFC series
number space.

I'd really like something like this!  It would greatly help solve a
number of problems.

> > to find how many RFC have to be read before understanding the whole

Yes.  See above.  Though one does get good at it eventually.

> This is problematic, but inherent, not so much in the RFC series, but in the
> way we've chosen to do our standards process.  We extend, we rarely amend,
> and we run into problems when we amend.  DNS being the most egregious
> example of this (amend -> DNSSEC, extend -> more RFCs than I care to think
> about) that I can think of with possibly TLS a close second.   I think
> that's more of a standards discussion than an RFC series discussion.  Also,
> it is possible (and has been done) to write a "here's what you need to do to
> implement" RFC.   Perhaps we  (the IETF - at some cost) might think of
> paying someone to do that for a few of the more extensive cases?

Yes.  We should provide more links like the updated-by/obsoleted-by
links.  But even better, if we had a related series naming scheme (see
above).

> quality of each of these, although I'm getting a little concerned with the
> Informational RFCs coming out of the CFRG that are actually cryptographic
> standards of first publication.   Each and every RFC (or at least in the
> last 10-15 years or so) has the disclaimer to "go check XXX to find out what
> the status of this document is and what 'informational' or 'experimental'
> actually means".
> 
> worlds of ANSI, IEEE or ISO standards I have to refresh my memory on their
> various varieties of document markings.

+1

> separate institution.  Perhaps I'm misreading this, but perhaps what you're
> implying is that more attention to cleaning up (and speeding up) the
> standards process pre-submission-to-the RFC Editor is warranted?  What do
> you see as the RFC Series Editor's role in that?

A new series naming/numbering scheme would though.  That would be my
preference.

Nico
--

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Oct 2019 12:52:04 -0400

Mike,

Strongly +1.  We are attributing too many things to the RFC
Editor Function that are really issues with the standards
process.

Two small additional comments:

(1) You wrote "not (only?) the actual document production that
takes time, but the authoring, and then getting through WG, then
various twiddles by the IESG, and then finally IETF last call,
all before it ever gets to the RFC editor for publication.".
But it isn't "finally IETF Last Call" because there is another
round of IESG twiddling.  In my recent experience, that takes a
minimum of three weeks just to get a document scheduled for a
call.  Then IESG members make comments and vote, typically
within 24 hours of the call time.  If any of those is a DISCUSS
or contains comments of significance, there are further delays,
with a month or more after the Last Call closes not being
unusual.  As you point out, the RFC Production Center gets the
document only after that.  My experience has been that, For a
well-written and reasonably short document that doesn't have
"cluster" entanglements with others, the time they take is
usually trivial relative to everything else.

(2) While I agree that there are document marking issues with
other SDOs that are not hugely different from ours, their
specific review cycles tend to keep them out of the problems we
get into by a collection of extensions, amendment documents that
don't quite replace the originals, replacements that don't
address all outstanding issues, and so on.  While not technical
standards, the IASA2 work has illustrated many of those
problems: ANSI, IEEE, and ISO procedures would make it nearly
impossible to publish a new document that said "this revision
does not address the following problems that are believed or
known to be significant".   While not a perfect solution, the
work of the NEWTRK WG tried to address some of the issues
associated with our collections of related documents but was
never formally considered outside the WG because the IESG
refused to issue a Last Call, so we are not making much progress
in that area.

best,
   john

--On Friday, October 4, 2019 12:11 -0400 Michael StJohns
<[email-masked]> wrote:

> Hi Christian - I thought I'd dive down into some of your
> specific comments on the standardization process.  Subject
> changed appropriately.
> 
>> At the same time, there is a tension between the tradition
>> and the need to serve and recruit a wider community. Our
>> document production time is counted in years, and that does
>> not help convincing open source projects to work with us.
> 
> To be clear, it's not (only?) the actual document production
> that takes time, but the authoring, and then getting through
> WG, then various twiddles by the IESG, and then finally IETF
> last call, all before it ever gets to the RFC editor for
> publication.
> 
> A while back I managed to move RFC5011 from Proposed to
> Standard without a document action.  From Last Call to the
> announcement of the standards action was about 6 months.  
> Let me repeat that - 6 months.  And there were no RFC editor
> actions AFAICT.   I think it was most of a year from the
> time I requested the upgrade until it was done.
> 
> WRT to Open Source projects:  I keep running afoul of these
> in that the code tends to be where the standard is documented.
> That's not what we do here.   I do understand we need to
> work with this community, but we also need to avoid being
> captured by any one community.  We also need to have people
> willing to do the hard part of writing the documents and
>> which does not help the part the part of the readership who
>> wants to implement standards.
> 
> Generically, erratas cover non-interoperable errors (and the
> occasional error of a constant or a value).  It's pretty rare
> that not implementing an errata will break something
> AFAICT.   Or do you have a few counter examples with
> implementation experience?
> 
> 
>> to find how many RFC have to be read before understanding the
>> whole picture.
> This is problematic, but inherent, not so much in the RFC
> series, but in the way we've chosen to do our standards
> process.  We extend, we rarely amend, and we run into
> problems when we amend.  DNS being the most egregious example
> of this (amend -> DNSSEC, extend -> more RFCs than I care to
> think about) that I can think of with possibly TLS a close
> second.   I think that's more of a standards discussion than
> an RFC series discussion.  Also, it is possible (and has been
> done) to write a "here's what you need to do to implement"
> RFC.   Perhaps we  (the IETF - at some cost) might think of
>>   And that's before we even consider the potential of
>>   confusion between standards, experiments, independent
>> efforts, and drafts.
> 
> I rarely have a problem differentiating between the relative
> values and quality of each of these, although I'm getting a
> little concerned with the Informational RFCs coming out of the
> CFRG that are actually cryptographic standards of first
> publication.   Each and every RFC (or at least in the last
> 10-15 years or so) has the disclaimer to "go check XXX to find
> out what the status of this document is and what
> Note that this is NOT specific to the IETF.  Every time I
> delve into the worlds of ANSI, IEEE or ISO standards I have to
> refresh my memory on their various varieties of document
> markings.
> 
>> The
>> IETF community will need to solve that over time. I assume
>> that this will imply some sharing of the work between the RFC
>> Editor and the "superstructure" of the IETF, and I wait to
>> see the discussion happening in the ad hoc working group. And
>> yes, of course the discussion process should be open and fair.
> 
> Nothing I've seen above really has an impact on the RFC editor
> as an separate institution.  Perhaps I'm misreading this, but
> perhaps what you're implying is that more attention to
> cleaning up (and speeding up) the standards process
> pre-submission-to-the RFC Editor is warranted?  What do you
> see as the RFC Series Editor's role in that?
> 
> Later, Mike

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Oct 2019 13:07:57 -0400

--On Friday, October 4, 2019 11:48 -0500 Nico Williams
<[email-masked]> wrote:

> The ITU-T has a much better document naming scheme, and they
> too have an immutability property.  Thus ASN.1 is the x.680
> document series (x.680, x.681, x.682) and the encoding rules
> for ASN.1 are the x.690 series, and each document gets a
> "version number" in the form of publication year and month,
> and old versions remain accessible and unchanged.
>...
> We would do much better to start having series identifiers for
> related RFCs.  All the LDAP ones, all the SSHv2 ones, all the
> PKIX ones, ... - all related RFCs should be easy to find under
> one prefix.
> 
> We could design such a naming scheme and bolt it onto the
> existing RFCs, much like STDs have distinct (and stable)
> numbers from the RFCs that back them.
> 

Nico,

I won't try to spend the time today to explain why that would
cause a different set of problems other than to note that we
often process documents that don't fall neatly into one category
and that would just cause other arguments and uncertainties.

At the risk of excessive kicking of dead horses, I note that
there have been multiple proposals to assign STD numbers to
standards track documents at Proposed.  STF numbers have, as you
more or less point out, never served their intended purpose
because we advance so few documents past Proposed but they do
perform the grouping function you are looking for.   There were
also pieces of the NEWTRK work that would have provided a clear
structure for documents that would group others, explain what
actually was "the standard" for a particular topic area, and
even allow for incorporating comments on interoperability status
and errata.  There were similar, earlier proposals for grouping
and status documents, as well as attempts to get more effort
into Applicability Statements with the same intent.  All of
those efforts met the same fate: the IESG wasn't interested in
them or willing to initiate IETF Last Calls.  And no one in the
community was willing to press that, e.g., by appealing the
IESG's non-action of WG Last Call requests, at least in part
because of concern that the appeal process would be damaging to
the community and that the IESG would, even if they were told to
rethink the decision, either reaffirm it or figure out other
ways to kill an idea they didn't like.

best,
   john

---

From: Nico Williams <[email-masked]>
Date: Fri, 4 Oct 2019 12:42:20 -0500

> cause a different set of problems other than to note that we

Maybe you can try tomorrow then?  I don't see any obvious problems.

> and that would just cause other arguments and uncertainties.

I don't see how that's an issue.  Those can just get a plain ol' RFC
number.

>      [...].  There were similar, earlier proposals for grouping

Perhaps so, but a) the IESG is not an unchanging body, b) this seems
like as good a time as any to bring this up again.  If no one cares for
this, then no one cares for this.  Let's see.

Nico
--

---

From: Michael StJohns <[email-masked]>
Date: Fri, 4 Oct 2019 13:55:15 -0400

> year and month, and old versions remain accessible and unchanged.

*laugh*  But then you end up with weirdnesses like X.500 vs X.509.  I 
*know* why the certificate stuff started out in Directory oh so many 
years ago, but in hindsight maybe not where it should be today?

Or you end up with something like DNS running out of series numbers and 
others requiring a series for a single document.   ITU tends to be MUCH 
more formal about which documents and standards they will even start 
working on (e.g. a "work plan") before they ever start allocating 
numbers.  They also *require* a document to reviewed each period of time 
and updated - that would be a substantial change to our model.   Then 
you have things like TLS 1.0, 1.1, 1.2 and 1.3 that share a negotiating 
strategy and have similar protocols, but might be hard to characterize 
as the same protocol in the ISO model meaning.

If you go into the other direction, you get things like IEEE 802.11 
which depends on 802.1 and has a bunch of sub standards ( *pun 
intended*) such as 802.11ac and that collection seems to change each 
time I go looking.

In any event I think it's TANSTAAFL - you pick one approach, you close 
off others and each has its own flaws.

I'm not opposed to having the conversation, but we need to pick 
something that works for how we do things, or we need to change how we 
do standards.  And that's a conversation I'm not sure we're quite yet 
ready to have.

Later, Mike

---

From: Christian Huitema <[email-masked]>
Date: Fri, 4 Oct 2019 11:21:51 -0700

> the above example set seems just broken to me.

Sure, but if they don't somehow communicate, how do you know they are there?

And if they do communicate, the question is "with whom"? Where do they
send the message saying that they are trying to implement protocol FOO
but they don't get what section 3.1.5 of RFC XXXX really means?
Slashdot? Stack overflow? Some Reddit group? Actually, it would be very
nice if the IETF had a documented feedback channel for such exchanges.
That would be a nice way to grow the community.

-- Christian Huitema

---

From: Nico Williams <[email-masked]>
Date: Fri, 4 Oct 2019 14:32:45 -0500

On Fri, Oct 04, 2019 at 01:55:15PM -0400, Michael StJohns wrote:
> *laugh*  But then you end up with weirdnesses like X.500 vs X.509.  I *know*
> why the certificate stuff started out in Directory oh so many years ago, but
> in hindsight maybe not where it should be today?

You could always assign a new series identifier when an old one stops
bein relevant to a larger family.

And, frankly, though I detest x.400 and x.500 as much as anyone, the
series naming is just fine.  I couldn't care less that ITU-T's PKI
series is x.509 which means it's related to ITU-T's x.500 directory
series.  (x.509 and PKIX being related to x.500 is why we have the
monstrosity of x.500 naming in PKIX, but we're moving past that, and
we've done a lot of PKIX work here instead of there.)

The point is that series naming is very helpful in reducing the number
of things I have to recall in order to find a relevant specification.
Organizing knowledge is, in fact, helpful.

If I'm looking for some ASN.1 encoding rules spec, I just start by
looking for x.690 and go from there.  Try that with RFCs -- you'll need
a search engine, and the RFC-Editor's search engine is damned near
useless, while the I-D tracker is ever so slightly better, but still,
nothing like free-text search.

Now, maybe we just need to improve those search engines, or outsource
the whole thing to general purpose search engines.  But because these
documents are the sort that can be organized with relatively little
effort, doing so seems like no-brainer.

An argument that organizing RFCs this way would be more expensive that
one might think would be an interesting argument.  An argument that it
would be less useful than one might think would also be interesting.

That related series might diverge in time is not really an interesting
argument, IMO.

> Or you end up with something like DNS running out of series numbers
> and others requiring a series for a single document.   ITU tends to be

I wouldn't give lonely RFCs a series number, nor did it follow from what
I wrote that I would.

> MUCH more formal about which documents and standards they will even
> start working on (e.g. a "work plan") before they ever start
> allocating numbers.  They also *require* a document to reviewed each
> period of time and updated - that would be a substantial change to our

Not relevant to the series concept.

> model.   Then you have things like TLS 1.0, 1.1, 1.2 and 1.3 that
> share a negotiating strategy and have similar protocols, but might be
> hard to characterize as the same protocol in the ISO model meaning.

The point is to organize the specs in a meaningful way.  For users and
implementors, organizing TLS 1.0 through 1.3 as a single versioned
series is perfectly reasonable.

If at some point we end up wanting a new series for just TLS 1.53, then
we could do that too.

> If you go into the other direction, you get things like IEEE 802.11 which
> depends on 802.1 and has a bunch of sub standards ( *pun intended*) such as
> 802.11ac and that collection seems to change each time I go looking.

Thus versioning.  There has to be some degree of immutability.  But also
some degree of familiarity where it's useful.

> In any event I think it's TANSTAAFL - you pick one approach, you close off
> others and each has its own flaws.

Not so.  You could have a document appear in any of zero, one, or N > 1
series -- whatever's appropriate.

> I'm not opposed to having the conversation, but we need to pick something
> that works for how we do things, or we need to change how we do standards. 
> And that's a conversation I'm not sure we're quite yet ready to have.

If you laugh at, and discount an idea without considering it in any
seriousness, then you're right: you're not ready to have that
discussion.

Nico
--

---

From: Keith Moore <[email-masked]>
Date: Fri, 4 Oct 2019 15:46:38 -0400

On 10/4/19 3:32 PM, Nico Williams wrote:

> series naming is just fine.

Well, sure.   After all, there's no need to rename specifications that 
were never broadly adopted, and which are cited more for historical 
interest than anything else.

Keith

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Oct 2019 15:48:37 -0400

Nico,

Mike's examples of the ITU-T and IEEE 802.x problems should be
suff9icent to put your naming proposal to rest, but let me add
two examples of the sort of question I was thinking about.   

(1) RFCs 5890-5894 and maybe 5895 and others are collectively
known as "IDNA2008".  Do they become RFC-IDNA-nn or, given what
they do, RFC-DNS-nn?  And are other documents that specify
special characteristics or syntax for DNS labels become part of
RFC-DNS-nnn or are they separate?  Similarly, are DNSSEC and the
various encrypted DNS query specs and proposals properly
RFC-DNS-nn or do they get their own subseries?

(2) There are interesting dependencies among PRECIS work, IDNA,
specifications for language negotiation, language tag and media
type specifications, and the several interdependent
specifications for non-ASCII email addresses.  If each
specification get a single number --regardless of which
sub-series it is associated with -- then the system breaks down
with regard to the other groups.  In particular, are the latter
group part of email or part of some more or less generic I18n
category?

I think any way you would go with this would either require
drastic changes in how we do standards or would turn out to
create as much confusion as it solved.

>...
>>      [...].  There were similar, earlier proposals for
>>      grouping and status documents, as well as attempts to
>> get more effort into Applicability Statements with the same
>> intent.  All of those efforts met the same fate: the IESG
>> wasn't interested in them or willing to initiate IETF Last
>> Calls.  And no one in the community was willing to press
>> that, e.g., by appealing the IESG's non-action of WG Last
>> Call requests, at least in part because of concern that the
>> appeal process would be damaging to the community and that
>> the IESG would, even if they were told to rethink the
>> decision, either reaffirm it or figure out other ways to kill
>> an idea they didn't like.
> 
> Perhaps so, but a) the IESG is not an unchanging body, b) this
> seems like as good a time as any to bring this up again.  If
> no one cares for this, then no one cares for this.  Let's see.

I don't believe the IESG's willingness to actively encourage and
process proposals for significant process changes, at least ones
that that they did not originate, have changed much and might
have gotten worse.  But I do care and maybe some others do, so
let me pose a question: if any ADs would like to see either the
NEWTRK "ISD" or the related most recent "assign STD numbers at
Proposed Standard" I-D reposted so they could either sponsor
them or start a serious effort to launch a "reform the standards
process" WG, would they please speak up?   And, if they don't, I
would encourage people who care about this issue to either
volunteer for the IESG or at least be willing to speak to the
Nomcom about its importance.

best,
   john

---

From: Nico Williams <[email-masked]>
Date: Fri, 4 Oct 2019 15:21:51 -0500

> two examples of the sort of question I was thinking about.   

And yet they weren't.

> they do, RFC-DNS-nn?  [...]

Yes, possibly.  I.e., both, if that's deemed to be useful.

>               [...]?  And are other documents that specify

Ditto.

> group part of email or part of some more or less generic I18n

Same answer.  You could have one RFC in zero, one, or more series as
appropriate.

I'd expect an RFC that specifies a new DNS RR type for, say, TLS, to be
in at least a series related to TLS.  I could find the misc RR type in
an IANA registry (since I know to look there), and such an RFC might not
be said to modify core DNS in any way, but it might still be useful for
it to *also* appear in the DNS series.

> create as much confusion as it solved.

One could begin curating "series" like this right now without any change
to anything, though without any authority or process to maintain it it
wouldn't be so valuable.  What process is needed to establish and
maintain such series?

For maintenance, sometime in between WG adoption and AUTH48, the
authors, WG, IESG, or IETF, would get to pick zero, one, or more series
to contain the new RFC.

For establishment we might task WGs with proposing appropriate series.
Or the RFC-Editor might have this as a responsibility.

Since we're discussing the RFC-Editor SOW, and since organizing the
series might be the sort of task that might fall in the RFC-Editor's
purview, I think this is on-topic.

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Fri, 4 Oct 2019 13:28:08 -0700

Skickat från min iPhone

> 4 okt. 2019 kl. 11:21 skrev Christian Huitema <[email-masked]>:
> 
> 
> And if they do communicate, the question is "with whom"? Where do they send the message saying that they are trying to implement protocol FOO but they don't get what section 3.1.5 of RFC XXXX really means? Slashdot? Stack overflow? Some Reddit group? Actually, it would be very nice if the IETF had a documented feedback channel for such exchanges. That would be a nice way to grow the community.
> 
> -- Christian Huitema
> 
All of the above probably. Contrary to popular opinion the IETF is not the center of the universe. 

There are good sw engineers out there who (#pearlclutch) couldn’t give a penny about what the IETF believe is proper procedure for communicating feedback on whatever.

Cheers Leif

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Oct 2019 22:17:01 +0100

Hiya,

On 04/10/2019 19:21, Christian Huitema wrote:
> Sure, 

As in: you agree that particular set of people do deserve
consideration in the upcoming discussion? If so, I think
that's correct.

But, that implies we should also be thinking if there are
other sets of folks (adding up <<7.7 billion:-) who similarly
deserve consideration.

> but if they don't somehow communicate, how do you know they are there?

For the set I mentioned? Do you really doubt they're there?
I do not.

> And if they do communicate, the question is "with whom"? 

I don't think that's a question we need address at all. That's
just their business.

> Where do they
> Slashdot? Stack overflow? Some Reddit group? 

Yes. stackexchange etc. mostly at present it seems. It'd
once have been things like Dr. Dobbs magazine and/or
comp.<various> via usenet I guess.

> Actually, it would be very

We did discuss exactly that (a stackexchange <something>) at
the IAB retreat - not for IETF process-wonkery like this, but
for protocols that are widely used like HTTP. I think someone
there was gonna look into it but can't recall if anything's
been done since. I can totally such a channel working for HTTP
or maybe DNS, but I'd guess not for this discussion. Might be
worth a try regardless though, even if it didn't work for this
discussion, we'd learn HOWTO.

I do however have a glib answer for how we could try communicate
with people who read some RFCs but who don't otherwise get at all
involved... we write an RFC. Maybe one describing the upcoming
discussion and try see if promoting that in various places gets
any feedback. So there may be a case for writing charter-like
text for the upcoming discussion in an RFC (I guess that'd be
an IAB-stream RFC if we did it).

For other subsets of people, other mechanisms will I guess be
needed, hence me wondering if it'd be good to try characterise
better who might really be in that "bigger" community. We seem
to have identified at least one set of people already so maybe
it'll not be too hard to find more sets or agree we've found
enough.

Cheers,
S.

---

From: Randy Bush <[email-masked]>
Date: Fri, 04 Oct 2019 14:38:30 -0700

> reasonable definition of "us", so we have a broad responsibility.

and we should have the honesty and the humility not to put words in
the mouths of those neither present nor having the floor to speak for
themselves.

randy

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 5 Oct 2019 11:07:27 +1300

> And if they do communicate, the question is "with whom"? Where do they send the message saying that they are trying to implement protocol FOO but they don't get what section 3.1.5 of RFC XXXX reall…

Yes, but it isn't just the IETF. It's all the streams, so the dispatcher for generic queries will have to be (at least externally) the RFC Editor, I think.

On the underlying point - the fuzziness of the community boundary - I really don't believe in magic, or that the community we should worry about is 7.7 billion people. But we would be deluding ourselves to think that we can count the members of the community; we can't even count the members of the IETF. So we really have to accept, IMHO, that there is an open-ended public service responsibility here, not just a responsibility to a well-defined closed community. And if an obscure network operator in Northern Elbonia has a comment to make on an RFC from 1969 tagged in the index as "(Status: UNKNOWN)", that is automatically part of the community discourse, even though we don't know which stream that RFC belongs to.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 5 Oct 2019 15:40:34 +1300

On 05-Oct-19 05:11, Michael StJohns wrote:
...
...
> the way we've chosen to do our standards process. 

Bingo! Changing the RFC series *will not* fix this problem.

My favourite example of this problem is the standards process itself.
This is exactly why I originated what is now at:
https://www.ietf.org/standards/process/informal/
Read it and have a good laugh. We shouldn't underestimate the size
and complexity of the problem.

Beating an old drum (and also indirectly replying to Nico Williams),
people really do need to read the earlier work on this topic:
https://tools.ietf.org/html/draft-ietf-newtrk-repurposing-isd
Whatever the reasons why that document did not progress, it is
very clearly about the standards process, not the RFC series.

I've just looked back at some of my notes from 2005/2006, and what
I see is that vast amounts of IESG time (and worry) then went on things
that today are largely automated by the tracker. The same is probably
true for WG Chairs. In that context,
  "This document proposes that a new document series be created, called
   Internet Standards Documents ("ISD"s) and that these be real
   documents, separate from the underlying RFCs."
seemed pretty scary to a lot of people. So we got:
https://mailarchive.ietf.org/arch/msg/newtrk/j8Si3b0cqnQSX5a5Ee8NIVdyZg4
Maybe today we are better positioned to make progress.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Fri, 4 Oct 2019 23:10:18 -0400

On 10/4/19 10:40 PM, Brian E Carpenter wrote:

> Bingo! Changing the RFC series*will not*  fix this problem.

If I understand what problem is being described, I'm not sure changing 
the standards process would address it either.   (Though I do suspect 
that some changes are in order for other reasons.)

Most standards that are used on a large scale will need to be amended 
and/or extended over time.    Attempting to get everything right the 
first time can easily doom a standard to failure for any of multiple 
reasons (e.g. irrelevance, or too much complexity, or too little ability 
to adapt to changing conditions).

In a sense, the extensions and amendments are signs of success. If 
nobody used the standard, there would probably not be sufficient energy 
to make the changes.

Keith

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 5 Oct 2019 06:38:28 +0200

On 2019-10-05 00:07, Brian E Carpenter wrote:
>> And if they do communicate, the question is "with whom"? Where do
>> they send the message saying that they are trying to implement
>> protocol FOO but they don't get what section 3.1.5 of RFC XXXX
>> really means? Slashdot? Stack overflow? Some Reddit group?
>> Actually, it would be very nice if the IETF had a documented
>> feedback channel for such exchanges. That would be a nice way to
>> grow the community.
> 
> Yes, but it isn't just the IETF. It's all the streams, so the
> dispatcher for generic queries will have to be (at least externally)
> the RFC Editor, I think.
> 
> On the underlying point - the fuzziness of the community boundary - I
> really don't believe in magic, or that the community we should worry
> about is 7.7 billion people. But we would be deluding ourselves to
> think that we can count the members of the community; we can't even
> count the members of the IETF. So we really have to accept, IMHO,
> that there is an open-ended public service responsibility here, not
> just a responsibility to a well-defined closed community.

I agree, and it's an important point.

	Henrik

> And if an
> obscure network operator in Northern Elbonia has a comment to make on
> an RFC from 1969 tagged in the index as "(Status: UNKNOWN)", that is
> automatically part of the community discourse, even though we don't
> know which stream that RFC belongs to.
> 
> Brian

---

From: John C Klensin <[email-masked]>
Date: Sat, 05 Oct 2019 04:02:22 -0400

--On Saturday, October 5, 2019 11:07 +1300 Brian E Carpenter
<[email-masked]> wrote:

> On the underlying point - the fuzziness of the community
> boundary - I really don't believe in magic, or that the
> community we should worry about is 7.7 billion people. But we
> would be deluding ourselves to think that we can count the
> members of the community; we can't even count the members of
> the IETF. So we really have to accept, IMHO, that there is an
> open-ended public service responsibility here, not just a
> responsibility to a well-defined closed community. And if an
> obscure network operator in Northern Elbonia has a comment to
> make on an RFC from 1969 tagged in the index as "(Status:
> UNKNOWN)", that is automatically part of the community
> discourse, even though we don't know which stream that RFC
> belongs to.

I think this is key although I look at it a bit differently.
Nothing I've said implied that we should be seeking consensus
of, much less speaking for, several billion people (nor trying
to enumerate them).   I don't think we should even be trying to
determine consensus among ISOC members or ISOC chapters even
though we presumably could get them enumerated if we asked
nicely.   At the same time, we know they are out there.  We can
identify many of the communities and at least crudely describe
their needs.  We should not presume we can identify all possible
communities or get the description of any one of them and their
needs exactly right.   We don't even make that presumption about
the community of active IETF participants and that is one reason
we talk only about "rough consensus" and not "strong consensus"
or "broad consensus".  To those communities who are part of the
global Internet community and whom we can identify, we owe a
real, good-faith, effort to try to make educated guesses at
their needs and to take what Brian calls an open-ended public
service responsibility and what I described earlier as acting as
trustees for that broader community.  We also have some
obligation to keep looking for and identifying those smaller
communities and clusters, rather than, in the extreme case,
either no one we cannot precisely identify or no one who is not
an active IETF participant, actually counts.

best,
   john

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 5 Oct 2019 12:20:41 +0100

Hiya,

On 05/10/2019 09:02, John C Klensin wrote:
> to enumerate them).

That's not how I read what you and Brian wrote TBH. I did
and still do think that both of you are saying that anyone
affected by the Internet should somehow "count" (in the
future of the RSE discussion) and ISTM that that does end
up setting up someone to grandiosely claim to be speaking
for the entire planet. (I hope none of us really want to
try do that;-) Again, I'd love to be corrected but that's
how I've read your and Brian's mails on this so far.

ISTM that damages the argument that there's more than the
IETF involved - if we can't characterise (characterise, not
"count") the "who else" in some sensible manner then we do
kinda end up where Christian seemed to be starting from.

And just to be clear, I at least have said nothing about
calling consensus for any such grouping. I think we'd be
jumping too far ahead in worrying about that right now TBH.
I'd first like to know the kinds (not numbers, kinds) of
people involved and then worry abut how they might be
consulted.

Cheers,
S.

PS: "ISOC chapters" (and I guess ISOC members if there are
some uninvolved in the IETF) is another totally credible set
of people that ought be considered. The HOWTO for consulting
them also seems easy enough which is good.

> I don't think we should even be trying to

---

From: Randy Presuhn <[email-masked]>
Date: Sat, 5 Oct 2019 09:12:47 -0700

Hi -

> years ago, but in hindsight maybe not where it should be today?

And there are still some of us around who remember when ASN.1 was part 
of the
X.400 series...  (Though in fairness, ASN.1 has mutated significantly 
over the decades.)
If folks think things are immutable, they might need to take a longer 
view of history.

Randy

---

From: Christian Huitema <[email-masked]>
Date: Sat, 5 Oct 2019 11:43:30 -0700

On 10/4/2019 9:11 AM, Michael StJohns wrote:
> To be clear, it's not (only?) the actual document production that
> various twiddles by the IESG, and then finally IETF last call, all
> before it ever gets to the RFC editor for publication.

Yes indeed. I am trying to measure that in
https://datatracker.ietf.org/doc/draft-huitema-rfc-eval-project/.
According to my measurements, the average RFC published in 2018 took 3
years and a half from start of the individual draft to publication. Out
of this, three years were spent in the working group, three months spent
gathering IETF consensus through IETF last call and IESG review, and
three months spent in the publication phase. So it is pretty clear that
if we want shorter cycles the place to look first is the working group
process.

The RSOC and the RSE do care about the time spent in RFC edition, but
this is more a concern with the overall cost of processing than with the
delay impact. Issues such as clustering of RFC cause spikes in load and
delay, and it would be nice if we could make this part of the process
smoother. But overall, functions like copy editing do bring value to the
process and are only a minimal part of the "end to end" delay.

>
> A while back I managed to move RFC5011 from Proposed to Standard
> without a document action.  From Last Call to the announcement of the
> standards action was about 6 months.   Let me repeat that - 6 months. 
> And there were no RFC editor actions AFAICT.   I think it was most of
> a year from the time I requested the upgrade until it was done.

My little study shows that the current end-to-end delay are basically
unchanged from 10 years ago, but are about twice longer than they were
20 years ago. I believe this is due to changes in process occurring
close to year 2000, but I have not investigated which changes caused what.

For software releases, I have observed that long production cycles have
a self-perpetuating effect. If you arrange a large product in a cycle of
"big releases", then multiple participants will try to jam their
preferred feature in the release. They fear that if they miss this
release, it will take years before the next release and that their
customers will not get the desired feature for that long. But when
contributors do that, they increase the complexity of the current
release, which tends to increase production delays. I wonder the same
kind of dynamics are at play in the IETF, with participants trying hard
to get their preferred option in a big standard and thus causing
discussions to last longer.

For software products, the classic cure is to switch from big releases
defined by big features to periodic releases that ship all the features
ready at a given time. The equivalent in the IETF would be to have
periodic publications such as "here is the interoperable version of
protocol FOO as of December 2019". The "living document" effort seems to
me like a step in that direction.

-- Christian Huitema

---

From: S Moonesamy <[email-masked]>
Date: Sat, 05 Oct 2019 12:14:21 -0700

Hi Stephen,
>kinda end up where Christian seemed to be starting from.

That's a good point.

I went through some documents, e.g. RFC 6635 and the discussions 
which happened many years ago.  There is the following in the RFC: 
"to better serve the communities that produce and depend on the RFC 
Series".  I gather that the usage of the word "communities"  is 
intentional, i.e. it means that there is more than one community.

Is the IRTF a subset of the IETF?  If that was the case, they can 
folded into one community.  One side-effect of such a decision is 
that it constrains (future) decisions of the IRTF about its 
identity.  We could hand-wave that question and deal with it when it 
becomes a problem.  As I look back, I would say that this is why the 
IETF ended up with its inconsistent stories.

I assume that the IAB is aware that there are other organizations 
which rely on documents published through the Series.  In my opinion, 
some of those organization might not agree to be seated under the 
IETF umbrella.

There was a comment [1] from Mr Johansson.  There are a few persons 
on the ietf@ mailing list who are ex-IAB members.  I have no doubt 
that they would understand what the comment means.

Regards,
S. Moonesamy

1. https://mailarchive.ietf.org/arch/msg/ietf/3lVQg1IX1HGjgT-ogevbLPHqyyc

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 6 Oct 2019 09:05:29 +1300

Hi Stephen,

> how I've read your and Brian's mails on this so far.

Let me try to answer this by example. Who do you think is in the
community to which RFC7258 (BCP188) is relevant? Or RFC1984,
for that matter. These may be outliers, but that doesn't take
them out of scope.

> kinda end up where Christian seemed to be starting from.

The IRTF is easily identified. The various operator groups and
the RIRs and their customers/members. ISOC and its chapters.
The SDOs that we have formal or informal relationships with.
All product developers and open source developers who implement
RFCs. Government regulators (think cryptography, privacy, network
neutrality). The courts, when IPR issues come up. I don't think
it's at all hard to cite large groups that are affected. What's
hard is knowing when to stop.
 
> calling consensus for any such grouping.

No, indeed not. Calling for comments is easy enough, but calling for
consensus isn't plausible. But I don't think that's what John and I
are saying. 

Regards
   Brian

> I think we'd be

---

From: Michael StJohns <[email-masked]>
Date: Sat, 5 Oct 2019 17:39:36 -0400

Hi Stephen - I hope I've gotten far enough back in this thread to make a 
sensible comment on the topic and sorry for the top post, but I couldn't 
figure where place to paste the various items.

My concern about the broader community is not so much characterizing or 
enumerating them, or binding them into our discussions on the RFC 
Series, but more about ensuring that our (IETF, IAB, IRTF, etc) 
parochial views of the RFC series as authors/users does not limit the 
usefulness of the series to that broader community (e.g. by doing what's 
important to us and only that, without considering what might be 
important to them). As long as the RFC editor was somewhat independent, 
I was pretty sure that there would be resistance to imposing a narrower 
world view (e.g. to bring the RFC series more in line with what the IETF 
needs/wants/demands at the expense of somewhat undefined more global needs).

I think you've got a good grasp on the problem - and I like your 
discussion points with Christian below - I think they're on target.

one more point for thought:  A given document or book generally has a 
somewhat limited community of some sorts - authors, implementers, 
reviewers, teachers, students.  A library - by it's nature - has a much 
broader community, even if you might not be able to enumerate or 
characterize each one.   Maybe that's a better model for thinking of 
some parts of the RFC Editor model?

Later, Mike

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 5 Oct 2019 23:24:55 +0100

Hiya,

> Hi Stephen,
...>
> for that matter. These may be outliers, but that doesn't take

Heh, using my own argument against me, eh:-) That's fair
though. Both are largely but not entirely written for IETF
participants. So yes, 7258 was written also explicitly
considering how other readers might perceive the text And
it wasn't just the editors/authors doing that, many of the
(very many!) comments on the draft considered that aspect.
I didn't check back but don't however recall any major
change made for only that specific reason, it was more a
case of re-wording, mostly for clarity or to avoid specific
potential misunderstandings. I guess the same was true for
1984. The relevant "other readers" are pretty much covered
by your list below, maybe with the addition of tech journos.

> neutrality). 

The above is a good list, thanks. And I can envisage ways one
might try look for feedback from those kinds of people. (Doing
so may fail, but it's doable.)

> The courts, when IPR issues come up. 

I think I'd argue to not go that far on the basis that any
court action involving an RFC likely already involves someone
from the earlier list.

So I guess the question is whether or not people starting from
Christian's position find that a convincing list or not. I do
think it is myself. Christian, what do you think? (Others with
a similar position should feel free to answer too.)

Cheers,
S.

> I don't think

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 5 Oct 2019 23:33:25 +0100

Hiya,

On 05/10/2019 22:39, Michael StJohns wrote:
> important to them). 

Fair point.

> As long as the RFC editor was somewhat independent,
> one more point for thought:Â  A given document or book generally has a
> reviewers, teachers, students.Â  A library - by it's nature - has a much
> characterize each one.Â Â  Maybe that's a better model for thinking of

Yep, I tend to agree that the series has a value over and
above the set of individual RFCs. Not sure I'd be able to
describe that well myself though, but one to ponder.

Cheers,
S.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 6 Oct 2019 11:37:36 +1300

One quick addendum: researchers and educators. I know people
personally who cite RFCs for research & teaching purposes, but
don't participate at all in I*TF activities.

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sun, 06 Oct 2019 00:53:11 +0200

> intangible, thus difficult to arrange.

This is why I'd like to formalize the acknolwedgement process.
Formal (sector) reviews ought to clearly get reviews, and other reviews are
more of an ad-hoc situation.  Having that acknowledgement would, I think,
help justify employee time spent.  It's clearly, as you said, quid-pro-quo.

    > RFC numbers tend to become meaningless as we have more and more of

It is difficult to know that the numbers mean when you are not in the middle
of that WG's efforts.  And, I've had to cite 7951 and 7591 in the same
document, and gotten the wrong one in the wrong place.
(Not sure if I got those right from memory. One is supposed to be JSON)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Christian Huitema <[email-masked]>
Date: Sat, 5 Oct 2019 17:25:54 -0700

> a similar position should feel free to answer too.)

I think that the list above is a plausible definition of the
"readership" of the RFC series. We have feedback channels with many of
those, and it would be nice to get more. On the other hand, I do not
believe that this defines a "community", and I certainly can't see that
as the basis for any serious accountability mechanism.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Sat, 5 Oct 2019 17:34:30 -0700

> don't participate at all in I*TF activities.

Yes, but again I struggle with the distinction between readership and
community. Would you say that an anthropologist reading the literature
of a foreign culture becomes part of the community for that culture? I
perceive these educators that you describe in much the same way, as
getting the production of a foreign body and studying them. I would only
feel a notion of "community" if they start engaging and trying to affect
the publication.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 6 Oct 2019 16:58:34 +1300

> feel a notion of "community" if they start engaging and trying to affect

This is indeed where we may differ. I think that in setting up the
arrangements for stewardship of the series, we should consider all the ways
RFCs are used. That doesn't mean we expect input from the professors at
the University of Northern Elbonia, but I think we should nevertheless
consider the whole audience. Whether this has any major impact on the
future governance mechanisms is another matter, of course.

   Brian

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 6 Oct 2019 13:28:56 +0100

Hiya,

>> Yes, but again I struggle with the distinction between readership and

I think Christian's right that the level of what one might
call "community engagement" varies a lot between these various
sets of RFC readers. With e.g. the NRENs and RIRs and small
bits of ICANN say, there are fairly clear interactions and
feedback loops. I think the same could be said for some s/w
developers directly implementing from RFCs.

When one gets to Government regulators I think I'd have to
side with Christian that it'd be odd to describe them as
part of the same community as the IETF. I'm sure that they'd
find it equally odd as well if someone told a regulator that
they were part of a community including the entities they
(may or may not) regulate.

>> Would you say that an anthropologist reading the literature

So maybe the people engaged in the future RFC series editor
discussions should:

a) identify sets of people like those discussed here where we
want to explicitly consider whether changes being discussed may
have noteworthy effects (good or bad), and
b) make some effort to try communicate with and get feedback
from each of those sets of people, and,
c) even if we don't succeed at (b) we should make our best
guess as to what they might think.

And then weigh all that alongside trying to figure out if
there's rough consensus within the IETF for whatever changes
look sensible.

To me, that sounds doable (if a bit tedious:-)

Cheers,
S.

---

From: Keith Moore <[email-masked]>
Date: Sun, 6 Oct 2019 09:10:01 -0400

On 10/5/19 11:58 PM, Brian E Carpenter wrote:

> RFCs are used.

This reply isn't intended for anyone in particular, and is not in 
response to any particular message, but generally to the thread.

I agree that the set of users affected by the RFC series is, in the long 
run, very close to the entire human population.   But it seems odd that 
somehow more emphasis is being put on the importance of the RFC series 
editor, than on the importance of the technical contributions.   If the 
technical standards don't meet the needs of the broad Internet user 
population, how the RSE is operated hardly matters at all.

Keith

---

From: Christian Huitema <[email-masked]>
Date: Sun, 6 Oct 2019 12:39:54 -0700

Replying to Stephen and Keith:

On 10/6/2019 6:10 AM, Keith Moore wrote:
>
> I agree that the set of users affected by the RFC series is, in the
> long run, very close to the entire human population.   But it seems
> odd that somehow more emphasis is being put on the importance of the
> RFC series editor, than on the importance of the technical
> contributions.   If the technical standards don't meet the needs of
> the broad Internet user population, how the RSE is operated hardly
> matters at all. 

I tend to agree with Keith here. The technical content of the RFC series
is by and large the product of the IETF. The RFC Editor function does
have a significant impact on how the content is expressed, with
functions such as format definition, copy editing, archiving and
references. But in first order, the impact of the series depend on the
technical value of the content, and also on its timeliness. I also agree
with Stephen that it is important to identify the readership of the
series, to collect feedback, and to make changes based on that feedback.
But in my mind, this is as much a responsibility of the IETF leadership
as it is a responsibility of the RFC Editor.

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 6 Oct 2019 20:47:12 +0100

Hiya,

On 06/10/2019 20:39, Christian Huitema wrote:
> technical value of the content, and also on its timeliness.

Sure. In my little head, this thread is really part of tee-ing
up the discussion about 6635bis and there are for sure many other
things about the IETF that could be improved and that might have
bigger impact.

> I also agree

Well, I guess I'd say that in the context of a 6635bis discussion,
it's the responsibility of whoever's driving that. (Which remains
to be seen/decided.)

Cheers,
S.

---

From: Colin Perkins <[email-masked]>
Date: Sun, 6 Oct 2019 22:06:09 +0100

> On 5 Oct 2019, at 20:14, S Moonesamy <[email-masked]> wrote:
> I went through some documents, e.g. RFC 6635 and the discussions which happened many years ago.  There is the following in the RFC: "to better serve the communities that produce and depend on the RFC Series".  I gather that the usage of the word "communities"  is intentional, i.e. it means that there is more than one community.
> 
> Is the IRTF a subset of the IETF?  If that was the case, they can folded into one community.  One side-effect of such a decision is that it constrains (future) decisions of the IRTF about its identity.  We could hand-wave that question and deal with it when it becomes a problem.  As I look back, I would say that this is why the IETF ended up with its inconsistent stories.

The IRTF is not a subset of the IETF, although the participants have significant overlap. The RFC Editor and IAB have been careful to involve the IRTF in this discussion.

> I assume that the IAB is aware that there are other organizations which rely on documents published through the Series.  In my opinion, some of those organization might not agree to be seated under the IETF umbrella.

I’ve certainly not seen any suggestion to 'seat the IRTF under the IETF umbrella' from the IAB.

Colin

> There was a comment [1] from Mr Johansson.  There are a few persons on the ietf@ mailing list who are ex-IAB members.  I have no doubt that they would understand what the comment means.
> 
> Regards,
> S. Moonesamy
> 

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 7 Oct 2019 10:19:15 +1300

>> as it is a responsibility of the RFC Editor.

Without denying that the IETF is the largest source of RFCs, I would say
that responsibility exists for all streams, and the integration point is
the RFC Editor.

> it's the responsibility of whoever's driving that. (Which remains

Certainly.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Sun, 6 Oct 2019 19:26:53 -0400

> that responsibility exists for all streams, and the integration point is

This makes less and less sense to me every time I think about it 
again.   The RSE should not be changing the intended content of RFCs 
produced by IETF consensus.   So the RSE's role, relative to the actual 
technical content of standards, should be a very limited one.    Yet 
somehow the responsibility to serve the greater user community is being 
put on the RSE?

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 7 Oct 2019 16:16:26 +1300

On 07-Oct-19 12:26, Keith Moore wrote:
> produced by IETF consensus. 

No, of course not, nor for any other stream for that matter. Of course there
can always be disagreement about whether a particular edit changes the
intent, but the principle is clear. Isn't that why the concept of stream
managers was invented some years ago?

> So the RSE's role, relative to the actual 

That's over-interpreting what I intended to say.

    Brian