Re: [Pesci-discuss] My Notes on draft-davies-pesci-initial-considerations-00.txt

["Spencer Dawkins" <[e-mail]>]

Dear Awake Half of Pesci Design Team ("you know who you are"),

Thanks, Scott, for quick feedback. There were only a couple of "huh?" 
responses, so I'll delete everything else:


> On 10/19/2005 15:11 PM, Spencer Dawkins allegedly wrote:
>> Dear Pesci Design Team,
>
> Dear Spencer ... half the pesci group is in bed already.  I'll give my
> personal opinions.  If I don't say something, it's because the issue
> is substantive or belongs to someone else, and I'm waiting for them.
>

>> 4.2.6.  Areas
>>
>> SD: The majority of the IETF membership likely has little clue about
>> "Kobe", except as a type of steak - it would be nice to provide any
>> pointer as background for this point of first use (not everyone spends
>> hours on IETF archeology, fascinating as it often is). Also - "the
>> central focus of ... technical expertise in the IETF" seems slightly
>> overblown - I'd go for "the central focus of ... cross-area technical
>> expertise in the IETF", but at least one adjective seems indicated.
>>
>>   Areas have become a fundamental structuring mechanism for IETF work
>>   since the Kobe reorganization.  Area Directors (ADs) are at the
>>   moment the central focus of management and technical expertise in the
>>   IETF.
>
> (1) nnngg, let's not try to describe the Kobe thing in a nutshell.  Do
> we have something we can reference?

Dave Crocker gave some references in 
http://www.alvestrand.no/pipermail/problem-statement/2003-March/001098.html 
a couple of years ago (how long have we been talking about process change?). 
It looks like http://ietf.org/rfc/rfc1640.txt?number=1640 would be the RFC 
reference, with ftp://ftp.ietf.org/ietf-mail-archive/ietf/1992-07 as the 
source material. Dunno if this helps.

>>
>> 4.2.8.  Extended Review
>>
>> SD: A number of us were SIRS volunteers, but I think the statement that
>> "The SIRS experiment ... [has] shown the value of extended, cross-area
>> review of documents" is grossly generous. SIRS showed that reviewers
>> would volunteer (for some number of "reviewers"), that the IETF has the
>> attention span of a hamster when it comes to evaluating process change,
>> and that WGs had no appetite for additional review steps that didn't
>> bypass review steps later on. IMO. I would also note that I've gotten
>> pushback on technical objections based on how late in the approval cycle
>> Gen-ART reviews happened - "haven't these guys suffered enough?", and
>> "jeez, they deployed this stuff four years ago anyway, and it sort of
>> works". Which leads me to suggest a P33 - "Technical show-stoppers are
>> always relevant, at any point in the approval process".
>>
>>   The SIRS experiment and the General Area review team have shown the
>>   value of extended, cross-area review of documents.  Currently most
>>   such review is carried out too late in the document life cycle for
>>   best effectiveness.
>
> ok ... but what would you say?

Sorry, this one was too easy. "The General Area review team has shown ..." 
Does MIB-doctor review count, for MIBs that aren't done in OPS?

>> SD: I cannot get from the following IAB writeup to the conclusion that
>> there is no reason to change the IAB. The second paragraph seems
>> justification enough to include IAB changes as in-scope, without
>> reference to anything else..
>>
>>   IAB       The main function of the IAB is architectural oversight of
>>             developments in the Internet.  This includes monitoring
>>             standards development work to ensure that it does not
>>             adversely impact the existing Internet, setting guidelines
>>             for architectural aspects of development, helping to
>>             determine what new working groups should be chartered,
>>             keeping a watching brief on technical developments outside
>>             the IETF, and providing statements on such developments as
>>             appropriate.
>>
>>             The IAB currently acts as the second line of appeal for
>>             decisions of the IESG on standards development and other
>>             matters.  This function is not an ideal fit with the
>>             general architectural remit of the IAB: the competencies of
>>             the IAB members do not necessarily equip them to deal with
>>             the process appeals that come to them from the IESG.  Some
>>             of the members of the IAB may consider them a distraction
>>             from their architectural role.
>
> There's plenty of reason to change the IAB, but not this round.

That's fine - could we at least delete the justification for including it 
this round from the draft? :-) I got whiplash reading it.

>> 5.2.  Components Considered for Major Change in the Document
>>
>> SD: I would append "for final cross-area review, only for ensuring that
>> final cross-area review has been performed".
>>
>>   IESG      The IESG is central to the processes of standards
>>             development in the IETF.  The steering role of the IESG in
>>             acceptance of new work, formation, and chartering of WGs,
>>             monitoring of WGs, and final stages of document processing
>>             seems to be appropriate, as it is essential to coordinate
>>             these functions.  This does not imply that the IESG must be
>>             solely responsible for final cross-area review.
>
> but they are not, at this time.

This is probably premature-creep. Good catch.

>>
>> SD: If you're scoping out NOMCOM process change parameters, please
>> include a note about the desire to get better community input on
>> non-incumbent candidates - discussed on IETF Discussion List, I believe?
>>
>>             Changes to these processes should ensure that overlaps of
>>             role (as regards those performing the selection and the
>>             leaders being selected) do not arise and that the workload
>>             of the NOMCOM does not get out of hand.
>
> I dunno, that's just one of many factors.  I would be careful about
> calling it out especially since things that are tend to become
> shibboleths.

That's fair. 


_______________________________________________
Pesci-discuss mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pesci-discuss