Subject: [apps-discuss] APPSDIR review of draft-ietf-homenet-arch-10

From: S Moonesamy <[email-masked]>
Date: Sat, 14 Sep 2013 17:06:52 -0700

I have been selected as the Applications Area 
Directorate reviewer for this draft (for 
background on APPSDIR, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any 
other Last Call comments you may receive. Please 
wait for direction from your document shepherd or 
AD before posting a new version of the draft.

Document: draft-ietf-homenet-arch-10
Title: Home Networking Architecture for IPv6
Reviewer: S. Moonesamy
Review Date: September 14, 2013
IETF Last Call Date: August 8, 2013
IESG Evaluation: September 26, 2013

Summary: This draft is not ready for publication as an Informational RFC.

The document defines a general architecture for 
IPv6-based home networking, describing the 
associated principles, considerations and 
requirements.  It draws parallels with IPv4 
scenarios to explain the proposed architecture to 
the reader.  There is an assumption that the IPv6 
home network runs as an IPv6-only or dual-stack network.

I am not sure whether application developers will 
be able to understand the document as it is 
written from a routing perspective.  I found the 
document confusing.  After reading the document I 
am left with a sense that it tried to solve the 
problems the working group participants could 
think about instead of taking an architectural view of IPv6 home networking.

Major issues:

I am listing these issues as major mainly for the 
attention of the Applications Area Directors.

According to RFC 1958:

   "4.2 A single naming structure should be used."

This document introduces a "Locally Qualified 
Domain Name" in Section 1.1.  Section 3.7.3 
refers to it as a "Unique Locally Qualified 
Domain Name".  There is also a mention of 
"Ambiguous Local Qualified Domain Name space" in that section.

The document mentions ".sitelocal (or an 
appropriate name reserved for the purpose)".  Quoting RFC 6761:

   "Are writers of application software expected to make their
    software recognize these names as special and treat them
    differently?  In what way?"

In Section 3.7.7:

   "Similarly the search domains for local FQDN-derived zones should
   be included."

Why is the document recommending search domains?

Minor issues:

In Section 2.6:

   "It is likely that IPv6-only networking will be deployed first in
    'greenfield' homenet scenarios, or perhaps as one element of an
    otherwise dual-stack network."

Given that this is an architectural document 
intended for a wide audience it would be clearer 
to the non-English reader to have a description instead of "greenfield".

In Section 3.2.3:

   "A general recommendation is to follow the same topology for IPv6 as
    is used for IPv4, but not to use NAT."

As a non-actionable comment, there are benefits 
to such an approach, i.e. IPv6 is like IPv4.  The 
drawback is that it may encourage an IPv4 mindset.

  "In some cases IPv4 home networks may feature cascaded NATs.  End
   users are frequently unaware that they have created such networks
   as 'home routers' and 'home switches' are frequently confused."

I don't see the relevance of the second sentence 
in a document about architecture.  The document 
has a tendency to get into IPv4 NAT details 
(first sentence).  That is odd for a document about IPv6 home networking.

In Section 3.4.1:

   'One particular situation that must be avoided is having an end site
    feel compelled to use IPv6-to-IPv6 Network Address Translation or
    other burdensome address conservation techniques because it could not
    get sufficient address space."'

The document references RFC 6177 for address 
assignments to end sites.  It then goes into the 
details of IPv6 prefix length and highlights that NPTv6 must be avoided.

   "There are many problems that would arise from a homenet not being
    offered a sufficient prefix size for its needs."

The above argues that not having an acceptable 
prefix side for the homenet can be a problem.  It 
would be easier to start with an assumption that 
the IPv6 homenet will have sufficient address space.

   "For a typical IPv6 homenet, it is not recommended that an ISP offer
    less than a /60 prefix, and it is highly preferable that the ISP
    offers at least a /56."

 From RFC 6177:

   "RFC 3177 [RFC3177] called for a default end site IPv6 assignment
    size of /48.  Subsequently, the Regional Internet Registries (RIRs)
    developed and adopted IPv6 address assignment and allocation policies
    consistent with the recommendations of RFC 3177"

What follows after that is a mention of policies 
no longer consistent with RFC 3177.  This 
document seems to be taking the same approach as 
RFC 3177 which has to be updated because of policy issues.

   "There may be cases where local law means some ISPs are required to
    change IPv6 prefixes (current IPv4 addresses) for privacy reasons for
    their customers."

In Section 3.6:

   "The most notable difference to the IPv4 operational model is the
    removal of NAT"

The following is under a "Security" heading.  I 
assumed that the stance of the IETF was that NAT does not provide security.

In Section 3.7.3:

  "Such name spaces may be acquired by the user or provided/generated
   by their ISP or an alternative cloud-based service."

What is a cloud-based service and what name space does it provide?

   "Also, with the introduction of new 'dotless' top level domains, there
    is also potential for ambiguity between, for example, a local host
    called 'computer' and (if it is registered) a .computer gTLD."

The IAB has issued a statement about "dotless 
domain considered as harmful" ( 
http://www.iab.org/2013/07/10/iab-statement-dotless-domains-considered-harmful/ 
).  I don't understand why this document 
discusses about the introduction of dotless domains.

In Section 3.7.8:

   "It is likely that some devices which have registered names within the
    homenet Internet name space and that are mobile will attach to the
    Internet at other locations and acquire an IP address at those
    locations."

What is the homenet Internet name space?  There 
is an IAB technical comment about a unique DNS Root (RFC 2826).

Nits:

I suggest fixing "This text" in the Abstract.

This review does not include other editorial nits.

I am including the review from Dave Cridland for APPSDIR:

§1 para 5: Apparently home networks are what they 
are. I admit to being easily baffled, but I 
cannot understand how they might not be what they are. Perhaps:

"We assume that the IPv4 network architecture 
currently deployed in home networks can not be 
modified by new recommendations."

In general, §1 uses a lot of the terms of art 
from §1.1, which I found quite hard to deal with 
- perhaps some of the paragraphs of §1 could be 
moved below §1.1, either as a §1.2 or something else.

§1.1

"CER" I understand as "the router"; that is, it's 
the pre-existing DSL/Cable router that's in the 
majority of home networks now, right? The term 
used elsewhere in the document is "modern home 
router", which seems obvious enough, but isn't present in the definition.

I've read through the rest of the document, it 
looks good to me (though some parts I've only skimmed).

§4 seems less of a conclusion and more of a 
summary; I'm not really sure what it's there for. 
What I was hoping to find here was a bullet point 
list of new work needed. Instead, potential new 
work items are scattered throughout the text, 
making them hard to locate and enumerate.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Thu, 19 Sep 2013 03:59:30 -0700

Hi Tim

I added Dave Cridland to the Cc so that he can 
follow up on your response to his comments.

At 16:10 18-09-2013, Tim Chown wrote:
>The document was produced with five general 
>areas in mind, which was the brief agreed by the 
>chairs after the original interim meeting in 
>Philiadelphia. Those are routing, prefix 
>configuration, name resolution, service 
>discovery, and network security.  There is thus 
>no specific consideration of applications.  That 
>said, such guidance would be very useful, and it 
>would be quite feasible to draft a separate 
>application-oriented/perspective text, including 
>expertise from apps area - would that address your concern?

The intent of my comment was not about adding 
more text, or application-specific 
considerations, to the document.  The title of 
the document is "Home Networking Architecture for 
IPv6".  My guess is that if IPv6 home networking 
takes off people, e.g. application developers, 
will look for some material to understand what it 
is about.  As this document is about the 
architecture it looks like a good starting point 
to understand the subject.  Section 1 is lengthy 
but it does not provide a concise description of 
what IPv6 home networking is about.   That 
section has some discussion about what can be 
assumed and what should not be assumed.  Section 
2 discusses about the effects of IPv6 on home 
networking.  The reader has to reach Section 3 to 
see the general principles (Page 12).  There is 
then a description of different network 
topologies.  The average or application reader 
might conclude that the document is about routing 
stuff and it is not useful to spend more time 
reading.  Please note that although the intended 
status is Informational I am reading the document 
as one intended for the standards track as it is about architecture.

The Chairs have already agreed about the five 
topics to be covered.  It's not a problem.  The 
next step would be to take these topics, make 
them accessible to the average reader, and 
organize them.  This may require avoiding too many details if it is doable.

   (a) Should effects be before principles?  Do you even need that section?

   (b) Will the application developer, for 
example, understand PI and end sites?

   (c) Does the document need seven paragraphs about ULA?

   (d) What are realms, borders and demarcation about?

   (e) What is important about prefixes?

   (f) Why have stable internal IP addresses and ULA separately?

   (g) How does naming and service discovery affect my application?

   (h) Should I assume end-to-end (with a global namespace)?

   (i) What is the security model?

Please note that the above questions are there 
mostly to look at the different from a different 
perspective.  They do not need to be answered and it is not an exhaustive list.

>There is already a split namespace for existing 
>home networks. Devices may live under .local 
>(for mDNS/DNS-SD), which has meaning on the 
>subnet in question (though some emerging vendor 
>products are proxying this through routers - 
>hence the desire to form a dnssdext WG to look 
>at that topic), and/or may use a globally unique name space.
>
>The issue in future home networks is how naming 
>and SD works across a routed, multi-link home. 
>What is the equivalent "local" name space, that 
>can be used whether the home is externally 
>connected or not, providing independent operation where necessary.
>
>That section discusses how that "local" name 
>space might look, and is the result of 
>considerable discussion in the homenet WG.
>
>Do you have something specific to propose to say instead?

 From the above I gather that the namespace issue 
is currently unresolved.  I suggest stabilizing 
the document and put the part about namespace on 
hold.  You could document the discussion for now 
and list that as unresolved issues.

>It's interesting that the dnssdext BoF pushed 
>back on tackling name space issues, and focusing 
>on service discovery, should that WG be formed. 
>But there has been plenty of discussion in the BoF(s)

That sounds like hot potato routing. :-)

>  and (old name) mdnsext list about the issues. 
> For example how names used in "local" service 
> discovery protocols might be published in a 
> global DNS name space.  One of the three 
> proposed deliverables of dnssdext would be to 
> identify and document those issues as the SD 
> work progresses.  Input from application developers would be welcome.

I suggest talking to the relevant Area Directors about the above.

>The point here is that hosts in a 
>self-configuring routed home network need to 
>learn the DNS resolvers to use. How for example 
>the leaf router determines which DNS resolvers 
>to put into RAs. There has been discussion on 
>homenet and elsewhere about how that could be 
>done, whether it might (for example) be passed 
>in the routing protocol (e.g. OSPF could support 
>it) or whether a separate protocol is 
>required.  The search domain sentence is an 
>example of other configuration information. It could be omited if prefered.

The above is what the IETF calls a chicken and 
egg problem.  I mentioned search domains because 
of RFC 1535.  Search domains are not related to 
DNS resolvers.  Even if you get information about 
DNS resolvers from your upstream you still have 
to consider the disconnected scenario (Section 3.7.5).

The document discusses about independent 
operation in Section 3.7.5 while namespace (e.g. 
Local Qualified Domain Name) is discussed in 
Section 3.7.3 (re. previous comment about 
organizing topics).  It may be easier for the 
reader if the principle is introduced before the discussion relating to it.

RFC 1123 discusses about requirements for 
Internet hosts.  There is a discussion of search 
lists in Section 6.1.4.3.  I suggest considering 
whether there is a conflict between that and the 
architecture which is being proposed, and what 
are the workable alternatives between the layer 
you are working at and the application layer.  As 
a matter of individual preference I would omit 
the search domain sentence as there isn't an 
explanation about why it should be included.

>This was a general principle agreed early on in 
>the WG, and appears to have wide consensus. The 
>sentence is in the context of a dual-stack homenet.

Ok.

>The second sentence stems from the 'support 
>arbitrary topologies' principle. Do you have 
>alternative text, or would you prefer it was 
>omited? I think we'd need to have words there to 
>suggest that the homenet user is most likely 
>unaware of the creation of internal NAT, be that 
>from introducing an IPv4 internal router, or by 
>running a VM or something similar.  So long as it "just works".

I would consider moving the text (and other IPv4 
related discussions) to an appendix.  I don't 
think that it is that important for the homenet 
user to be informed about the creation of hidden 
NATs, or being confused about home routers and 
home switches.  What you are looking at is 
cascaded NATs. Does it fit within an existing 
topology?  If the answer is yes the scenario is 
already covered.  The same applies for Virtual 
Machine Hypervisors.  RFC 4101 states that 
abstraction is good.  I think that there would be 
agreement about it "just works".  If some finer 
details can be omitted to get there I suggest 
omitting them.  My preference would be to remove the second sentence.

>There is very strong consensus in homenet 
>against introducing NPTv6. Whether that affects 
>what ISPs do is of course another question.

Ok.

>Certainly.  The above text stems from some ISPs 
>already only offering a /64. Currently some 
>offer /48, while many offer a /56. But it's too 
>early still to make any firm comment on common practices.

The above explanation is clear.  You could add 
some text and put the details in an unresolved issues.

>Well, RFC 3177 is now considered 
>obsolete.  There is strong consensus in the 
>homenet WG that the text from RFC 6177 is 
>appropriate, and I have spoken to a number of 
>ISPs about it, who seem to agree. So emphasising 
>what RFC 6177 says today seems a reasonable approach.

I'll highlight that the previous comment 
mentioned that it is to early to make a firm 
comment on common practices.  The lesson learnt 
from RFC 3177 is what people will agree to 
something now and disagree later.  The argument 
is then of a political nature.  I suggest not 
attempting to tackle assignment policies in the document.

>Of course, some countries may introduce laws or 
>regulations that make RFC 6177 hard to 
>follow.  But that shouldn't affect our document 
>on architectural principles, should it?

draft-kolkman-proposed-standards-clarified is 
also about taking care of regulatory issues.  If 
RFC 6177 was revisited it can affect this document.

>My understanding is that this was added as a result of German law.

Ok.

>It provides some security. Is there specific 
>text in 3.6 or one of its subsections that's problematic for you?

It's not problematic for me.

>That could instead say "third party service" - would that be better?

That sounds better.  The other part of the 
question was what name space does it provide.

>I don't understand why it would not mention the 
>issue. The IAB statement post-dated the (brief) 
>text in this draft. Would a reference to the IAB statement address your point?

Version -10 is dated August 1.  That is after the 
IAB statement.  My suggestion is to avoid having 
any text about 
dotless.  draft-moonesamy-dotless-domains-00 is a 
quick attempt to list the application perspective.

>The wording is clumsy here I agree. The point is 
>that some devices in the homenet may be 
>registered under the/a global name space 
>associated with the homenet, but where mobile 
>may acquire a different IP address to that 
>registered to that name in their home network. 
>Hence the next sentence and next paragraph. We 
>can rewrite that text to be clearer.

Ok.

>This document? Or…?

"This document" could be used throughout the draft.

> > I am including the review from Dave Cridland for APPSDIR:

[snip]

>Yes, it could be improved. An AD I think asked 
>if there should be a summary of 
>recommendations/principles, perhaps as an 
>appendix.  In an earlier version we had these 
>enumerated in each section, but that was undone 
>at the request of the chairs, because (I think) 
>they felt it broke the flow of the text. Do you 
>think an appendix summary (with pointers back to 
>the sections they are taken from) is desirable 
>as a form of "checklist" for readers?

I'll leave this question for Dave Cridland to answer.

Regards,
S. Moonesamy

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Sep 2013 08:55:14 -0400

On Sep 19, 2013, at 6:59 AM, S Moonesamy <[email-masked]> wrote:
> The Chairs have already agreed about the five topics to be covered.  It's not a problem.  The next step would be to take these topics, make them accessible to the average reader, and organize them.  This may require avoiding too many details if it is doable.

I think that you are interpreting this document to be something that it is not, and cannot yet be.   What this document is is an architecture for the homenet working group—a crib sheet that tells us what we are trying to accomplish.   I don't think it's intended to be something that a random person who is not implementing home gateways would find useful.   The working group is hoping that subsequent versions of this document will evolve over time, and I think it would be good for the working group to evolve the document into something that meets the goals that you've set out above.

However, I think that if the working group attempts to do that now, two things will happen.  First, the working group won't actually get to the work it's supposed to be doing, because completing the architecture document will continue to be an all-consuming effort.   Second, the document that is produced will be purely theoretical, not based on actual practice, and probably useless.

So I would like you to consider whether you can accept this restatement of the purpose of the document.   Do you feel that this document cannot be of use until it meets the goals you've set out above, or does the different purpose I've expressed here make sense to you?   If the latter, can you reconsider your review in light of this new stated purpose for the document?   Is part of the problem that the goals of the document are poorly expressed in the document?   Given the goals I've stated, do all of your comments still apply, or would you have responded differently to the document if you'd been evaluating it on the basis I'm proposing?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Sep 2013 11:31:11 -0400

Dave Cridland and I had a bit of a side conversation about this, which started out with me being a bit shirty, but eventually produced some useful output (I think) which I have included below (with Dave's permission):

On Sep 19, 2013, at 10:40 AM, Dave Cridland <[email-masked]> wrote:

> Ted Lemon wrote:
>> On Sep 19, 2013, at 10:06 AM, Dave Cridland <[email-masked]> wrote:
>>> I reiterate for you: If the IETF publishes this document as it stands,     it will look like, and be taken as, the official "Home Networking     Architecture for IPv6". Change the title (at least) to avoid this. I even     proposed alternate title texts. How much more constructive would you     like?
>> 
>> That is the goal of the document.   And that is what the document is.   The problem with your suggestions is that they propose that we give the document at title that does not describe what it is.   Perhaps a better title would be "Preliminary Home Network Architecture for IPv6."
> 
> That would work as well, I'm fine with that.
> 
> A note saying that at the time of publication, this topic was under active work by the homenet WG would be good too, but IETF tradition seems to be to avoid such things.
> 
>> But my criticism of your criticism about publishing the document stands. The point of the document is for the IETF to say "this is what we are trying to do."   It's entirely appropriate for this information to be available to the IETF as a whole, and not just to the homenet working group.   AFAIK the homenet working group has IETF consensus to do this work, and there is no competing work.   So it would IMHO be wrong for the working group to propose an architecture and not publish it—to do so would be essentially to shortcut the IETF consensus process.
> 
> There's been a few cases over the years where a document has been published knowing full well it's not complete, or that there would be a replacement within the lifetime of the working group, I know. But all the ones I can immediately think of were cases where the document could clearly provide value to people outside the IETF, and the document stood on its own.
> 
> This document is, to my eyes, borderline for this. In point of fact, you don't seem to be arguing it should be thrust in front of the noses of every TP-Link and so on; you talk above about making it available to "the IETF as a whole". I appreciate an RFC (and the publication process surrounding it) acts as a useful mechanism for internal publicity and awareness, of course, but I'd be more comfortable if this were handled by an explicit note to [email-masked] asking for cross-area review.
> 
> However, I'm certainly willing to stand in the rough here.
> 
> What I do suspect is that a number of external parties, including most particularly consumer-grade ISPs, may well read this with interest, and I think that kind of audience could use a few more hints (and less hints to the contrary) of the actual status of the document.
> 
> Sent with [inky: <http://inky.com?kme=signature>]

Hm, okay, now I think we're getting somewhere.   I think the reason the IETF should publish this is that there is no clear "outside" to the IETF—everybody is welcome.   So part of the goal of publishing it ought to be to put a stake in the sand that CPE vendors will pay attention to, and possibly criticize.   That won't happen with a working group document.   But I think you are right that it would help to be clearer about that.   Do you mind if I forward this discussion (that is, the contents of this particular email message) back to the original distribution?   I'm the one who took it private, but I don't want to presume.

---

From: S Moonesamy <[email-masked]>
Date: Thu, 19 Sep 2013 10:36:24 -0700

Hi Ted,
At 05:55 19-09-2013, Ted Lemon wrote:
>I think that you are interpreting this document 
>to be something that it is not, and cannot yet 
>be.   What this document is is an architecture 
>for the homenet working group—a crib sheet that 
>tells us what we are trying to accomplish.   I 
>don't think it's intended to be something that a 
>random person who is not implementing home 
>gateways would find useful.   The working group 
>is hoping that subsequent versions of this 
>document will evolve over time, and I think it 
>would be good for the working group to evolve 
>the document into something that meets the goals that you've set out above.

The problem may be that the document uses the 
word "architecture".  The sense I got after 
reviewing the document was that it was more of a 
requirements document instead of one about 
architecture.  I may not be implementing home 
gateways but I would still read the document to 
understand what assumptions I can make for my 
IPv6 application.  This entails understanding how 
what the working group is trying to accomplish 
affects my area of interest.  If I look at the 
document as one about requirements I'll conclude 
that there isn't anything that has an impact on application technologies.

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.

>However, I think that if the working group 
>attempts to do that now, two things will 
>happen.  First, the working group won't actually 
>get to the work it's supposed to be doing, 
>because completing the architecture document 
>will continue to be an all-consuming 
>effort.   Second, the document that is produced 
>will be purely theoretical, not based on actual practice, and probably useless.

Agreed.

That's why I emphasized the it "just works" in my 
previous comment.  I would leave it to the 
working group to make the trade-offs so that the 
document is about something that will actually 
work in practice.  I would assess the effort so 
that it does not turn into an all-consuming one.

>So I would like you to consider whether you can 
>accept this restatement of the purpose of the 
>document.   Do you feel that this document 
>cannot be of use until it meets the goals you've 
>set out above, or does the different purpose 
>I've expressed here make sense to you?   If the 
>latter, can you reconsider your review in light 
>of this new stated purpose for the 
>document?   Is part of the problem that the 
>goals of the document are poorly expressed in 
>the document?   Given the goals I've stated, do 
>all of your comments still apply, or would you 
>have responded differently to the document if 
>you'd been evaluating it on the basis I'm proposing?

I think that the document can be of use to the 
working group.  The document may not be that 
clear to people from outside the area.  I guess 
that the problem may be, as mentioned above, the 
goals of the document.  If the document is a 
(Informational) crib sheet I would rate it as good enough.

It's unfair of me to submit such a review at this 
late stage.  I have not taken into consideration 
the amount of effort involved in getting the 
draft this far.  I'll defer to the document shepherd (or you).

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Thu, 19 Sep 2013 12:34:38 -0700

Hi Ted,

At 08:31 19-09-2013, Ted Lemon wrote:

> >>> I reiterate for you: If the IETF publishes 
> this document as it stands,     it will look 
> like, and be taken as, the official "Home 
> Networking     Architecture for IPv6". Change 
> the title (at least) to avoid this. I 
> even     proposed alternate title texts. How 
> much more constructive would you     like?
> >>
> >> That is the goal of the document.   And that 
> is what the document is.   The problem with 
> your suggestions is that they propose that we 
> give the document at title that does not 
> describe what it is.   Perhaps a better title 
> would be "Preliminary Home Network Architecture for IPv6."

I like Dave's idea of having a different title 
for the draft.  The problem, to state it in 
simple terms, was "architecture".  The problem 
could be solved by using a different term, e.g. 
framework.  I would avoid "preliminary architecture" (see comment below).

> > There's been a few cases over the years where 
> a document has been published knowing full well 
> it's not complete, or that there would be a 
> replacement within the lifetime of the working 
> group, I know. But all the ones I can 
> immediately think of were cases where the 
> document could clearly provide value to people 
> outside the IETF, and the document stood on its own.

I am not keen on the idea of committing to do future work on a replacement.

> > This document is, to my eyes, borderline for 
> this. In point of fact, you don't seem to be 
> arguing it should be thrust in front of the 
> noses of every TP-Link and so on; you talk 
> above about making it available to "the IETF as 
> a whole". I appreciate an RFC (and the 
> publication process surrounding it) acts as a 
> useful mechanism for internal publicity and 
> awareness, of course, but I'd be more 
> comfortable if this were handled by an explicit 
> note to [email-masked] asking for cross-area review.

Yes.

>Hm, okay, now I think we're getting 
>somewhere.   I think the reason the IETF should 
>publish this is that there is no clear "outside" 
>to the IETF—everybody is welcome.   So part of 
>the goal of publishing it ought to be to put a 
>stake in the sand that CPE vendors will pay 
>attention to, and possibly criticize.   That 
>won't happen with a working group 
>document.   But I think you are right that it 
>would help to be clearer about that.   Do

I understand the goal and I am okay with it.

Regards,
S. Moonesamy

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Sep 2013 15:43:07 -0400

On Sep 19, 2013, at 1:36 PM, S Moonesamy <[email-masked]> 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.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Sep 2013 08:59:09 +1200

> Possibly Tim got that from your comments—I didn't.   I should probably let Tim respond rather than continuing to muddy the waters.

Reading this thread, I perceive big differences in understandings
of the scope of the document (and of the WG).

IMHO the document (and the WG) are about making the networking layer
(layer 3), and routing, work consistently in zero-management home
networks. That inevitably spills over into DNS.

The document (and the WG) are not about making the application
eco-system work consistently. That is completely absent from the WG
charter; after all, it's an Internet Area WG.

I believe the draft meets the charter goals. It's certainly a snapshot,
and should be labelled as such, but it isn't intended to stray much
outside layer 3, and shouldn't.

Whether work is need in the application eco-system for home networks
is a separate discussion.

    Brian

---

From: Pete Resnick <[email-masked]>
Date: Thu, 19 Sep 2013 16:33:33 -0500

Understand that I still haven't done my review of the document, and that 
I was the one who pushed for an APPSDIR review:

> is a separate discussion.

Let's be fair: The charter talks about tackling requirements in name 
resolution *and* service discovery. Once you get into those areas, but 
especially the latter, you're dealing with the needs of applications. 
Most of the work in this WG requires INT area expertise, but APP issues 
are inevitably going to pop up. I think to say that the draft shouldn't 
stray much outside of layer 3 is a bit naive. But since we're being 
fair: I've tried to keep an eye on things going on in homenet and to 
attend homenet meetings myself, and I've tried to encourage other 
applications folks to do so, and I've failed miserably on both counts. 
In large part, the former has been due to time and scheduling issues, 
and for the latter I clearly was unable to make the case to applications 
folks that this work *did* require cross-area review. What else is new 
in the IETF lately?

It sounds like we have a path forward for this document. But I've always 
been wary about INT groups doing things for applications without serious 
APP area input. (Lists of bad things available upon request.) Blame all 
around, including myself, for not making that situation better.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Tim Chown <[email-masked]>
Date: Thu, 19 Sep 2013 00:10:50 +0100

Hi,

Some comments in line.

On 15 Sep 2013, at 01:06, S Moonesamy <[email-masked]> wrote:

> I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).
> 
> Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.
> 
> The document defines a general architecture for IPv6-based home networking, describing the associated principles, considerations and requirements.  It draws parallels with IPv4 scenarios to explain the proposed architecture to the reader.  There is an assumption that the IPv6 home network runs as an IPv6-only or dual-stack network.
> 
> I am not sure whether application developers will be able to understand the document as it is written from a routing perspective.  I found the document confusing.  After reading the document I am left with a sense that it tried to solve the problems the working group participants could think about instead of taking an architectural view of IPv6 home networking.

The document was produced with five general areas in mind, which was the brief agreed by the chairs after the original interim meeting in Philiadelphia. Those are routing, prefix configuration, name resolution, service discovery, and network security.  There is thus no specific consideration of applications.  That said, such guidance would be very useful, and it would be quite feasible to draft a separate application-oriented/perspective text, including expertise from apps area - would that address your concern?

> Major issues:
> 
> I am listing these issues as major mainly for the attention of the Applications Area Directors.
> 
> According to RFC 1958:
> 
> This document introduces a "Locally Qualified Domain Name" in Section 1.1.  Section 3.7.3 refers to it as a "Unique Locally Qualified Domain Name".  There is also a mention of "Ambiguous Local Qualified Domain Name space" in that section.

There is already a split namespace for existing home networks. Devices may live under .local (for mDNS/DNS-SD), which has meaning on the subnet in question (though some emerging vendor products are proxying this through routers - hence the desire to form a dnssdext WG to look at that topic), and/or may use a globally unique name space.

The issue in future home networks is how naming and SD works across a routed, multi-link home. What is the equivalent "local" name space, that can be used whether the home is externally connected or not, providing independent operation where necessary.

That section discusses how that "local" name space might look, and is the result of considerable discussion in the homenet WG.

> The document mentions ".sitelocal (or an appropriate name reserved for the purpose)".  Quoting RFC 6761:
> 

It's interesting that the dnssdext BoF pushed back on tackling name space issues, and focusing on service discovery, should that WG be formed. But there has been plenty of discussion in the BoF(s) and (old name) mdnsext list about the issues. For example how names used in "local" service discovery protocols might be published in a global DNS name space.  One of the three proposed deliverables of dnssdext would be to identify and document those issues as the SD work progresses.  Input from application developers would be welcome.

> Why is the document recommending search domains?

The point here is that hosts in a self-configuring routed home network need to learn the DNS resolvers to use. How for example the leaf router determines which DNS resolvers to put into RAs. There has been discussion on homenet and elsewhere about how that could be done, whether it might (for example) be passed in the routing protocol (e.g. OSPF could support it) or whether a separate protocol is required.  The search domain sentence is an example of other configuration information. It could be omited if prefered.

> Given that this is an architectural document intended for a wide audience it would be clearer to the non-English reader to have a description instead of "greenfield".

OK.

> As a non-actionable comment, there are benefits to such an approach, i.e. IPv6 is like IPv4.  The drawback is that it may encourage an IPv4 mindset.

This was a general principle agreed early on in the WG, and appears to have wide consensus. The sentence is in the context of a dual-stack homenet.

> I don't see the relevance of the second sentence in a document about architecture.  The document has a tendency to get into IPv4 NAT details (first sentence).  That is odd for a document about IPv6 home networking.

The second sentence stems from the 'support arbitrary topologies' principle. Do you have alternative text, or would you prefer it was omited? I think we'd need to have words there to suggest that the homenet user is most likely unaware of the creation of internal NAT, be that from introducing an IPv4 internal router, or by running a VM or something similar.  So long as it "just works".

> The document references RFC 6177 for address assignments to end sites.  It then goes into the details of IPv6 prefix length and highlights that NPTv6 must be avoided.

There is very strong consensus in homenet against introducing NPTv6. Whether that affects what ISPs do is of course another question.

> The above argues that not having an acceptable prefix side for the homenet can be a problem.  It would be easier to start with an assumption that the IPv6 homenet will have sufficient address space.

Certainly.  The above text stems from some ISPs already only offering a /64. Currently some offer /48, while many offer a /56. But it's too early still to make any firm comment on common practices.

> What follows after that is a mention of policies no longer consistent with RFC 3177.  This document seems to be taking the same approach as RFC 3177 which has to be updated because of policy issues.

Well, RFC 3177 is now considered obsolete.  There is strong consensus in the homenet WG that the text from RFC 6177 is appropriate, and I have spoken to a number of ISPs about it, who seem to agree. So emphasising what RFC 6177 says today seems a reasonable approach.

Of course, some countries may introduce laws or regulations that make RFC 6177 hard to follow.  But that shouldn't affect our document on architectural principles, should it?

> The following is under a "Security" heading.  I assumed that the stance of the IETF was that NAT does not provide security.

It provides some security. Is there specific text in 3.6 or one of its subsections that's problematic for you?

> The IAB has issued a statement about "dotless domain considered as harmful" ( http://www.iab.org/2013/07/10/iab-statement-dotless-domains-considered-harmful/ ).  I don't understand why this document discusses about the introduction of dotless domains.

I don't understand why it would not mention the issue. The IAB statement post-dated the (brief) text in this draft. Would a reference to the IAB statement address your point?

> What is the homenet Internet name space?  There is an IAB technical comment about a unique DNS Root (RFC 2826).

The wording is clumsy here I agree. The point is that some devices in the homenet may be registered under the/a global name space associated with the homenet, but where mobile may acquire a different IP address to that registered to that name in their home network. Hence the next sentence and next paragraph. We can rewrite that text to be clearer.

This document? Or…?

> §1 para 5: Apparently home networks are what they are. I admit to being easily baffled, but I cannot understand how they might not be what they are. Perhaps:
> 
> "We assume that the IPv4 network architecture currently deployed in home networks can not be modified by new recommendations."

That's fine by me.

> In general, §1 uses a lot of the terms of art from §1.1, which I found quite hard to deal with - perhaps some of the paragraphs of §1 could be moved below §1.1, either as a §1.2 or something else.

Ah yes, we could do that.

> §1.1
> 
> "CER" I understand as "the router"; that is, it's the pre-existing DSL/Cable router that's in the majority of home networks now, right? The term used elsewhere in the document is "modern home router", which seems obvious enough, but isn't present in the definition.

Yes. Though I can only find one instance of "modern home router". But that can certainly be changed to CER.

> I've read through the rest of the document, it looks good to me (though some parts I've only skimmed).
> 
> §4 seems less of a conclusion and more of a summary; I'm not really sure what it's there for. What I was hoping to find here was a bullet point list of new work needed. Instead, potential new work items are scattered throughout the text, making them hard to locate and enumerate.

Yes, it could be improved. An AD I think asked if there should be a summary of recommendations/principles, perhaps as an appendix.  In an earlier version we had these enumerated in each section, but that was undone at the request of the chairs, because (I think) they felt it broke the flow of the text. Do you think an appendix summary (with pointers back to the sections they are taken from) is desirable as a form of "checklist" for readers?

Tim

---

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Sep 2013 18:04:03 +0300

> is a separate discussion.

FWIW, I agree with Brian. (And I'm speaking as an author and WG participant, not with my AD hat on.)

Jari

---

From: David Harrington <[email-masked]>
Date: Fri, 20 Sep 2013 10:20:35 -0400

Which reinforces the point that the title and intro are misleading if this
is just a temporary "snapshot of current thinking" document.

I personally am not convinced publishing this as an RFC is beneficial -
submitting for RFC publication starts a series of reviews etc. that might
effected by asking for those external reviews directly. Publishing as an
RFC, even an Informational one, tends to cast things into stone to a
degree. And this document doesn't sound ready for that step.

If the document is very clear that it is a temporary snapshot of current
thinking for the WG, maybe publishing as an RFC could be justified, but
I'M clear it meets the bar for RFC publication, even with the requested
changes to title and intro.

My $.02
--
David Harrington
[email-masked]
+1-603-828-1401

On 9/19/13 5:33 PM, "Pete Resnick" <[email-masked]> wrote:

>_______________________________________________
>homenet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/homenet

---

From: Tim Chown <[email-masked]>
Date: Fri, 20 Sep 2013 17:29:35 +0100

> 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

---

From: Tim Chown <[email-masked]>
Date: Fri, 20 Sep 2013 17:37:57 +0100

On 19 Sep 2013, at 11:59, S Moonesamy <[email-masked]> wrote:

> From the above I gather that the namespace issue is currently unresolved.  I suggest stabilizing the document and put the part about namespace on hold.  You could document the discussion for now and list that as unresolved issues.

Apologies for the grievous chop in the above included text, but I think it's worth adding here that the dnssdext proposed charter (under review by the IESG currently I believe) focuses on service discovery, and has been steered away from naming issues. It instead proposes to document the issues arising. But additionally, thanks to Toerless, the proposed charter not only talk about the networking elements of a SD solution, but also what the API would look like to application developers who may be advertising or discovering the services.

As per Mike's question today, the relationship between homenet and a potential dnssdext WG would need further clarification, but there is overlap and there are some mutual interests. 

I'll do a more detailed review of your other comments later. 

Tim

---

From: S Moonesamy <[email-masked]>
Date: Fri, 20 Sep 2013 11:27:24 -0700

Hi Tim,
At 09:37 20-09-2013, Tim Chown wrote:
>Apologies for the grievous chop in the above included text, but I 
>think it's worth adding here that the dnssdext proposed charter 
>(under review by the IESG currently I believe) focuses on service 
>discovery, and has been steered away from naming issues. It instead 
>proposes to document the issues arising. But additionally, thanks to 
>Toerless, the proposed charter not only talk about the networking 
>elements of a SD solution, but also what the API would look like to 
>application developers who may be advertising or discovering the services.
>
>As per Mike's question today, the relationship between homenet and a 
>potential dnssdext WG would need further clarification, but there is 
>overlap and there are some mutual interests.

Pete Resnick explained why the APPSDIR review was requested ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10461.html 
).  The follow-up on the review is getting more difficult as what is 
being discussed in the document is related to a working group and a 
proposed working group (dnssdext).

Please note that I am okay with your previous message (see 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10475.html 
).  Someone will have to pick a path forward and we can take it from there.

Regards,
S. Moonesamy

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Sep 2013 10:30:37 -0400

> changes to title and intro.

This is not a temporary snapshot of current thinking for the WG.   It is a specification of what we think we are trying to achieve.   It is likely that some things will be removed, and some things will be made clearer, as work progresses.   But this isn't just a strand of spaghetti cast at the wall in hopes that it will stick.

If you have specific criticisms of the document, that would be very helpful.   If you think it's going in the wrong direction, please say so, and say why.   But "I am personally not convinced that publishing this is a good idea" is the opposite of a helpful comment.   If it's not ready, please say why, not just that you think so.

---

From: Mark Townsley <[email-masked]>
Date: Mon, 23 Sep 2013 00:43:23 -0700

> FWIW, I agree with Brian. (And I'm speaking as an author and WG participant, not with my AD hat on.)

Same here. I've said many a time from the chair seat that we are working on the "plumbing", "IP" and, tongue-in-cheek a bit,  "Layer 3 plus or minus half a layer"

Of course, the network layer affects the transport layer affects the app layer, etc.  The cross area review of the IETF and IESG helps to remind us of this lest we forget. It's not just what goes on above that matters, we've had IEEE folks come in to let us know what's happening below us as well.

Ultimately though, this group is as tightly focused as we can manage to be on the Internet Area in terms of deliverables. It would be a farce to believe we had the ability to do otherwise.

- Mark

---

From: Ray Bellis <[email-masked]>
Date: Tue, 24 Sep 2013 15:54:08 +0000

On 24 Sep 2013, at 16:49, Michael Richardson <[email-masked]>
 wrote:

> 
> Tim Chown <[email-masked]> wrote:
>    tim> Do we want to spend more time now, given the desire to move ahead
>    tim> with the
>    tim> other work, restructuring the arch doc? It could be done, but I
>    tim> wonder whether
> 
> I am opposed to any restructuring.  I am in favour of two rounds of external
> tweaks.  I believe that by addressing the review now, we will avoid doing
> further work at IESG stage, and that's what the directorates are about.
> 
>    tim> And the title? Well, personally I have no emotional attachment to
>    tim> the current
>    tim> title. If the IESG were to say let's rename it "Networking
>    tim> Principles for
>    tim> Future IPv6 Home Networks" then I would lose no sleep.
> 
> That's not the name I would pick.  I think it is too weak: there is
> significant design decisions made.  We have something which is much more than
> requirements, but not quite architectural.
> 
> In *building* terms (where we think we know the waterfall process of
> architecture, civil, structure engineering, and construction planning, but
> really we are wrong. It's way more complex than we think)...
> 
> We know how many stories the building will have... but it might be that
>   putting the highest efficiency HVAC on the roof will reduce that by one.
> We know that the building will have a glass exterior, but the exact
> dimensions of the panes is not yet known, estetically and weight wise, it's
> understood, and they won't be mirrored because the neighbours won't like
> that... but there are seismic considerations, and a new city bylaw on
> mitigation of falling glass...  (to make some stuff up)

So would you consider what we have now to be a "framework" ?

Ray

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Sep 2013 12:01:03 -0400

On Sep 24, 2013, at 11:18 AM, Michael Richardson <[email-masked]> wrote:
> I believe that perhaps the title is now wrong.
> I think that it should say:
>    "Requirements for Home Networking for IPv6"
> 
> (But, it's really more than requirements. It's just less than architecture)

I previously suggested "Preliminary architecture ..."   Would that address your concern?   I don't think it's precisely a requirements document; the document does what the working group currently needs it to do, and I would hate to see us spend another couple of meeting cycles turning it into a formal requirements document unless someone can make a clear argument that doing so is necessary.

---

From: Scott Brim <[email-masked]>
Date: Tue, 24 Sep 2013 12:16:31 -0400

Architectural overview?
On Sep 24, 2013 12:02 PM, "Ted Lemon" <[email-masked]> wrote:

> I previously suggested "Preliminary architecture ..."   Would that address
> your concern?   I don't think it's precisely a requirements document; the
> document does what the working group currently needs it to do, and I would
> hate to see us spend another couple of meeting cycles turning it into a
> formal requirements document unless someone can make a clear argument that
> doing so is necessary.
>
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Sep 2013 11:04:47 +1200

> I previously suggested "Preliminary architecture ..."   Would that address your concern?   I don't think it's precisely a requirements document; the document does what the working group currently n…

Both 'framework' and 'architecture' mean different things to different
people. I could say the same about 'guidelines' too.

It doesn't matter which of these vague words we use. 'Preliminary
architecture' is fine. Just make sure that the abstract and introduction
set the reader's expectations correctly, which judging by SM's review
is not quite the case yet.

    Brian

---

From: Scott Brim <[email-masked]>
Date: Tue, 24 Sep 2013 19:08:19 -0400

I propose Architecture Overview.
On Sep 24, 2013 7:04 PM, "Brian E Carpenter" <[email-masked]>
wrote:

> > I previously suggested "Preliminary architecture ..."   Would that
> address your concern?   I don't think it's precisely a requirements
> document; the document does what the working group currently needs it to
> do, and I would hate to see us spend another couple of meeting cycles
> turning it into a formal requirements document unless someone can make a
> clear argument that doing so is necessary.
>

---

From: Claudio Allocchio <[email-masked]>
Date: Wed, 25 Sep 2013 09:47:11 +0200 (CEST)

> I propose Architecture Overview.

it's a very tricky definition to choose, but I also like more 
"Architecture Overview". +1

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Sep 2013 11:18:11 -0400

S Moonesamy <[email-masked]> wrote:
    > The intent of my comment was not about adding more text, or
    > application-specific considerations, to the document.  The title of the
    > document is "Home Networking Architecture for IPv6".  My guess is that

I think that we can't really write the architecture until we are clear
what the tradeoffsof the final consensus solution is.

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Sep 2013 11:49:39 -0400

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Sep 2013 13:22:02 -0400

> turning it into a formal requirements document unless someone can make

I agree.
It's not the document that's wrong: the document does exactly what the WG needs.
And I agree that it's not *formal* requirements.

What it is *consensus requirements".
Perhaps there is a more eloquent phrase that eludes me.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Sep 2013 13:25:01 -0400

> So would you consider what we have now to be a "framework" ?

/me makes sign of cross, reaches for wooden dagger and mutters a few hail
    mary's.

===

translation: "framework" is an evil word.  A vampire that won't die.
      I think it's content-free at this point.