I hit send too quickly after answering the first question, neglecting to answer 
the latter two.

2. In general, IETF has a difficult time maintaining a cadre of people with 
expertise in any particular area.   There's very little representation by 
applications developers; there's also insufficient representation (IMO) by 
people who take a long view of maintaining the Internet architecture as opposed 
to people who are focused on product development and dealing with immediate 
problems.  Finding a way to attract participation from a diverse range of 
interests is an important problem, but attracting people who have expertise in 
old protocols is the least of it.

3. I get the impression that "we" (or maybe just IESG) are taking errata too 
seriously.  I always thought that the errata reporting mechanism was intended 
to be relatively informal and low overhead, something more akin to expert 
review than IESG review.   Now I get the impression that IESG wants to do 
formal review on all errata before they're published.   That, IMO, is an 
unnecessary distraction for IESG and less likely to serve the community's needs 
than the original mechanism.   I also think that it's reasonable for errata to 
be unverified or for whoever reviews them to be able to say "I/we don't know 
what to make of this report".   

I think we need a low-overhead and relatively informal mechanism of reporting 
errata and requesting clarifications, and maybe that it should be expanded a 
bit to serve as an implementation and interoperability reporting mechanism.  
But I don't think that having such a mechanism requires us to maintain 
expertise in every subject matter area covered by every RFC.

Keith

On Sep 16, 2011, at 9:30 AM, Ronald Bonica wrote:

> Scott,
> 
> On one hand, most of these RFCs do not harm the Internet. However, if we 
> don't clean house periodically, we are left with the following questions:
> 
> 1) In the future, does the IETF have the latitude to do things that might 
> break these old protocols?
> 2) If not, must the IETF maintain a cadre of people who are familiar with 
> these old protocols to ensure that they are not broken?
> 3) If we don't maintain a cadre of people familiar with these RFCs, how 
> should the community react to errata against them?
>                                 Ron
> 
> 
> 
>> -----Original Message-----
>> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
>> Scott O Bradner
>> Sent: Thursday, September 15, 2011 2:37 PM
>> To: Mykyta Yevstifeyev
>> Cc: IETF Discussion
>> Subject: Re: Pre-IETF RFCs to Historic (not really proposing)
>> 
>> I'm fully supportive of reclassifying any RFCs that pose a risk to the
>> Internet
>> to historic but fail to see the usefulness of doing so for RFCs that
>> describe
>> unused but non-harmful technologies - seems like busywork and useless
>> at best.
>> 
>> Scott
>> 
>> On Sep 15, 2011, at 1:45 PM, Mykyta Yevstifeyev wrote:
>> 
>>> Dear all,
>>> 
>>> I've recently received a message from Ronald Bonica, one of the ADs,
>> proposing undertaking an effort to reclassify many pre-IETF (pre-1000)
>> RFCs as Historic.  However, I initially had a concern regarding
>> community consensus on such effort, and whether it will be accepted so
>> that the IESG may claim the former.  Since I've already suggested a
>> very similar proposal, and there was a negative reaction of community,
>> I assumed the same would happen in the case Ronald pursued the work and
>> forwarded it to the IESG.  So am I right?
>>> 
>>> Mykyta
>>> _______________________________________________
>>> Ietf mailing list
>>> Ietf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf
>> 
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Reply via email to