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

[S Moonesamy <[e-mail]>]

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.


> > 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?"
>
>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.


> >  "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.
>
>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.

> > Nits:
> >
> > I suggest fixing "This text" in the Abstract.
>
>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