[rfc-i] Representation to the community and rest of the world

Andrew Sullivan ajs at shinkuro.com
Sat Nov 27 17:27:15 PST 2010


On Sat, Nov 27, 2010 at 11:09:00AM -0800, Paul Hoffman wrote:

> don't even know that there are four streams. Having the RSE tasked
> with being the focal point for education about RFCs (not about
> education about the contents of RFCs) seems reasonable, given that
> no one else is that focal point.

I like the particular task outlined above: being the focal point for
education about RFCs (or, in the language of the draft, "the Series").
This actually strikes me as entirely correct for an editor of a
technical series.  It's also a reasonably concrete thing to specify.

In my reading, however, it is not actually covered by any of the items
in sections 4.2.4 or 4.2.5 of the draft.  I'd support its addition.  I
still think the items that are there aren't really needed, however (or
at least, I haven't seen an argument for them and therefore to the
extent I understand them I don't see why they're needed).

> There are a few very large communities that do not participate in the IETF at all that use RFCs, and they often do so blindly. Three come to mind immediately:
> 
> - Software and hardware implementers
> 
> - IT departments who rely on RFCs for conformance requirements in purchasing
> 
> - Other SDOs who deal with the Internet

I grant this (with regret, of course, that it's true).  

> We have few significant liaisons to implementers. Note that I say
> that as the primary liaison to the IPsec implementation
> community. Way fewer than half of VPNC's members are in the least
> bit active in the IETF. The same is certainly true for many other
> areas of implementation. They are often genuinely surprised when a
> new RFC that directly impacts their products is issued.

This is a case where we collectively are doing a poor job of engaging
the implementation community.  I am not even a little convinced that
it is the RSE's job to explain to implementers what the IETF is, but
it is not hard to imagine the above being used as scope creep for the
RSE job.  I don't think that's what you intended, I'm just pointing
out a hazard.

> The trade press used to be the liaison to the IT community, but it
> has mostly folded. The number of reporters who know diddly squat
> about IETF activities can be counted on one hand.

This is probably true, but it runs perilously close to suggesting that
the RSE ought to be responsible for highlighting important _content_
of the RFC series to the IT community.  I think that is not the RSE's
job.  But explaining how RFCs might relate to one another could be.
See below.

> A few other SDOs are actively represented in the IETF, but the
> homegate BoF alone showed that many SDOs whose technologies rely on
> RFCs know anything about the RFC series or process.

This is just a liason failure, I say, and really really not the job of
the RSE to fix.  We have a whole structure that is supposed to address
this.  If it isn't happening, we need to fix that, not try to plug the
leak here.  So while I recognize the problem, I don't want to make it
wholly or even significantly the RSE's job.

> Again, all these can be somewhat alleviated by the RSE spending some
> time reaching out to the RFC-using outside world to let them know
> how RFCs are produced, how that world can participate in the
> process, and how that world can keep up to date more easily.

This part of the description actually doesn't sound dramatically
different from what you were suggesting about explaining the different
streams, above.  I can certainly support this kind of thing, which
could be sloganized as "Education and outreach about the nature of the
Series itself" or something like that.

My main objection to the items in the draft as they are written is
that their either massive overreach, or else they're already (in my
view) covered in other more carefully-specified items.  4.2.4 reads to
me like a list of items all of which tend to promote a bureaucratic,
meeting-going view of the RSE.  4.2.5 reads to me like a list of items
that tend to promote a gadfly view of the RSE.  I don't think that's
what we need.  We have specific problems to solve, so let's list what
they are.

What I like about (part of) Paul's argument is that it calls out a
specific problem I can immediately recognize as one that needs
solving, and one that is directly related to the RFC series itself.
Anything along those lines I can support as part of the job
description of the RSE.  It's possible that items 4.2.4 and 4.2.5 in
the existing draft _also_ have arguments that would lead me to that
kind of understanding, but without having seen such arguments I can't
support them as written.

A

-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.


More information about the rfc-interest mailing list