Subject: [homegate] Charter Question - 1 Doc, Multiple Docs

From: Jason Livingood <[email-masked]>
Date: Thu, 12 Aug 2010 08:38:30 -0400

As we refine the charter, a question arising is whether to have the charter
be very specific and state that only one document will come out of the WG
for now. An alternative is to leave the charter more open on the question,
potentially giving us flexibility to figure this out once we start writing a
document as well as to enable additional work via the new work consideration
process discussed at the BoF.

Any feedback?

Jason

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 12 Aug 2010 08:59:22 -0400

On Thu, Aug 12, 2010 at 08:38:30AM -0400, Jason Livingood wrote:
> for now. 

I don't think that belongs in a charter.  It's a purely editorial decision, IMO.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Ray Bellis <[email-masked]>
Date: Thu, 12 Aug 2010 13:53:05 +0000

> I don't think that belongs in a charter.  It's a purely editorial decision, IMO.

To help people find it, the current charter text is at:

  http://trac.tools.ietf.org/area/tsv/trac/wiki/HOMEGATE

I've just made some minor edits (see the Trac history) to fix a few minor grammatical errors and to remove any "single document" requirements.

Please all review and comment on this text as soon as possible - the formal decision on working group formation needs to happen pretty soon.

In particular it would be useful to get ideas on what specifically should be addressed in the initial work item(s).

Ray Bellis
HomeGate BOF co-chair

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Thu, 12 Aug 2010 10:20:13 -0400

Jason,

In my opinion, I would keep it open. Multiple docs are more likely than not. I'm surprised that we would need to be that specific on the output.

-KE
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Jason Livingood [[email-masked]]
Sent: Thursday, August 12, 2010 6:38 AM
To: [email-masked]
Subject: [homegate] Charter Question - 1 Doc, Multiple Docs

As we refine the charter, a question arising is whether to have the charter be very specific and state that only one document will come out of the WG for now. An alternative is to leave the charter more open on the question, potentially giving us flexibility to figure this out once we start writing a document as well as to enable additional work via the new work consideration process discussed at the BoF.

Any feedback?

Jason

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Aug 2010 08:05:16 -0700

I agree that we don't have to limit the number of documents that the WG would produce at this point; we just don't know. HOWEVER, the proposed charter at <http://trac.tools.ietf.org/area/tsv/trac/wiki/HOMEGATE> says:

>Proposed Deliverables and Priorities: The working group works to improve the networking experience for the user of home gateways. The group has the following work items:
>
>1. Recommendations and guideline documents for implementation of basic, mandatory functionality for IPv4-only home gateways (BCP)
>2. Recommendations and guideline documents for implementation of basic, mandatory functionality for dual-stack (IPv4 and IPv6) home gateways (BCP)

Saying that this WG is going to produce #1 is just wrong. An IPv4-only document in 2011 *cannot* be a BCP; it is too myopic. I thought that I heard a fair amount of agreement with this at the mic during the BoF.

A different proposal:

The group has one initial work items, which might be followed by additional items that could be added in later charters. The initial work item is a Best Current Practices document with recommendations and guidelines for implementation of basic, mandatory functionality for dual-stack (IPv4 and IPv6) home gateways. This document may include a profile for IPv4-only devices, but would make clear that excluding IPv6 is not recommended.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ray Bellis <[email-masked]>
Date: Thu, 12 Aug 2010 15:53:00 +0000

>  agree that we don't have to limit the number of documents that the WG would produce at this point; we just don't know. HOWEVER, the proposed charter at <http://trac.tools.ietf.org/area/tsv/trac/wiki/HOMEGATE> says:
> 

I believe you're correct - the exact scope of the initial work items is (IMHO) the most significant remaining issue with the charter.

> The group has one initial work items, which might be followed by additional items that could be added in later charters. The initial work item is a Best Current Practices document with recommendati…

My concern with this is that I believe such an apparently wide-ranging document would essentially replicate much of Broadband Forum's TR-124.  That's already a 124 page document. [*]

Not only would that make it out of scope for us, it would itself be a similarly long document which would likely take several years to complete.

Hence from a workflow and productivity perspective I would rather see the group initiate a series of documents each of which addresses a small part of the home gateway functionality. Some of those elements will be agnostic to the IPv4/v6 question.

By focusing on individual functional elements we could attract subject matter experts for those documents, and (I believe) progress those work items much more rapidly than if we try to put everything down in one place.  

My own RFC 5625 is an example of just such a document.  It's short, and only addresses DNS and some minor DHCP issues.  It took only(!) 10 months from first individual draft to publication as an RFC.

Let's think about the other pain points we actually know about.  What about IPSEC, SIP ALGs, all those other things that are commonly known not to work the way they're supposed to?

There are network operators here - what are your help desks telling you are the common bugs that you see time and time again?  In particular, which of those bugs are due to incorrect implementation of IETF protocols?

Ray Bellis
HomeGate BoF co-char

[*] http://www.broadband-forum.org/technical/download/TR-124_Issue-2.pdf

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 12 Aug 2010 12:19:11 -0400

> Please all review and comment on this text as soon as possible - the formal decision on working group formation needs to happen pretty soon.

As a nit, the bullets following "These problems include but are not
limited to:" don't follow or complete the sentence.  What about
"Prominent among the problems are the following:" or something
similar?

In the paragraph following the bullet list, there's the claim that a
baseline will include RFCs that must be supported.  This might raise
fewer eyebrows if it said "ought to be", since the goal is not
actually to specify anything, I think.

"This working group will not develop new protocols, but makes
recommendations …": the verbs need to agree.  Perhaps remove the "s"
on "makes".

Working Group is sometimes capitalized and sometimes not.

I fully agree with Paul that work item 1 is not something anyone
should do.  My impression was that that was the agreement in the room
in Maastricht too.  Since this is supposed to be work that guides
_new_ gateways, and not just any gateway, I think the only advice
anyone should give today is, "Don't build new IPv4-only gateways.
They're already obsolete."  We don't hardly need an RFC for that.

Finally, at one point there was some discussion of making this about
small-network gateways and not just "home".  Did that decision get
made while I was busy looking elsewhere?  (I don't feel strongly about
this, just asking.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Mark Baugher <[email-masked]>
Date: Thu, 12 Aug 2010 10:05:00 -0700

> recommendations …": the verbs need to agree.  Perhaps remove the "s"

"Group makes" is typically used in American English and treats "group" as a singular entity.

Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 12 Aug 2010 13:19:15 -0400

> "Group makes" is typically used in American English and treats "group" as a singular entity.

That's not the problem.  The first verb is future tense, and the
second isn't.  It's at least awkward (but I think it's a malformed
parallelism).  Either the WG will do something, or else it does
something.  So "WG does not develop new protocols, but makes" or "will
not develop, but make".

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 12 Aug 2010 11:01:46 -0700

>My concern with this is that I believe such an apparently wide-ranging document would essentially replicate much of Broadband Forum's TR-124.  That's already a 124 page document. [*]

...much of which is stuff we wouldn't put in an IETF document. This is an unfair comparison.

>Not only would that make it out of scope for us, it would itself be a similarly long document which would likely take several years to complete.

Why is it "out of scope for us"? More precisely, why is it in scope if we break it into a bunch of smaller documents as you proposed below, but out of scope if it is a single document? When I brought up logoizing in the BoF, there seemed to be a fair amount of support for it.

I disagree that we would produce "a similarly long document"; lots of stuff in TR-124 is of no interest to the IETF.

Given that we don't even have a WG, it seems a tad premature to say it would take several years to complete. That kind of depends on the document editors, the WG leadership, and the interest in the WG. I don't think we have an example in the IETF where breaking up a document into smaller bits has made the overall process go faster, and we have many counter-examples.

>Hence from a workflow and productivity perspective I would rather see the group initiate a series of documents each of which addresses a small part of the home gateway functionality. Some of those e…

If we did this, logoizing kind of goes out the door. "Complies with RFC 7821, 7369, 8230, and 8299" doesn't have nearly the oomf of "Complies with RFC 7821". Forcing customers to track many RFCs for their requirements gets us back to our current state.

>By focusing on individual functional elements we could attract subject matter experts for those documents, and (I believe) progress those work items much more rapidly than if we try to put everythin…

That really depends on how the editor works. If the editor organizes the subject experts by section, it is no different than having them work on smaller documents.

>My own RFC 5625 is an example of just such a document.  It's short, and only addresses DNS and some minor DHCP issues.  It took only(!) 10 months from first individual draft to publication as an RFC.

Fully agree, and it is a great example of what we would want as part of the WG work. However, compare it to, for example, the IPv6 gateway firewall requirements document, that has taken significantly longer.

>Let's think about the other pain points we actually know about.  What about IPSEC, SIP ALGs, all those other things that are commonly known not to work the way they're supposed to?

Fully agree. ALGs in general. DNS proxying. DNS pass-through (I don't consider DNS an "alg", but I know others do). IPv4 and IPv6 address discovery.

>There are network operators here - what are your help desks telling you are the common bugs that you see time and time again?  In particular, which of those bugs are due to incorrect implementation…

When we start hearing responses to that, it would be better to be able to pour them into one omnibus document instead of a zillion topic-specific documents, yes?

--Paul Hoffman, Director
--VPN Consortium

---

From: "David Harrington" <[email-masked]>
Date: Thu, 19 Aug 2010 12:31:52 -0400

Hi,
 
Let me inform you what I, as an IESG member and possibly the
Responsible AD, will be looking for in a charter.
 
I don't care how many documents you will need to document what you
document.
I will care a great deal that you can identify a clear deliverable
that is achievable in a reasonable amount of time.
 
I don't care much about the uniqueness of the name. 
I would prefer a name that is intuitive, that is reasonably indicative
of the focus, but the name is just a name.
Many of the proposed names are rather meaningless without a tag to
explain it.
homegate is fine with me, even though it is close to the HGI name.
The documents we put out will be IETF RFCs; the documents they put out
will be HGI or Homegate Initiative documents.
Unless we have a joint working agreement where IETF's homegate and
HGI's homegate are developing as a single team, I doubt we'll see much
conflict from the name.
We've had discussion of the name. 
Reach a consensus quickly or go with homegate.
It's a bad sign when the homegate community gets distracted by minor
details.
 
IETF79 Working Group session scheduling has already started, and the
cutoff is 9-27.
The IESG needs to approve the charter. 
There are only three official telechats before that cutoff, and they
are filling fast.
We will want a WG session agenda to accompany the ietf79 session
request
Use your time wisely.
 
I am concerned that the scope is so elusive.
This MUST be nailed down.
People are still expanding the list of what they want included in the
scope.
It is time to start cutting away things that will NOT be in scope for
the initial charter.
 
Here are my suggestions for cutting:
If it is not an on-the-wire protocol, drop it.
If it is IPv4-only, drop it
If it will not impact the big-I Internet, drop it.
If it is in the 20% of the 80/20, drop it.
if it is a corner case, drop it, but note it as a corner case to keep
in mind while designing.
If it has only one proponent, drop it.
You're ready when there is nothing left to cut away - what remains has
consensus as being critical.
 
Lars and I have not really talked about who will be the Responsible
AD. It could be me.
Personally, I like short charters.
I suggest you plan on a first deliverable that can be submitted to
IESG within 12 months.
That will force you to really cut away anything not critical, and
focus on what consensus you already have.
The WG will have new chairs, new editors, and new contributors, and a
new (to this WG) AD.
Figuring out how to work together will be part of your first year's
deliverables, like it or not.
That's harder if you have multiple promised deliverables and a lack of
clear consensus on the scope and content.
People can always work on additional proposals outside the WG.
After the first year, you'll have a better idea of consensus on what
is needed for additional deliverables.
Then you can ask the AD to extend the charter.
And if people have developed individual proposals, you may have
something concrete as a basis for new deliverables.
By that time, the AD will also know whether the WG can accomplish what
it sets out to accomplish.
If you've done a good job, the AD willl likely grant you lots of
leeway in the subsequent charter.
If all the people who want things now walk away once the charter is
approved,
If people from other SDOs return to their SDOs and don't really
contribute to the work here,
If documents are published and nobody steps up to review them,
If everybody goes off to work on their own drafts rather than helping
get the WG drafts done,
then the Responsible AD will probably be less likely to approve an
extended charter.

dbh

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jason Livingood
Sent: Thursday, August 12, 2010 8:39 AM
To: [email-masked]
Subject: [homegate] Charter Question - 1 Doc, Multiple Docs

As we refine the charter, a question arising is whether to have the
charter be very specific and state that only one document will come
out of the WG for now. An alternative is to leave the charter more
open on the question, potentially giving us flexibility to figure this
out once we start writing a document as well as to enable additional
work via the new work consideration process discussed at the BoF.

Any feedback?

Jason

---

From: Mark Baugher <[email-masked]>
Date: Thu, 19 Aug 2010 09:57:40 -0700

> If it will not impact the big-I Internet, drop it.

I think this has been a problem with past attempts to standardize home network or private network protocols in the IETF.   But I guess it depends on how you define 'impact'.

Mark

---

From: "David Harrington" <[email-masked]>
Date: Thu, 19 Aug 2010 13:16:35 -0400

I guess it also depends on how you define "problem"
 
The IETF Mission:
The mission of the IETF is to make the Internet work better by
producing high quality, relevant technical documents that influence
the way people design, use, and manage the Internet.
 
dbh

  _____  

From: Mark Baugher [mailto:[email-masked]] 
Sent: Thursday, August 19, 2010 12:58 PM
To: David Harrington
Cc: 'Jason Livingood'; [email-masked]
Subject: Re: [homegate] Charter Question - 1 Doc, Multiple Docs

I think this has been a problem with past attempts to standardize home
network or private network protocols in the IETF.   But I guess it
depends on how you define 'impact'.

Mark

---

From: Mark Baugher <[email-masked]>
Date: Thu, 19 Aug 2010 12:48:49 -0700

David
  By "problem" I was referring to the lack of publication of any home network standards.  

Mark

On Aug 19, 2010, at 10:16 AM, David Harrington wrote:

> The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet.
>  
> dbh
>