Re: [homenet] Updates to Homenet Architecture Principles doc

Markus Stenberg <> Fri, 13 June 2014 12:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 45FF51B285A for <>; Fri, 13 Jun 2014 05:56:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kstMO_KxfPT2 for <>; Fri, 13 Jun 2014 05:56:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D8F6A1A04CA for <>; Fri, 13 Jun 2014 05:56:23 -0700 (PDT)
Received: from poro.lan ( by ( (authenticated as stenma-47) id 534D29300496E1BB; Fri, 13 Jun 2014 15:56:16 +0300
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Markus Stenberg <>
In-Reply-To: <>
Date: Fri, 13 Jun 2014 15:56:12 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Ted Lemon <>
X-Mailer: Apple Mail (2.1878.2)
Cc: Ray Bellis <>, " Group" <>, Markus Stenberg <>, Lorenzo Colitti <>
Subject: Re: [homenet] Updates to Homenet Architecture Principles doc
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Jun 2014 12:56:26 -0000

On 13.6.2014, at 14.40, Ted Lemon <>; wrote:
> On Jun 13, 2014, at 2:26 AM, Lorenzo Colitti <>; wrote:
>> I vote for removing the text and returning the draft to the IESG as WG consensus, and if the IESG is not happy with that, then ask them to explain clearly what it is that they are worried about.
> People have already made suggestions for how to fix the text, which I would like implemented.   "The IESG" isn't asking for a change.   Adrian has been trying to negotiate a change for several months, and that resulted in some text that was reluctantly agreed to, but that the chairs felt didn't reflect the working group consensus, which appears to have been a correct evaluation.   The proposed text sucks, and is not what the IESG asked for.   It is just text that was agreed to because the AD who raised the DISCUSS was tired of arguing.   So blaming the IESG for the bad text and demanding that we do something to fix it isn't going to work.   We don't know what the working group wants the text to mean.   That's the problem.
> I asked the working group to think about this a little harder because I need your help.   If your answer to this request for help is "no," then you are basically asking _me_ to take on this burden, and I can't.   So please reconsider.   As I said, we've already had some good suggestions.   There is no reason why this has to be hard.

Problem for me is that I don’t understand what that added text _is_ about. What I _would_ like to do is remove even _more_ from that section, but for some reason that doesn’t sound like direction the routing ADs want to go.

Without understanding the reasoning behind why that text was added, it’s hard to figure how to fix it by anything else than using ‘cut’ tool in text editor.

As an example, has _two_ requirements for a routing protocol. Two. (One could argue for physical media independence, and even the second requirement of zeroconf in that text is arguable because if something else does the magic, you _can_ e.g. use OSPFv3 non-AC perfectly fine given someone provides it with unique IPv4 addreses to use as router IDs). So in IETF level jargon, only MUST is source specific routing support. There’s TON of SHOULDs but I’m not sure they belong in arch document.

That said, if we’re ever to converge on _one_ routing protocol, the set of requirements would be much stricter. But as that discussion hasn’t even started, I don’t see why we should stick _those_ requirements into RFC and freeze them long before discussion even starts.