(Doing my homework at the last minute.)
First, let me say that I think this document is well-written, and I like the
way it builds up from fundamentals to explain why the architecture ought to
meet certain cases.
The last paragraph of "Multiple Segments" says "multiple routers" but that
principle hasn't been mentioned. I agree that the architecture should allow
for it, but it comes up abruptly.
The section " Security, Borders, and the elimination of NAT" discusses
security, but provides no architecture or advice. It seems odd to lump these
things together, unless there is an assumption that Borders are firewalls or
advanced-security-monsters. For defense in depth, that unstated assumption
should be explicitly repudiated. There's not really any discussion of the
elimination of NAT.
"Naming and service discovery are thus important, but they {may==>should} also
be expected to operate across the scope". Or "should" could be "will" or
"would" if you want to avoid rfc2119 language.
"For the purposes of this memo and IP layer
operation this arrangement is considered equivalent to the topology
in Figure 1."
Huh? How could they be equivalent?
Figure 3 has some vertical lines that I think are strays. I wouldn't expect a
host in a home network to have two simultaneous connections to the same network
segment (e.g., Network A, or Network B).
The principle "Largest Possible Subnets" is explained, but given that routing
will be required, the reasons why large L2 domains are preferable to routing
are still unclear.
The "Transparent End-to-End" principle is clearer now than it the previous
draft. To make the language consistent with rfc1958 though, it should be
mentioned that end-to-end communications are important for their robustness to
failure of intermediate systems, and that NAT (and firewalling, if you want to
argue that) is dependent on state machines which are not self-healing.
Why is "IP Connectivity between All Nodes" an important architectural
principle? What if the SmartGrid guys don't want us touching some of their
nodes? What if some parts of the network are managed and others are unmanaged?
The reason for this principle is unclear, and seems only to constrain us where
constrain may or may not be needed.
I'd like to add a modifier to "Self-Organization" that manual configuration
should override self-organization.
"Least Topology Assumptions" should be "Fewest Topology Assumptions."
The "Intelligent Policy" principle is poorly defended. Apparently Cisco wants
to sell database/signature updates, but this principle presumes consensus on an
operating model that has never been tried. If the sentence "these traffic
patterns should be driven off up-to-date databases in the Internet" is removed,
I do not object.
Section 3.5 needs to be rewritten. It asserts that little to no protocol work
is necessary, when previous sections said (or asked) that remains to be seen.
It's difficult to assert that extensions are possible without defining the
requirements or at least use cases, and naming the protocols to be extended.
I'm arriving very late tonight. See you all tomorrow.
Lee
> -----Original Message-----
> From: homenet-boun...@ietf.org [mailto:homenet-boun...@ietf.org] On Behalf Of
> Tim
> Chown
> Sent: Wednesday, September 21, 2011 8:27 AM
> To: homenet@ietf.org
> Subject: [homenet] draft-chown-homenet-arch-00.txt
>
> Hi,
>
> I have been working with Jari, Jason and Ole to produce a new version of the
> homenet
> architecture draft. Mark, who produced the first version with Jari, is now of
> course WG
> chair and has stepped down as editor of the text.
>
> The structure of the draft remains similar. We have expanded section 2 on
> IPv6 implications
> for home networking, added a couple of extra models in section 3, expanded
> the principle
> section and also added a considerations section where we discuss certain
> topics that may (or
> may not) be deemed in scope for the text.
>
> Feedback is of course welcome, indeed required!
>
> I don't know whether Mark and Ray will call for WG adoption at this stage.
> The charter
> targets a WG draft by the end of September, but this is also a document that
> I hope will
> have some additional revisions from your feedback before the interim meeting.
>
> There are some acknowledgements to be added; these will be included in the
> next version.
>
> Tim
>
> On 21 Sep 2011, at 12:37, internet-dra...@ietf.org wrote:
>
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> > Title : Home Networking Architecture for IPv6
> > Author(s) : Jari Arkko
> > Tim Chown
> > Jason Weil
> > Ole Troan
> > Filename : draft-chown-homenet-arch-00.txt
> > Pages : 20
> > Date : 2011-09-21
> >
> > This text describes the evolving networking technology within small
> > "residential home" networks. The goal of this memo is to
> > define the
> > architecture for IPv6-based home networking. The text highlights the
> > impact of IPv6 on home networking, and illustrates some topology
> > scenarios. The architecture shows how standard IPv6 mechanisms and
> > addressing can be employed in home networking, lists a number of
> > principles that should apply, and outlines the need for specific
> > protocol extensions for certain additional functionality.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-chown-homenet-arch-00.txt
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely for
the use of the individual or entity to which it is addressed. If you are not
the intended recipient of this E-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation to the
contents of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify the sender
immediately and permanently delete the original and any copy of this E-mail and
any printout.
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
