Re: Last Call: <draft-arkko-iesg-crossarea-02.txt> (Experiences from Cross-Area Work at the IETF) to Informational RFC

Benoit Claise <bclaise@cisco.com> Thu, 14 February 2013 16:04 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113FC21F84F4 for <ietf@ietfa.amsl.com>; Thu, 14 Feb 2013 08:04:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.539
X-Spam-Level:
X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8mjOmDvh9VB for <ietf@ietfa.amsl.com>; Thu, 14 Feb 2013 08:04:37 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id DADE121F883A for <ietf@ietf.org>; Thu, 14 Feb 2013 08:04:36 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1EG4Z2P022986; Thu, 14 Feb 2013 17:04:35 +0100 (CET)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1EG4EZQ018930; Thu, 14 Feb 2013 17:04:25 +0100 (CET)
Message-ID: <511D0AFE.3000407@cisco.com>
Date: Thu, 14 Feb 2013 17:04:14 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Jari Arkko <jari.arkko@piuha.net>
Subject: Re: Last Call: <draft-arkko-iesg-crossarea-02.txt> (Experiences from Cross-Area Work at the IETF) to Informational RFC
References: <20130206234933.11375.20586.idtracker@ietfa.amsl.com> <6.2.5.6.2.20130209090616.0a22ba20@resistor.net>
In-Reply-To: <6.2.5.6.2.20130209090616.0a22ba20@resistor.net>
Content-Type: multipart/alternative; boundary="------------030700070008010902040401"
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Feb 2013 16:04:38 -0000

Hi Jari,
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>> - 'Experiences from Cross-Area Work at the IETF'
>>   <draft-arkko-iesg-crossarea-02.txt> as Informational RFC
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> ietf@ietf.org mailing lists by 2013-03-06. Exceptionally, comments 
>> may be
>
Hi Jari,

Thanks for your draft.
A couple of points.

1.

    Cross-area work does present some challenges, however.  Apart from
    the advisor model there are no established practices and the
    processes and division of responsibility differs from case to case
    [RFC2026  <http://tools.ietf.org/html/rfc2026>].

Regarding "there are no established practices", I would stress the 
directorate process. Not really processes in the sense of RFC 2026, but 
pretty useful for cross area work.

For example, for MIB doctors, see 
http://www.ietf.org/iesg/directorate/mib-doctors.html

    All MIB documents will be passed by a MIB doctor reviewer before
    they will be approved by the IESG. The MIB doctor review must be
    done after the Working Group Last Call and before the IETF Last
    Call. ADs and WG chairs responsible on I-Ds that include MIB
    documents should ask the OPS ADs for a MIB review as soon as the
    document completed WGLC.

For example, for the YANG doctors, see 
http://www.ietf.org/iesg/directorate/yang-doctors.html

    All YANG documents will be passed by a YANG doctor reviewer before
    they will be approved by the IESG. The YANG doctor review must be
    done after the Working Group Last Call and before the IETF Last
    Call. ADs and WG chairs responsible on I-Ds that include YANG
    documents should ask the OPS ADs for a review as soon as the
    document completed WGLC.

For example, the performance metrics directorate, see 
http://www.ietf.org/iesg/directorate/performance-metrics.html
Note that this directorate is a relatively new directorate, so the 
"process" is still debated

Etc... I can tell you that that "IPFIX doctors" is about to be put in place.

As an OPS AD, I'm trying to make sure that the OPS-related directorates 
have a clear documentation containing: the directorate goal, the 
"process", the benefits, the guidelines, etc...
2.

       part of the problem here is
       that IESG does not normally develop a master plan, but rather
       individual documents and charter proposals are brought to the IESG
       in a piecemeal fashion, one by one.  This makes it hard to see
       bigger trends and possibilities for colliding work.

I'm not sure if the master plan is the primary problem. At the time of 
the charter creation, discussions regarding the work division between 
different WGs take place. However, along the time, different WGs take 
different directions. And there, the master plan might fall apart. So I 
would say the problem is the lack of revisiting the existing charters/WG 
new directions on regular basis.
Somehow, my comment relates to a sentence I see later in the draft:

       Periodic review and re-assessment is healthy and encouraged.


3.
Jari, you mentioned in one of the emails: "The document has been mostly 
aimed at ADs and WG chairs"
Out of the 10 recommendations, some don't give me a clear advice. I can 
only say: "sure, that is common sense!"

    7.   The best examples of successful cross-area work involve
         combining two pieces of expertise, with both parties having an
         incentive to complete the work.

4.
Potentially, out of the 10 recommendations, you could flag the ones that 
might require some sort of process improvements.
For example:

    10.  In general, the ability to associate work with all the areas
         that it relates to will be helpful not just for scheduling, but
         also for participants following an area of work, review teams,
         and so on.


Regards, Benoit