ietf
[Top] [All Lists]

Re: [fun] [homegate] HOMENET working group proposal

2011-07-01 13:33:16
Anytime we develop standards, the standards apply to future products.  There's 
no point in defining standards for applications and devices that are already 
deployed.

Sure, it's nice to have backward compatibility.  But I don't think anyone is 
likely to propose standards for HOMENET that will significantly break 
compatibility with existing products.  It's not as if the set of applications 
and devices that one uses in a home network is disjoint from the set of 
applications and devices used in other networks.   And it's reasonable to 
expect that users of existing applications and devices might need to do some 
special-case configuration to get those applications and devices to continue to 
work.  

Just to pick one example, if a legacy device is v4-only, and the only access 
available is NATted v4 or native v6, there might be a need to configure the 
device to be externally accessible using a v6 address.  The home network might 
support v4 internally but there might not be v4 service available outside that 
enclave.

Backward compatibility = good.  Insisting that home networks always use the 
same kludges that are used now = bad.

Maybe the right answer is that the HOMENET group should consider what means are 
needed to provide some measure of compatibility with legacy devices and 
applications, that might continue to be used with networks meeting the new 
standards.  The working group seems like it's in a much better position than 
the IETF list to propose reasonable compromises on these issues.

Keith


On Jun 30, 2011, at 12:17 PM, Stephen [kiwin] PALM wrote:

It is not for "us" to decide when a user's network is not worth expending
any more energy on. They have deployed their network...
and do not want to expend any more energy themselves.  If their SP deploys
IPv6 inelegantly, the user would have a lot of frustration/work.  Which
will generate many expensive tech support calls... and potentially lost 
customers.

It's not the protocols... it's the DEPLOYED APPLICATIONS and DEVICES that 
users have.

regards, kiwin

On 6/30/2011 9:11 AM, Ralph Droms (rdroms) wrote:

"Gone" isn't so important as "not worth expending any more energy on.". So 
I'm with Keith and would like to find some words like "when it doesn't take 
any more work."

- Ralph

On Jun 30, 2011, at 12:00 PM, "Fernando 
Gont"<fernando(_at_)gont(_dot_)com(_dot_)ar>  wrote:

On 06/30/2011 12:46 PM, Keith Moore wrote:
I'd like for this group to relax the "wherever possible" bit, so as to not 
preclude solutions where IPv6 can do a better job than IPv4.

IPv4 is a dinosaur gasping for its last breaths.

Just curious: when you expect IPv4 to be gone? (including "gone" from
home and enterprise networks)

Thanks,
--
Fernando Gont
e-mail: fernando(_at_)gont(_dot_)com(_dot_)ar || fgont(_at_)acm(_dot_)org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



_______________________________________________
fun mailing list
fun(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/fun
_______________________________________________
fun mailing list
fun(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/fun


-- 
Stephen [kiwin] Palm   Ph.D.                          E:  
palm(_at_)kiwin(_dot_)com
Senior Technical Director                             T: +1-949-926-PALM
Broadcom Broadband Communications Group               F: +1-949-926-7256
Irvine, California                               W: http://www.kiwin.com
Secondary email accounts:  stephenpalm(_at_)alumni(_dot_)uci(_dot_)edu  
palm(_at_)broadcom(_dot_)com
s(_dot_)palm(_at_)ieee(_dot_)org  palm(_at_)itu(_dot_)ch  
spalm(_at_)cs(_dot_)cmu(_dot_)edu  
palm(_at_)ics(_dot_)t(_dot_)u-tokyo(_dot_)ac(_dot_)jp

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>