Subject: [homenet] I-D Action: draft-ietf-homenet-arch-16.txt

From: [email-masked]
Date: Thu, 12 Jun 2014 11:43:51 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Home Networking Working Group of the IETF.

        Title           : IPv6 Home Networking Architecture Principles
        Authors         : Tim Chown
                          Jari Arkko
                          Anders Brandt
                          Ole Troan
                          Jason Weil
	Filename        : draft-ietf-homenet-arch-16.txt
	Pages           : 53
	Date            : 2014-06-12

Abstract:
   This text describes evolving networking technology within residential
   home networks with increasing numbers of devices and a trend towards
   increased internal routing.  The goal of this document is to define a
   general architecture for IPv6-based home networking, describing the
   associated principles, considerations and requirements.  The text
   briefly highlights specific implications of the introduction of IPv6
   for home networking, discusses the elements of the architecture, and
   suggests how standard IPv6 mechanisms and addressing can be employed
   in home networking.  The architecture describes the need for specific
   protocol extensions for certain additional functionality.  It is
   assumed that the IPv6 home network is not actively managed, and runs
   as an IPv6-only or dual-stack network.  There are no recommendations
   in this text for the IPv4 part of the network.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-homenet-arch/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-homenet-arch-16

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-arch-16

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 19 Jun 2014 14:19:42 +0200 (CEST)

I decided to re-read the entire arch document frmo scratch. I have some 
comments. I don't mind shipping the document as-is, but I thought I'd 
write down my thoughts as I read the document.

1. "This means that Layer 2 is largely out of
    scope, we're assuming a data link layer that supports IPv6 is
    present, and that we react accordingly.  Any IPv6-over-Foo
    definitions occur elsewhere."

While I personally have no problem with the above, it kinds of breaks 
"tone" of the rest of the document. Using "foo" in this kind of document 
where before in the document things are very strict and formal, stands 
out. It also changes from an impersonal note to "we" all of a sudden in 
the middle of the paragraph.

1.1 FQDN should probably have a reference to an RFC or something?

2.2 First paragraph is long and complicated. Took me 3 reads to store 
enough information on the stack to be able to pop at the end to the 
context understand.

In 2.2, there could be a mention added of users expecting their devices to 
not be reachable from the Internet and they historically have not been 
reachable, but when these devices are put on an IPv6 homenet, they are 
suddenly reachable if there is no filtering. Users might choose weak or no 
passwords because historically this has been fine.

2.3. With SLAAC, devices don't "receive" addresses. Perhaps write 
something about "addresses can exist within one prefix per ISP" or 
something of that effect? This section, "devices", does that mean the CER 
or devices the user connects to the CER, or both?

2.6, last paragraph. To make it more clear, I propose to change to "The 
widespread availability of robust solutions to these types of 
transition technologies requirements", since "these" refers to a previous 
paragraph and I was confused for a while what "these" actually referred 
to.

GENERAL: Generally throughout the document it talks about "acquiring an 
address" or similar wording. Perhaps this could be changed to "acquires 
adress(es)" ? It has specific statements around end hosts having multiple 
addresses, but then reverts back to mentioning adresses in singular term.

3.3.5 seems very open ended and vague. What is "the homenet DHCP server"? 
I thought each router within the home could be a DHCP server for a subnet. 
Does homenet aim to solve this information spreading problem or is it out 
of scope, or we don't know at this time?

3.6.1 there is no "." at the end of the last paragraph.

GENERAL: Since RFC6204 has been obsoleted by RFC7084, shouldn't we refer 
to 7084 instead of 6204?

So... as I stated initially, the above is mostly "nitpicking" and I don't 
require a re-spin of the document just for my comments sake, but if the 
document is re-spun for other reasons perhaps some of my comments could be 
taken into account?

Oh, just to be clear, I think this document is in good shape generally and 
I want it progressed.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jun 2014 09:03:02 -0400

On Jun 19, 2014, at 8:19 AM, Mikael Abrahamsson <[email-masked]> wrote:
> I decided to re-read the entire arch document frmo scratch. I have some comments. I don't mind shipping the document as-is, but I thought I'd write down my thoughts as I read the document.

The working group is not allowed to make random changes to the document at this late stage of the process.   The reason I brought this back to the working group was to address a specific point raised by an AD during IESG review.   Please do not discuss changes to other parts of the document, because it will just waste the working group's time.   If you want to do a -bis, I of course have no problem with that, but let's not discuss that now.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Jun 2014 08:37:33 +1200

On 20/06/2014 01:03, Ted Lemon wrote:
...
> Please do not discuss changes to other parts of the document, because it will just waste the working group's time.

Nevertheless, this nit Mikael noticed should be fixed:

> Since RFC6204 has been obsoleted by RFC7084, shouldn't we refer to 7084 instead of 6204? 

 Brian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jun 2014 21:25:16 -0400

>> Since RFC6204 has been obsoleted by RFC7084, shouldn't we refer to 7084 instead of 6204? 

This is something I'd expect the RFC editor to catch, but yes, sure.