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

Peter Saint-Andre <stpeter@stpeter.im> Fri, 15 February 2013 03:29 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: appsdir@ietfa.amsl.com
Delivered-To: appsdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47E821F8464 for <appsdir@ietfa.amsl.com>; Thu, 14 Feb 2013 19:29:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.592
X-Spam-Level:
X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 R1XfNoUhUTdi for <appsdir@ietfa.amsl.com>; Thu, 14 Feb 2013 19:29:01 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C806C21F8461 for <appsdir@ietf.org>; Thu, 14 Feb 2013 19:28:57 -0800 (PST)
Received: from [192.168.1.7] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7498140A5E for <appsdir@ietf.org>; Thu, 14 Feb 2013 20:36:07 -0700 (MST)
Message-ID: <511DAB7B.1010603@stpeter.im>
Date: Thu, 14 Feb 2013 20:28:59 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: appsdir@ietf.org
References: <511DA9ED.9040105@stpeter.im>
In-Reply-To: <511DA9ED.9040105@stpeter.im>
X-Enigmail-Version: 1.5
X-Forwarded-Message-Id: <511DA9ED.9040105@stpeter.im>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: [appsdir] Fwd: Re: Last Call: <draft-arkko-iesg-crossarea-02.txt> (Experiences from Cross-Area Work at the IETF) to Informational RFC
X-BeenThere: appsdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Apps Area Review List <appsdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/appsdir>, <mailto:appsdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/appsdir>
List-Post: <mailto:appsdir@ietf.org>
List-Help: <mailto:appsdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/appsdir>, <mailto:appsdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Feb 2013 03:29:01 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

FYI. I wasn't sure whether to make this an AppsDir review...


- -------- Original Message --------
Subject: Re: Last Call: <draft-arkko-iesg-crossarea-02.txt> (Experiences
from Cross-Area Work at the IETF) to Informational RFC
Date: Thu, 14 Feb 2013 20:22:21 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
To: jari.arkko@piuha.net
CC: ietf@ietf.org

Hi Jari, although I was asked to complete an AppsDir review of this
document, on reading it several times I realized that my feedback is
more personal and less from the Apps Area perspective, so I am sending
a more general message.

On 2/6/13 4:49 PM, The IESG wrote:
> 
> 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

Section 3 begins:

   From an IETF participant's point of view, it is important that there
   is a working group where the technical topic that he or she is
   interested in can be discussed.

I'm not convinced that IETF participants really care whether the
institutional machinery of WG formation has been put in place. In my
experience, a fair amount of interesting work has happened outside of
any WG (e.g., Jeff Hodges and I worked on RFC 6125 on a
special-purpose IETF mailing list, not in a WG). As long as there's
some kind of venue, discussion can occur.

A related note on the following sentence in Section 1:

   If the work is
   interesting, the necessary people come to the meetings and work on
   the specifications.

Well, meetings (in the sense of WG sessions, or even IETF meetings)
aren't truly necessary if there is some other appropriate venue available.

IMHO, Section 2 could benefit from examples of cross-area work
involving RAI and Apps. Current and recent WGs include PRECIS (with
involvement from Apps, RAI, Security, and Ops/Mgt), ALTO (straddling
Apps and Transport), OAUTH (straddling Apps and Security), CORE (in
Apps but with close connections to 6lowpan in Int), PAWS (it was an
open question whether it would end up in Apps or Ops/Mgt), and current
efforts to define multi-stream support in MMUSIC, CLUE, and RTCWEB.
The Apps and RAI AD can probably provide further insight here.

In Section 3:

   Cross-area work is needed,
   of course, in any situation where a particular technical problem does
   not cleanly map to one organization.

Is an IETF area truly an "organization"? Isn't the organization here
the IETF?

In Section 4:

      But it
      is also possible that concerns raised in one forum are not
      understood in another, and this can lead to an effort going
      forward after finding the "lowest bar" forum to take it up.

By "forum" you seem to mean "IETF area".

OLD
      Similarly, requests for cross-area review are relatively
      infrequent or sent only to a particular subset of people in an
      area (such as a directorate).
NEW
      Similarly, requests for cross-area review are relatively
      infrequent or sent only to a particular subset of people in an
      area (such as a directorate or related working group).

I tend to agree with Benoit that the scope of, and audience for, the
suggestions in Section 4 are not particularly clear. Unfortunately, I
do not yet have actionable suggestions for improvement.

Peter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRHat6AAoJEOoGpJErxa2pPAMP/iHR0eoCRjbeGUvZkCmmZVNb
UNs+xC8MFRhP1AaRGXas8XMgjgYp02yZryXe590CcpwCVohk/agMs9Z+hKCBDi6F
46n+p+Y6UBI1O53Vloo/BkFZTQ/q4FkwIYiCF0o9PmW10tiwhisYkIuFf3Jza5HV
y3GZ6AUs1UIQYF3CFAripFPEZst+OQ8yWrzxuPkdpnMBIoaDxvBV/NsYluq5H5Xv
FYfGhgBaCKViQme2E8tHsY9YC4MGCCmepXMGfmP5ZoVmwwKYZhvN3GSIuDL96m3y
tUsC1lcdpkA3ZLayO339+ZFQztzncsjxp+WzV/yxY64T12qckLY+FqI/xmTxEffw
JT02IzjU9dZ398UXXZcIbEUBeoa8Qyrfy1qTn6b6fga3y49M3A2QnEiggiyXvk9F
WlO9YE6Pd8ns6aGZ46vPS6Gg6FJDQyquPA+gcg0koyiYxtysCRiLHO8wXlAhpxoU
TpxxR0delXREUxzpZvXJG5KxoZASC6aY/01kuw849IkcoRHTrygED3U3VKslBfSi
tqCnNPv4NoCcqm5mtMxFCONOs+sIVA0UQbismUxf0RYYkUReafGrb97mRGJCHn4J
Vqk1rZQ2KMU/zra7yzdm417ZHjYKNYQCYk6kOd/bY3w4X09WcpHFmFctBmGPMJr+
Qo9dhaske2MFLUnrHXYb
=g3pF
-----END PGP SIGNATURE-----