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

Paul Hoffman paul.hoffman at vpnc.org
Sat Nov 27 18:19:46 PST 2010

At 8:27 PM -0500 11/27/10, Andrew Sullivan wrote:
>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).

Let's look at 4.2.4 again. Picking it apart:

>   o  provide all necessary points of contact and services to support
>      policy inputs and questions from the community, including
>      production-side and end-user customers,

This is reasonable, although we all certainly hope that there is not much need to have "policy inputs" so that the series stays stable. It is also a significant change from the current model and from the way that Glenn has been acting as TRSE. That is, the RSE today does *not* answer questions from the community during the production of RFCs; the Production Center does. This bullet probably needs to be scaled back (or we need to agree that the RSE should be in front of Production Center questions, which I would not support).

>   o  take part in (or delegate attendance at) formal meetings,
>      telechats, and other communications among entities (e.g., IESG and
>      IAB), as well as general meetings such as the IETF, or retreats,
>      as required,

The IESG and IAB *are* part of the community, so it is appropriate for the RSE to be their general point of contact for the series. In the case of the IESG, however, I have heard that historically most of the desired contact from the RFC Editor is from the Production Center, not the RSE. This bullet makes it sound like that would be reversed in the future; if so, the IESG should make it clear whether or not they want that. Again, this bullet probably needs to be scaled back.

>   o  provide consistent communication of the status and plans of the
>      Editor,

This makes good sense, although the community doesn't currently have such communication, so we can't judge how important it is. The status communications we get are mostly generated by the Production Center, it seems.

>   o  liaise and work with the IAB so that the IAB may be confident
>      there has been sufficient community review before significant
>      policies or policy changes are adopted, and

This bullet is misplaced: it is part of the management communication between the RSE and it's boss, not community communication.

>   o  engage all team members and the community with a spirit of common
>      purpose, accomplishment, and teamwork.

Blah, blah, blah. In fact, I don't believe this belongs here at all because the community does not need to show any such spirit for the RFC series to work.

The unaddressed elephant in the room is communication between the community and the Production Center. It is difficult to tell if the current draft is punting on the question or is making the RSE the point of contact. The eventual document *needs* to be completely clear, and the community needs to agree with what it says.

The "RSE is the point of contact for everything" model assumes that there is a problem with the way things currently happens, namely that it is the Production Center that regularly speaks with the leadership and sits at the tables at IETF meetings; it also assumes that having the RSE do that instead would be better for the RFC-producing community. Unless Glenn's forthcoming document of rationale and experience shows lots of evidence to the contrary, I would support keeping the current way things are being done.

Thus, an alternate to 4.2.4 might be:


- Be the central point of contact for RFC-producing community for the RFC series, but not represent the Production Center in questions of process and status

- Educate the RFC-producing community about the RFC series, particularly about common misunderstandings and during times of potential significant change in the series

- Work with the Production Center to regularly report series status


If Glenn or others are advocating a "strong RSE" model, then the list in 4.2.4 still needs to be clarified.

> > 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.

Absolutely. I would hope that the head of the streams would stomp on the RSE if he/she started speaking to the outside world about how to get RFCs published without directing that discussion to the streams themselves.

> > 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 different view would be that the RSE can speak to the IT community about the importance of the series without highlighting any particular RFC or even any particular stream. When the inevitable question of "which ones are we supposed to read" comes up, the RSE should say "I don't know, but if you find out, maybe consider writing it up as an Internet Draft and finding an appropriate stream where it might be published".

> > 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.

We fully agree on "wholly or even significantly", but that doesn't mean that the RSE has no role here. It takes less than an hour with a search engine to find SDOs with whom the IETF does not have a liaison that are normatively referencing RFCs, sometimes quite badly. In the "represents the RFC series to the external world" role, the RSE might spend a bit of time to at least get them to understand that RFCs are sometimes updated and obsoleted. This has nothing to do with active liaison relationships for current or new work in the IETF stream and everything to do with making the RFC series more useful (and possibly even more appreciated) outside the IETF.

> > 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.

So, let's work on 4.2.5:

>   o  be available to entities that seek representation of the series,
>      including the press, and

It would be interesting if Glenn or Bob Braden can speak of any experiences of someone seeking representation of the series; this seems kind of unlikely. It can safely be dropped.

>   o  be open to support low-cost high-impact opportunities to promote
>      the series.

The "be open to" sounds flimsy, and the "promote" part sounds like hucksterism. Maybe replace it with "help organizations that are not part of the RFC-creating community but that rely on RFCs to understand the series better". We don't need to promote the fact that RFCs exist; we want to help those who use the RFCs to do so well.

>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.

--Paul Hoffman, Director
--VPN Consortium

More information about the rfc-interest mailing list