Re: [homenet] Updates to Homenet Architecture Principles doc

Tim Chown <tjc@ecs.soton.ac.uk> Fri, 13 June 2014 14:11 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AA21B290F for <homenet@ietfa.amsl.com>; Fri, 13 Jun 2014 07:11:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.871
X-Spam-Level:
X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_Y3L0DcMVhK for <homenet@ietfa.amsl.com>; Fri, 13 Jun 2014 07:11:00 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1D71A00FB for <homenet@ietf.org>; Fri, 13 Jun 2014 07:10:59 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s5DE9dDX000924; Fri, 13 Jun 2014 15:09:49 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s5DE9dDX000924
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1402668615; bh=TjMIzDY0G3s8lt5sLkFv59SrUio=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=VGp3pma1tPm2p8kBDWJ+ehDxfbwDEI3CCIQZPx/62owxxgO/f3AFDwP0BvrLYYrux EQnYcgSg0kryMNtTX1ZlbJ7ikMVXzblj5Zn47fLeCfXHvXHSvz0Dm2G07Zl52ALVLw MupADlw0E6cnuEJWC8uccgVbBw354vQw6Cgf8YD0=
Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP (valid=N/A) id q5CF9Y05460355350O ret-id none; Fri, 13 Jun 2014 15:10:15 +0100
Received: from [IPv6:2001:630:d0:ed04:6936:1e53:cbc4:2789] ([IPv6:2001:630:d0:ed04:6936:1e53:cbc4:2789]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s5DE9SDU030348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Jun 2014 15:09:28 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_7A87C212-B28B-4B81-922B-48BC13DFE80D"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <569F1126-D0A4-47ED-9261-F4E727B1C072@fugue.com>
Date: Fri, 13 Jun 2014 15:09:28 +0100
Message-ID: <EMEW3|53cba0e8e8132f6ec78242f43ab287b0q5CF9Y03tjc|ecs.soton.ac.uk|797DA508-0CCE-4D62-9C8E-57B8BC15094C@ecs.soton.ac.uk>
References: <BEB843C7-EB1D-486A-A9A1-B99D48775D33@nominet.org.uk> <85F978F4-1293-4F9E-B5C7-068F95A0B626@nominet.org.uk> <CAKD1Yr2mzZOvCDwyyEZHef1rk5PAxtNZRVRys43SXnD=gVxLBA@mail.gmail.com> <143C7553-11D4-41A9-910E-FAD26F484635@fugue.com> <CAKD1Yr0hr8Pa_QU_9mjRjbxffQ=mdgOWYSQUyLc5ewkpuf5OmA@mail.gmail.com> <569F1126-D0A4-47ED-9261-F4E727B1C072@fugue.com> <797DA508-0CCE-4D62-9C8E-57B8BC15094C@ecs.soton.ac.uk>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.1878.2)
X-smtpf-Report: sid=q5CF9Y054603553500; tid=q5CF9Y05460355350O; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: s5DE9dDX000924
X-ECS-MailScanner: Found to be clean
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/homenet/ZUH3wVZKFir2leFJP0lk8EKtp_g
Cc: Bellis Ray <Ray.Bellis@nominet.org.uk>, "homenet@ietf.org Group" <homenet@ietf.org>, Lorenzo Colitti <lorenzo@google.com>
Subject: Re: [homenet] Updates to Homenet Architecture Principles doc
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jun 2014 14:11:05 -0000

On 13 Jun 2014, at 14:38, Ted Lemon <mellon@fugue.com> wrote:

> On Jun 13, 2014, at 9:27 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
>> No, the problem is that the working group doesn't know what is being asked for.
> 
> We could go around on this all week…

I must say as the editor of the arch text I am also very confused. I don’t understand what is required in a replacement for the “contentious" paragraph (paragraph 4 of section 3.5), rather than simply removing the paragraph based on strong WG consensus.

In producing the -13, which was pushed out at IETF London, it seemed to me that there was clear WG consensus in that meeting that we should not constrain, witness the minutes at http://www.ietf.org/proceedings/89/minutes/minutes-89-homenet (under Slide 9). This view was reinfroced by comments elsewhere, and by the WG chairs. While it’s possible the WG view may have changed since London, it’s not a big surprise that it hasn’t. That message is why the one reference to link metrics earlier in section 3.5 is clearly qualified by “if supported by the protocol in use”.

As Ray points out, the paragraph added by the Routing ADs does make other some text in other paragraphs (which isn’t so prescriptive) seem out of place. My personal view, which happens to be in line with most (all?) who have commented in the WG is simply to strike the proposed prescriptive paragraph.  The question of course is whether/if Ted can square that off with our routing ADs who have genuine concern in raising the issue… it’s simply that the WG is coming back here and saying “it’s OK, thanks for raising the point, but we’re sure we want to do it this way”.

The -13 also includes other changes in response to discussion at London, as documented in the minutes, e.g. about the zero or one routing protocols. 

Tim