Re: [homenet] Updates to Homenet Architecture Principles doc

[Markus Stenberg <[e-mail]>]

On 13.6.2014, at 14.40, Ted Lemon <[e-mail]> wrote:
> On Jun 13, 2014, at 2:26 AM, Lorenzo Colitti <[e-mail]> 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, http://tools.ietf.org/html/draft-ietf-homenet-hncp-00#section-8.1 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.

Cheers,

-Markus