Subject: [homegate] What's Homegate reeeeally going to accomplish?

From: "James M. Polk" <[email-masked]>
Date: Sun, 26 Jul 2009 17:44:16 -0500

Guys

I'm seeing basic low-level stuff mentioned as "what this group ought 
to focus on", like v6 (DHCP and DNS), ZeroConf, TFTP, DNSSEC, and 
other low level things -- that all have admittedly real issues wrt 
interoperability and adoption.

What I'm not seeing, other than from James Woodyatt is what a user is 
going to be able to accomplish with something produced by this BOF 
(hopefully group soon, if things go well).

The keys to that are interoperability, minimums of features per 
protocol written in a BCP where coders can implement a Homegate 
*thing* that is useful.

But we cannot - even though most of us want to - forget how this 
Homegate *thing* is going to be used.  It is the demarcation between 
the residential user and the SP (for the most part), 
right?  Otherwise, what's it good for?

Unfortunately (for some) - that means it has to be a Layer 7 box as 
well as everything else mentioned on the list so far.

This most likely means it needs to be a audio/video SIP/RTSP/SDP 
server, call it a mini-SBC/keysystem lookin` *thing*, because if it's 
not, then it has to let all that traffic in so another Homegate 
*thing* CAN do this functionality. The idea of two boxes instead of 
one seems stupid when we all know those two are necessary for this to 
go anywhere.

It also has to be a firewall that allows RTP in and out, and keeps 
the bad guys out.

Someone brought up that is has to be a NAT. As much as I hate NATs, I 
think it has to be a NAT (or at least can be a NAT).

All this doesn't mean we talk about all this tomorrow (all in 1 hour) 
- but we ought to acknowledge that this is part of what Homegate is 
to produce (*IF* this group becomes a WG).

I think that is gonna mean that someone or some team eventually gets 
to decide which parts of SIP/RTSP/SDP are necessary for Homegate, 
meaning another BCP (*IF* this group becomes a WG).

Now - the whole kitchen sink doesn't have to be in this *thing* this 
group produces (*IF* this group becomes a WG), but it needs to have a 
fair amount of function for the applications that are in use by 
residential users today, and out at least 5 years. Remember - it'll 
take at least 3 years to get the first RFC our of this group (*IF* 
this group becomes a WG).

my 0.14986272 SEK (based on Friday's exchange rate)

;-)

James

---

From: Hongyu Li <[email-masked]>
Date: Mon, 27 Jul 2009 16:07:58 +0800

Hi James,

My feeling for this BoF is it focuses on the transport part of and  
HGW, as it is in the transport area. There are already several other  
parties in industry, e.g. HGI and BBF, are working on device  
requirements of HGW. Those are the places where what an HGW as a whole  
box should look like. As for IETF, a place more for protocol, I don't  
think it is our responsibility to define every aspect of a future HGW.
Even if for application layer protocols, there are too many parties  
are already working on it. Before we incorporate application layer  
protocols or applications capabilities in an HGW we are going to  
study, we need to clarify what are the specific worked related we need  
to do here in this BoF. It is not valuable to repeat others' job or  
just simply include them.

Cheers,
Hongyu

在 2009-7-27，上午6:44， James M. Polk 写道：

> What I'm not seeing, other than from James Woodyatt is what a user  
> is going to be able to accomplish with something produced by this  
> BOF (hopefully group soon, if things go well).
>
> the residential user and the SP (for the most part), right?   
> Otherwise, what's it good for?
>
> server, call it a mini-SBC/keysystem lookin` *thing*, because if  
> it's not, then it has to let all that traffic in so another Homegate  
> one seems stupid when we all know those two are necessary for this  
> to go anywhere.
>
> Someone brought up that is has to be a NAT. As much as I hate NATs,  
> I think it has to be a NAT (or at least can be a NAT).
>
> All this doesn't mean we talk about all this tomorrow (all in 1  
> hour) - but we ought to acknowledge that this is part of what  
> Homegate is to produce (*IF* this group becomes a WG).
>
> group produces (*IF* this group becomes a WG), but it needs to have  
> a fair amount of function for the applications that are in use by  
> _______________________________________________
> homegate mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homegate

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 27 Jul 2009 03:53:03 -0500

Hongyu

While I mostly agree with what you say, the list 
of things Jason put together this BOF ought to 
focus on (v6 (DHCP and DNS), ZeroConf, TFTP, 
DNSSEC) have nothing to do with transport either 
- since none of them are in the TSV Area (where I'm a WG chair).

That's why I was trying to be more of a catalyst 
for discussion than anything else by phrasing my comment the way I did.

James

At 03:07 AM 7/27/2009, Hongyu Li wrote:
>ÔÚ 2009-7-27£¬ÉÏÎç6:44£¬ James M. Polk Ð´µÀ£º
>
>>Guys
>>

---

From: Hongyu Li <[email-masked]>
Date: Mon, 27 Jul 2009 17:28:47 +0800

James,

You are right. There are more work than transport only we need to  
cover, but we shouldn't go too far.

Hongyu

在 2009-7-27，下午4:53， James M. Polk 写道：

> Hongyu
>
> While I mostly agree with what you say, the list of things Jason put  
> together this BOF ought to focus on (v6 (DHCP and DNS), ZeroConf,  
> TFTP, DNSSEC) have nothing to do with transport either - since none  
> of them are in the TSV Area (where I'm a WG chair).
>
> That's why I was trying to be more of a catalyst for discussion than  
> anything else by phrasing my comment the way I did.
>
> James
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 27 Jul 2009 07:29:47 -0400

We should not get hung up on what area this work is in right now (we're not
even an official BoF).  Let's focus instead on what work we think we should
focus on (which necessarily includes what things the IETF can do compared to
other groups).

Jason

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 27 Jul 2009 14:44:53 +0200

>focus on (which necessarily includes what things the IETF can do compared to

The latter point is particularly important. The IETF is the wrong place for some of the things that people have listed so far.

--Paul Hoffman, Director
--VPN Consortium

---

From: james woodyatt <[email-masked]>
Date: Mon, 27 Jul 2009 17:17:55 +0200

On Jul 27, 2009, at 14:44, Paul Hoffman wrote:
>> Let's focus instead on what work we think we should focus on (which  
>> necessarily includes what things the IETF can do compared to other  
>> groups).
>
> The latter point is particularly important. The IETF is the wrong  
> place for some of the things that people have listed so far.

Maybe I'm wrong, but I think we've successfully pushed back on most or  
all of those efforts.  Perhaps we can now concentrate on refining the  
proposed charter to focus on serving the Internet engineering  
community as a whole.

The elevator pitch in my head goes like this: we're collecting the  
IETF standards, information and best current practices relevant to the  
engineering of residential Internet gateways for convenient reference  
by external standards documents with an aim toward promoting  
consistency and simplicity of operation and to facilitate the  
transition of residential networks to IPv6 operations.

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

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 27 Jul 2009 11:14:33 -0500

>transition of residential networks to IPv6 operations.

well, that sounds a LOT like product mgmt -- which the IETF isn't...

---

From: james woodyatt <[email-masked]>
Date: Mon, 27 Jul 2009 19:04:24 +0200

> well, that sounds a LOT like product mgmt -- which the IETF isn't...

Hmmm.  None of the product managers I know think that IETF setting  
standards, making recommendations and providing information is a  
serious encroachment on their turf.  In fact, one of the frustrations  
I've heard them voice to me is that the IETF has often failed to set  
important standards or make useful recommendations to simplify the  
problem domain, and this leads inevitably to unnecessary complications  
for applications engineers and network operators.

For example, IETF long refused to set a standard for IPv4/NAT gateway  
behaviors, and even now IETF has not finished documenting the basic  
behaviors that have emerged in the absence of such standards.  Those  
behaviors widely vary, unnecessarily, and this poses all kinds of  
problems for the Internet community.

I could prattle on enumerating a lengthy list of similar IETF  
failures.  I'd really not like to see the transition of residential  
Internet service to IPv6 plagued with similar failures.  This is the  
basic idea behind draft-ietf-v6ops-cpe-simple-security, but there are  
plenty of areas besides security where specific information and  
recommendations would be helpful, e.g. DNS, MLD, MIP, etc.

One of the best documents we have is RFC 4084, which lays down the  
basic framework of what it means to deliver "Internet service" to  
retail consumers.  [If you're on this list and you haven't read it,  
then you should read it ASAP.]  It's really good, and it isn't product  
management, if you ask me.  We should look to it for inspiration.

Sadly, RFC 4084 is dated, and it doesn't really go far enough.  It  
needs to be updated and augmented with more detailed explanations of  
what functions are required and/or recommended in home gateways to  
facilitate the delivery of Internet services-- with varying  
capabilities-- to residential users.  Sure, we could leave that to  
various other bodies to define, separately, and differently, as we did  
for IPv4, but if we do, then we shouldn't be terribly surprised when  
the IPv6 transition turns out to solve no real problems beyond the  
immediate IPv4-allocation exhaustion problem.  That, I submit, would  
be a colossal waste of engineering effort.