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

Joel M. Halpern jmh at joelhalpern.com
Sat Nov 27 17:52:58 PST 2010


It seems to me that the person in charge of the RFC series (the RSE) 
ought to be charged with representing the RFC Series to its customers. 
As Glenn has identified, there are two sets of customers.  You seem (and 
I will readily grant that I may be misunderstanding your point) to be 
objecting to the RSE being the primary person talking to and listening 
to either of its sets of customers.

Given that the RFC Series is broader than the standards, and that the 
IETF liaisons (as selected by the IAB) are about the stnadards 
relationship), it does not seem that the liaison role is the designee 
for the functions we are discussing relative to the SDOs (who are one 
part of the larger community of outside customers.)

No, the RSE can not and should not be the only person talking to any of 
the interested parties about either the standards process (which is not 
his job) or the RFC Series.  But it sure seems that such conversations 
about the RFC Series ought to be part of his job.

Yours,
Joel


On 11/27/2010 8:27 PM, 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).
>
>> 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
>


More information about the rfc-interest mailing list