From Ray.Bellis@nominet.org.uk Thu Feb 2 06:59:36 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4B521F8570 for ; Thu, 2 Feb 2012 06:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.809 X-Spam-Level: X-Spam-Status: No, score=-9.809 tagged_above=-999 required=5 tests=[AWL=0.790, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0htrnHm2+nh for ; Thu, 2 Feb 2012 06:59:35 -0800 (PST) Received: from mx3.nominet.org.uk (mx3.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1F09F21F8526 for ; Thu, 2 Feb 2012 06:59:34 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=qr28NaQXFv+9GTvQfqntJqbeZHpLsIyxkoZAqCOuwnpJUpxIzFV4x3NF 4wVlk6mxvD8Qi3ek3j6q/8Eu3P/Bo4YGnt1bXQ6Cr2kQYAHCn3dRAV3gs XKnPkC6RmmHmaXy; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1328194775; x=1359730775; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20I-D=20Action:=20draft-ietf- homenet-arch-01.txt|Date:=20Thu,=202=20Feb=202012=2014:59 :31=20+0000|Message-ID:=20<7200307E-255F-4FCA-9AA5-D4104E 9577DF@nominet.org.uk>|To:=20"homenet@ietf.org=20Group" =20|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<5b97880b-2fc3-46a9-912d-9e31ef5dfa41> |In-Reply-To:=20<20120130163845.2110.6281.idtracker@ietfa .amsl.com>|References:=20<20120130163845.2110.6281.idtrac ker@ietfa.amsl.com>; bh=WqTCL0zKSFNLBAa/kOZ46RV2vmHjzTbi5aX9f3Z+zis=; b=TvhJdau9f73PwlmmEdzzNn+vhEuAxWWcfM2qHeHHNOOLj2zVVPtAcSQG cMiRuwbLAYwWcy/YO1Dau4EljaIbQyXLsyLlT2nMEWyAsb/WMNzvzCD9T 5AY3MzDf8C5EO1r; X-IronPort-AV: E=Sophos;i="4.71,609,1320624000"; d="scan'208";a="38043803" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx3.nominet.org.uk with ESMTP; 02 Feb 2012 14:59:32 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Thu, 2 Feb 2012 14:59:32 +0000 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: [homenet] I-D Action: draft-ietf-homenet-arch-01.txt Thread-Index: AQHM3221AoegeUL8lku115UXIIHjKJYpt62A Date: Thu, 2 Feb 2012 14:59:31 +0000 Message-ID: <7200307E-255F-4FCA-9AA5-D4104E9577DF@nominet.org.uk> References: <20120130163845.2110.6281.idtracker@ietfa.amsl.com> In-Reply-To: <20120130163845.2110.6281.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <5b97880b-2fc3-46a9-912d-9e31ef5dfa41> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 14:59:36 -0000 On 30 Jan 2012, at 16:38, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Home Networking Working > Group of the IETF. >=20 We'd like to urge all WG participants to review this draft and provide feed= back. This is our major chartered work item and forms the basis for all future wo= rk in the group. thanks, Ray and Mark From brian.e.carpenter@gmail.com Sun Feb 5 11:52:57 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE06021F853F for ; Sun, 5 Feb 2012 11:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1z-wflJITNB for ; Sun, 5 Feb 2012 11:52:56 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9389321F853A for ; Sun, 5 Feb 2012 11:52:56 -0800 (PST) Received: by eaaq13 with SMTP id q13so609633eaa.31 for ; Sun, 05 Feb 2012 11:52:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=J0U75S5edqV/XpCxJ3bGMCz1cBGOWKDRhp/K+nduNbY=; b=HqJzo6OlDsL/m7q93ZQLaRke8zq6c5avTImHnA7tu29t+1os+BmAg5m9IOgH+7jEi4 1jR1sNs06OFtwH8niEvXtFFqI/urZcAfqTXsBAuv+28eIaoAAIkDN9baNFyJaDhM1gA5 rKsxz83od6EPf9wxMGsJA9HD2Bhj1v6Ty82BE= Received: by 10.213.106.14 with SMTP id v14mr913464ebo.55.1328471575795; Sun, 05 Feb 2012 11:52:55 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id x4sm52081921eeb.4.2012.02.05.11.52.53 (version=SSLv3 cipher=OTHER); Sun, 05 Feb 2012 11:52:54 -0800 (PST) Message-ID: <4F2EDE09.8080805@gmail.com> Date: Mon, 06 Feb 2012 08:52:41 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: homenet@ietf.org References: <20120130163845.2110.6281.idtracker@ietfa.amsl.com> In-Reply-To: <20120130163845.2110.6281.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 19:52:57 -0000 Hi, > 3.1. Network Models > > In this section we list six network models. I have no complaint about those 6 models, but the reality is that in an unmanaged homenet, the topology will be effectively random, and solutions have to work whatever the user happens to do. (Or alternatively, some sort of topology wizard would have to tell the user to disconnect or move particular cables, but that seems unreasonable.) Therefore, these 6 models are useful but they can only be illustrative. The requirement is that stuff works for any topology. I think this needs to be said as an introduction to section 3.1, and it prepares the way for sections 3.4.7 "Self-Organising" and 3.4.8 "Fewest Topology Assumptions". > PD13) The delegation method should support "flash" renumbering. and > When an ISP needs to restructure and in doing so renumber its > customer homenets, "flash" renumbering is likely to be imposed. This > implies a need for the homenet to be able to handle a sudden > renumbering event which, unlike the process described in [RFC4192], > would be without a "flag day". This needs more analysis. As the draft mentions, homenets are out of scope for 6renum, and in any case the emphasis there is on planned renumbering, which seems the only conceivable approach for enterprises. I think we need to analyse in what way flash renumbering is different from a cold start. More or less by definition, if we cold start a homenet (as after a power cut), everything except ULAs will be renumbered, even if they end up with the exact same addresses again. It's therefore accurate to say that a cold start will cause flash renumbering but is that sufficient to meet the requirement? If not, requirement PD13 seems to be very demanding. Brian From v6ops@globis.net Fri Feb 10 04:22:21 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A007321F86B0 for ; Fri, 10 Feb 2012 04:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHvct9RShaQt for ; Fri, 10 Feb 2012 04:22:20 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id B6DAF21F86A5 for ; Fri, 10 Feb 2012 04:22:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 983E48700E2 for ; Fri, 10 Feb 2012 13:22:18 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb+yPkqwvYhW for ; Fri, 10 Feb 2012 13:22:09 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 7DC418700B9 for ; Fri, 10 Feb 2012 13:22:09 +0100 (CET) Message-ID: <4F350BF1.2060001@globis.net> Date: Fri, 10 Feb 2012 13:22:09 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: "homenet@ietf.org Group" References: <20120130163845.2110.6281.idtracker@ietfa.amsl.com> <7200307E-255F-4FCA-9AA5-D4104E9577DF@nominet.org.uk> In-Reply-To: <7200307E-255F-4FCA-9AA5-D4104E9577DF@nominet.org.uk> Content-Type: multipart/alternative; boundary="------------010306020805060108090306" Subject: Re: [homenet] I-D Action: draft-ietf-homenet-arch-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 12:22:21 -0000 This is a multi-part message in MIME format. --------------010306020805060108090306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have reviewed this document. Generally I like it. I have a lot of detailed comments. p4 > The assumption of this document is that the homenet is "not actively managed". I think this is a very challenging assumption. I think it is perfectly reasonable to require some basic level of low-tech management (to be defined). I think this assumption effectively as written says that a Homenet needs to be "self organising" which to me is a step far beyond what happens today. Even in today's Homenet of cascaded IPv4 devices with NAT, an end user still has to physically plug the boxes together in a fixed hierarchy in order for it to work. I see no reason why a future IPv6 Homenet could not require some topology restrictions (some time ago I proposed multi-rooted tree topology to mirror current IPv4 practice with 1 root per ISP). > Discussion in the homenet WG has led to a suggestion that there should be a baseline homenet "version 1" architecture, based on protocols and implementations that are as far as possible proven and robust. A future architecture may incorporate more advanced elements. Feedback is sought on what if anything do we want to say about potential homenet versions here. Support. IMHVO the likely major challenge is going to be how to handle multihoming. IMHO V1 should therefore concentrate on a single ISP model with multiple devices. [model A-C] V2 should concentrate on a multiple, competing, ISP model. [model D-F] Section 2.3 p6 talks about external and internal communication. May be useful to define "internal" and "external" in 1.1 as traffic that crosses the "border interface" for the hard of thinking like me. p7. > It may be useful to classify the border of the home network as a unique logical interface separating the home network from service provider network/s. I think defining a Homenet "border" at least in terms of management is going to prove essential in the long term. There may be instances when the ISP manages the Homenet, but there will also be instances where it doesn't. The document already defines demarcs at various points. I think formalizing these interfaces will be a major benefit to interoperability and flexibility. Section 2.4 p7 should mention RFC 6177 IPv6 Address Assignment to End Sites Without sufficient addresses you can't have multiple subnets and still use SLAAC. Section 3.1 p10-15 Why are the topologies limited to 2 ISPs? I already have potentially >= 4 ISPs in my house. Is there any benefit limiting the discussion specifically to 2 ISPs, rather than "multiple" ISPs? Section 3.4.6 p22 RT12 could be challenging, and is arguably a host function to select the correct source address. I miss some discussion of the unique challenges of using wireless connections with many existing IETF protocols, which have largely been developed on wired networks and where all nodes enjoy mutual visibility (unless your segment is too long). Section 3.4.7 PD13 Flash Renumbering Not sure why this is a requirement? We've said earlier that reachability and addressing are orthogonal. What harm would it do if some older prefixes were to hang around on interfaces, but not be routed or selected for new sessions? Wouldn't deprecation and eventual removal of a default route tagged per ISP achieve the same effect? e.g. RFC4192 together with a new prefix policy table to prefer the new prefix for new outbound sessions at some point during the transition? I think it's perfectly reasonable to drop the odd long-lived session and require the app to reestablish if necessary. I miss some discussion on the transient nature of some connectivity, perhaps requiring the topology to auto-update and flush information e.g. a mobile phone as an ISP, or a tablet computer acting as a host entering and leaving the home, perhaps even suggesting that the CER could also act as the Mobile IPv6 Home Agent (RFC3775). I did see Shim6 (RFC5533) Section 3.4.9 p26 Agreed. Now that end to end connectivity is being restored, there is more potential scope for DNSSec (RFC 4033 4034 4035) and DNS update (RFC2136) in the home. Section 3.4.10 p27 Generally, in my humble experience, most enterprises use DHCP to discover any services from a centralized DHCP server reached via a DHCP relay configured on each local switch interface, or via downloading a centralized proxy pac file, or distributing a Domain policy (Windows only). The natural extension of this to Homenet would be to run a DHCPv6 server on the CER, with one LAN interface per subnet running as a DHCPv6 Relay, but that still leaves the challenge of providing relay interface ID's, and combining information from multiple ISPs. I miss some discussion on the challenge of handling multiple authoritative sources of configuration and management information. e.g. conflicting routing tables / selection of competing ISPs, election of a single CER to act as the Homenet DHCPv6 server, or how to communicate with multiple DHCPv6 servers. Section 3.4.11 p27 Not sure flash renumbering will work. See previous comments suggesting RFC4192. A natural consequence of removal of NAT, and opening up bi-directional end to end connectivity, is that upstream providers have to communicate with downstream users. Section 3.5 p28 I don't think a summary is useful. IMHO Two alternative topologies should also be considered and discussed (even if they are rejected): 1. Use of RFC3931 L2TPv3 LNS - LNS to create flat emulated /64 subnets extended from each CER to all hosts in the Homenet over an underlying L3 routed infra based on ULA, with the tunnel endpoints terminating in the Homenet routers. The end devices could then connect to multiple subnets either with a dedicated 802.1Q interface per provider, or to a single subnet via the default L2 LAN. This could have the advantage of avoiding modifying existing protocols that are limited to a single L2 segment, and hide the internal complexity of the Homenet from hosts. 2. Use of one or other standard p2p tunneling protocol (or mobile IPv6) so that each end node (or a router acting as a proxy for the end node) builds an overlay network to one or more CER's for external traffic. regards, RayH Ray Bellis wrote: > On 30 Jan 2012, at 16:38, > wrote: > > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Home Networking Working >> Group of the IETF. >> >> > > We'd like to urge all WG participants to review this draft and provide feedback. > > This is our major chartered work item and forms the basis for all future work in the group. > > thanks, > > Ray and Mark > > > --------------010306020805060108090306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have reviewed this document. Generally I like it.

I have a lot of detailed comments.

p4
> The assumption of this document is that the homenet is "not actively managed".

I think this is a very challenging assumption. I think it is perfectly reasonable to require some basic level of low-tech management (to be defined). I think this assumption effectively as written says that a Homenet needs to be "self organising" which to me is a step far beyond what happens today. Even in today's Homenet of cascaded IPv4 devices with NAT, an end user still has to physically plug the boxes together in a fixed hierarchy in order for it to work. I see no reason why a future IPv6 Homenet could not require some topology restrictions (some time ago I proposed multi-rooted tree topology to mirror current IPv4 practice with 1 root per ISP).

> Discussion in the homenet WG has led to a suggestion that there should be a baseline homenet "version 1" architecture, based on protocols and implementations that are as far as possible proven and robust.  A future architecture may incorporate more advanced elements. Feedback is sought on what if anything do we want to say about potential homenet versions here.

Support. IMHVO the likely major challenge is going to be how to handle multihoming.
IMHO V1 should therefore concentrate on a single ISP model with multiple devices. [model A-C]
V2 should concentrate on a multiple, competing, ISP model. [model D-F]


Section 2.3 p6 talks about external and internal communication.

May be useful to define "internal" and "external" in 1.1 as traffic that crosses the "border interface" for the hard of thinking like me.

p7. > It may be useful to classify the border of the home network as a
   unique logical interface separating the home network from service
   provider network/s.

I think defining a Homenet "border" at least in terms of management is going to prove essential in the long term. There may be instances when the ISP manages the Homenet, but there will also be instances where it doesn't. The document already defines demarcs at various points. I think formalizing these interfaces will be a major benefit to interoperability and flexibility.


Section 2.4 p7 should mention RFC 6177 IPv6 Address Assignment to End Sites
Without sufficient addresses you can't have multiple subnets and still use SLAAC.


Section 3.1 p10-15
Why are the topologies limited to 2 ISPs? I already have potentially >= 4 ISPs in my house.
Is there any benefit limiting the discussion specifically to 2 ISPs, rather than "multiple" ISPs?


Section 3.4.6 p22
RT12 could be challenging, and is arguably a host function to select the correct source address.

I miss some discussion of the unique challenges of using wireless connections with many existing IETF protocols, which have largely been developed on wired networks and where all nodes enjoy mutual visibility (unless your segment is too long).

Section 3.4.7

PD13 Flash Renumbering
Not sure why this is a requirement? We've said earlier that reachability and addressing are orthogonal. What harm would it do if some older prefixes were to hang around on interfaces, but not be routed or selected for new sessions? Wouldn't deprecation and eventual removal of a default route tagged per ISP achieve the same effect? e.g. RFC4192 together with a new prefix policy table to prefer the new prefix for new outbound sessions at some point during the transition? I think it's perfectly reasonable to drop the odd long-lived session and require the app to reestablish if necessary.

I miss some discussion on the transient nature of some connectivity, perhaps requiring the topology to auto-update and flush information e.g. a mobile phone as an ISP, or a tablet computer acting as a host entering and leaving the home, perhaps even suggesting that the CER could also act as the Mobile IPv6 Home Agent (RFC3775). I did see Shim6 (RFC5533)


Section 3.4.9 p26
Agreed. Now that end to end connectivity is being restored, there is more potential scope for DNSSec (RFC 4033 4034 4035) and DNS update (RFC2136) in the home.

Section 3.4.10 p27
Generally, in my humble experience, most enterprises use DHCP to discover any services from a centralized DHCP server reached via a DHCP relay configured on each local switch interface, or via downloading a centralized proxy pac file, or distributing a Domain policy (Windows only). The natural extension of this to Homenet would be to run a DHCPv6 server on the CER, with one LAN interface per subnet running as a DHCPv6 Relay, but that still leaves the challenge of providing relay interface ID's, and combining information from multiple ISPs.

I miss some discussion on the challenge of handling multiple authoritative sources of configuration and management information. e.g. conflicting routing tables / selection of competing ISPs, election of a single CER to act as the Homenet DHCPv6 server, or how to communicate with multiple DHCPv6 servers.

Section 3.4.11 p27
Not sure flash renumbering will work. See previous comments suggesting RFC4192.

A natural consequence of removal of NAT, and opening up bi-directional end to end connectivity, is that upstream providers have to communicate with downstream users.

Section 3.5 p28
I don't think a summary is useful.


IMHO Two alternative topologies should also be considered and discussed (even if they are rejected):

1. Use of RFC3931 L2TPv3 LNS - LNS  to create flat emulated /64 subnets extended from each CER to all hosts in the Homenet over an underlying L3 routed infra based on ULA, with the tunnel endpoints terminating in the Homenet routers. The end devices could then connect to multiple subnets either with a dedicated 802.1Q interface per provider, or to a single subnet via the default L2 LAN. This could have the advantage of avoiding modifying existing protocols that are limited to a single L2 segment, and hide the internal complexity of the Homenet from hosts.

2. Use of one or other standard p2p tunneling protocol (or mobile IPv6) so that each end node (or a router acting as a proxy for the end node) builds an overlay network to one or more CER's for external traffic.

regards,
RayH


Ray Bellis wrote: 
On 30 Jan 2012, at 16:38, <internet-drafts@ietf.org>
 <internet-drafts@ietf.org> wrote:

  
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Home Networking Working
Group of the IETF.

    

We'd like to urge all WG participants to review this draft and provide feedback.

This is our major chartered work item and forms the basis for all future work in the group.

thanks,

Ray and Mark
--------------010306020805060108090306-- From Ray.Bellis@nominet.org.uk Tue Feb 21 06:25:04 2012 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5CC21F8658 for ; Tue, 21 Feb 2012 06:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.715 X-Spam-Level: X-Spam-Status: No, score=-8.715 tagged_above=-999 required=5 tests=[AWL=-0.530, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGDV2L0i5Zn9 for ; Tue, 21 Feb 2012 06:25:00 -0800 (PST) Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id C65E821F858F for ; Tue, 21 Feb 2012 06:24:58 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=TE9SHs0hbDQ6aZtyXXsgZjfrZnhrdGTD90P+GIxNEvOGky50AV570FTV Yl9mIrAO98A5OyObvnCBPpFVnUNf7Pg38/TgvYBrYH9aUw6QT6UEYpUXa LUL24wAnygOmjxH; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1329834300; x=1361370300; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20-00=20submission=20deadline|Date:=20Tue,=2021 =20Feb=202012=2014:24:56=20+0000|Message-ID:=20<4C0563AC- B59A-407C-8210-3E2D49DB1A69@nominet.org.uk>|To:=20"homene t@ietf.org=20Group"=20|MIME-Version:=20 1.0|Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<6faace4b-3d22-464b-a4a5-297b6ef4f6c9>; bh=ODPooV6dnHYLe5akM36weSsfiXk2tIakh+tXz3xsvBs=; b=KhtcpeLskYhd/NBqXniUn4QpqoqyqjXLjbEfadAhsaWC9CF8Y9tpy6Yl VcL+MT0szaHpGPcSlNvyBbx/iK5JXTpAtPaFeXFV33uNseOBiv2cfFpPz ob4PJhxS3FGO1ja; X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="31325864" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 21 Feb 2012 14:24:57 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Tue, 21 Feb 2012 14:24:57 +0000 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: -00 submission deadline Thread-Index: AQHM8KSVAmZfkhVDPkyGl2bOwXvUNw== Date: Tue, 21 Feb 2012 14:24:56 +0000 Message-ID: <4C0563AC-B59A-407C-8210-3E2D49DB1A69@nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <6faace4b-3d22-464b-a4a5-297b6ef4f6c9> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [homenet] -00 submission deadline X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 14:25:04 -0000 Just a quick reminder that the submission deadline for any new -00 drafts i= s just under two weeks away on 5th March. If you have new material that you would like to present in Paris please get= your drafts in soon! Ray