Re: [homenet] homenet "no host changes" assumption and DNS

["STARK, BARBARA H" <[e-mail]>]

> > Currently, there is no host that expects to use .home.arpa (or any other
> domain) inside the premises.
> 
> I don't think the "or any other domain" claim is true.  At the very least, _lots_
> of hosts are already using local. in homenets -- indeed, that's how we got to
> this pass.

Yes. I should have been clearer. I meant this in the context of DNS. Though mDNS uses the same protocol semantics and Record structure as DNS, I see mDNS as a rather distinct architecture from that of DNS. Maybe I'm mistaken in looking at it that way.  I'm not aware of widespread use by hosts of local. for DNS queries. Implementations for processing (when to send, how to respond, what to do with the info) of mDNS and DNS tend to be distinct.
 
> > There is no host that expects a general-purpose in-home domain name
> system to work or be present.
> 
> That's because there is no host that "expects an in-home domain name
> system" at all.  I think your position is starting from a position with which I
> disagree pretty strongly.  

My primary position is that homenet solutions must do no harm. They must not cause people to have a worse or more  frustrating experience and must not impose cost on anyone who does not benefit from them (cause other people's experience to be worse by making one person's experience better).
My secondary position is they should create an improved user experience. And the improvement should be desirable by average people, perceived by these people to be worth the cost, and easy for these people to get.
In the context of homenet naming architecture, my position is that a solution must meet these "do no harm" and "create an improved experience" positions.

> In my view, what we did many years ago was hook
> up individual machines to an ISP's network.  When broadband home access
> came along, we continued to pretend that the link in the CPE was just a node
> in an ISP's network, and pretended that the home network was not a first-
> class network that was internetworked together with other networks to
> make the Internet.  We ended up with multiple classes of network, some of
> which are only kinda part of the Internet.

I don't understand this concept of first and second class networks. I do see a distinction between my home network and networks that participate as part of the "public" Internet (including access ISP networks). My home network is mine. I don't care whether it uses the same architectural elements as in the "public" Internet as long as it does what I want. I recently participated in writing a paper with a number of other technology people from various companies, and one thing we determined was we could not decide on a definition of "the Internet". So I don't know what definition you use. I do know that by my definition, my home network is not part of "the Internet", and I don't ever want it to be part of "the Internet". I do not want it to be assimilated. This doesn't make my home network a lower class network, IMO. It makes it a distinct and different network. I agree we have ended up with multiple networks. I disagree they are of different classes. They are, simply, different.

I've spent many years focused on understanding and meeting the needs of consumers and their home networks. I believe my view of my home network is consistent with how most people think of their home network. If you ask an average person whether their home network is part of the Internet, I believe they will say "no".
 
> The reason that homenet is being worked on in the IETF as opposed to, say,
> the Broadband Forum, is exactly that we are trying to provide
> internetworking services for these surprisingly sophisticated, unmanaged
> networks.  So to say that there's no "general-purpose in-home domain name
> system" misses the point: it's _the_ domain name system, and the homenet
> is part of that global DNS just as surely as com. is, and participates in the
> global name space just as surely as onion. and local. do.

I'm not quite sure what you mean by "global DNS" or what conclusions I should draw from this statement. AFAIK, local. is only used with mDNS (which, as I mentioned above, I consider to be distinct from DNS, in spite of using the same protocol semantics and record structures). I do know, absolutely, that I don't ever want my home network names exposed to the public Internet or resolvable by everyone "out there". I also know that I don't care how similar or dissimilar my home network naming architecture is to "global DNS", as long as it works and meets my needs. And I'm quite sure this sentiment is very much shared by regular consumers -- the target homenet deployers. 
 
> So, the reason we can't expect host changes for naming is because any plan
> for internetworking that starts, "First, upgrade all the hosts,"
> is doomed.  That hasn't worked since 1983.

I have no expectation of updating *all* hosts. But I do think it may be reasonable to expect "if a host wants to participate in the brand new homenet naming architecture, it must be updated". There's a difference between *all* hosts and a conditional set of hosts. I'm aware of many home network consumer electronics devices (TVs, Blu-ray players, etc.) that were shipped with no DNS or mDNS support at all. I'm quite sure no-one is expecting to support these devices in a homenet naming architecture. If you agree our solution doesn't have to handle hosts with neither DNS nor mDNS, then we agree the set of hosts we need to consider is conditional. We are disagreeing on what the condition is that defines the set. I predicate my conditional expectations on "must do no harm and should improve the user experience". BTW, I'm pretty sure that any HTML browser from 1983 would provide an excruciatingly bad user experience in today's Internet. I don't even think there are many browsers in use today that don't do HTML5. If the upgrade is easy, and people care (because they don't like the un-upgraded experience or because they like what the upgrade provides), then it will happen. If the feature is something people care absolutely nothing about, no-one will be incented to implement or apply the upgrade. If the feature is something people like and want, the incentive will exist on all sides. If we think no-one will care, then we shouldn't be doing this.

> > If we got rid of the "no changes to host" tenet (for hosts that can make use
> of the home naming architecture), that would give us much more freedom to
> create an in-home DNS architecture without a dependency on homenet
> routers implementing the DNS Proxy kludge. Or any other kludge. It would
> let us create an architecture that would finally start to move us away from
> DNS Proxy and other methods that intercept DNS queries to make
> supposedly "intelligent" decisions on behalf of stupid hosts. And we would
> not be further entrenching use of these DNS intercept functions.
> >
> 
> I don't understand how you can claim the above: the plain fact of the matter
> is that we have multiple domain-name-using protocols in action
> here: at the very least, mDNS, DNS, and LLMNR, and maybe Tor resolution
> and some other stuff.  If what you're saying instead is that hosts are
> supposed to know which networking context they're living in, then perhaps
> we need a radical rethinking of what we're working on.  It _might_ be the
> case that end to end is the wrong model given the kinds of things we turn
> out to be attaching to the Internet (this was part of what got discussed in the
> IAB's technical plenary last November).  But if that's what we're doing, I think
> this WG needs at the very least to go through a round of rechartering so that
> the rest of the IETF understands that we are proposing a really significant
> break with the nominal Internet architecture.  I'm not convinced that the WG
> has the patience to do such an effort, BTW.  But I think this is a pretty
> fundamental change you're proposing, and I think it would not be wrong for
> the IETF to push back pretty hard against such a change should the WG come
> out with documents that embed such an assumption.

As chair: OK. I hear you. But I'll need to understand this better.
 
> > I would like to require the hosts that want to make use of the new
> homenet naming architecture responsible for understanding the different
> provisioning domains and simultaneously launching queries to the advertised
> (or internally configured) DNS servers for each provisioning domain.
> >
> 
> DNS doesn't work that way, is the problem.  It doesn't have a mode bit.
> What you are proposing is homenet-DNS; it's a new protocol.
> Maybe that's the right answer, but I'm far from convinced that this is the
> place to create DNSbis.

I'm not proposing any changes to the DNS (or mDNS) protocol or DNS record structure. But I think what I am proposing I should put into a different email so I can describe it in more detail.
Barbara
 
> Best regards,
> 
> A
> --
> Andrew Sullivan
> [e-mail]