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:
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
shepherding them through the system.
Our documents are cast for eternity, errors included,
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?
Implementing our standards involves a treasure hunt
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 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
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
-- Christian Huitema
