Re: [fun] Revised homenet charter for IESG consideration

Jari Arkko <jari.arkko@piuha.net> Mon, 27 June 2011 22:52 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: fun@ietfa.amsl.com
Delivered-To: fun@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042271F0C51; Mon, 27 Jun 2011 15:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.996
X-Spam-Level:
X-Spam-Status: No, score=-101.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 FdxKa44OeJkL; Mon, 27 Jun 2011 15:52:52 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id DE4751F0C49; Mon, 27 Jun 2011 15:52:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 46A842CC39; Tue, 28 Jun 2011 01:52:50 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYooj4Bq6RNs; Tue, 28 Jun 2011 01:52:49 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 0634C2CC2F; Tue, 28 Jun 2011 01:52:48 +0300 (EEST)
Message-ID: <4E0909C0.1090108@piuha.net>
Date: Tue, 28 Jun 2011 00:52:48 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.24 (X11/20101027)
MIME-Version: 1.0
To: David Harrington <ietfdbh@comcast.net>
References: <4E031DCD.1010606@piuha.net> <BEF28DA8BF08419EA670A910D2438F28@davidPC>
In-Reply-To: <BEF28DA8BF08419EA670A910D2438F28@davidPC>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: ipdir@ietf.org, 'IAB' <iab@iab.org>, 'IESG' <iesg@ietf.org>, fun@ietf.org
Subject: Re: [fun] Revised homenet charter for IESG consideration
X-BeenThere: fun@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "FUture home Networking \(FUN\)" <fun.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fun>, <mailto:fun-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fun>
List-Post: <mailto:fun@ietf.org>
List-Help: <mailto:fun-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fun>, <mailto:fun-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2011 22:52:53 -0000

David,

> I think work on home networking standards is very important, and
> strongly support the effort.
> A little guidance on how I think this charter can be improved.
>   

Great!

> >From the 110623 version, 
> "Specific protocol work described below is anticipated to be within 
> the scope of the working group. However,
> the group is required to review its charter and milestones with the
> IESG and IETF community before submitting documents that make protocol
> changes."
>
> "anticipated to be within the scope" is very unclear as to what is or
> is not in scope.
> Is that "anticipated to be within the scope" AFTER a re-charter, and
> thus is NOT NOW is scope of this charter?
>   

After the recharter. I can clarify this. And it already says what 
specifically is not in scope (submitting documents that make protocol 
changes). How about this:

OLD:
Specific protocol work described below
is anticipated to be within the scope of the working group. However,
the group is required to review its charter and milestones with the
IESG and IETF community before submitting documents that make protocol
changes.
NEW:
Specific protocol work described below
is expected to be within the scope of the working group one the 
architecture work
is complete. However,
the group is required to review its charter and milestones with the
IESG and IETF community before submitting documents that make protocol
changes. It is expected that the group has to discuss some of the below 
solutions,
however, in order to complete the architecture work.

Would this be clearer?

> or is that "anticipated to be within the scope", so WG members can
> interpret it as being in scope NOW?
>
> My concern, and the concern of others, was that the original charter
> was too open-ended and did not provide for IETF review of the
> architecture and the potential changes it might drive before the WG
> was chartered to make such changes. This left  potentially important,
> and possibly bad, changes in protocols to be caught in IETF Last Call
> or IESG Evaluation, rather than in a review of the proposed protocol
> work during the chartering process.
>   

Right. I was one of those ADs who balloted against the charter back 
then. But lets focus on the current charter. I don't think this issue 
exists in the current charter as written.

> The charter text makes it obvious that the engineering changes are not
> yet clearly understood: 
>   

That's right. There's some work to be done. And given your comments from 
a couple of IESG meetings ago, we've changed the charter so that the 
architecture and plan for changes needs to come first. Once it is clear, 
the group can proceed for real with the changes.

> "The architecture document should drive what protocols changes, if
> any, are necessary."
> "existing protocols are likely sufficient, and at worst may need some
> small enhancements, ..."
> "it is expected that existing routing protocols can be used as is,
> however, a new mechanism may be needed ..."
> "The main goal of this [security] work is to enable a security policy
> that adapts to IPv6 threats as they emerge,..."
>
> This sounds more like the description of an IRTF RG than an IETF WG.
> The ***engineering*** apparently is not yet clearly understood, and
> the "specific protocol work described below" is not at all specific.
>   

I think we need to distinguish engineering efforts with a priori known 
end result (build this house) from those with more initial effort on 
requirements (build the optimal house for this family) and from research 
(develop new materials technology for houses). HOMENET is of the second 
type. In general, the IETF does not work only on the first type of 
efforts. We do constrain (and sometimes over- or under-constrain) 
efforts based on specific concerns, of course. The method that we're 
using in this case is to have the scope of solutions work decided by the 
IESG/IETF only after the architecture is clear. Continuing with the 
house construction analogy, this is like asking for the architects to 
make a plan for the house before committing to materials and 
construction contracts. However, just like with architecture, materials 
choices and technology has to be discussed as part of the architectural 
design, as they drive what can be built.

> a resulting architecture document needs to be clear
> about what specific engineering work is needed, and a subsequent
> re-charter should be clear about the ***engineering*** work to be
> done.

I think that is the intent. Is there something missing from the current 
charter text with regards to this? It says:

The task of the group is to produce an architecture document that outlines
how to construct home networks involving multiple routers and
subnets. This document is expected to apply ... and other existing 
components of the IPv6
architecture. The architecture document should drive what protocols
changes, if any, are necessary.

Jari