Subject: [homegate] Bar BoF Draft Topics

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 22 Jul 2009 08:58:03 -0400

For your review, comment, changes...

Homegate Bar BoF
Details 
* When: Monday, July 27, 8:00pm (20:00) local time
* Where: TBD 
Topics 
* Thoughts on the scope of a draft charter  how broad or narrow should it
be? 
* DNSSEC and DNS Proxy concerns
* IPv6 and DHCPv6 concerns
* ECN and RED concerns
* Multicast functionality/performance - MLD, IGMP proxying,
multicast/unicast conversion.
* Security concerns
* Firmware update concerns
* Questions over management of devices (and split management)
Resources 
* Homegate mailing list @ https://www.ietf.org/mailman/listinfo/homegate
* Draft homegate overview @
http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/HomeGate%20BoF
%20Proposal%20-%20IETF%2075%20-%20v7.pdf

---

From: Martin Focazio <[email-masked]>
Date: Wed, 22 Jul 2009 11:05:07 -0400

Hello folks - I've been lurking on this list for a while and I'm pleased to
see that there's some movement on the subject.
I am not on the engineering side of things - I work for a digital media
agency in New York City that does large-scale web projects for huge
companies (like AT&T for instance), and my primary concern is in User
Experience strategic planning and design. Thus, my main concerns in this
project are both technical (what can it do and how) and experiential (what
is the user going to experience when they try to set up and manage a gateway
for a home-based heterogeneous IPv4/V6 environment?).

While this may be a technical task force now, it's really, really important
that at this stage of the game a LOT of consideration is given to reality of
a slow, painful and complicated time of mixed IPv4 and IPv6 home networks as
well as the reality that many of the IPv6 features - like Multicasting -
will need far more core network capability before any significant effort is
needed to define the home gateway requirements.

While travel to Stockholm sounds wonderful, I can't be there, but I send you
all this message in the hopes that even at this stage of the project, you
keep the following scenario in your mind:

One day, Dad comes home from work. Everyone in the house is mad at him.
*His wife was trying to print something, but she had to turn the printer off
because it was spewing page after page of porn- the printer
was inadvertently visible to the whole internet and folks were throwing
files at it from all over the world. A friend of his son's is sleeping over
and he brought his netbook and can't connect to the home wifi network.. His
daughter is trying to set up a webcam to monitor the growth of some plants
as part of a school project, but the camera's built-in web server is fixed
to an IP4 address and port 8080 and her friends can't see it. The phones
stopped working because their Voice Over IP box from Vonage had an automatic
firmware update that changed a network setting. *

All of this is about the Home Gateway, and the smart but overwhelmed dad or
mom IS THE USER BASE, so while the real core technology thought goes on for
the Home Gateway, I hope that there's an eye toward the mundane reality of
end-user experiences and how they will be realized and metaphors that have
been successful in the past ("Leasing" an IP address via DHCP) are used as
wither a basis of or extension of new and improved functionality.

Again, thank you to all who are participating in this group, this is a
much-needed thing!

Martin T. Focazio

On Wed, Jul 22, 2009 at 8:58 AM, Livingood, Jason <
[email-masked]> wrote:

> *
> *
>    - When: Monday, July 27, 8:00pm (20:00) local time
>    - Where: TBD
>
> *Topics
> *
>
>    - Thoughts on the scope of a draft charter – how broad or narrow should
>    it be?
>    - DNSSEC and DNS Proxy concerns
>    - IPv6 and DHCPv6 concerns
>    - ECN and RED concerns
>    - Multicast functionality/performance - MLD, IGMP proxying,
>    - Security concerns
>    - Firmware update concerns
>    - Questions over management of devices (and split management)
>
> *Resources
> *
>
>    - Homegate mailing list @ *
>    https://www.ietf.org/mailman/listinfo/homegate*
>    - Draft homegate overview @ *
>    http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/HomeGate%20BoF%20Proposal%20-%20IETF%2075%20-%20v7.pdf
>    *
>    -
>
>
> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate
>
>

---

From: David R Oran <[email-masked]>
Date: Wed, 22 Jul 2009 11:19:30 -0400

Looks good! Let's go for it.

On Jul 22, 2009, at 8:58 AM, Livingood, Jason wrote:

> 	• When: Monday, July 27, 8:00pm (20:00) local time
> 	• Where: TBD
> Topics
> 	• Thoughts on the scope of a draft charter – how broad or narrow  
> should it be?
> 	• DNSSEC and DNS Proxy concerns
> 	• IPv6 and DHCPv6 concerns
> 	• ECN and RED concerns
> 	• Multicast functionality/performance - MLD, IGMP proxying,  
> 	• Security concerns
> 	• Firmware update concerns
> 	• Questions over management of devices (and split management)
> Resources
> 	• Homegate mailing list @ https://www.ietf.org/mailman/listinfo/homegate
> 	• Draft homegate overview @ http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/HomeGate%20BoF%20Proposal%20-%20IETF%2075%20-%20v7.pdf
> 	•

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 22 Jul 2009 17:17:45 +0200

> Topics

I would be interested in having a short discussion on cascading of  
home gateways, where there are several of them in the home.

Assuming a DHCPv6 prefix delegation model, this would require that the  
first (often ISP-provided and therefore presumably not that fully  
featured) gateway be able to act as a DHCPv6 server and subdelegate a  
subprefix from the prefix it got from the ISP. A possible simpler  
solution would be for that gateway to go into bridge mode and let the  
next CPE do the heavy lifting.

It would be good if we could agree that this is an important feature  
for users, so we should support it. But can we reasonably expect the  
subdelegation to be implemented in ALL home gateways?

---

From: David R Oran <[email-masked]>
Date: Wed, 22 Jul 2009 11:55:31 -0400

> home gateways, where there are several of them in the home.
Good addition, I would generalize it slightly and see if we want to  
tackle the "multiple subnets in the home" problem. These could be  
cascaded, parallel, same-cable, or multi-NAT in the IPv4 case.

> Assuming a DHCPv6 prefix delegation model, this would require that  
> the first (often ISP-provided and therefore presumably not that  
> fully featured) gateway be able to act as a DHCPv6 server and  
> subdelegate a subprefix from the prefix it got from the ISP. A  
> possible simpler solution would be for that gateway to go into  
> bridge mode and let the next CPE do the heavy lifting.
>
Yes.

> subdelegation to be implemented in ALL home gateways?
I would think so, but of course this should be discussed broadly.
If we don't do this, we won't get the auto-configuration properties of  
802.1 bridges and people will continue to try to hack things at L2  
rather than use IP capabilities. For example, at least one vendor uses  
link-local directly for application interactions because of the  
inability to count on routing transitive closure in the home.

---

From: Martin Focazio <[email-masked]>
Date: Wed, 22 Jul 2009 12:15:44 -0400

On Wed, Jul 22, 2009 at 11:17 AM, Iljitsch van Beijnum
<[email-masked]>wrote:

> first (often ISP-provided and therefore presumably not that fully featured)
> gateway be able to act as a DHCPv6 server and subdelegate a subprefix from
> the prefix it got from the ISP. A possible simpler solution would be for
> that gateway to go into bridge mode and let the next CPE do the heavy
> lifting.
>

Indeed, the next CPE might be something like a "home access & cloud
 controller" (HACC) that manages some  shared resources (storage, printing,
fax gateway, scanners, cameras, VoIP gateways, Media Devices, Gaming
Devices, etc) and it also will take on the role of overall network device
and user management.

We have been designing a pseudo-interface to just such a hypothetical device
as a means of conceptualizing how this might work for home users - this
downstream CPE device falls somewhere in between a NAS, A Media Center, a
Firewall and a Router, and might even toss in Parental Controls. It's kind
of the logical evolution of things, and we see this as being a critical
concept in the successful deployment of IPv6 to the home.

---

From: james woodyatt <[email-masked]>
Date: Wed, 22 Jul 2009 12:35:08 -0700

> 	• Thoughts on the scope of a draft charter – how broad or narrow  

My concern is that I want it to be pretty narrow.  Here are the items  
I believe MUST be on the agenda:

   - Zeroconf issues;
   - Security issues;
   - IPv6 and DHCPv6 issues;
   - DNS issues.

Additional items that I believe to be OPTIONAL, i.e. only if schedule  
permits:

   - ECN issues;
   - Diffserv issues;
   - Multicast issues.

Other items that I plan to argue vigorously SHOULD NOT be our concern:

   - Provider management issues, including firmware update and split  
management;
   - Sub-ip layer issues, including directed multicast links;
   - Any *non*-zeroconf prefix sub-delegation schemes. [!!!]

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

---

From: [email-masked]
Date: Wed, 22 Jul 2009 21:27:52 +0100

>    - Any *non*-zeroconf prefix sub-delegation schemes. [!!!]

+1, fully in agreement, particularly to the list of stuff that James 
suggests should be off-charter.

As protocol folks, we should be concentrating on protocol level issues, 
not advising on how to write provisioning / management GUIs.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 22 Jul 2009 22:38:34 +0200

On 22 jul 2009, at 22:27, [email-masked] wrote:

> As protocol folks, we should be concentrating on protocol level  
> issues, not advising on how to write provisioning / management GUIs.

The IETF is not just about protocols. We have tons of protocols,  
probably enough to make a home gateway do everything that it needs to  
do. What we don't have is an implicit (like in IPv4) or explicit  
understanding between the different parties involved (network  
operators, vendors, users) about how to deploy those protocols.

Although we must always be on the ready to escape from ratholes poste  
haste, I don't think it's useful to start declaring all sorts of  
things off-topic in this meeting that is going to lead up to the  
meeting where we decide what to work on.

If there's ever a time in the IETF where our reach should exceed our  
grasp it's during a bar bof.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Wed, 22 Jul 2009 17:03:50 -0400

> The IETF is not just about protocols. We have tons of protocols,
probably enough to make a home gateway do
> everything that it needs to do. What we don't have is an implicit
(like in IPv4) or explicit understanding
> between the different parties involved (network operators, vendors,
users) about how to deploy those protocols.

+1 

I think Homegate should primarily focus on the issues with deployment of
protocols in a home router - and if we find a gap in our deployment
model, then a protocol can be developed - but that may very well be a
rare occurance.

- Wes

---

From: Martin Focazio <[email-masked]>
Date: Wed, 22 Jul 2009 17:05:37 -0400

>
> The IETF is not just about protocols. We have tons of protocols, probably
> enough to make a home gateway do everything that it needs to do. What we
> don't have is an implicit (like in IPv4) or explicit understanding between
> the different parties involved (network operators, vendors, users) about how
> to deploy those protocols.
>

Thanks Iljitsch - to clarify - yes, I understand that this is a protocol
level discussion. All I ask is that you all consider what a protocol means
to the end user and usability and that as you gather to think about deep
deep, complicated things, you all keep somewhere in your minds the examples
of the successful protocols and practices that brought IPv4 to the awesome,
incredibly successful and really fascinating point where it's outgrown
itself. Of course, I am not proposing designing a GUI for a router as your
mission.

I am thinking, though how things like DHCP - and dare I say it - NAT
actually made things fairly easy for the home network setup. So when
zeroconf and security bubble up to the top of the discussion list, consider
the "competitive set" of what these protocols will have - which is to say
the protocols and practices and ease of use we have now.

Again, I'm a UX guy, and I'm talking to engineers. I think that there needs
to be a bridge here at least conceptually early on,  lest IPv6 becomes the
next x.400 over OSI vs SMTP over TCP/IP  situation with IPv6 turning into
some sort of a backhaul protocol that never quite makes it into the home.

Home networks - and by extension home gateways - will outnumber business
applications by 20 to 1. It's an important time to be thinking about the
current user experience of managing a home network, the transitional
experience to get to IPv6 and ultimately, the pure IPv6 experience.

Thanks again for your time in putting this event together.

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Wed, 22 Jul 2009 17:05:29 -0400

+2
 
I concur. I think we have the ingredients to define a gateway with existing protocols (or late drafts of protocols). Product specs within specific service providers/MSOs may go above and beyond what ends up being defined, but that's normal as it reflects somewhat different business models.
 
Regards,
 
-KE

________________________________

From: [email-masked] on behalf of Wes Beebee (wbeebee)
Sent: Wed 7/22/2009 3:03 PM
To: Iljitsch van Beijnum; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [homegate] Bar BoF Draft Topics

+1

- Wes

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: [email-masked]
Date: Wed, 22 Jul 2009 23:50:18 +0100

> I concur. I think we have the ingredients to define a gateway with 
> existing protocols (or late drafts of protocols).

That's sort of my point.

I'm much keener to see manufacturers build equipment that conforms to the 
protocols we have (and does so completely) than in trying to come up with 
some whizz-bang new standard and/or protocol for doing firmware updates.

See for example my draft-dnsext-dnsproxy, which is currently in the RFC 
Editor's Queue.

By the way, FWIW, I think I've seen at least four different ways to update 
a home gateway's firmware over IP, all of which use IETF-documented 
protocols:

- TFTP
- FTP
- HTTP upload
- HTTP download

I don't think it's our place, though, to recommend for or against any of 
these, since they all work, albeit with varying degrees of simplicity. 
Vendors that happen to choose a poor method will learn the error of their 
ways via commercial pressure (i.e. bad reviews).

IMHO, we should let the Broadband Forum et al worry about management and 
provisioning - as you say there's every chance that the underlying 
protocols they'll need already exist.

We can then concentrate on documenting and resolving real interoperability 
problems that affect end-users of the device while it's in service.

Ray