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

["David Harrington" <[e-mail]>]

Hi,

Let me explain the rationale behind the new milestones.

The previously proposed charter is just way too open-ended. 

<sermon>
There is a real possibility I will be the Responsible AD. Maybe a
different AD would have a different idea on this, and I won't be
offended if you choose to AD-shop, but  my impression is the IESG
won't approve this charter without tighter scope. I've asked the other
INT/TSV ADs for their feedback.

I favor charters that have tight enough scope to help chairs keep ML
discussions focused on deliverables, and away from tangential
discussions that produce nothing. I find this ML has done a great deal
of "well, we need to include this, and this, and this, and what about
that ...?" I have given my sermon about not continuning to expand the
scope, but starting to focus on cutting the scope. I really didn't see
that happen much.

I favor charters that allow me as an AD (and previously as a chair) to
assess whether the chairs are able to get the deliverables delivered
reasonably on-time. If the charter makes no promises about what will
be delivered or when, then obviously it's not very useful for that
purpose. 

I make it a policy not to sign blank checks or contracts with fields
"to be filled in later". Per RFC2418 "IETF Working Group Guidelines
and Procedures", 

   A charter is a contract between a working group and the IETF to
perform
   a set of tasks.

The previously proposed charter was missing the set of tasks.

Jari sent the proposed charter to the INT area directorate for
comments, and the responses were "this is way too open-ended, and I
can't even tell what is supposed to be delivered".

There were lots of people in the last BOF, but I didn't recognize many
of them. I suspect many were from other SDOs (or fora) and won't be
around to do the WORKing group tasks. 

The BOF also failed to demonstrate to me that there was consensus on
the golas and deliverables for this proposed WG. and, for me, it is a
bad sign when a second BOF fails to reach consensus. and just to mak
things worse, this mailing list has chosen to change the focus from
homegate to homenet.

Now let me be very clear. I personally look to the WG to be the
technical experts on this work, the chairs are the first-line
managers, and I'm just a facilitator and second-line manager. I'm not
trying to force my technical views on the WG; I'm trying to make sure
this group has a reasonable project plan to produce something useful.
If you give me a good project plan, and the chairs make you follow it,
you will probably see very little of me until you're ready to submit
documents to the IESG. 
</sermon>

I want to see a tighter project plan. I worked with Ray to get a set
of tasks into the contract.

We discussed a few ways to try to do that, 
1) serialize the work. Have one architecture/framework document as a
deliverable. Ray and I had agreed to this approach in an earlier
proposed charetr. Such a framework document would likely do a gap
analysis. When the gap analysis is completed, then we can look to
recharter with some specific items to work on.

Mark's argument against doing this serialized approach is that each
player has their own special interests, and if their favorite topic
won't be addressed now, then they'll walk away and maybe come back
when their stuff gets addressed. Even if everybody stays, using a
serial approach slows everything down.

Mark, and others, also pointed out that the architecture doc will be
inter-related with individual topics to be addressed. Until we start
poking at the individual topics, we might not agree on scope and how
it fits into the architecrture, so it would be difficult to develop an
architecture without starting to look at the individual topics and
their scope.

2) parallelize the work. Identify all the work items and put each task
into the charter now. The problem is that we don't know what all the
work items are. Part of the work of this WG will be to develop a
better understanding of what a home network is, including better
defining the scope to include/exclude SOHO, IT-managed networks in the
SOHO, various layer 2 technologies, mutiple routers, cascading
routers, etc.

We're not ready yet to identify and prioritize all the tasks that need
to be addressed. So this approach seems highly impractical at this
time.

3) choose one (or more) serial activity to all work on together - the
framework doc, and parallelize individual efforts so everybody gets to
start work on their favorite technology.

The framework doc might be considered a WG draft from the start,
although Lars and I both favor having it first published as an
individual draft, and later adopted as a WG item once we see the
quality and quantity of content. This framework document will require
the WG members to work together to achieve consensus. 

The parallel work of delivering individual drafts lets everybody be
involved in their favorite topic, and gives the WG something "with
meat" to discuss, so we can try to achieve consensus on the directions
for each of the seven bullet topics. These drafts would be the input
to a re-chartering effort. If some of the drafts never get written,
obviously the WG didn't have enough resources, or the topic wasn't
high enough priority, and it won't end up in the recharter. If
multiple individual drafts get written for a topic, then obviously we
have resources and a priority topic, and the WG will have some
consensus-building to do to converge the positions.

As contributors work on specific topics, they will likely raise
question on the ML about scope and specific requirements. Portions of
individual drafts might end up being incorporated into the
framework/architecture draft, and the eveolving arch draft might help
guide the individual drafts. Individual drafts might also end up being
recognized as work appropriate for another existing WG, so it won't
need to be part of the recharter. Or individual drafts might have
portions farmed out to other WGs, and portions incorporated into the
arch/framework draft.

>From my perspective, the third approach seems most appropriate right
now, since we have a bunch of people with "special interests" but we
also need to come together more to achieve consensus on how to deliver
promised deliverables on a timely basis. We can do both at the same
time.

David Harrington
Director, IETF Transport Area
[e-mail] (preferred for ietf)
[e-mail]
[phone] (cell)

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Paul Hoffman
> Sent: Thursday, September 09, 2010 11:52 AM
> To: [e-mail]
> Subject: Re: [homegate] Proposed Charter Update - 2010/09/09
> 
> At 3:18 PM +0000 9/9/10, Ray Bellis wrote:
> >Most of the changes relate to scope and work items - in 
> particular the ADs wanted to see a concrete list of proposed 
> goals and milestones.  There's also some structural change - 
> mostly moving the text that was below the bullet list higher 
> up the document.
> 
> . . .
> 
> >Goals and Milestones:
> >---------------------
> >
> >Nov 2010 - Initial revision of a Home Network Architecture 
> document Mar 
> >2011 - Adopt a Home Network Architecture document as a WG 
> item Mar 2011 
> >- Individual drafts as WG candidates for Routed home 
> requirements Mar 
> >2011 - Individual drafts as WG candidates for Simple naming 
> >requirements Mar 2011 - Individual drafts as WG candidates for 
> >Multi-homing requirements Mar 2011 - Individual drafts as WG 
> candidates 
> >for QoS requirements Mar 2011 - Individual drafts as WG 
> candidates for 
> >Security requirements Mar 2011 - Individual drafts as WG 
> candidates for 
> >DNSSEC requirements Jul 2011 - Recharter the working group 
> Dec 2011 - 
> >Submission of the Home Network Architecture document to the IESG
> 
> 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.
> 
> - 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.
> 
> - 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. 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. We'll have to hold some completed documents for a 
> long time while slower referenced documents complete. These 
> are common hallmarks of dysfunctional IETF WGs.
> 
> 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.
> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homegate
>