Subject: [homegate] Management of the Home Gateway

From: <[email-masked]>
Date: Wed, 17 Jun 2009 09:48:45 +0200

Hi again,

Although I managed it already, I want to start a separate discussion about the management of the home gateway. I think, that might be an important topic too. There are several points to discuss:

1)      Who manages/ configures such a device? The user? The operator? Doesn't matter?

2)      Is it a device, that can also be used for networks, that are not connected to the Internet? (which means, that management/configuration over a server in the Internet is not possible)

3)      Are there at least parts of the device, that cannot be accessed by the user (the operator can use it for whatever reason, e.g. network specific configurations...)?

4)      ...

I just think loud :) Maybe we don't want to deal with that, but I think it could be interesting to take those things in account too.

Carolin

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Wed, 17 Jun 2009 10:06:20 -0400

Carolin,
 
I'm a big believer in limiting the scope, at least at first, so that we can proceed more quickly. Note this is just my opinion but it's an informed one as an MSO that provides both managed and unmanaged services:
 
1) Who manages the device? - I Think in most cases, 90% of the time it is the customer/end user. Cablehome was a specification that detailed a router for a residential managed service and it pretty much failed miserably. It really does matter who controls/manages the device/devices within the home as the models are almost completely incompatible at an operational level. The cost of these devices will go up slightly with every MIB, every client control and remote access widget we add. We need to be mindful of that.
 
2) Is this a device that can also be used for network that are not connected to the Internet? - My position is that there is a degree of necessary bias that says these devices are tailored to a broadband service offering and that when that service does not exist, the device just sits there (at least as a scope constraint for this spec effort). That said, there is nothing we will write in the text to preclude the router from operating standalone while still being complaint to the spec. Any vendor wanting to provide a product differentiator could well add the necessary components to operate standalone without a broadband service. It's my view we shouldn't expend our effort/time on this "product spec" in the interests of time and of the primary purpose for these routers in a broadband service.
 
3) Are there parts of the device configuration that may not be accessible to the end user/customer? - This is possible, but when you get this far into the device control (i.e. configuration management) you have to start assuming models, which would break the above simpler assumptions unless you detailed multiple scenarios. It is quite possible to simply detail "some" of the configuration management aspects of this device and stay out of making a full product spec, which will tend to include the detailed configuration management aspects of a fully integrated gateway as produced by a vendor. We can afford to be more vague here. For example, we can describe how a stateless or stateful DHCP server could be implemented, provide examples of controls for these services, briefly describe the NAT process, packet filtering firewall feature and then stop right there. We need not mandate that the router have an SSH and/or HTTP remote management interface, or use XML to download a new configuration file that if in "standalone" will just pull up some default config that the user can alter themselves. 
 
4) ..... other stuff related to management - One of the ways we can handle this and any other functionality we want to account for when writing a more generic router spec is that the language you choose should never preclude a vendor/service provider going further (the above mentioned "product specification" which is always more detailed and tailored to a specific service offering) and should allow evolution without requiring the specification to be superceded a lot sooner. There is often no harm done to remain silent on areas of functionality which fall outside the core functionality of a router, allowing the service provider/vendor to innovate in these areas individually. The only basic assumption I would like to make (and to refrain from going much further on detailing) is that the router is assumed to operate within a service providers' access network for the purposes of broadband access and stop just short of using this router as a generic router in a standalone environment. Let the service provider/MSO and their vendors come up with the product spec to deliver that standalone device, they can rely on the spec we develop as their starting point (and probably 80-90% of the requirements we stipulate in the broadband delivered assumptions for the basic spec are retained).
 
Your thinking out loud is great, keep it up and I'll do the same.
 
-KE

________________________________

From: [email-masked] on behalf of [email-masked]
Sent: Wed 6/17/2009 1:48 AM
To: [email-masked]
Subject: [homegate] Management of the Home Gateway

Hi again,

4)      ... 

I just think loud J Maybe we don't want to deal with that, but I think it could be interesting to take those things in account too. 

Carolin

P Go Green! Print this email only when necessary. Thank you for helping Time Warner Cable be environmentally responsible.

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: Stephen Farrell <[email-masked]>
Date: Wed, 17 Jun 2009 15:12:43 +0100

Erichsen, Kirk wrote:
> 1) Who manages the device? - I Think in most cases, 90% of the time it is the customer/end user. 

If so, then I think part of any spec here should include some sort
of requirement for software/firmware update for the device. While
there may not be a specific protocol for that that every vendor
would want to use, this activity (if it becomes a WG) might be
able to at least set requirements there.

Stephen.

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Thu, 18 Jun 2009 10:05:01 +0100

Here are my thoughts:

The device does not necessarily have to be a home gateway.  By way of  
example, look at Apple's Airport Express, and the numerous ways it can  
be used: as NAT box, as WAP/bridge, as extender, simply as print  
server and audio receiver ...

I don't think, in a sentence, that it's right to deliberately  
constrain devices when there's no reason.  Right now it's hard enough  
separating out layer 2 upstream from residential gateway, especially  
for DSL, since a lot of messing about has to happen to make a DSL  
modem that emulates a cable modem (because PPP brings the need to do  
things like layer 3 proxying of DHCP, for instance).  I wonder Apple  
gets much sale at all - the real benefitiary of their products are  
cable modem users, or maybe PPPoE over anything users.  In the  
meantime many DSL boxes already do NAT and we have a lot of double- 
natted subnetworks where consumers have tried to make a "Router" work  
with a "DSL modem".

Of course, I don't say integrated devices are bad.  But utilitarianism  
is what I believe in fundamentally, however simple the process is.

Cheers,
Sabahattin

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 18 Jun 2009 15:56:01 -0400

> able to at least set requirements there.

Firmware update methods were a topic of discussion when a few parties met to
discuss the problem space in Philadelphia months ago.  One of the issues is
related to why web browsers and operating systems now perform automatic
checks for updates.  Today, this generally does not happen, though in some
cases it can be prompted by the user savvy enough to visit the local device
management web page periodically.  In any case, there are regular security
fixes which are made available and without recommendations on how updates
should occur (user intervention, automatically downloaded, automatically
applied, etc.) many devices leave this to the users -- and probably 90%+ of
the user base will never upgrade the firmware on the device.

Jason

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Thu, 18 Jun 2009 16:34:17 -0400

Are we only interested in a generic software mechanism ("how") that be standardized, without really worrying about the management model (the "who")?

-----Original Message-----
From: Livingood, Jason [mailto:[email-masked]]
Sent: Thu 6/18/2009 1:56 PM
To: Stephen Farrell; Erichsen, Kirk
Cc: [email-masked]; [email-masked]
Subject: Re: [homegate] Management of the Home Gateway

Jason

---

From: "Richard Bennett" <[email-masked]>
Date: Thu, 18 Jun 2009 18:57:40 -0700

The telco-deployed gateways are managed as CPE, using the TR stuff for
firmware upgrades, but for the retail product about all we can do is advise
customers to periodically apply upgrades the hard way. In a perfect world, I
suppose there would be a single web site where both customers and support
people could go to see what the latest revision is for every gateway, but
this isn't such a world.

Another option is to declare it a BCP to have an easy "check for upgrade"
button on the first page of the gateway's GUI or something similar.

Richard Bennett

-----Original Message-----
From: Erichsen, Kirk [mailto:[email-masked]] 
Sent: Thursday, June 18, 2009 1:34 PM
To: Livingood, Jason; Stephen Farrell
Cc: [email-masked]; [email-masked]
Subject: Re: [homegate] Management of the Home Gateway

Are we only interested in a generic software mechanism ("how") that be
standardized, without really worrying about the management model (the
"who")?

P Go Green! Print this email only when necessary. Thank you for helping Time
Warner Cable be environmentally responsible.

-----Original Message-----
From: Livingood, Jason [mailto:[email-masked]]
Sent: Thu 6/18/2009 1:56 PM
To: Stephen Farrell; Erichsen, Kirk
Cc: [email-masked]; [email-masked]
Subject: Re: [homegate] Management of the Home Gateway
 
On 6/17/09 10:12 AM, "Stephen Farrell" <[email-masked]> wrote:
> Erichsen, Kirk wrote:
>> 1) Who manages the device? - I Think in most cases, 90% of the time it is
the
>> customer/end user.

Jason

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

---

From: "Richard Bennett" <[email-masked]>
Date: Fri, 19 Jun 2009 01:10:09 -0700

Or even better, we can recommend that the gateway automatically check an ftp
archive for updates and apply them like Windows does with patches. Vendors
could allow this feature to be turned off by the skilled user, but by
default it should be on.

RB

> From: Richard Bennett [mailto:[email-masked]]
> Sent: Thursday, June 18, 2009 6:58 PM
> To: 'Erichsen, Kirk'; 'Livingood, Jason'; 'Stephen Farrell'

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Jun 2009 11:39:14 +0100

Well, I'm not sure that all vendors would want to use the
same protocol - I think pretty much everything in the desktop
space that gets used is proprietary, so I think that we'd
be more in the business of stating requirements, e.g.
that there must be an auto-update that can be easily turned
off and on, that the update protocol must strongly authenticate
the source of updates, that updates must not have to happen
on a single connection (trickle-updates) etc.

I don't think there'd be too much work to get that done,
so I could envisage a nice short RFC that'd be useful to
vendors who were designing their own update schemes.

OTOH, if there were a sufficient number of folks that wanted
to define an IETF s/w update protocol that might be worthwhile,
but I've not seen that demand. I guess the main argument for
the IETF being involved in that would be to make it easier
for vendors to just pick up something that's high quality,
rather than making e.g. the security mistakes that might
otherwise happen. However, it seems to me that that might
need a WG all of its own, for which I doubt the interest
exists.

I still think it'd be useful for this group to specify
update requirements since as others said, this is an area
where embedded devices are sadly lacking.

S.

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Fri, 19 Jun 2009 13:17:39 -0400

I concur. Don't get hung up on the protocols, just keep the functions clear and concise. Given the disparity in management models, this could easily become a time-sink without much value to the end product.
 
-KE

From: Stephen Farrell [mailto:[email-masked]]
Sent: Fri 6/19/2009 4:39 AM
To: Richard Bennett
Cc: Erichsen, Kirk; 'Livingood, Jason'; [email-masked]; [email-masked]
Subject: Re: [homegate] Management of the Home Gateway

S.

---

From: "Richard Bennett" <[email-masked]>
Date: Fri, 19 Jun 2009 11:57:39 -0700

I agree it's the function that matters, not the means. Take my reference to
ftp below as a "for example."

Richard Bennett

-----Original Message-----
From: Erichsen, Kirk [mailto:[email-masked]] 
Sent: Friday, June 19, 2009 10:18 AM
To: Stephen Farrell; Richard Bennett
Cc: Livingood, Jason; [email-masked]; [email-masked]
Subject: RE: [homegate] Management of the Home Gateway

I concur. Don't get hung up on the protocols, just keep the functions clear
and concise. Given the disparity in management models, this could easily
become a time-sink without much value to the end product.
 
-KE

From: Stephen Farrell [mailto:[email-masked]]
Sent: Fri 6/19/2009 4:39 AM
To: Richard Bennett
Cc: Erichsen, Kirk; 'Livingood, Jason'; [email-masked];
[email-masked]
Subject: Re: [homegate] Management of the Home Gateway

S.

Richard Bennett wrote:
>> customers to periodically apply upgrades the hard way. In a perfect
world,
>> I

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Fri, 19 Jun 2009 15:02:09 -0400

Richard,
 
That was how I interpreted it. :)
 
-KE

From: Richard Bennett [mailto:[email-masked]]
Sent: Fri 6/19/2009 12:57 PM
To: Erichsen, Kirk; 'Stephen Farrell'
Cc: 'Livingood, Jason'; [email-masked]; [email-masked]
Subject: RE: [homegate] Management of the Home Gateway

Richard Bennett

-----Original Message-----
From: Erichsen, Kirk [mailto:[email-masked]]
Sent: Friday, June 19, 2009 10:18 AM
To: Stephen Farrell; Richard Bennett
Cc: Livingood, Jason; [email-masked]; [email-masked]
Subject: RE: [homegate] Management of the Home Gateway

-KE

S.

world,

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sat, 20 Jun 2009 09:44:45 +0100

> could allow this feature to be turned off by the skilled user, but by

There'll be screams of cold bloody murder if this sort of thing gets  
used for evil purposes like interception and/or monitoring.  Some  
people like the control over installed software.  Windows, with its  
multitude of unwanted critical patches, goes for example.  As a  
general rule I doubt most people will care but I think users should  
probably be notified in advance that their gateway has a will of its  
own.

Cheers,
Sabahattin

---

From: <[email-masked]>
Date: Mon, 22 Jun 2009 08:59:14 +0200

I agree, that people *should* be notified, but it is not necessarily the case today. My (ISP) DSL router for instances updates itself from time to time. There is nothing I can do about it. One of the updates moved the wireless configuration to my ISP's server (not really sure why but I have a theory that might make sense) and even if I - as an experienced and skilled user - do not want that, I have to accept that or install an additional AP. So, probably we should try to find a trade-off between what we - as techies - would like to have and what a normal user needs/ requests. As you said, most of the people won't care (even if they should :( )

Carolin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sabahattin Gucukoglu
Sent: Samstag, 20. Juni 2009 10:45
To: [email-masked]
Subject: Re: [homegate] Management of the Home Gateway

Cheers,
Sabahattin

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 22 Jun 2009 15:13:47 +0200

> could allow this feature to be turned off by the skilled user, but by

No, it shouldn't be. Updates often cause just as many problems as they  
solve. Having a home gateway that worked just fine break because  
someone decided to push out an update is completely unacceptable.  
Especially because update procedures are often lengthy, may render the  
device unusable if interrupted, and if the device ends up in a non- 
working state there is no recovery because there is no internet  
connection.

---

From: Iñigo Artundo <[email-masked]>
Date: Mon, 22 Jun 2009 15:53:43 +0200

Totally agree, if an update renders the gateway offline, the ISP will 
have thousands of angry users knocking at its door with a brick on their 
hands.

It's true that firmware upgrading is easier and less risky than 
operating system or other software updates, as the hardware is 
(supposedly) all the same. But still, for such a critical device on the 
home network, I would be very careful and leave the updating to the 
user, maybe reminded by an applet on the GUI of the gateway.

Iñigo

Iljitsch van Beijnum wrote:
> solve. Having a home gateway that worked just fine break because someone 
> decided to push out an update is completely unacceptable. Especially 
> because update procedures are often lengthy, may render the device 
> unusable if interrupted, and if the device ends up in a non-working 
> state there is no recovery because there is no internet connection.

-- 

Iñigo Artundo, PhD
iTEAM - Grupo de Comunicaciones Opticas
Universidad Politecnica de Valencia (UPV)
http://www.iteam.upv.es

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Mon, 22 Jun 2009 10:18:20 -0400

In order for this to work, you would have to have basic connectivity
without the firmware upgrade.  Something like ROMMON on Cisco routers
would do the trick: a very basic OS with just the capability of
contacting the server and downloading upgrades, and then boot the main
OS, which would be upgraded.  Then you would also need to have enough
regression done on updates to be sure that there won't be a deployment
problem - something like the regression scripts that Debian runs for
upgrades may do the trick.  The question is: with the razor-thin margins
on this device, could vendors afford to provide this capability?

- Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Iljitsch van Beijnum
Sent: Monday, June 22, 2009 9:14 AM
To: Richard Bennett
Cc: 'Livingood, Jason'; [email-masked]; [email-masked]
Subject: Re: [homegate] Management of the Home Gateway

On 19 jun 2009, at 10:10, Richard Bennett wrote:

> Or even better, we can recommend that the gateway automatically check 
> an ftp archive for updates and apply them like Windows does with 
> patches.
> Vendors

decided to push out an update is completely unacceptable.

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Mon, 22 Jun 2009 21:14:46 +0100

My cable company provides updates to my cable modem.  Fine; if they  
break it, it's their fault, and they lose.  But my home gateway is  
mine, and it merely flashes it's status light (which, being blind, I  
can't see) to indicate update availability.  Perhaps this is good  
enough for Joe Consumer.

For cable there are generally better possibilities for delivering  
updates in an automatic and side-channel process.  The same can't be  
said for DSL because, as somebody mentioned, the primary lin *is* the  
update delivery method, and if you bust the brick, you've lost a  
customer and probably broken his network too.

Cheers,
Sabahattin

---

From: <[email-masked]>
Date: Mon, 22 Jun 2009 22:23:43 +0200

Hi,

I think there is a need for common management, and functionality that the user can relate to besides the branding on the carton. The average user is becoming very aware of the technologies in use, still most CPEs is sold with little-to-nothing about what dark magic it supports and how it can be managed, besides the logos. Document (3) could act as a baseline, if you are planning on specifying more than just management, also functionality.

Management (1) and the data models to go with it standardize a way for operators to manage the CPE and devices behind it. I think that at some point this has been considered, at least how to separate users that want to manage this them selves. The table on page 20 (2) specifies a attribute named "UpgradesManaged" that an CWMP ACS should relate to, that states if the ACS should manage firmware or not. For our part, notification of firmware upgrades will in the future be done through walled garden.
 
A complicating factor of firmware management is that physical interoperability is at best intricate; we spend a great deal of time making this work for every single release. In some countries this is at such a level that competition within the CPE marked is non existent. This is a thing to keep in mind.

At the same time I think most ISPs are becoming aware of the fact that the CPE terminating the access line is becoming an important part of their network, since they are now delivering services deep within the customer's network (IPTV, SIP, alarms, power readings, backup, you name it). In other words I suspect that the box in charge of terminating the line for the customer in a much larger degree will have to be owned and/or managed by the ISP. This in turn leads to reports, documents, standards that define management of devices in the home network as seen from the Broadband Forum.

I'm not saying that retail products (CPE), but I think we must consider the implications of such a standard and be careful :-) For a layer 3 device deep within the network, these kind of considerations does not apply. Still firmware upgrade (or what I would like to call firmware change, since it is not always per se an 'UPgrade') is a tedious process, many considerations for how this can be done as safe as possible is outlined in the different Broadband Forum documents.

References:

1) "TR-069 Amendment 1 and 2, CPE WAN Management Protocol"
http://broadband-forum.org/technical/download/TR-069Amendment1.pdf
http://broadband-forum.org/technical/download/TR-069Amendment2.pdf

2) "TR-098 Amendment 2, Internet Gateway Device Data Model for TR-069"
http://www.broadband-forum.org/technical/download/TR-98_Amendment_2.pdf

3) "TR-124, Functional Requirements for Broadband Residential Gateway Devices"
http://broadband-forum.org/technical/download/TR-124.pdf

Thanks,
Ole Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Bennett
Sent: 19. juni 2009 03:58
To: 'Erichsen, Kirk'; 'Livingood, Jason'; 'Stephen Farrell'
Cc: [email-masked]; [email-masked]
Subject: Re: [homegate] Management of the Home Gateway

Richard Bennett

-----Original Message-----
From: Livingood, Jason [mailto:[email-masked]]
Sent: Thu 6/18/2009 1:56 PM
To: Stephen Farrell; Erichsen, Kirk
Cc: [email-masked]; [email-masked]
Subject: Re: [homegate] Management of the Home Gateway
 
the

Jason

---

From: "Richard Bennett" <[email-masked]>
Date: Mon, 22 Jun 2009 14:13:30 -0700

The fact of the matter is that the telco home gateways already support
automated firmware updates, with the appropriate failsafes and recovery
mechanisms to deal with the odd case of a failed update. So the question is
whether the retail home gateways should strive for a similar level of
functionality. It seems to me that automated firmware updates are the only
way to ensure that updates will ever be applied in most cases, as the
typical user probably never uses the management GUI and would therefore
never be able to force an update via manual means.

While there's some element of risk in any action, the risk of updating
firmware in the process that's well-specified for authentication and
recovery is less than the risk of never updating and therefore exposing the
Internet to the consequences of bad code.

Richard Bennett

-----Original Message-----
From: Wes Beebee (wbeebee) [mailto:[email-masked]] 
Sent: Monday, June 22, 2009 7:18 AM
To: Iljitsch van Beijnum; Richard Bennett
Cc: Livingood, Jason; [email-masked]; [email-masked]
Subject: RE: [homegate] Management of the Home Gateway

- Wes

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Mon, 22 Jun 2009 17:37:20 -0400

Ole,
 
While I'd agree we could perhaps come up with a framework for how features (mandatory and vendor defined) "should" be supported within the gateway from a UI/management perspective, I think this may get too far into product specification grounds and away from a spec that is basically about features/functions unless we very carefully map out the expectations here. 
 
With regards to management, I quote your thread from below: "Management (1) and the data models to go with it standardize a way for operators to manage the CPE and devices behind it."
 
This is a sore spot in cable. We had a magnificent specification developed to do just that. It produced a very complex, very expensive box that lacked alignment with trends towards more and more user managed gateways. It is for that reason I would agree that some effort to craft text around user-management expectations should be included in the document. However, it's my view we need to resist the temptation to over-specify low level functionality/look and feel with regards to management and should de-emphasize service providers ownership of the device management. If we can agree, for example, on a set of user-management functions, what might those be? Here is an example of a few, in no particular order and open to debate:
 
1) a Web based UI exposing configuration management of features defined elsewhere in the document 
2) a "return to default" configuration option to ensure that any meddling done by the user that causes unexpected behavior can be neutralized with a reset to default option and a reboot of the device. This option is applicable to a push-pin, a software-only method or some other method. There may be some value in standardizing down to one or two approaches, though if these devices aren't managed by the service provider (customer care doesn't have to keep a sheet of all potential methods for every model router) this may not be necessary.
3) A method of backing up/restoring configurations so that configurations can be restored when new configurations are tried. The simplest way to do this is allow the user's PC to store the configs and back/restore "off board" of the router itself (reduce the need for the router to be able to discern one config over another to boot from). For example, the user could "test" a configuration change and if odd behavior occurs, revert. This is in addition to a reset to defaults since the defaults may have features disabled or configured differently than the customer requires. As the number of features and the interactions among features increases, odd behavior is bound to pop up with a bad configuration choice. This could manifest as decreased packet forwarding performance, or other telltales that only occur when using certain applications.  
 
-KE

From: [email-masked] [mailto:[email-masked]]
Sent: Mon 6/22/2009 2:23 PM
To: [email-masked]; Erichsen, Kirk; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [homegate] Management of the Home Gateway

Hi,

References:

Thanks,
Ole Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Bennett
Sent: 19. juni 2009 03:58
To: 'Erichsen, Kirk'; 'Livingood, Jason'; 'Stephen Farrell'
Cc: [email-masked]; [email-masked]
Subject: Re: [homegate] Management of the Home Gateway

Richard Bennett

-----Original Message-----
From: Livingood, Jason [mailto:[email-masked]]
Sent: Thu 6/18/2009 1:56 PM
To: Stephen Farrell; Erichsen, Kirk
Cc: [email-masked]; [email-masked]
Subject: Re: [homegate] Management of the Home Gateway

the

Jason

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Mon, 22 Jun 2009 20:29:29 -0400

All,
 
I'd be willing to concede on the issue of automatic updates so long as we are clear what this means in spec terms and that we are willing to justify the time necessary to do it properly. Also, what problem are we trying to solve with automatic software updates that directly affect the other features we want? Is this "core" functionality, or it is something else? 
 
For example, if the text tells you "how" the automatic updates could be accomplished, without mandating that the router must be automatically updated (vs. manual, etc.) and then render the actual mechanisms optional, I think we'd have a fair compromise. From a vendor perspective, this would mean that if the feature is implemented in the router, it must follow the spec text. With regards to the details within the "how" I think we have to clarify that there may be differences in a "standalone" router vs. one which has an embedded cable modem or DSL modem.  Where a DSL or cable modem may be embedded, I suggest we reference the architecture-dependent parts back into those standard bodies (this applies to a host of other features that will come up) as they already cover these issues within these respective specs quite well. In cable, we rely upon the eDOCSIS model wherever a CM is embedded with another device (like a router) and the DOCSIS software download framework for software download requirements.   
 
By assuming that we have either a standalone device (the "generic" case) or an embedded device with some form of modem (DSL, cable) we can bi-ficate into handling the issues separately. For the generic standalone case, we could strip down many of the functions and behaviors, or rely on an existing framework spec.
 
Operationally, software download is non-trivial and as has been mentioned, without QA testing to make sure the code behaves appropriately you might get "newer" code with more wrong than right with it. Given the razor thin margins common to these platforms, what gets added is usually features that were advertised, but were missing from the original builds or major/minor bug fixes to existing functionality that have been noticed after the first release. It would not be unreasonable to expect that very few software updates actually come out for a given product these days (from a business perspective, it's a big cost sink to a vendor and is only done when it must be). One very good reason for keeping the feature list tight is that this will control code bloat and invariably code defects that prompt one to update the software on the router in the first place. 
 
Some of the rather icky issues we would confront for the generic standalone case include one that may not be so obvious: If the CM or DSL modem is updating and reboots, can the background data transfer for the standalone router's own software download, if happening concurrently, be affected? In this scenario, perhaps the user has a very low upper transfer rate for software downloads set (or it could even be the default configuration) which may be at a transfer rate too low for the modem to defer it's own reboot for, or no one bothered to check the activity before forcing the reboot. 
 
What affect might an interrupted software download have on the standalone router (it probably shouldn't matter what caused it)? Will the transfer need to resume where it left off when the modem comes back up and bridging proceeds, or just start over again? Are there retries, bakeoffs or ICMP messages that the router needs to pay attention to with regards to software download? Does the router need to check activity on it's own interfaces or system counters before initiating the either a download or rebooting with a new software image? Can you safely determine when to reboot the device without suddenly being obligated to add counter objects to monitor system/interface statistics? If it really is a user-managed gateway, we remove many of these concerns, though if they are "fully" automatic in the download, they are probably going to have to do some checking to decide when or even if to automatically reboot to use that new software image.
 
In the case of a cable modem, we have access to the CM's counters and we can sweep through devices of the same sysDesc for hardware/software rev and determine the correct image to download, then verify when activity is low enough that we can safely reboot the CM. Every DOCSIS CM can support two software loads in flash in case the new load fails for one reason or another.
 
There are some other oddities you have to plod through, like multi-level software upgrades and whether you support something other than one big binary blob coming down the pipe. You may find you have old software versions out there that a vendor wants to update from 2.0 to 4.1a. However, to get from 2.0 to 4.1a, you may have to upgrade to a break-point version like 3.1 (say if the new software changes the organization or format of the flash device, etc).  

These are just examples of some of the issues we will need to confront. Best to go in with eyes wide open.
 
Regards,
 
-KE

From: [email-masked] on behalf of Richard Bennett
Sent: Mon 6/22/2009 3:13 PM
To: 'Wes Beebee (wbeebee)'; 'Iljitsch van Beijnum'
Cc: [email-masked]; 'Livingood,Jason'; [email-masked]
Subject: Re: [homegate] Management of the Home Gateway

Richard Bennett

-----Original Message-----
From: Wes Beebee (wbeebee) [mailto:[email-masked]]
Sent: Monday, June 22, 2009 7:18 AM
To: Iljitsch van Beijnum; Richard Bennett
Cc: Livingood, Jason; [email-masked]; [email-masked]
Subject: RE: [homegate] Management of the Home Gateway

- Wes

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Jun 2009 12:45:23 +0100

> Internet to the consequences of bad code.

+1 to that.

Stephen.

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 23 Jun 2009 09:16:06 -0400

This is precisely what I was getting at.  It seems bad hygiene to expect
that a user will update their software automatically - it just does not
happen in reality.  The box runs, so why update it?  As OS vendors have
learned, you have to automate this for the user.

So something along the lines of:
A software (firmware) update function must be present, which periodically
and without user intervention, checks for and downloads firmware updates.
Optionally, a software installation function may apply these
automatically-downloaded firmware updates on the device on either (1) an
immediate basis or (2) a pre-scheduled basis.  All of the above settings
should be pre-configured and defaulted on/active by the device maker, and
users should have the ability to modify such settings.  [We may also need to
provide some text about a security mechanism to verify that the firmware
updates is properly signed/trust-verified.]

Jason

---

From: "Jeff Goodwin (jegoodwi)" <[email-masked]>
Date: Tue, 23 Jun 2009 06:20:53 -0700

Kirk, ALL, 

One of the major differences between "retail" CPE, and "Service Provider
routers" layer 2 related components in the service provider network.
Examples of this include CMTS/DSLAM, SoftSwitch.   However, layer 3
components such as IMS, and emerging categories like self-healing
support systems could be considered common.

It would be useful to allow the CPE to register & receive notifications
of network components that go through SW upgrades.

A software framework which embodies this, while allowing differences in
protocol implementation (e.g., TR--069, v.s. HTTP/SOAP/XML, HNAP, SNMP,
CLI, WEB, etc..) would be ideal from our perspective.   Having an XML
schema to represent the data model would serve as a good point of
reference.  There is also a need to register network elements for
logging, self-healing, and corrective action to be taken based on events
happening in the network or on the device (including possible SW
upgrades).

Note that the ability to extend the framework by allowing registration
of other devices in the internal network, would improve the ability to
automate problem resolution in home networking.

Best regards,
Jeff

Product Management & Engineering
Cable Home Networking Business Unit
Cisco Systems, Inc.

-----Original Message-----
From: Erichsen, Kirk [mailto:[email-masked]] 
Sent: Monday, June 22, 2009 8:29 PM
To: [email-masked]; Wes Beebee (wbeebee); Iljitsch van Beijnum
Cc: [email-masked]; Livingood,Jason; [email-masked]
Subject: Re: [homegate] Management of the Home Gateway

All,
 
I'd be willing to concede on the issue of automatic updates so long as
we are clear what this means in spec terms and that we are willing to
justify the time necessary to do it properly. Also, what problem are we
trying to solve with automatic software updates that directly affect the
other features we want? Is this "core" functionality, or it is something
else? 
 
For example, if the text tells you "how" the automatic updates could be
accomplished, without mandating that the router must be automatically
updated (vs. manual, etc.) and then render the actual mechanisms
optional, I think we'd have a fair compromise. From a vendor
perspective, this would mean that if the feature is implemented in the
router, it must follow the spec text. With regards to the details within
the "how" I think we have to clarify that there may be differences in a
"standalone" router vs. one which has an embedded cable modem or DSL
modem.  Where a DSL or cable modem may be embedded, I suggest we
reference the architecture-dependent parts back into those standard
bodies (this applies to a host of other features that will come up) as
they already cover these issues within these respective specs quite
well. In cable, we rely upon the eDOCSIS model wherever a CM is embedded
with another device (like a router) and the DOCSIS software download
framework for software download requirements.   
 
By assuming that we have either a standalone device (the "generic" case)
or an embedded device with some form of modem (DSL, cable) we can
bi-ficate into handling the issues separately. For the generic
standalone case, we could strip down many of the functions and
behaviors, or rely on an existing framework spec.
 
Operationally, software download is non-trivial and as has been
mentioned, without QA testing to make sure the code behaves
appropriately you might get "newer" code with more wrong than right with
it. Given the razor thin margins common to these platforms, what gets
added is usually features that were advertised, but were missing from
the original builds or major/minor bug fixes to existing functionality
that have been noticed after the first release. It would not be
unreasonable to expect that very few software updates actually come out
for a given product these days (from a business perspective, it's a big
cost sink to a vendor and is only done when it must be). One very good
reason for keeping the feature list tight is that this will control code
bloat and invariably code defects that prompt one to update the software
on the router in the first place. 
 
Some of the rather icky issues we would confront for the generic
standalone case include one that may not be so obvious: If the CM or DSL
modem is updating and reboots, can the background data transfer for the
standalone router's own software download, if happening concurrently, be
affected? In this scenario, perhaps the user has a very low upper
transfer rate for software downloads set (or it could even be the
default configuration) which may be at a transfer rate too low for the
modem to defer it's own reboot for, or no one bothered to check the
activity before forcing the reboot. 
 
What affect might an interrupted software download have on the
standalone router (it probably shouldn't matter what caused it)? Will
the transfer need to resume where it left off when the modem comes back
up and bridging proceeds, or just start over again? Are there retries,
bakeoffs or ICMP messages that the router needs to pay attention to with
regards to software download? Does the router need to check activity on
it's own interfaces or system counters before initiating the either a
download or rebooting with a new software image? Can you safely
determine when to reboot the device without suddenly being obligated to
add counter objects to monitor system/interface statistics? If it really
is a user-managed gateway, we remove many of these concerns, though if
they are "fully" automatic in the download, they are probably going to
have to do some checking to decide when or even if to automatically
reboot to use that new software image.
 
In the case of a cable modem, we have access to the CM's counters and we
can sweep through devices of the same sysDesc for hardware/software rev
and determine the correct image to download, then verify when activity
is low enough that we can safely reboot the CM. Every DOCSIS CM can
support two software loads in flash in case the new load fails for one
reason or another.
 
There are some other oddities you have to plod through, like multi-level
software upgrades and whether you support something other than one big
binary blob coming down the pipe. You may find you have old software
versions out there that a vendor wants to update from 2.0 to 4.1a.
However, to get from 2.0 to 4.1a, you may have to upgrade to a
break-point version like 3.1 (say if the new software changes the
organization or format of the flash device, etc).  

These are just examples of some of the issues we will need to confront.
Best to go in with eyes wide open.
 
Regards,
 
-KE

The fact of the matter is that the telco home gateways already support
automated firmware updates, with the appropriate failsafes and recovery
mechanisms to deal with the odd case of a failed update. So the question
is
whether the retail home gateways should strive for a similar level of
functionality. It seems to me that automated firmware updates are the
only
way to ensure that updates will ever be applied in most cases, as the
typical user probably never uses the management GUI and would therefore
never be able to force an update via manual means.

While there's some element of risk in any action, the risk of updating
firmware in the process that's well-specified for authentication and
recovery is less than the risk of never updating and therefore exposing
the
Internet to the consequences of bad code.

Richard Bennett

P Go Green! Print this email only when necessary. Thank you for helping
Time Warner Cable be environmentally responsible.

-----Original Message-----
From: Wes Beebee (wbeebee) [mailto:[email-masked]]
Sent: Monday, June 22, 2009 7:18 AM
To: Iljitsch van Beijnum; Richard Bennett
Cc: Livingood, Jason; [email-masked]; [email-masked]
Subject: RE: [homegate] Management of the Home Gateway

- Wes

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 23 Jun 2009 15:23:16 +0200

> and without user intervention, checks for and downloads firmware  

I have to very strongly object to the above.

Your assumption is that upgrading is necessary, even if the user  
doesn't want to. That is a flawed assumption unless you're speaking  
from personal involvement in creating firmware that is so bad that  
this is true.

Updates frequently introduce new bugs, so the hesitation on many  
user's part to upgrade is often quite reasonable.

The service interruption involved may be unacceptable on its own.

I don't think vendors want to include double the flash memory for this  
purpose, either.

A much better way to upgrade would be to download the new firmware to  
a local system which also has a copy of the currently running  
firmware, and then perform the update over the local network when the  
user chooses to do so.

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 23 Jun 2009 09:36:57 -0400

> I have to very strongly object to the above.

+1 from me.

Marshall

> I don't think vendors want to include double the flash memory for  
> this purpose, either.
>
> A much better way to upgrade would be to download the new firmware  
> to a local system which also has a copy of the currently running  
> firmware, and then perform the update over the local network when  
> the user chooses to do so.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Jun 2009 15:35:16 +0100

Iljitsch van Beijnum wrote:
> Your assumption is that upgrading is necessary, even if the user doesn't
> want to. That is a flawed assumption unless you're speaking from
> personal involvement in creating firmware that is so bad that this is true.

I think that's overstated somewhat. There are times when pushing out
fixes is the right thing. I guess security patches would be the
prime example there.

> Updates frequently introduce new bugs, so the hesitation on many user's
> part to upgrade is often quite reasonable.

Fair point. I think everyone seems to agree that if anything is
done here, that the user must be able to override whatever is
the default setting.

> A much better way to upgrade would be to download the new firmware to a
> local system which also has a copy of the currently running firmware,
> and then perform the update over the local network when the user chooses
> to do so.

Right. But the problem there is that most users just aren't aware
of any of this and so never upgrade/patch.

I guess the question for me is whether its better to have a default
of automatically updating or a default where the user chooses when
to update. I don't claim to know the right answer, but I do think
that savvy users are a minority that are more likely to want to
control when updates happen, and that the majority of users never
do anything and hence never get anything except automatic updates.

To me that implies that the better default is to automatically
update. However, that's really just a hunch - does anyone have
any data on this that they could share?

S.

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 23 Jun 2009 10:49:19 -0400

> learned, you have to automate this for the user.

The OS's I use do not do this by default, and I only know of one which  
does. That is different from
informing the user that upgrades are available or needed.

There is to me another issue here. Most home users, in my experience,  
know (or remember) nothing of the various GUI
interfaces for their devices. A SOHO network might easily have a cable  
modem, a wireless router, and a wireline switch from different  
vendors, all with completely different GUI's for fairly similar  
functions. Very few users will deal with this unless forced to. That  
is one advantage an OS vendor has - the power to put a dialog box in  
front  of the user.

Would it be in scope to describe some sort of ZeroConf type mechanism  
for doing this ? My printer complains when it needs ink, why shouldn't  
my router be able to complain when it needs an update ?

Regards
Marshall

>>> customers to periodically apply upgrades the hard way. In a  
>>> perfect world,
>>> I
>>> Time
>>>>> 1) Who manages the device? - I Think in most cases, 90% of the  
>>>>> time it
>>> is
>>> the
>>>>> customer/end user.
>>>>
>>> Firmware update methods were a topic of discussion when a few  
>>> parties met
>>> to
>>> discuss the problem space in Philadelphia months ago.  One of the  
>>> issues
>>> is
>>> applied, etc.) many devices leave this to the users -- and  
>>> probably 90%+
>>> of

---

From: "Bob Carrick" <[email-masked]>
Date: Tue, 23 Jun 2009 11:01:54 -0400

Just a quick chime in on this thread guys.  There is a remote management
standard, TR-069, for all broadband types (currently minus the Cable
forums though, but is Wimax, DSL, Femto, IPTV, VoIP, Fiber and their
respective forums, etc) that answers most if not all of these questions
for you that have been brought up in this thread, or at least the
vendors of those solutions do.

With many TR-069 solutions you can do hands free provisioning (remote)
and simple things such as scheduled remote upgrades via a simple unified
interface for remote management of all those above mentioned device
types.  This allows firmware revs to be signed off on by you and rolled
out across all the supported devices.  This way bugs are introduced etc.
You could also automatically roll your users back to your "supported"
firmware if you know bugs are in newer versions (or older) that you
don't want to support, etc.

You can also provide that unified interface to your customer in a portal
of types and let them upgrade or manage their own CPE.

I could go on and try to touch on each point raised in the thread, but
it is a long thread.

Bob Carrick
Director - Broadband Products
Fine Point Technologies, Inc.
75 Broad Street, Suite 300
New York, NY 10004
email:  [email-masked]
phone: +1.212.962.7410 x62
fax: +1.212.962.7404
web: http://www.finepoint.com

> Behalf Of Marshall Eubanks
> Sent: Tuesday, June 23, 2009 10:49 AM
> To: Livingood, Jason
> Cc: [email-masked]; [email-masked]
> >>> firmware upgrades, but for the retail product about all we can do
> is
> >>> advise
> >>> cases it can be prompted by the user savvy enough to visit the
> local
> >>> device

---

From: [email-masked]
Date: Tue, 23 Jun 2009 16:20:15 +0100

Personally, I would rather see this group concentrate on developing BCPs 
for ensuring *correct* implementation of current IETF *protocol* 
standards, and not working to develop new protocols, mechanisms, update 
systems, etc. 

Ray

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Tue, 23 Jun 2009 11:43:39 -0400

All,
 
Keep in mind there is a difference between a general purpose OS and an embedded system when it comes to frequency of updates. Active ongoing development after the initial release is pretty rare and most of the time that code comes from the reference design vendor, not the router manufacturers themselves. It's been my experience residential focused embedded systems do not (and indeed for the price, should not)  do not get a lot of software updates after the fact. A typical number might be one or two updates a year and only as a consequence of some major new feature addition and/or major bug fixes. Collapsing minor bug fixes into a one or twice a year schedule for up to three years is common. The vendors usually move on to the next platform and the focus is there for software development. 
 
Lets set expectations realistically around the profile of embedded systems, where not a lot of development is likely to continue for these types of products.  
 
-KE

From: Marshall Eubanks [mailto:[email-masked]]
Sent: Tue 6/23/2009 8:49 AM
To: Livingood, Jason
Cc: Richard Bennett; Erichsen, Kirk; 'Stephen Farrell'; [email-masked]; [email-masked]
Subject: Re: [homegate] Management of the Home Gateway

Regards
Marshall

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Tue, 23 Jun 2009 11:53:54 -0400

Cable has it's own method defined in the DOCSIS software download framework. As mentioned before, this group has two rather nice, already complete specs to work from. I'd suggest in the case of an embedded routing device with a DSL CM, point to TR069 and for an embedded router with a cable modem, point into the CableLabs specs. We can do a requirements extract on both specs to come up with what might be a dramatically stripped down list. 

From: [email-masked] on behalf of Bob Carrick
Sent: Tue 6/23/2009 9:01 AM
To: [email-masked]
Subject: Re: [homegate] Management of the Home Gateway

Bob Carrick
web: http://www.finepoint.com <http://www.finepoint.com/>

---

From: "Van de Poel Dirk" <[email-masked]>
Date: Wed, 24 Jun 2009 08:44:58 +0200

Gentlemen,

What is the scope of HomeGate?

>From the discussion around this topic I get the impression the scope
would only be covering retail devices that don't embed DSL, Cable or
other access technology modems?

>From a DSL home gateway perspective we so see a significant number of
deployments where the service provider managed home gateway is combined
with external modems/NTs.  Also in this case the home gateway is key is
triple play service delivery (multicast/QoS/VoIP) and is partly managed
by the operator (network settings, QoS, VoIP...) using a remote
management protocol and partly by the end-user (NAT portmaps...) using a
device embedded GUI.

Aspects like remote firmware upgrade are today covered in BBF TR-69 and
CableLabs specs. 

Does HomeGate intend to define requirements beyond the existing
standards for operator managed gateways (with or without embedded
modem)?  Does it intend to only define firmware upgrade requirements for
retail home routers?

For other aspects such as multicast, Jumbo frames, DNSSEC would HomeGate
define requirements for service provider managed gateways or only retail
home routers?

Thanks,
Dirk

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Erichsen, Kirk
Sent: dinsdag 23 juni 2009 17:54
To: Bob Carrick; [email-masked]
Subject: Re: [homegate] Management of the Home Gateway

Cable has it's own method defined in the DOCSIS software download
framework. As mentioned before, this group has two rather nice, already
complete specs to work from. I'd suggest in the case of an embedded
routing device with a DSL CM, point to TR069 and for an embedded router
with a cable modem, point into the CableLabs specs. We can do a
requirements extract on both specs to come up with what might be a
dramatically stripped down list. 

Bob Carrick

---

From: <[email-masked]>
Date: Wed, 24 Jun 2009 10:53:07 +0200

> from personal involvement in creating firmware that is so bad that  

Speeking as a service provider I think periodic updates is a good thing. 
Most end users will not touch their network equpment unless forced to do so.
A couple of years back when migrating from adsl to adsl2+ we sendt a mail 
(the kind with a stamp on, not email) to 10.000 customers which had non 
adsl2+ equipment.  All they had to do was to respond by sms, phone, mail and
they would recive a new adsl2+ device free of charge and double speed.
17 responded. 

My suggestion is that per default the device should update itself, but with
a "opt out" choice for the paranoid, and a experimental for the curios.

NB: These are comments for the service provider devices, retail I do not have
an opinion for.

-Erik Taraldsen
Telenor

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 24 Jun 2009 11:24:16 +0200

> Speeking as a service provider I think periodic updates is a good  

I do understand that if you depend on the user to initiate any action,  
very little will happen. Still not sure why this is important enough  
to incur the risks. Are there often CPE updates that are critical?  
Doesn't seem that way to me.

> NB: These are comments for the service provider devices, retail I do  

Which brings up the question: what exactly are we trying to solve on  
this list? If it's devices delivered to users as part of the service,  
then obviously any and all issues can be negotiated between the vendor  
and the service provider so there isn't much need to discuss them in  
the IETF. (Although it would probably be helpful to come up with a  
more standardized way to interact on the LAN side.)

The case where the CPE is obtained by the user separately from the  
service is much more complex and more inline with the IETF's mission  
and I don't think it's even possible to come up with a working  
scenario for pushing out updates there.

---

From: "Richard Bennett" <[email-masked]>
Date: Wed, 24 Jun 2009 03:16:25 -0700

In my experience, code often has bugs in it, sometimes critical ones, and
they need to be patched. Perhaps a larger issue is that IETF protocols tend
to evolve, so it's good for devices to catch up with the current standards. 

This is all practical nuts and bolts stuff, not advanced networking theory
and dissertation material.

Richard Bennett

---

From: "Richard Bennett" <[email-masked]>
Date: Wed, 24 Jun 2009 03:22:35 -0700

I don't know that the scope has been defined yet, actually. We're just
having a discussion around what the major issues with home gateways and the
stability/functionality of IP networks might be. It seems that there's a
desire to specify some BCPs more than anything, not invent new protocols.

I don't see any desire to limit the scope to CPE, the retail stuff has
perhaps greater needs since it's not tended by TR69 and has interoperability
issues of its own. I think of HOMEGATE as a supplement to TR69 and DLNA, not
a replacement (except where the other guys screwed up.)

Richard Bennett

-----Original Message-----
From: Van de Poel Dirk [mailto:[email-masked]] 
Sent: Tuesday, June 23, 2009 11:45 PM
To: [email-masked]
Subject: Re: [homegate] Management of the Home Gateway

Gentlemen,

Thanks,
Dirk

-----Original Message-----

Bob Carrick

---

From: <[email-masked]>
Date: Wed, 24 Jun 2009 18:14:27 +0200

Hi,

> Doesn't seem that way to me.

For me it sounds like we have to find a trade-off between security (or other) problems caused by buggy updates and the problem caused by not updated devices... it is not easy to decide which way is right and depends perhaps on the use case. If the gateway includes the modem I would support automatic updates, but if users have to have  a separate modem, I am not sure ...

> more standardized way to interact on the LAN side.)

Service Providers are interested in open standards too since they reduce costs. So it is very interesting for a service provider to have an IETF specified home gateway.

> service is much more complex and more inline with the IETF's mission

Depends on what most users have at home... Do they buy their own gateway or do they only have the one that came with the service? I think, it is 50-50. Some users are happy the provider's box, other buy their own and place it behind the provider's box, using the ISP's box only as modem. I think, we should address both as far as possible.

Carolin

---

From: "Howard, Lee" <[email-masked]>
Date: Wed, 24 Jun 2009 14:11:13 -0400

-----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> Iljitsch van Beijnum
> Sent: Wednesday, June 24, 2009 5:24 AM

Make it a SHOULD with user-override, or maybe we can work out a
provider-override (i.e., ISP A wants auto-push and is willing to accept
responsibility for outages, ISP B doesn't; negotiated capability).  

> scenario for pushing out updates there.

Is "who owns the box?" really the question?   Seems to me we're looking 
to internetwork two kinds of networks, one of which (the residence) 
needs better standardization.   If we can provide common expectations,
regardless of the layer 2 protocols (Ethernet, DSL or cable) we can
reduce complexity.  

Lee

---

From: <[email-masked]>
Date: Thu, 25 Jun 2009 10:03:19 +0200

Hi,

I would agree on this approach. I think that we need to first look what others have done and what is missing. I am not sure if markets would agree on some certain device management scheme as there are many already existing, but I think that IETf could recommend certain approaches. Other issue would be looking what other SDOs have defined and if it is something that has been really deployed and if it overlaps homegate way and how. I have been working with DLNA and UPnP, so I know that area somewhat. DLNA as an organization is focused on creating interoperability with certification test tool than creating new protocols. DLNA has not really defined any home gateways, but its guidelines does address full protocol stack, so there are guidelines for IETF protocols too.

 UPnP forum does have its gateway committee that has defined Internet gateway speciifications and works for the next version. UPnP IGD is not a holistic definition what is a gateway and how it should work, but it provides APIs to mostly IETF or de facto standards on layer 2 and layer 3 (possibly even to application level) protocols. What definetely lacks from that specification family is how to implement IETF protocols in detail. For instance, details and options for DNS, DHCP etc are not defined. Current UPnP gateway work for now expands from NAT traversal, IPv6 firewall control to security solution, so from UPnP perspective this home gateway would touch only partially the area and vice versa. Also, how many other groups in IETF actually define stuff that is really part of this home gateway initiative.

Maybe we should take following topics into discussion and eventually to the charter:
* Model what is a home gateway, what it does, does it have variations?
* Device management aspects, and if the solution defined would have real chance to be widely deployed
* BCPs for IETF protocols in gateways
* what APIs and protocol definitions other SDOs have done, missing things, whats wrong, would these SDOs take input. I am not sure if the list broadband forum, HGI, OSGI, UPnP, cablelabs

best regards,
    Mika

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: 23. kesäkuuta 2009 18:20
To: Bob Carrick
Cc: [email-masked]; [email-masked]
Subject: Re: [homegate] Management of the Home Gateway

Personally, I would rather see this group concentrate on developing BCPs for ensuring *correct* implementation of current IETF *protocol* standards, and not working to develop new protocols, mechanisms, update systems, etc.

Ray

---

From: <[email-masked]>
Date: Thu, 25 Jun 2009 10:18:34 +0200

+1

Carolin

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Donnerstag, 25. Juni 2009 10:03
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [homegate] Management of the Home Gateway

Hi,

best regards,
    Mika

Ray

---

From: <[email-masked]>
Date: Thu, 25 Jun 2009 14:00:49 +0200

> Doesn't seem that way to me.

Approx once a year pr HW device. As mentioned elsewhere on this list there is sometimes security holes which needs to be patched.  Most often though there is compatibility, stability and evovling standards which are the reasons for upgrading. ADSL is still evolving.  A device we are upgrading this summer will have approx 20% increase in dsl sync rate, 20% longer reach and reduce resync problems to nearly zero for long reach lines.  The increased dsl performance is not a poor implementation originaly, but the adsl standard has continiualy refined over the years.  

There are also cases where major operating system vendors introduce bugs in their network stack where the CPE vendors have to introduce bug compatebility.

I also expect introduction of features like IPv6 and vdsl2 will need a lot of upgrades since we all are learning there.

-Erik Taraldsen
Telenor