Subject: [homegate] PDF of BoF Proposal

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 04 Jun 2009 16:06:48 -0400

The PDF of the BoF proposal, which is informative to anyone joining this
list, is available for your review at:
http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/HomeGate%20BoF
%20Proposal%20-%20IETF%2075%20-%20v7.pdf

Regards
Jason

---

From: Lars Eggert <[email-masked]>
Date: Thu, 11 Jun 2009 19:50:57 +0200

Hi,

the IESG and IAB have discussed this BOF proposal today, and I have  
decided to not accept this BOF for Stockholm.

That said, I believe that the IETF should spin up work in this space,  
and my impression was that much of the IESG and IAB shared that  
opinion. The decision to turn down the BOF proposal for Stockholm was  
based on other factors:

First, the proposed work needs to be focused and detailed more, it is  
currently still too broad for an IETF effort and some of it is still  
unclear. (There is no charter proposal, for example.)

Second, because other industry forums and SDOs have been producing  
specifications in this space (DLS Forum, CableLabs, UPnP Forum, Wimax  
Forum, etc.), it will be important to identify where we will overlap  
with them and where we can complement their efforts.

Third, it is currently not clear how substantial the community is that  
would participate in an IETF effort in this space. Traffic on the  
mailing list has been absent, and I have also received only very few  
direct emails about it. This effort may require more socializing.

In order to get this work to a point where we can BOF it, I'd be very  
happy to offer time in the transport area area open meeting in  
Stockholm to discuss this effort. Another alternative may be the  
Internet area open meeting, because the proposed work touches on both  
areas. Instead of these open meeting discussion (or in addition to  
them), I'm also happy to get you a room for a bar BOF, if you like.

The idea is to raise interest in this work in Stockholm and discuss  
the issues I've identified above, in order to form a community around  
this work that will carry it to a successful BOF at IETF-76 in  
Hiroshima. I'm looking forward to help the effort along as best as I  
can.

Lars

---

From: grenville armitage <[email-masked]>
Date: Fri, 12 Jun 2009 08:18:22 +1000

Lars Eggert wrote:
	[..]
> direct emails about it. This effort may require more socializing.

I wonder how many people (like me) subscribed when we first saw
the mailing list announced last week on [email-masked], and have since 
been waiting to have someone kick off discussions.

cheers,
gja

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Thu, 11 Jun 2009 22:34:33 +0100

Sorry, I was expecting a roundup before discussion began on homegate.

I do think a lot of this should be standardised behaviour, and that  
IETF is the place to standardise it.  In particular, v6 security  
policy and v4 traversal issues need standardising in a way favourable  
to IETF participants and by extension the net community (EG: v6  
defaulted, UPnP alternative).  I cannot speak for media protocols,  
that's for ITU or cable forum or whoever it is.  But I wanted to  
signify my interest in consensus-driven practices, though I can't  
attend IETF sessions yet.

Is there an alternative format for the PDF proposal?  I think I may  
not have read the entire thing (I'm using clumsy access with a screen  
reader at the moment and haven't installed pdf2txt).

Cheers,
Sabahattin

---

From: Carolin Latze <[email-masked]>
Date: Fri, 12 Jun 2009 08:58:59 +0200

> been waiting to have someone kick off discussions.
tbh I also expected somebody of the authors of the BOF proposal to kick 
off the discussion. If it up to the silent listeners to start it, I will 
do it now :-)

I think that the topic is very important and interesting, but I am not 
sure, the IETF is the right place for it. For me it sounds like the only 
thing you can standardize here is something like "A home gateway has to 
support protocol X, Y, and Z" and I don't see that there is the need to 
form a WG to do that. The protocol standards exist and most of the home 
gateways support them (or a subset of them), so why do we need another 
standard here? What did I miss here?

BTW I am sure whether I got it right, but a home gateway here is more or 
less that what xDSL modems are today? I mean, something that serves as a 
router for your local network and gateway to the internet?

Carolin

---

From: Henk Uijterwaal <[email-masked]>
Date: Fri, 12 Jun 2009 07:55:29 +0200

> been waiting to have someone kick off discussions.

I agree, the PDF looked interesting, so I put myself on the list and
waited for a kick-off.

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.xs4all.nl/~henku
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Belgium: an unsolvable problem, discussed in endless meetings, with no
          hope for a solution, where everybody still lives happily.

---

From: Murari Sridharan <[email-masked]>
Date: Fri, 12 Jun 2009 00:17:10 -0700

PDF definitely looked interesting, a bit too broad but I assumed scoping discussions would start to happen on the mailing lists. 

Murari 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henk Uijterwaal
Sent: Thursday, June 11, 2009 10:55 PM
To: grenville armitage
Cc: [email-masked]; [email-masked]; IAB IAB; [email-masked] IESG; TSV Dir; Jason Livingood
Subject: Re: [homegate] PDF of BoF Proposal

Henk

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

---

From: "Richard Bennett" <[email-masked]>
Date: Fri, 12 Jun 2009 03:45:11 -0700

Could be that the authors are busy or off the net at the moment, they'll
have to speak for that. From my own experience as an engineer who until
recently worked for a home gateway company in a product development role, I
think this is a vital piece of work and an area where IETF could make a huge
positive impact with less effort than is involved in several other areas.

Home gateways are the combinations of a NAT, an Ethernet switch, a Wi-Fi
access point, and some sort of WAN connection, which can be either a DSL
adapter, a cable modem, or a connection to an external layer two device
reached over a separate Ethernet connection or something more obscure like
MoCA. They're very low margin products, so the companies that produce them
tend to have more expertise at manufacturing than engineering, and very
little expertise specific to IETF protocols. The norm in the industry is
engineering managers who understand DSL but not DHCP and certainly not DSCP.
If you asked one to explain MPLS they would probably tell you it's the
sister city of St. Paul. 

A sub-sector of that industry builds specialized gateways for telcos that
includes a suite of management protocol called things like TR069 and TR098,
which were defined by the DSL Forum (now called the Broadband Forum) because
they didn't understand SNMP. The "TR" protocols have a very bizarre object
model that bears a minimal resemblance to any actual network devices, and
uses SOAP and XML instead of ASN.1. The one good thing about it is that it
can used to download firmware updates the ISP wants to get out.

The software in these boxes is open source combinations of Linux kernels,
busybox, and the related networking pieces, packaged with proprietary TR069
components. The principal packagers are Broadcom and Jungo.

>From the perspective of the engineering managers and customers, the software
is at best a nuisance, as they view their hardware and manufacturing
processes as the primary value of the boxes. Hardware tends to be designed
according to reference designs from the chip companies. 

Specs in this industry are laughably terse, generally consisting of Excel
spreadsheets that describe complete functional subsystems with two or three
garbled sentences. They're very heavy on buzzwords. It's a miracle that most
of these products don't explode the first time they're powered on.

The value of this BOF and eventual working group would be to define a
thorough BCP for the software components that go into home gateways. The
management protocol is pretty hopeless, but probably 75% of the code can be
drastically improved if the right people were to write a spec that described
the proper revisions, options, and features for the IETF protocols involved.
ECN was mentioned prominently in the PDF, and I can guarantee you personally
that there is no knowledge of ECN or why anybody would want it in the home
gateway industry. But if the IETF produces a BCP that says "Home gateways
should not halt and catch fire if they receive an IPv4 packet with ECN set,"
the next round of RFPs from the telcos and other ISPs to the gateway vendors
would include that requirement and the products would conform. 

I don't think it's realistic to try and slough this work off on UPnP or
DLNA, as those organizations are very application-oriented and don't have
great awareness of IETF protocols either. I personally sat through a whole
series of teleconference in which DLNA leaders proposed to limit MTU sizes
to 1000 octets because they didn't know how to do Path MTU discovery, such a
new thing it's only been specified since RFC 1191. According to DLNA, the de
facto standard protocol for streaming Internet video is HTTP, not RTP/RTSP.

The DNSSEC people have tested home gateways for compliance and found none of
them can handle UDP-framed request packets larger than 512 bytes. The home
gateway response is "what's DNSSEC?" 

I went to work in that particular segment because it seemed to me that it's
dragging down the whole Internet because it installs obsolete protocols in
hundreds of millions of homes and small offices around the world. I quickly
found that one person was not going to make much of a difference, and now
feel that it's an urgent priority for IETF to show some leadership in this
area. And believe me, if you don't, nobody else will and we'll all just keep
on complaining about the fact at ECN languishes even though it's been a
draft standard since 2001 (RFC 3168), and similar fate will befall DNSSEC. 

This is important work and it deserves some serious attention.

Richard Bennett 

-----Original Message-----
From: Murari Sridharan [mailto:[email-masked]] 
Sent: Friday, June 12, 2009 12:17 AM
To: Henk Uijterwaal; grenville armitage
Cc: [email-masked]; [email-masked]; IAB IAB; [email-masked] IESG; TSV Dir;
Jason Livingood

PDF definitely looked interesting, a bit too broad but I assumed scoping
discussions would start to happen on the mailing lists. 

Murari 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henk Uijterwaal
Sent: Thursday, June 11, 2009 10:55 PM
To: grenville armitage
Cc: [email-masked]; [email-masked]; IAB IAB; [email-masked] IESG; TSV Dir;
Jason Livingood
Subject: Re: [homegate] PDF of BoF Proposal

Henk

-- 
----------------------------------------------------------------------------
----------------------------------------------------------------------------
--

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 12 Jun 2009 02:17:45 -0700

Lack of a "kick-off" indicates that the people whose career is focused on home gateways were
not sufficiently motivated to participate to bring the effort to critical mass. 

Ideally an outreach effort would include not only the organizations that focus on 
standardization of aspects of home gateways, but also the implementers of home
gateway products.  

Given the razor thin margins of the home gateway industry, structuring the effort
to cater to remote participants (e.g. virtual interim meetings) wouldn't hurt
either.

---

From: Lars Eggert <[email-masked]>
Date: Fri, 12 Jun 2009 18:45:16 +0200

Hi,

> been waiting to have someone kick off discussions.

that discussion seems to have started now, which I'm very happy about.  
Andrew made a good proposal in his email: let's use the time before  
Stockholm to start working out what should be done, have an informal  
meeting in Stockholm with whoever is there to discuss things in  
person, and aim for a BOF in Hiroshima.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 12 Jun 2009 18:49:59 +0200

Hi,

> standard here? What did I miss here?

the protocol specifications are there, but some if not many home  
routers don't implement what some of us would consider the minimal  
subset of modern Internet functionality, and sometimes what they try  
and implement is buggy (braindead queueing, no ECN, no DNS over TCP or  
EDNS0, DHCP oddities, etc., etc.)

The idea isn't for this effort to do major (or maybe even any)  
protocol work; the idea is to document what the IETF believes a home  
gateway should implement at the minimum, and maybe at the optimum. A  
set of BCPs seems to be the correct vessel for this.

> router for your local network and gateway to the internet?

Correct.

Thanks,
Lars

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Fri, 12 Jun 2009 12:49:18 -0400

I too daftly assumed something would be transmitted to the list after I joined to kick things off, but that was a passive view point. I concur with Andrew on initiating an effort and work towards the next meeting to perhaps finalize some of the details of the document itself and perhaps even the charter.
 
-KE

________________________________

From: [email-masked] on behalf of Lars Eggert
Sent: Fri 6/12/2009 10:45 AM
To: grenville armitage
Cc: [email-masked]; [email-masked]; IAB IAB; [email-masked] IESG; TSV Dir; Jason Livingood
Subject: Re: [homegate] PDF of BoF Proposal

Hi,

Lars 

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: "Erichsen, Kirk" <[email-masked]>
Date: Fri, 12 Jun 2009 13:30:48 -0400

Lars,
 
I agree with your proposed scope below to which I propose some additional work items. I would agree that we can reference any required protocols within their respective standards body while focusing on the necessary features and the feature behaviors we expect for the home gateway. I think we will find we have broad consensus on what we are really looking for, that there is a need for a more definitive compendium of features within the gateway routing device. We need not, in my opinion, initiate drafting of new protocols to accomplish this goal.  
 
I would like to establish some of our essential assumptions regarding the environment we are tailoring this effort to. I believe we are already equipped to establish the assumptions based on observed trends in existing home/small business customer networks. 
 
1) For the most part and with few exceptions, we expect a v6 router in every home we provide IPv6 enabled services to. The exceptions for a non-embedded device (a router which embeds no modem) would likely be during initial installation and when diagnostics of the underlying bandwidth services are called for. The expectation assumes we provide only a single IPv6 prefix to the customer, even if legacy devices/computer systems supporting only IPv4 continue to reside behind the IPv6 gateway. 
 
2) That the gateway we define is the core of the customer's network and is the only router likely to be present. We can contemplate additional links with additional routers after we've hashed out details for the simpler use cases. In assuming that the customer network is flat and uncomplicated, we can reduce the scope of use cases (at least at first) to the basic networks we currently see in home networks today. It can be anticipated that the number of routers within the home will increase over time, but that we have some debate to get through on how to structure that expectation.  
 
3) That the router would require, as a minimum, a stateless DHCP server and DNS proxy and at least one LAN interface and one WAN. Depending on the model of service delivery, a stateful DHCP server and the associated code-bloat may be necessary (particularly if we stray from the simpler case of a single router, with the device we are defining being that core of the customer network). 
 
4) That while likely to be present, the full details of the packet filtering firewall should be left, wherever possible, to vendor interpretation to work out with the service providers/MSO. If there is a role for discussing the packet filtering, it will probably relate to a NAT for translating (as mentioned above in my first assumption) IPv4 legacy clients behind the IPv6 router. I would suggest we limit the scope of any NAT/packet filtering discussion to the traversal aspects where translation is called for. It may be a bridge to far at this point to assume broad agreement with local protocol family translation at the customer gateway. I add it here to stimulate that conversation.
 
5) QoS is a slippery slope and may be something we can limit description of as it is almost always application specific and relates to which services a service provider/MSO may plan to offer over the gateway. I'd like to approach the issue similar to what I suggest for packet filtering/firewall. 
 
6) Our high level (non packet filtering/firewall related) security considerations, in my opinion, should flow from the simpler use cases I propose above and be added upon as we branch out as far as we feel comfortable with regarding home network complexity. I'll state my security assumptions as being relatively minimal, at least for what I presume to be the bulk of current and future deployments as a non-managed services (basic bandwidth services, vs. a "managed service"). In my view, the primary objective in our security considerations should be in protecting assets of the service provider from untrusted elements within the customer network, or even from the customer themselves (whether unknowingly as by configuration error, code defects in software or via genuinely nefarious intentions). It's my opinion, considerations which seek primarily to protect the customer from other customers or unknown external parties are outside the scope of this effort.   
 
Let the debate begin!
 
Warm regards,
 
-KE

From: [email-masked] on behalf of Lars Eggert
Sent: Fri 6/12/2009 10:49 AM
To: Carolin Latze
Cc: Jason Livingood; [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

Hi,

Correct.

Thanks,
Lars

---

From: Damian Gerow <[email-masked]>
Date: Fri, 12 Jun 2009 13:32:20 -0400

Thus spake Lars Eggert <[email-masked]> [Fri, 12 Jun 2009 18:49:59 +0200]:
: The idea isn't for this effort to do major (or maybe even any)  
: protocol work; the idea is to document what the IETF believes a home  
: gateway should implement at the minimum, and maybe at the optimum. A  
: set of BCPs seems to be the correct vessel for this.

As the target consumers of this effort would be the end user, I think a set of
BCPs falls just short of the mark.  There needs to be some way for John Q.
Public to pick up a box, look at a logo or phrase, and understand exactly
what that product gives him.  i.e. 'Gateway Certified' would meet all stated
requirements for acting as your standard home gateway.  'Media Certified' means
it would also provide media functionality (DAAP, UPnP/DLNA).  'Print Certified'
would mean it provides a standard printer interface (can load arbitrary
printers, provides an IPP/whatever interface).  'Wireless Certified' would
mean it provided a WiFi-compliant network.

A small handful of 'certifications', as well as, say, a rating of 1-3 for each
of those certifications, would provide something clear and concise for the
consumer.  So, 'WiFi Level 1' would mean it provides basic Wireless access.
Level 3 would be WPA2, WMM, and XYZ support.  And so on.  Obviously, this would
quickly become overwhelming, so the number of 'certifications' would have to
be kept to a minimum.

However, this may be overstepping the boundaries of the IETF; I don't know.

---

From: [email-masked]
Date: Fri, 12 Jun 2009 13:37:34 -0400

> 3) That the router would require, as a minimum, a stateless DHCP 
> server and DNS proxy and at least one LAN interface and one WAN. 
> Depending on the model of service delivery, a stateful DHCP server 
> and the associated code-bloat may be necessary (particularly if we 
> stray from the simpler case of a single router, with the device we 
> are defining being that core of the customer network). 

If at all possible the router SHOULD NOT act as the default DNS proxy.

See draft-ietf-dnsext-dnsproxy for why.

Ray

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

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Fri, 12 Jun 2009 13:35:28 -0400

Damian,
 
The issue of some sort of label to provide guidance to a retail consumer is particularly salient. How we accomplish that task should be discussed further. Within cable we have the DOCSIS certified logo to guide customer's in obtaining products known to interoperate and comply with the feature requirements of a particular interface specification. It may be outside of the IETF to provide such branding/logo programs, but we may be able to provide guidance to vendors as to what easily conveyed term/terms might accomplish much the same effect. 
 
"Complies with xxxxxxx" on the product packaging may not be quite what we had in mind, but may be sufficient for our purposes. I'll throw some ideas out as they come. 
 
-KE 

From: [email-masked] on behalf of Damian Gerow
Sent: Fri 6/12/2009 11:32 AM
To: Lars Eggert
Cc: [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

---

From: james woodyatt <[email-masked]>
Date: Fri, 12 Jun 2009 10:47:36 -0700

On Jun 12, 2009, at 03:45, Richard Bennett wrote:
>
> I don't think it's realistic to try and slough this work off on  
> [organizations that are not] very application-oriented and don't  
> have great awareness of IETF protocols either.

Concur with all of the excerpted message, and especially this part I  
just quoted.

I'd much prefer that IETF be where the IPv4 and IPv6 functional  
requirements of residential Internet gateways are nailed down.  If we  
allow others to set these standards, then the whole Internet community  
will be forced to endure behaviors at residential gateways that may  
not fit well with the Internet architecture and could potentially  
cause widespread damage to the total utility of the Internet.

Politeness requires that I refrain from citing historical precedents  
for this that spring to mind when I think about how similar past  
missteps by IETF have greatly damaged the Internet.  I expect everyone  
on this distribution has already heard my intemperate rants on that  
subject.

Summary: I strongly advocate getting all our gear in one sack and  
setting a proper agenda for this work.  I'm prepared to take an active  
role in a working group, should one be formed.

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

---

From: james woodyatt <[email-masked]>
Date: Fri, 12 Jun 2009 11:10:32 -0700

> See draft-ietf-dnsext-dnsproxy for why.

That draft does not appear to explain why residential gateways SHOULD  
NOT be composed with a DNS proxy.  Indeed it makes no such  
recommendation, and its title suggests that it should be interpreted  
as guidelines for implementing a DNS proxy integrated with residential  
gateways.

If necessary, I'll be happy to explain why all Apple residential  
gateway appliances since January 2003 have had an integrated  
forwarding/resolving/caching DNS server, i.e. not merely a translating  
proxy.  We didn't bite off the extra work of doing it that way for  
light and transient reasons, not the least of which is the need to  
prepare IPv6 transition with Internet service providers where DNS  
service is provided over only one of the two protocol versions, IPv4  
or IPv6.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 12 Jun 2009 14:14:21 -0400

I agree with Ray.  Those DNS proxies exist only as an inadequate  
alternative to properly providing devices in the home with pointers to  
real recursive resolvers.

- Ralph

---

From: [email-masked]
Date: Fri, 12 Jun 2009 14:17:39 -0400

> as guidelines for implementing a DNS proxy integrated with residential 

You're correct, it is more accurately a set of guidelines on how to 
_correctly_ implement a proxy, albeit also containing recommendations on 
how the proxy should step out of the way whenever possible.

> service is provided over only one of the two protocol versions, IPv4 

Indeed, on doing the testing for ICANN SSAC report SAC035 we tested an 
Apple unit, and it faired relatively well.  I'd be happy to have a further 
offlist discussion about those parts where it didn't work quite so well.

kind regards,

Ray

---

From: Carolin Latze <[email-masked]>
Date: Fri, 12 Jun 2009 21:03:14 +0200

> set of BCPs seems to be the correct vessel for this.
Sounds good, I'm in and would also help to write those documents.

Carolin

---

From: Carolin Latze <[email-masked]>
Date: Fri, 12 Jun 2009 21:09:10 +0200

> 6) Our high level (non packet filtering/firewall related) security considerations, in my opinion, should flow from the simpler use cases I propose above and be added upon as we branch out as far as…
I would like to add the management of the home gateway as one of the 
items we should work on. Is it a device that is managed locally by the 
user (which mean he can manage it offline too), or does the 
configuration reside on a central server in the Internet (which means, 
the user cannot configure it anymore when he is offline). I don't know 
how it is handled in all your routers, but parts of my router config are 
actually on a server somewhere in the Internet.

Carolin

---

From: james woodyatt <[email-masked]>
Date: Fri, 12 Jun 2009 12:17:09 -0700

> offlist discussion about those parts where it didn't work quite so  

I've read the report, and we've had the discussion.  I suspect my  
disagreements about what works better than what else will eventually  
be part of the group discussion.

p1.  I've yet to be sold on the proposition that DNSSEC is headed for  
widespread application deployment.  For the sake of discussion here,  
I'm willing to assume it is, but I'm hesitating because Apple hasn't  
committed to DNSSEC yet and I'm not sure when, how or if it ever will.

p2.  There are DHCP-related issues that make attempting transparency  
of the local DNS proxy a very bad idea.  Ralph Droms and I still have  
a long-standing disagreement over where the root cause of that problem  
lies, but I contend the problem is with the DHCP protocol.  Once a  
client gets a lease, there isn't a reasonable way for a server to  
update it with new information immediately, i.e. when the DNS server  
addresses change.

p3.  Finally, in any residential gateway with a "connect-on-demand"  
feature, e.g. for providers who bill by the minute for connect time,  
which is not uncommon in some parts of the world, then the problem  
with DHCP described above becomes intolerable.  The demand trigger  
MUST be the initial DNS query, and the service-provider DNS servers  
haven't been configured yet when the user initiates the demand for an  
Internet connection, so the query MUST be handled by an integrated  
forwarding server that's aware of the connection demand protocol.

If and when I'm convinced that widespread application of DNSSEC is  
inevitable, then I will argue that residential gateways should be  
composed with a non-transparent and security-aware forwarding server.   
This will be the case unless and until RFC 5006 is used for  
configuring hosts with DNS server addresses.  I don't expect that to  
*EVER* happen, so I see no alternative to using an integrated, non- 
transparent DNS server.

I suppose it might be possible to enhance the DHCP protocol to address  
the deficiencies to which I'm referring, but I've been warned  
repeatedly that such heresy is highly unlikely to be received warmly  
by the DHCP working group.  So, I haven't tried even to initiate an  
exploration of the topic.  Perhaps, if a HOMEGATE working group were  
to converge on my view of how the DNS configuration problem should be  
solved, then the DHCP working group might see fit to reconsider some  
of its ancient history, which has led to the current less than  
spectacular results.

---

From: grenville armitage <[email-masked]>
Date: Sat, 13 Jun 2009 09:44:41 +1000

Damian Gerow wrote:
> BCPs falls just short of the mark.

That's a key point to clarify early on - I forsee the target consumers as
being the box builders (rather than the end users who'll be purchasing the boxes
off the shelf of their local WalMart). Getting BCPs on how to build homegateways
seems like a concrete and reasonable target, without worry too much about
certification labels for now.

cheers,
gja

---

From: Lars Eggert <[email-masked]>
Date: Sat, 13 Jun 2009 08:40:42 +0200

Hi,

> Thus spake Lars Eggert <[email-masked]> [Fri, 12 Jun 2009  

it's not clear that the consumer of this effort would be the end user  
- few IETF specifications are. In my mind, this was mostly about  
giving guidelines to vendors and operators.

We should definitely discuss if this effort could result in a document  
or two that were targeted at end users, but the bulk of the work  
probably wouldn't.

>  There needs to be some way for John Q.

The IETF isn't doing standards certification, and there are good  
reasons for that. But nothing stops an outside entity to run a  
conformance test program based on IETF specs, and I agree that for the  
end users, some sort of easily identified distinguisher on the box  
would be helpful.

Thanks,
Lars

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 15 Jun 2009 10:40:43 +0200

> it's not clear that the consumer of this effort would be the end  
> user - few IETF specifications are. In my mind, this was mostly  
> about giving guidelines to vendors and operators.

Operators are important here, especially in the v6 space where there  
is no established practice for connecting a home gateway to the ISP  
network. This has been under discussion in v6ops, how do the efforts  
here relate to that?

Iljitsch

---

From: Lars Eggert <[email-masked]>
Date: Mon, 15 Jun 2009 12:39:41 +0300

> network. This has been under discussion in v6ops, how do the efforts

This would not only be about IPv6. As far as IPv6 is concerned, the  
current V6OPS docs would likely be referred to by what this effort  
would produce.

We could even think about moving the IPv6-home-gateway-related work  
form V6OPS to here, but I don't see that as very critical.

Lars

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 15 Jun 2009 09:30:49 -0400

On Sat, Jun 13, 2009 at 08:40:42AM +0200, Lars Eggert wrote:

> it's not clear that the consumer of this effort would be the end user - 
> few IETF specifications are. In my mind, this was mostly about giving 
> guidelines to vendors and operators.

> The IETF isn't doing standards certification, and there are good reasons 
> for that. But nothing stops an outside entity to run a conformance test 
> program based on IETF specs, and I agree that for the end users, some 
> sort of easily identified distinguisher on the box would be helpful.

In my view, the above should be a key factor in our thinking.  IETF
standards get "enforced" by contracts.  Large numbers of these gateway
devices are sold or otherwise provided to end users by ISPs.  So if
ISPs have something to which they can require vendors to conform as
part of the ISPs' purchase of the devices or recommendation of them to
end customers, that will probably be enough market pressure to achieve
the desired result.

A

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

---

From: "Heather Kirksey" <[email-masked]>
Date: Mon, 15 Jun 2009 15:57:49 -0500

Andrew,

If you're considering ISPs using this work to enforce requirements on their vendors, it might be worth checking out some work that's already gone on in this area:

Broadband Forum TR-124 defines a set of modular functional requirements for broadband residential gateways: http://www.broadband-forum.org/technical/download/TR-124.pdf.

The Home Gateway Initiative also has a Home Gateway Requirements: Residential Profile document: http://www.homegatewayinitiative.org/publis/HGI_V1.01_Residential.pdf.

In addition, Broadband Forum has a work-in-progress document called PD-192 that deals with the functional IPv6 requirements for gateways in the home based on current operator plans for migration and deployment.  BBF was already planning to liaise the PD-192 document in the relatively near future to get feedback on it.

Thanks,
Heather

Heather Kirksey
Motive Product Division
Alcatel-Lucent
[email-masked]
+1.512.531.1126 (office)
+1.512.917.7938 (mobile)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
Sent: Monday, June 15, 2009 8:31 AM
To: [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

> The IETF isn't doing standards certification, and there are good reasons [[HRK]] 

A

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 15 Jun 2009 17:21:54 -0400

> standard here? What did I miss here?

Actually, what we're finding is that most of the existing (and currently for
sale) home gateways do not provide sufficient support, or support these
things in ways not intended by the relevant standards authors.

> router for your local network and gateway to the internet?

A home gateway is different from a DSL modem, cable modem, etc.  It is the
general class of device that connects to that access device. These are often
branded as "home routers" though they are not purely routers. They variously
provide NAT/PAT, firewall services, DHCP servers for the LAN, etc.

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 15 Jun 2009 17:23:19 -0400

It is probably my job to kick some of this off, and I have just been a bit
too busy.  ;-)

I'll soon start to circulate revisions for comment and I think we'd benefit
from some discussion at the next IETF meeting to better hone the scope of
potential work.

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 15 Jun 2009 17:26:00 -0400

Good advice, Bernard.  We¹ll have to figure out an easy way to enable remote
participation.  The Hiroshima meeting may be pretty local for some of the
major players to do participate economically.

Jason

either.

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 15 Jun 2009 17:31:17 -0400

Great feedback, Richard.  This is certainly consistent with what we've been
hearing from a number of concerned parties, and is much of the background
motivation for this work.

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 15 Jun 2009 17:35:00 -0400

> I would like to suggest that we on the homegate list should take the
> time between now and Stockholm to start working out what we want to
> do, and perhaps even put a proposed charter -- or -00 draft or two --

I think that's exactly what we'd like to do now and will be a good use of
time for the homegate list.

> I hereby volunteer to help with such work, particularly with respect
> to DNS, DNSSEC and its interactions with home gateways.

Cool!  Consider yourself volunteered!  :-)

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 15 Jun 2009 17:38:45 -0400

I'm not sure that end users are the target audience.  Instead, IMHO, I think
it is equipment vendors and large buyers (ISPs, mega retailers, etc.).

Jason

On 6/12/09 1:32 PM, "Damian Gerow" <[email-masked]> wrote:

> requirements for acting as your standard home gateway.  'Media Certified'

---

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

On 15 jun 2009, at 23:38, Livingood, Jason wrote:

> I'm not sure that end users are the target audience.

They're maybe not the audience for the documents that will be the  
output of an IETF effort, but they're absolutely the target audience  
for the products that will be built based on these documents. (Not to  
mention, they pay for everything!) As such, the user's needs must be  
front and center.

For instance, I think that someone mentioned something along the lines  
of "let's keep things simple and assume only a single subnet" (my  
interpretation). This won't do. Today, only advanced or dumb users  
have multiple subnets, but in the future with more and more heavy  
security requirements for working from home and appliances that  
connect to the home network, more and more regular users will want/ 
need multiple subnets. With IPv6 we have to specifically support this,  
we can't just let them double NAT like what happens often today if  
there's more than one IPv4 home gateway.

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Mon, 15 Jun 2009 21:43:57 -0400

Heather,

These were all good starting points, but probably not quite right for the intended role (inclusive of MSOs/Service Providers leveraging the spec to instruct vendors what to build/expected behaviors). We can probably explore extracting requirements, definitions from these and other documents in order to produce a more architecture-independent, generic router spec with additional use cases not likely to have been considered at the time these documents were crafted.
 
-KE

From: [email-masked] on behalf of Heather Kirksey
Sent: Mon 6/15/2009 2:57 PM
To: [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

Andrew,

Thanks,
Heather

Heather Kirksey
Motive Product Division
Alcatel-Lucent
[email-masked]
+1.512.531.1126 (office)
+1.512.917.7938 (mobile)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
Sent: Monday, June 15, 2009 8:31 AM
To: [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

A

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Mon, 15 Jun 2009 21:49:39 -0400

I concur and second the push for a WG to accomplish our collective ends.
 
-KE

From: [email-masked] on behalf of Livingood, Jason
Sent: Mon 6/15/2009 3:21 PM
To: Carolin Latze
Cc: [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

Jason

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Mon, 15 Jun 2009 21:57:19 -0400

I concur (again). From an MSO/Service Provider standpoint, it's all about detailed instruction for the gateway router vendors to ensure we have a consistent feature set and functionality from vendor to vendor and product to product, at least within the constraints of the core functionality. We can be mindful that we will invariable leave holes that allow for vendors to innovate on some of the less critical details to provide product differentiation.
 
-KE

From: [email-masked] on behalf of Livingood, Jason
Sent: Mon 6/15/2009 3:38 PM
To: Damian Gerow; Lars Eggert
Cc: [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

Jason

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Mon, 15 Jun 2009 22:13:34 -0400

Iljitsch,
 
I'll clarify the point in my previous post. What I was suggesting was that we start our efforts around a more basic set of use case assumptions (i.e. single subnet, device is core of the network, etc.), fully flesh out the simpler use case scenarios and move on to the more conjecture/debate-prone use cases from there. I did not intend to suggest we would not make the effort to capture the more complex networks that will invariably exist (and over time, the simpler networks will become more complicated as a function of increased numbers of embedded devices, and the implementation of those devices, etc.). 
 
What I am proposing is a crawl, walk, run progression from least complex to most complex, with the decision on how far we go determined by this group. We will need to discuss the likely complexity to be found in the foreseeable future within the home network and choose our wording accordingly to accommodate. I was thinking specifically of some of the small businesses/home worker and of the sales office/branch/division/head quarters model, where hub and spoke and partial or fully meshed networks may exist. I've also contemplated some of the implications for the majority of the embedded devices in the home network each being both router and host (based on certain CE trends). Since the permutations are dramatically more complicated than the simple case I proposed in my previous post (and some of this is crystal ball type futurism), I re-iterate we can probably move faster with a first-draft strawman document to take to Hiroshima if we confine ourselves, at first, to a simpler set of use cases and give ourselves some time to contemplate the more complicated use case scenarios. When the time comes, I can offer several of the more complex use cases for open debate within this group.
 
-KE

From: [email-masked] on behalf of Iljitsch van Beijnum
Sent: Mon 6/15/2009 3:44 PM
To: Livingood, Jason
Cc: [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

---

From: "Richard Bennett" <[email-masked]>
Date: Mon, 15 Jun 2009 22:04:38 -0700

These two documents are very informative regarding the state of the art
regarding Internet protocol knowledge among gateway vendors, and I recommend
reading them. What you'll likely find most interesting is not what they say
as what they don't; there are enormous holes in both of them. Search for
"ECN" and you'll get no hits, for example. 

>From my experience, Broadband Forum has an international membership with a
North American bias, while HGI has a more European membership, FWIW. 

Richard Bennett
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Heather Kirksey
Sent: Monday, June 15, 2009 1:58 PM
To: [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

Andrew,

If you're considering ISPs using this work to enforce requirements on their
vendors, it might be worth checking out some work that's already gone on in
this area:

Broadband Forum TR-124 defines a set of modular functional requirements for
broadband residential gateways:
http://www.broadband-forum.org/technical/download/TR-124.pdf.

The Home Gateway Initiative also has a Home Gateway Requirements:
Residential Profile document:
http://www.homegatewayinitiative.org/publis/HGI_V1.01_Residential.pdf.

In addition, Broadband Forum has a work-in-progress document called PD-192
that deals with the functional IPv6 requirements for gateways in the home
based on current operator plans for migration and deployment.  BBF was
already planning to liaise the PD-192 document in the relatively near future
to get feedback on it.

Thanks,
Heather

Heather Kirksey
Motive Product Division
Alcatel-Lucent
[email-masked]
+1.512.531.1126 (office)
+1.512.917.7938 (mobile)

-----Original Message-----
Of Andrew Sullivan

> The IETF isn't doing standards certification, and there are good reasons
[[HRK]] 

A

---

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

On 16 jun 2009, at 4:13, Erichsen, Kirk wrote:

> What I was suggesting was that we start our efforts around a more  
> basic set of use case assumptions (i.e. single subnet, device is  
> core of the network, etc.), fully flesh out the simpler use case  
> scenarios and move on to the more conjecture/debate-prone use cases  
> from there.

I don't really see any value in that. There are two approaches: do it  
fast, or get it right. As we are more than a decade into the broadband  
revolution the ship has sailed on the former, so we have to go for the  
latter. This means addressing everything to the degree it needs to be  
addressed, not iterate over stuff that has been out in the market for  
years.

I haven't read the PDF that is still mentioned in the subject,  
apparently I joined the list after it was posted so I'm not sure  
what's in there that is considered important or time sensitive. But  
I've been following the IPv6 CPE efforts in v6ops and think that is  
very important work. Unfortunately, it's a bit too complex to hammer  
out quickly.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 16 Jun 2009 12:30:46 +0300

> I haven't read the PDF that is still mentioned in the subject,

I'm sure you know that this list has an archive at http://www.ietf.org/mail-archive/web/homegate/current/maillist.html 
, but I'll save you some searching: http://www.ietf.org/mail-archive/web/homegate/current/msg00001.html

Lars

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Jun 2009 12:36:41 -0400

> draft standard since 2001 (RFC 3168), and similar fate will befall DNSSEC. 

I agree that this is an area where the IETF could do some useful work.

One of the things that has historically been a complaint about the DNS
specifications (and I bet about other protocols, but I know the DNS
case best) is that there's a giant pile of RFCs; and if you want to
know what you need to implement you have to read them all, figure out
what updates what, and then work out precisely what applies to your
case.  This is by no means an impossible task for someone who
understands how the RFC series works and who knows about DNS, but I
think it is unrealistic of us to assume that home-gateway builders are
going to undertake that kind of work.  I bet the state of affairs is
similar for other protocols, particularly older ones.

So just putting together a "Home Gateway Builder's Guide to the
Perplexed" would be a useful piece of work.  That said, I have some
sympathy with the decision not to hold the BOF in Stockholm, since
there isn't a lot around which to structure a BOF yet.

I would like to suggest that we on the homegate list should take the
time between now and Stockholm to start working out what we want to
do, and perhaps even put a proposed charter -- or -00 draft or two --
together so that we have something to nudge people towards reading in
Stockholm.  Such work might turn out naturally to fit under one or two
existing WGs, or else we might find that we actually need a WG for the
work; in the latter case, at the next IETF meeting we'll have the
opportunity to ask for a BOF again, with a proposed charter in hand.

A

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

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Mon, 15 Jun 2009 21:52:56 -0400

Richard points out another very salient point: A detailed specification that covers the relevant options and may be a subset (or superset) of the requirements (where some functions may be mandatory vs. optional) from the x-referenced protocol specifications and detailed examples of the expected behaviors to favor consistent implementations that bear more commonality on core functionality from vendor to vendor than not. I was eating lunch when I read Richard's exasperation with manufacturing focus vs. engineering focus at the gateway vendors and nearly choked with laughter! Particularly the line about the "miracle" of gateway products so built did not just spontaneously explode on first power up! Too true!
 
-KE

From: [email-masked] on behalf of Livingood, Jason
Sent: Mon 6/15/2009 3:31 PM
To: Richard Bennett; 'Murari Sridharan'; Henk Uijterwaal; 'grenville armitage'
Cc: 'TSV Dir'; [email-masked]; 'IAB IAB'; [email-masked]; [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

Jason

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 16 Jun 2009 06:01:52 -0400

> it is equipment vendors and large buyers (ISPs, mega retailers, etc.).

+1. The end users, by and large, do not and will not know that the  
IETF exists.

Regards
Marshall

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Tue, 16 Jun 2009 09:29:38 -0400

CableLabs also has the eRouter specification, which was published at:

http://www.cablelabs.com/specifications/CM-SP-eRouter-I03-070518.pdf

All of these specifications make a large number of very specific mandatory requirements (lots of MUSTs) and were developed very quickly by a small number of people without any external review for a very limited and specific set of deployment patterns.  They are built with compliance in mind, and have organizations that have a history of testing products "to the spec".  They tend to have very little, if any, written justification for the requirements and don't have enough tutorial background material for developers to be able to make wise implementation choices or for those new to the area to understand where the protocols come from.  They have noticable, glaring holes and flaws that are no doubt a result of the time pressure and limited review.

What the IETF can do in this space is specifically not go the same route as these specifications and compete with them.  We can provide the missing background material in a simple, easy-to-understand, tutorial way.  We can fill in the holes and correct the flaws.  We can avoid being tied to any particular deployment pattern so as to remain relevant to all of them.  We can use the time we have and the broad review capabilities of the IETF to "get it right".  We can use MUST only when we have a good explanation for why it has to be there - and provide the explanation in the document(s).

- Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Bennett
Sent: Tuesday, June 16, 2009 1:05 AM
To: 'Heather Kirksey'; [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

These two documents are very informative regarding the state of the art regarding Internet protocol knowledge among gateway vendors, and I recommend reading them. What you'll likely find most interesting is not what they say as what they don't; there are enormous holes in both of them. Search for "ECN" and you'll get no hits, for example. 

>From my experience, Broadband Forum has an international membership with a North American bias, while HGI has a more European membership, FWIW. 

Richard Bennett
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Heather Kirksey
Sent: Monday, June 15, 2009 1:58 PM
To: [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

Andrew,

Broadband Forum TR-124 defines a set of modular functional requirements for broadband residential gateways:
http://www.broadband-forum.org/technical/download/TR-124.pdf.

Thanks,
Heather

Heather Kirksey
Motive Product Division
Alcatel-Lucent
[email-masked]
+1.512.531.1126 (office)
+1.512.917.7938 (mobile)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
Sent: Monday, June 15, 2009 8:31 AM
To: [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

> reasons
[[HRK]] 
> for that. But nothing stops an outside entity to run a conformance 
> test program based on IETF specs, and I agree that for the end users, 
> some sort of easily identified distinguisher on the box would be helpful.

In my view, the above should be a key factor in our thinking.  IETF standards get "enforced" by contracts.  Large numbers of these gateway devices are sold or otherwise provided to end users by ISPs.  So if ISPs have something to which they can require vendors to conform as part of the ISPs' purchase of the devices or recommendation of them to end customers, that will probably be enough market pressure to achieve the desired result.

A

---

From: "Erichsen, Kirk" <[email-masked]>
Date: Tue, 16 Jun 2009 10:29:11 -0400

All true with regards to eRouter. It's for that reason I'd prefer to use a requirements extraction on this and other specifications we might review (plus additional reqs as deemed necessary via use case scenario review). I'd prefer to start by defining some of the use cases and map these into the various gateway specifications already in existence. We could also take from the use case scenarios some of the text we develop in order to provide the crucial but often missing examples so often lacking from the current crop of specs. 
 
-KE

From: [email-masked] on behalf of Wes Beebee (wbeebee)
Sent: Tue 6/16/2009 7:29 AM
To: Richard Bennett; Heather Kirksey; [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

- Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Bennett
Sent: Tuesday, June 16, 2009 1:05 AM
To: 'Heather Kirksey'; [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

Richard Bennett
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Heather Kirksey
Sent: Monday, June 15, 2009 1:58 PM
To: [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

Andrew,

Thanks,
Heather

Heather Kirksey
Motive Product Division
Alcatel-Lucent
[email-masked]
+1.512.531.1126 (office)
+1.512.917.7938 (mobile)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
Sent: Monday, June 15, 2009 8:31 AM
To: [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

[[HRK]]

A

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 16 Jun 2009 09:00:13 -0600

Wes wrote:

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Wes Beebee (wbeebee)
> Sent: Tuesday, June 16, 2009 7:30 AM
As a side note, this is a 4-year old document that emerged from an
initiative that started in 2005, the doc was last updated in May 2007.

> All of these specifications make a large number of very specific
> mandatory requirements (lots of MUSTs) and were developed very
> quickly by a small number of people without any external review for

The people who helped write the documents & requirements are
acknowledged inside.

> a very limited and specific set of deployment patterns.  They are
> built with compliance in mind, and have organizations that have a
> history of testing products "to the spec".  They tend to have very
> little, if any, written justification for the requirements and
> don't have enough tutorial background material for developers to be
> able to make wise implementation choices or for those new to the
> area to understand where the protocols come from.  They have
> noticable, glaring holes and flaws that are no doubt a result of
> the time pressure and limited review.
Sure, getting something out to test it and realize what does not work is
always a plus.  Correcting flaws is good when you have products to test
with.

> 
> What the IETF can do in this space is specifically not go the same
> route as these specifications and compete with them.  
There is no competition really.  The IETF is an SDO and it is where the
expertise is, driven by end-user needs and e2e models (not solely driven
by a service provider model, even if it counts for some). There are
other organizations that need to be consulted like BBWF, UPnP Forum,
HGI, CableLabs, etc.
But what we all collectively need is to collaborate to come up with
requirements that home gateway vendors can implement for multiple
markets.  The IETF is a natural place to do some of what needed there.

> We can
> provide the missing background material in a simple, easy-to-
> understand, tutorial way.  
To me, we've past the stage of tutorials.  We need specifications that
vendors can build to and the smaller set of requirements the better.

> We can fill in the holes and correct the
> flaws.  We can avoid being tied to any particular deployment
> pattern so as to remain relevant to all of them.  We can use the
> time we have and the broad review capabilities of the IETF to "get
> it right".  We can use MUST only when we have a good explanation
> for why it has to be there - and provide the explanation in the
> document(s).
That would be ok.  Vendors can decide to implement SHOULDs and MAYs on
their own; some organizations will make those tighter by transforming
SHOULD into MUST to build compliance to specific scenarios.  But if we
all have a common base from IETF, it sure helps get there faster and
with scale, and with support for various user and service provider
deployment models.

> - Wes

Jean-Francois
[email-masked]

---

From: "Jeff Goodwin (jegoodwi)" <[email-masked]>
Date: Tue, 16 Jun 2009 06:05:49 -0700

Heather, Andrew,

For service providers (e.g., Telco's v.s. MSO's), it would be great to have some standardization of management protocols as part of this initiative.  

The issue being that TR-069 is more Telco centric, and MSO's having more SNMP centric or proprietary methods of handling XML based data models.

We are seeing some sentiment from MSO's to use TR-069 related protocols to handle statistics for example, where more proprietary methods for XML or SNMP based methods of managing residential gateway functions is still well engrained.

It would be good to have involvement from someone at CableLabs.

Best regards,
Jeff

-----Original Message-----
From: Heather Kirksey [mailto:[email-masked]] 
Sent: Monday, June 15, 2009 4:58 PM
To: [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

Andrew,

Thanks,
Heather

Heather Kirksey
Motive Product Division
Alcatel-Lucent
[email-masked]
+1.512.531.1126 (office)
+1.512.917.7938 (mobile)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
Sent: Monday, June 15, 2009 8:31 AM
To: [email-masked]
Subject: Re: [homegate] PDF of BoF Proposal

A