Re: [homenet] APPSDIR review of draft-ietf-homenet-arch-10

[Tim Chown <[e-mail]>]

On 19 Sep 2013, at 20:43, Ted Lemon <[e-mail]> wrote:

> On Sep 19, 2013, at 1:36 PM, S Moonesamy <[e-mail]> wrote:
>> I agree that it would be good for the working group to evolve the document (see my previous comments about stabilizing the document and having a discussion about unresolved issues).  It might have been missed in my comments; what I am saying is that the working group already has the text it needs to get the work done; what's left is some rearrangement and tightening of the text to get a crisp document.
> 
> Possibly Tim got that from your comments—I didn't.   I should probably let Tim respond rather than continuing to muddy the waters.

Long email threads are prone to misunderstanding, so I'll just try to state my interpretation of where the arch doc is, and how it got there.

The arch doc, which is Informational, emerged from the original homenet charter, as per http://datatracker.ietf.org/wg/homenet/charter/. This talks about, for example, emerging IPv6 home networks with internal routing, heterogeneous links, and internal service separation. As well as the implications of moving from private IPv4+NAT to global IPv6. It says "The task of the group is to produce an architecture document that outlines how to construct home networks involving multiple routers and subnets" and also specifies the five areas to include: routing, prefix configuration, security, naming and service discovery. So the arch text that has evolved over some 15 iterations over a year and a half reflects that, and the layer 3 focus.

You can argue that it's a snapshot of current thinking, and we have discussed the notion of homenet versions (and indeed current discussions about hipnet and homenet are potentially about such an evolution, and whether it can be made to work), but I think it's a little more than that given the 18+ months of discussion that have led us to where we are, including literally thousands of list emails, and at least five IETF meetings. Some paragraphs have been the result of 200+ emails. The document title has remained unchanged over that time, and the structure relatively stable. While there are some very valid DISCUSSes on the text, I believe it represents, as a whole, a good consensus of the WG.

I think the vast majority of DISCUSSes can be addressed without any serious surgery. And it's good to have such interest focused on the document.

The questions from APPSDIR seem to focus around a) the document structure and how/whether it's readily digestible by APPSDIR people, and whether certain application-oriented aspects are discussed/made clear, and b) the document title.

As the document editor, I agree with Jari and Brian that I believe the text meets the original brief. That said, the reality is that whatever is built at layer 3, and the way in which security and naming/SD are handled, will have an affect on applications. I've always assumed there would be a separate text aimed at application developers, just as I expect further texts on naming/SD, security, and routing protocol/prefix configuration solutions. The arch doc is not intended to be a standards track complete spec, rather as an Informational document it states the WG consensus on the path that we'll be taking in that future work. Could it be more concise? Yes, but having had some long threads to get consensus, I'm wary of significant pruning that might spark further long discussions. Might some of the documented principles change with the benefit of future hindsight? Yes, it's possible some may, but we need something to work from, and to point at when dojng the future work. And the RFC library is full of examples of -bis documents.

Do we want to spend more time now, given the desire to move ahead with the other work, restructuring the arch doc? It could be done, but I wonder whether the gain is a worthwhile tradeoff, when a separate document could be produced, co-authored perhaps by APPSDIR people.  Or perhaps we might instead add a short section early in the document on application implications, answering some or all of the questions SM raised.

And the title? Well, personally I have no emotional attachment to the current title. If the IESG were to say let's rename it "Networking Principles for Future IPv6 Home Networks" then I would lose no sleep.

Sorry if that was a bit rambling, but hopefully it makes some of the history and how we got where we are at least a bit clearer. If any of the above sounds in any way tetchy, my apologies, its the result of parsing a few thousand emails to get to the document that we currently have...

Tim