Re: [homegate] Proposed Charter Update - 2010/09/09

"David Harrington" <ietfdbh@comcast.net> Thu, 09 September 2010 20:26 UTC

Return-Path: <ietfdbh@comcast.net>
X-Original-To: homegate@core3.amsl.com
Delivered-To: homegate@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A23E23A6826 for <homegate@core3.amsl.com>; Thu, 9 Sep 2010 13:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.189
X-Spam-Level:
X-Spam-Status: No, score=-102.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RY5saGQmBpQP for <homegate@core3.amsl.com>; Thu, 9 Sep 2010 13:26:26 -0700 (PDT)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 328D63A67F9 for <homegate@ietf.org>; Thu, 9 Sep 2010 13:26:23 -0700 (PDT)
Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta04.westchester.pa.mail.comcast.net with comcast id 4b731f0030cZkys54kSrQR; Thu, 09 Sep 2010 20:26:51 +0000
Received: from 23FX1C1 ([67.189.235.106]) by omta10.westchester.pa.mail.comcast.net with comcast id 4kSr1f0012JQnJT3WkSrZ8; Thu, 09 Sep 2010 20:26:51 +0000
From: David Harrington <ietfdbh@comcast.net>
To: 'Paul Hoffman' <paul.hoffman@vpnc.org>, homegate@ietf.org
References: <14B94CC6-EA1D-44BD-9E01-457EB89C5E4E@nominet.org.uk> <p06240845c8aeaf99c3eb@[10.20.30.158]>
Date: Thu, 09 Sep 2010 16:26:26 -0400
Message-ID: <4ED69024CE914E21A1AFF4B8759FAAF4@23FX1C1>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <p06240845c8aeaf99c3eb@[10.20.30.158]>
Thread-Index: ActQNuiJ4iBgtbJuTvOsUiAodh+M4gAIYk1Q
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931
Subject: Re: [homegate] Proposed Charter Update - 2010/09/09
X-BeenThere: homegate@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Broadband Home Gateway Discussion <homegate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/homegate>, <mailto:homegate-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homegate>
List-Post: <mailto:homegate@ietf.org>
List-Help: <mailto:homegate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homegate>, <mailto:homegate-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Sep 2010 20:26:27 -0000

Hi Paul,

I sent another email with my whole spiel, but I'll respond to your
points.


> This list seems wrong on three axes:
> 
> - The first two happen at the same time; that is, the -00 
> draft of the Home Network Architecture document *is* adopted 
> as a WG item. That can be done in Nov 2010.

If you can get the draft written and achieve consensus by November,
great!
There are no penalties for delivering before a milestone date.

> 
> - It is questionable to start having further drafts until the 
> definitions-and-architecture draft is fairly stable. If it is 
> stable, it should be sent to the IESG. Thus, consider moving 
> the last element up to April 2011 and move all the "Mar 2011" 
> items down to April.

I explained the rationale for further drafts in my other email.
If somebody wants something included in the WG recharter, first, write
a draft!

The arch document might be delivered earlier than promised.
There are no penalties for delivering before a milestone date.

> 
> - Having multiple drafts on six different topics floating 
> around all at once will cause us to produce much less useful 
> work. Vendors won't know what to implement to, and purchasers 
> won't know what to specify. 

Part of my goal is to see if the WG can achieve enough consensus to
achieve useful work. If not, the WG will be closed.

The multiple draft approach is to have solid input for a recharter
process.
The recharter process should happen in July, so multiple drafts
floating around is a short-lived problem.

I recommend vendors not implement against works-in-progress.
I recommend purchasers not stipluate requirements based on
works-in-progress.

> We'll most likely cave in and 
> publish two or more competing documents on a single topic 
> because of strongly-held views of a small number of WG 
> members. 

I do not expect to approve multiple competing documents in the
recharter.
The WG needs to achieve consensus.
If that consensus is that there really are different sets of
requirements to meet, there might be justification for multiple
competing drafts.
I'll need to be convinced.

> We'll have to hold some completed documents for a 
> long time while slower referenced documents complete. 

Well, that might be true unless you are very careful about how you
handle normative references.
There already is a proposal to reduce the burden of downrefs.

> These 
> are common hallmarks of dysfunctional IETF WGs.

The single biggest hallmark of a dysfunctional WG in my experience, is
the inability to achieve consensus. So far, I have not been impressed
by the ability of this group to achieve consensus, which is why I am
involved at all in helping to craft a clearly-scoped charter. 

Traditionally, I have not worked much at helping people with barBOFs
or documents craft their proposals. Some of my coworkers with
less-than-examplary-English or less-than-perfect-expertise wish I
would. Typically I give strategic and tactical advice and then see if
they can execute effectively on the strategy and tactics. That's part
of my test of whether a group is ready to have a WG, or a contributor
is ready to submit a technical proposal.

I think this is an important WG effort, which is why I am helping
craft a charter.
I am unimpressed by the ability to converge on a consensus so far. 

> 
> If we have agreed on a single architecture, why not create a 
> single requirements document? That gives vendors a single 
> point of reference for their implementations, it gives 
> purchasers a single RFC to specify, it gives the future 
> chairs a stronger stick with which to beat out rough 
> consensus, and it means that we all finish at the same time.

Well, I question whether this group has agreed on a single
architecture.
I suspect there are lots of unspoken assumptions in people's minds
about what will go into the architecture, and what requirements will
be included in a WG requirements document.

Having multiple drafts floating around will help get some of the
unspoken assumptions from strong-willed individuals into writing, so
we discuss them, shoot down some of the strong-willed assumptions,
work toward consensus on the set of assumptions, and ultimately get WG
consensus documented in RFCs.

> 
> Given those three issues, a different set of goals and 
> milestones would be:
> 
> Nov 2010 - Initial version of WG's Home Network Architecture 
> document Apr 2011 - Submit Home Network Architecture document 
> to the IESG Apr 2011 - Initial version of WG's Home Network 
> Requirements document Apr 2012 - Submit Home Network 
> Requirements document to the IESG Apr 2012 - Possible recharter of
WG
> 
> Does this sound reasonable?
> 
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> homegate mailing list
> homegate@ietf.org
> https://www.ietf.org/mailman/listinfo/homegate
>