Subject: [homegate] Minor proposed charter text update

From: Ray Bellis <[email-masked]>
Date: Tue, 24 Aug 2010 09:43:52 +0000

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

I've reworded the first paragraph, removing the text about demarcation, and introducing the concept of cascaded home gateways.  I believe this addresses the question about whether the scope of the group includes other gateways sat _inside_ the customer network.

I've also addressed Andrew Sullivan's nits, and removed the "IPv4" only work item, per the discussion in Maastricht.

The reference to the TCP over DNS draft has also been updated, since that's just been published as RFC 5966.

Ray

---

From: Ray Bellis <[email-masked]>
Date: Thu, 26 Aug 2010 09:32:48 +0000

Based on off-list feedback and the comments from David Harrington, I've also now amended the "proposed deliverables" section such that the _initial_ deliverable is a single recommendations document for dual-stack home gateways.

Ray

---

From: Ole Troan <[email-masked]>
Date: Thu, 26 Aug 2010 13:14:08 +0200

Ray,

> I've reworded the first paragraph, removing the text about demarcation, and introducing the concept of cascaded home gateways.  I believe this addresses the question about whether the scope of the…

why should a home network be restricted to a "cascading" topology? as opposed to configured in an arbitrary topology.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Thu, 26 Aug 2010 13:15:06 +0200

from charter:

* Support for IPv6 is lacking to a great degree. More importantly, there is no clear understanding of what IPv6 features would be necessary on a home gateway beyond those specified in RFC 4294. For instance, what firewalling functionality should be employed, and with what defaults?

what makes this different from:
http://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router/

now on the RFC editor queue.

cheers,
Ole

---

From: Ray Bellis <[email-masked]>
Date: Thu, 26 Aug 2010 11:32:11 +0000

> why should a home network be restricted to a "cascading" topology? as opposed to configured in an arbitrary topology.

Other than multi-homed, what other topologies except cascading did you have in mind?  Would "daisy-chained" have been a better term than "cascading" ?

[My intent was to include in our scope topologies where additional devices sit _in path_ but inside the consumer network, e.g. a wireless gateway (not AP/bridge) sat on the LAN.  The previous text effectively restricted the scope to devices sat on the consumer/provider demarcation boundary].

Ray

---

From: Ray Bellis <[email-masked]>
Date: Thu, 26 Aug 2010 11:42:52 +0000

> now on the RFC editor queue.

That text was part of a major proposed rewrite from Jari Arkko (message to Homegate list 29th June 11:36 GMT).

Jari - are you able to address this question?

kind regards,

Ray

---

From: "Mario Paalvast (mpaalvas)" <[email-masked]>
Date: Thu, 26 Aug 2010 14:55:51 +0200

Please note that "Home Gateways" often include bridging functionality as
well. This is typically the case with ADSL CPE's deployed in a multi PVC
environment. In other words it is not a routing device only

Best regards
Mario Paalvast

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ray Bellis
Sent: Thursday, August 26, 2010 13:43
To: Ole Troan; Jari Arkko
Cc: [email-masked]
Subject: Re: [homegate] Minor proposed charter text update

On 26 Aug 2010, at 12:15, Ole Troan wrote:

> from charter:
> 
> * Support for IPv6 is lacking to a great degree. More importantly,
there is no clear understanding of what IPv6 features would be necessary
on a home gateway beyond those specified in RFC 4294. For instance, what
firewalling functionality should be employed, and with what defaults?
> now on the RFC editor queue.

That text was part of a major proposed rewrite from Jari Arkko (message
to Homegate list 29th June 11:36 GMT).

kind regards,

Ray

_______________________________________________
homegate mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/homegate

---

From: Ole Troan <[email-masked]>
Date: Thu, 26 Aug 2010 15:16:34 +0200

Ray,

> Other than multi-homed, what other topologies except cascading did you have in mind?  Would "daisy-chained" have been a better term than "cascading" ?

what about looped or directed graph topologies?

e.g:

      /--|R|---|H
|R|
      \--|R|---|H

      /--|R|---|H
|R|              |
      \--|R|---|H

> [My intent was to include in our scope topologies where additional devices sit _in path_ but inside the consumer network, e.g. a wireless gateway (not AP/bridge) sat on the LAN.  The previous text…

that I agree with. just unsure if we should restrict _how_ those devices could be plugged together.

cheers,
Ole

---

From: Ray Bellis <[email-masked]>
Date: Thu, 26 Aug 2010 14:42:45 +0000

> that I agree with. just unsure if we should restrict _how_ those devices could be plugged together.

I don't see the new text as _restrictive.  It removes the definition of the home gateway being the demarc point, and also mentions that they might be daisy-chained.

Ray

---

From: Ole Troan <[email-masked]>
Date: Thu, 26 Aug 2010 17:28:25 +0200

Ray,

> I don't see the new text as _restrictive.  It removes the definition of the home gateway being the demarc point, and also mentions that they might be daisy-chained.

a daisy chain is a linear topology (or a ring). why should any home network have to look like that? and why do we even need to say that in a charter. just state that a home network with multiple routers, internal as well as "border" routers are within scope.

cheers,
Ole

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 26 Aug 2010 11:32:03 -0400

On Thu, Aug 26, 2010 at 05:28:25PM +0200, Ole Troan wrote:

> in a charter. just state that a home network with multiple routers,
> internal as well as "border" routers are within scope.

That seems better to me.

A

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Aug 2010 08:25:13 -0700

>Based on off-list feedback and the comments from David Harrington, I've also now amended the "proposed deliverables" section such that the _initial_ deliverable is a single recommendations document…

Thanks, Ray. With that change, and the one calling out that this is for v4v6 dual stack, I strongly support the formation of this WG.

For the rest of the folks on this mailing list: the IESG might need to see a lot more interest from this thread before they will approve the formation of the WG. There were a zillion people in the room at the Maastricht BoF, and many different folks got to the mic with opinions. If a good handful of you say "I'm interested in the WG being formed and am willing to do real work*", that would help the IESG determine the level of interest.

I'm interested in the WG being formed and am willing to do real work!

--Paul Hoffman

* reviewing revs of the document, proposing new wording for it, proposing changed wording for it, writing whole sections, researching current and planned capabilities in products you work on, coordinating with other WGs in which you are active, and so on.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Aug 2010 08:28:11 -0700

>now on the RFC editor queue.

That document is a small subset of what has been proposed so far. Other topics include default filtering, DHCPv4, application-layer gateways,  management interfaces, which pieces should be user-settable, ...

--Paul Hoffman, Director
--VPN Consortium

---

From: "Kirksey, Heather R (Heather)" <[email-masked]>
Date: Thu, 26 Aug 2010 11:03:22 -0500

I'm confused by the below comments.

1. Isn't default filtering in the scope of the simple security doc in progress in v6Ops?

2. I believe there was a decision reached to exclude management of these devices during the bar BOF in Stockholm.  Why is it listed below as something "missing" that should be included in Homegate?

3. Are you really proposing that Homegate should tell product manufacturers which device settings they should let a user control and which they shouldn't?  Not only is that a product implementation decision, pure and simple, it's not the sort of thing you're likely to gain consensus on, and I'd definitely argue it's out of the scope of the IETF.    

4. What work would you propose doing on ALGs?  Listing apps that should work across them?  TR-124 has a (somewhat dated to be sure) non-exhaustive list in one of its appendices.  I'm really not sure what else beyond that can really be done on that topic. 

Thanks,
Heather 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
Sent: Thursday, August 26, 2010 10:28 AM
To: Ole Troan; Ray Bellis
Cc: [email-masked]
Subject: Re: [homegate] Minor proposed charter text update

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Aug 2010 09:21:21 -0700

>1. Isn't default filtering in the scope of the simple security doc in progress in v6Ops?

Yes, for IPv6. That does not preclude us from including it in our document, either by reference or with amendments. We can also talk about filtering for IPv4, if desired.

>2. I believe there was a decision reached to exclude management of these devices during the bar BOF in Stockholm.  Why is it listed below as something "missing" that should be included in Homegate?

There was lots of discussion of management during the virtual BoF before Maastricht, and some during the Masstricht BoF. I don't think this group has decided one way or another whether it wants to include management in a profile.

>3. Are you really proposing that Homegate should tell product manufacturers which device settings they should let a user control and which they shouldn't?  Not only is that a product implementation…

Here is a counter-example. If a manufacturer wants to include, for example, a DNS proxy that does not support DNSSEC, I believe an argument can be made that an IETF recommendation would be that the user should be able to turn off that proxy so that they can achieve better security.

It is also extremely premature to predict consensus. We don't even have a WG yet so we don't know who the active participants will be.

>4. What work would you propose doing on ALGs?  Listing apps that should work across them?  TR-124 has a (somewhat dated to be sure) non-exhaustive list in one of its appendices.  I'm really not sure…

Some ALGs have been found to cause security problems, for example by not supporting modern algorithms that are supported in many deployed servers. The dated, non-exhaustive list in TR-124 might not address this in a way that supports the IETF goals of interoperability and security.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ole Troan <[email-masked]>
Date: Thu, 26 Aug 2010 22:00:04 +0200

> That document is a small subset of what has been proposed so far. Other topics include default filtering, DHCPv4, application-layer gateways,  management interfaces, which pieces should be user-set…

how do you think this document compares with the above bullet in the charter?
I did not want to make any comment about other parts of the charter.

cheers,
Ole

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 26 Aug 2010 13:18:57 -0700

>I did not want to make any comment about other parts of the charter.

Whoops, sorry, I didn't catch that part. I can think of two things off the top of my head that an eventual WG might want to include over and above a pointer to that RFC-to-be:
- firewalling functionality, as the charter says
- subsetting of and/or modifying of the requirements from that document based on the model of no user control of these devices. If we do this in the document, I believe we absolutely must explicitly justify doing so in the document itself.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Lee Howard" <[email-masked]>
Date: Thu, 26 Aug 2010 17:09:50 -0400

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ole
> Troan
> Sent: Thursday, August 26, 2010 11:28 AM
> To: Ray Bellis
> Cc: [email-masked]
> >> that I agree with. just unsure if we should restrict _how_ those
devices could be plugged
> together.
> >
> > I don't see the new text as _restrictive.  It removes the definition of
the home gateway
> being the demarc point, and also mentions that they might be
daisy-chained.
> 
> a daisy chain is a linear topology (or a ring). why should any home
network have to look like
> that? and why do we even need to say that in a charter. just state that a
home network with
> multiple routers, internal as well as "border" routers are within scope.

Home networks can conceivably contain an arbitrary number of routers in an
arbitrary
topology.  But arbitrarily complex networks cannot be scoped; we have to
stipulate a 
maximum level of complexity.  Let's limit ourselves to cases that cover
99.9% of 
networks; i.e., linear or cascaded topologies.

Lee

---

From: [email-masked]
Date: Fri, 27 Aug 2010 16:27:06 -0400

> arbitrary topology.  But arbitrarily complex networks cannot be scoped; 
we have to
> stipulate a maximum level of complexity.  Let's limit ourselves to cases 
that cover
> 99.9% of networks; i.e., linear or cascaded topologies.
> 
> Lee

+1 on this. 
"tree" or "loop-free" topologies are also good names. It would mean a LAN 
IGP is out of scope (but not a WAN IGP). 

JF

---

From: "David Harrington" <[email-masked]>
Date: Fri, 27 Aug 2010 18:55:58 -0400

Hi,

One concern that I have is whether we have enough committed resources
to justify a WG.
 
My impression is that there are many people on this list, and many who
were at the meeting in Maastricht, from other SDOs. Their goal is to
ensure that overlap and conflict between the IETF work and their SDO's
work is minimized. I have a real concern that once we approve a WG
with a charter that is reasonably conflict-free, these people will "go
home" to their SDO, satisfied that they have achieved their mission.

But the mission of the WG will not have been achieved. I would like to
see statements of commitment from people who are willing to work at
achieving the WG's goals. I specifically would like to see volunteers
for editing, and for committed reviewing of each revision of the WG
document(s)*. 

I would also appreciate if you identified yourself if you realize
that, as an active member of another SDO, you will not have the time
to commit to this IETF work because you will be busy working on your
own SDO's work. Maybe you can do an occasional review to check that
the document doesn't get into conflicting territory, but making a more
time-consuming commitment wouldn't be reasonable. That might help us
get a feel for the size of the "real" WG resources.

As an IESG member, I could use that information to determine whether
the charter scope and the committed resources are aligned well.

Thanks,
David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

* I'm a realist. Day-job pressures might prevent reviewing every
revision, but I would expect a commitment for most of the revisions.
If the WG chooses to eventually produce multiple documents, I would
expect that those commitments might morph into commitments to review
certain documents. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Thursday, August 26, 2010 11:25 AM
> To: [email-masked]
> Cc: Ray Bellis
> >Based on off-list feedback and the comments from David 
> Harrington, I've also now amended the "proposed deliverables" 
> section such that the _initial_ deliverable is a single 
> recommendations document for dual-stack home gateways.
> 
> Thanks, Ray. With that change, and the one calling out that 
> this is for v4v6 dual stack, I strongly support the formation 
> of this WG.
> 
> For the rest of the folks on this mailing list: the IESG 
> might need to see a lot more interest from this thread before 
> they will approve the formation of the WG. There were a 
> zillion people in the room at the Maastricht BoF, and many 
> different folks got to the mic with opinions. If a good 
> handful of you say "I'm interested in the WG being formed and 
> am willing to do real work*", that would help the IESG 
> determine the level of interest.
> 
> * reviewing revs of the document, proposing new wording for 
> it, proposing changed wording for it, writing whole sections, 
> researching current and planned capabilities in products you 
> work on, coordinating with other WGs in which you are active, 
> and so on.

---

From: Ray Bellis <[email-masked]>
Date: Sat, 28 Aug 2010 10:05:09 +0000

> the charter scope and the committed resources are aligned well.

Echoing David's concerns - it would be a *great* help if those prepared to help could stand up and be counted ASAP.

Timing for establishing a working group for Beijing is rapidly running out.

Ray

---

From: Etienne Gallet de Santerre <[email-masked]>
Date: Tue, 31 Aug 2010 17:27:24 +0200

Hi all,

I am a PhD student working on home network routing.

I would appreciate if someone could clarify one point of the charter, 
which is partly discussed in this thread.

I have some difficulties to understand the expression "home gateways may 
be cascaded" (maybe because English is not my natural language).
Does it refers to a multihomed site with several (what-I-would-call) 
"parallels" home gateways interconnected inside the home network?
Does it refers to some other devices inside the home network in addition 
to the one at its border?
Something else?

Thanks,
Etienne Gallet de Santerre
PhD student at TELECOM Bretagne

---

From: Ray Bellis <[email-masked]>
Date: Tue, 31 Aug 2010 16:03:28 +0000

On 31 Aug 2010, at 16:27, Etienne Gallet de Santerre wrote:
> 
> I have some difficulties to understand the expression "home gateways may be cascaded" (maybe because English is not my natural language).
> Does it refers to a multihomed site with several (what-I-would-call) "parallels" home gateways interconnected inside the home network?
> Does it refers to some other devices inside the home network in addition to the one at its border?
> Something else?

A better phrase may have been "daisy chained", e.g. where the "WAN" interface of a second unit is connected to one of the "LAN" interfaces of a first unit - i.e. in series.

Ray

---

From: james woodyatt <[email-masked]>
Date: Tue, 31 Aug 2010 09:04:54 -0700

> Does it refers to some other devices inside the home network in addition to the one at its border?

It refers to a particularly short-sighted scheme for implementing home networks comprising multiple subnets without the use of a proper zero-configuration routing protocol.  Instead, the bastions between home subnets will be ordinary home gateways, which operate as hosts on one interface and as default routers on their other interfaces, using some underspecified and fragile method of delegating prefixes obtained from their DHCP6 servers.

It will be a usability disaster.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Tue, 31 Aug 2010 12:05:02 -0400

Ray,

Daisy-chained may not be helpful either. Parallel and serial are generally well understood, the "cascade" refers to several routers in serial, e.g. one behind the other. Orthogonal to this discussion of "cascaded" vs. "daisy-chained" vs. "serial" terminology, I recall a use case presented by BBF regarding multihoming (the parallel edge routers Etienne refers to below) as as either a requested inclusion into the scope, or an accepted inclusion into the scope for this phase, I don't recall which.

-KE
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ray Bellis [[email-masked]]
Sent: Tuesday, August 31, 2010 10:03 AM
To: Etienne Gallet de Santerre
Cc: [email-masked]
Subject: Re: [homegate] Minor proposed charter text update

Ray

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: Ray Bellis <[email-masked]>
Date: Tue, 31 Aug 2010 16:20:15 +0000

> It will be a usability disaster.

The draft charter does not _propose_ any such scheme, but recognises that daisy-chained / cascaded gateways is a known existing "dual gateway" configuration[*], and thus should be addressed by the proposed WG.

FWIW, I think that solving dual-homed networking issues is _much_ harder than getting the single gateway (or serial gateways) stuff right.

Is there a case for dual-homed (i.e. more than one gateway) being included now, or should that maybe form a later phase of the work?

Ray

[*] the obvious example being a separate wireless gateway (as opposed to a wireless bridge / AP) on the inside of another gateway.

---

From: Vittal Krishnamurthy <[email-masked]>
Date: Tue, 31 Aug 2010 09:46:11 -0700

Pls count me in. 

Rgds
-Vittal
-----------------
Quick terse message from my iPhone (with typos!)

---

From: Mark Townsley <[email-masked]>
Date: Tue, 31 Aug 2010 19:43:18 +0200

On 8/27/10 10:27 PM, [email-masked] wrote:
> > arbitrary topology.  But arbitrarily complex networks cannot be
> scoped; we have to
> > stipulate a maximum level of complexity.  Let's limit ourselves to
> cases that cover
I think that for home networks its actually more important to be sure
that fairly arbitrary apologies work as the targeted user base is
certainly bound to break any rules we might try and lay down.

Such a topology is certainly no worse than what we define for mobile ad
hoc networks.

- Mark

> >
> > Lee
>
> +1 on this.
> "tree" or "loop-free" topologies are also good names. It would mean a
> LAN IGP is out of scope (but not a WAN IGP).
>
> JF
>
>

---

From: Vittal Krishnamurthy <[email-masked]>
Date: Tue, 31 Aug 2010 10:56:50 -0700

I have a more basic question.
Are we focusing on the home gateway to the external world OR are we focusing on the home network as well?
Coz the scope is smaller  if we focus on the home gateway only, but on the other hand including the "home network" will probably get too complex and arbitrary.
So a home network can be as simple as a single 4 port wired/wireless router OR can get as complex as an enterprise branch office.
So what is our scope?

Cheers,
-Vittal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Townsley
Sent: Tuesday, August 31, 2010 10:43 AM
To: [email-masked]
Subject: Re: [homegate] Minor proposed charter text update

On 8/27/10 10:27 PM, [email-masked]<mailto:[email-masked]> wrote:

> arbitrary topology.  But arbitrarily complex networks cannot be scoped; we have to
> stipulate a maximum level of complexity.  Let's limit ourselves to cases that cover
I think that for home networks its actually more important to be sure that fairly arbitrary apologies work as the targeted user base is certainly bound to break any rules we might try and lay down.

Such a topology is certainly no worse than what we define for mobile ad hoc networks.

- Mark

> Lee

+1 on this.
"tree" or "loop-free" topologies are also good names. It would mean a LAN IGP is out of scope (but not a WAN IGP).

JF

homegate mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 31 Aug 2010 18:17:41 +0000

I am also able to contribute, whether by editing, writing, or reviewing
documents. (I think that was assumed but would love to see more people
raise their hand!)

Jason

On 8/31/10 12:46 PM, "Vittal Krishnamurthy" <[email-masked]> wrote:

>> Echoing David's concerns - it would be a *great* help if those prepared
>>to help could stand up and be counted ASAP.
>>

---

From: David R Oran <[email-masked]>
Date: Tue, 31 Aug 2010 14:47:58 -0400

> documents. (I think that was assumed but would love to see more people
I can certainly raise my hand for that level of participation.
I may have some difficulty attending IETF in person for the next year, which is why I do not feel comfortable putting my hand up for a more central role, such as WG secretary or WG co-chair.

I am most interested in the parts of the problem related to operation inside the home network and ensuring full access to internet services from the hosts on that network to the rest of the internet. This includes:
- address delegation and routing on the home network
- dealing with multi-interface and dual stack hosts
- dealing with multi-homing
- naming, particularly being able to name and access things inside the home from anywhere on the internet.

I am (personally) less interested in the issue affecting the link between the home gateway and the ISP's edge router, such as access link QoS, management of the connection, etc. although that's not to say I think they are in any way less important.

DaveO.

---

From: Mark Baugher <[email-masked]>
Date: Tue, 31 Aug 2010 11:57:18 -0700

> Is there a case for dual-homed (i.e. more than one gateway) being included now, or should that maybe form a later phase of the work?

I'd say that there is a case:  We already see dual-homed configurations today with cell phone APs.  I expect that this will become more important in the future as people get second and third ways to access the internet from home and personal devices.

Mark

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Tue, 31 Aug 2010 15:01:01 -0400

> Daisy-chained may not be helpful either. Parallel and serial are
> generally well understood, the "cascade" refers to several routers in
> serial, e.g. one behind the other. 

Every time I see "daisy-chained" being used because people don't like
"cascaded", it makes me cringe. Serial is better.

To be clear, the most common examples of daisy-chaining are found in
home phone wiring and electric circuits. A long, pair of wires is run
around a room or building, and it is tapped at various points so things
can be connected to it. These things are in parallel. They are not in
serial. If you add a device or remove a device, it does not interrupt
the circuit or the connection to other devices.

Cascaded gateways are not daisy-chained -- they are not in parallel.
They are in series. If a cascaded router breaks or otherwise fails,
connectivity is broken between its LAN and WAN.

Cascading comes from waterfalls. A cascade is a waterfall. Water goes
over one cascade, goes a little way, goes over another cascade,
continues, another cascade, etc. If you put something in the way of the
waterfall, you can affect and control the flow to everything downstream.
It's also common for a big upstream river to have its water split up so
that some water goes over one waterfall, and other water goes over other
waterfalls. Waterfalls (cascades) are in series. Not parallel. The main
difference between truly "serial" and "cascade" is that with the cascade
you have the big mass of water at the top that can get distributed to
various streams towards the bottom by routing portions of the water over
different waterfalls. Serial is generally considered to just be a single
sequence of things connected together. 

Therefore, cascade is not equal to daisy-chain. Cascade can be serial.
Barbara

---

From: Joe Touch <[email-masked]>
Date: Tue, 31 Aug 2010 12:53:54 -0700

Seems like some definitions are getting mixed here:

> the circuit or the connection to other devices.

That is the definition of parallel connections, NOT daisy chaining.

http://www.maxim-ic.com/glossary/definitions.mvp/term/daisy_chain/gpk/71

> sequence of things connected together.

You have just given a great reason why cascade is actually daisy chaining.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 31 Aug 2010 16:01:36 -0400

> You have just given a great reason why cascade is actually daisy chaining.

Surely, since this is all analogies with things in the world anyway
and people are disagreeing with the meanings, we ought to pick the
least fraught terms?

A

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 31 Aug 2010 13:09:36 -0700

> and people are disagreeing with the meanings, we ought to pick the

"relay" or "relay sequence" is the most clear, IMO.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 31 Aug 2010 17:57:20 -0400

> Is there a case for dual-homed (i.e. more than one gateway) being included now, or should that maybe form a later phase of the work?

There's nothing that says you have to have a particular work item for
every single thing that would naturally be in scope.  That is, the
charter could say, "The WG will take on the topic if there is
interest," without actually committing to doing that work.  That way,
if someone _wants_ to do it they have a home, but if nobody does the
work before everything else is done, there's no requirement that the
WG deliver something before winding down.

A

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

---

From: Mark Townsley <[email-masked]>
Date: Wed, 01 Sep 2010 00:12:22 +0200

> - naming, particularly being able to name and access things inside the home from anywhere on the internet.

I think your list captures the essence of the opportunities that the
IETF can most uniquely deliver upon, if it chose to do so.

> I am (personally) less interested in the issue affecting the link between the home gateway and the ISP's edge router, such as access link QoS, management of the connection, etc. although that's not…

This is important, but its also where you start getting into very
SP-specific territory, including deeper overlap with BBF, Cablelabs, etc.

- Mark

---

From: "David Harrington" <[email-masked]>
Date: Tue, 31 Aug 2010 21:03:56 -0400

> [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Tuesday, August 31, 2010 5:57 PM
> To: [email-masked]
> > FWIW, I think that solving dual-homed networking issues is 
> _much_ harder than getting the single gateway (or serial 
> gateways) stuff right.
> > 
> > Is there a case for dual-homed (i.e. more than one gateway) 
> being included now, or should that maybe form a later phase 
> of the work?
> > 
> 
> There's nothing that says you have to have a particular work 
> item for every single thing that would naturally be in scope. 
>  That is, the charter could say, "The WG will take on the 
> topic if there is interest," without actually committing to 
> doing that work.  

I'm not convinced you'll get iesg to sign off on a charter like that
;-)

> That way, if someone _wants_ to do it they 
> have a home, but if nobody does the work before everything 
> else is done, there's no requirement that the WG deliver 
> something before winding down.
> 
> A
> 
> 
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 31 Aug 2010 22:01:29 -0400

-- 
Andrew Sullivan
<[email-masked]>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 31 Aug 2010 22:09:11 -0400

> I'm not convinced you'll get iesg to sign off on a charter like that

Well, I guess I wrote a little sloppily, but the idea is to differentiate between the _topics_ a working group is willing to take on, and the specific work items a WG commits to delivering (i.e. with milestones). I can think of plenty of charters that seem to make this distinction, and there's a reason WGs occasionally have disputes about whether a draft is on-charter: if you had to have milestones for everything you could possibly do, then no such dispute would be possible. 

I will note in my own experience that DNSEXT (to my consternation) has been working on this model for years. 

A

-- 
Andrew Sullivan
<[email-masked]>