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
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
