Re: [homenet] I-D Action: draft-ietf-homenet-simple-naming-00.txt

[Andrew Sullivan <[e-mail]>]

Hi,

I've read
https://tools.ietf.org/html/draft-ietf-homenet-simple-naming-00.  I
have some questions & observations.  Some of these are perhaps
redundant to remarks I made at the mic at IETF 100.

In general, as I said during the adoption discussion, the aim of the
document seems a little shy of the architectural priniples.  I like
that the document now just says that it's not doing all of that.  It
seems to make a promise that the "full" version will come in the
future ("A later document will describe additional functionality"),
and I'm not totally convinced such a document will ever really achieve
consensus.  Why does this draft need to make that promise?  Moreover,
I'm not sure that the document is serious about the things that it
says it isn't going to try to do, and that is making the document
rather more complicated.  I still think this is a good start given the
constrained goals of the document.

NIT: There is a claim

   In general, the set of capabilities required to discover services on
   any network are:

that I think is a little too broad, given the list that follows.  For
instance, a different naming system might not use resource records.  I
guess this could be fixed by adding "based on DNS" or something like
that after "capabilities".

Similarly, section 1.1's discussion of getting keys to do dynamic
update seems not to consider SIG(0). Maybe it won't scale well enough,
but it surely does exist.

The local-link requirement in §3.2 feels to me like a fallback to a
previous model, but maybe I'm misunderstanding.  Aren't we supposed to
be in a world where some parts of the homenet and other parts of the
homenet are on different networks?  I guess that's the reason for the
proxy, but then the proxy must be in multiple networks?  (Maybe this
is the point of the "how" in parens?)  Also, given the "??? RCODE"
there, I wonder whether this is an example of something that really
does require some protocol extension beyond STD13 DNS?  Extended error
codes might be enough.

In §3.3, using the bootstrap domain from DHCP or DNSSL may leak the
queries to the ISP's full service resolver.  Is that ok?  Also in that
section, the third type of bootstrap domain will almost certainly
sometimes leak queries to AS112.  Is that ok?  (In both of these
cases, I'm thinking of the case where a system is configured to use
homenet but there isn't an HNR in the network.)

The discussion of DNSSEC delegations near the end of §3.3 is
confusing.  The document already says it's not going to do the DNSSEC
stuff, so I think you can leave most of that out.

In §3.4, there's a requirement that

    queries from outside of
   the homenet for any name, on or off the homenet, must be rejected
   with a REFUSED response.

Given the potential for VPNs and forwarders and so on to show up in
the homenet, I'm wondering a little bit about the practical
consequences of that "must."  I guess it doesn't matter if the names
leak because they either will work or not?

Also,

    Names
   ending in 'home.arpa' should never appear in RRDATA for names that
   are subdomains of reverse mappings for global IP addresses.

Why not?  It seems to me that you could have a homenet, numbered
entirely out of public v6 space, where there is no public DNS
delegation.  Why can't those be named inside home.arpa?  (I guess the
expectation of the ULA prefix says why not, but this feels like a
fragile assumption to me.)  The discussion of the "stable" addresses
in the next ¶ seems just irrelevant: the DNS is perfectly capable of
handling changing addresses, and does it all the time.  By the same
token, the requirement to filter out non-ULA addresses seems like it's
building a restriction that is going to make the promised, later,
complete homenet naming system much harder to deploy.

This provision

   Artificial link names will be generated using HNCP.  These should
   only be visible to the user in graphical user interfaces in the event
   that the same name is claimed by a service on two links.  Services
   that are expected to be accessed by users who type in names should
   use [12] if it is available.

seems troublesome to me.  There's a restriction that the artificial
names are only visible in GUIs (why only GUIs?  Is the command line a
GUI?), and only in case there's a collision.  How is one going to
troubleshoot this?  Also, what if [12] isn't available?  What then?

§3.5 seems to me especially troublesome for the upgrade path, because
even if you have a global name your minimal homenet is never going to
answer for it.  I think §3.6 should be removed, because the document
already says it just isn't going to support DNSSEC.



-- 
Andrew Sullivan
[e-mail]