Subject: Re: [homenet] last call comments on section 3.7

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Mar 2013 14:58:09 -0500

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:
    Michael> 3.7.1 Service Discovery

    Michael> This section starts out with telling us how it will be
    Michael> presented to the user (GUI) without any reference to why a
    Michael> user or anything else needs service discovery.  As service
    Michael> discovery is not common on the internet today, I think this

yeah, but it is done in the home LAN right now and is quite common.
I am not sure that we need to go on at length about why we need this.

-- 
]               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 Thomas <[email-masked]>
Date: Wed, 06 Mar 2013 12:05:43 -0800

> I am not sure that we need to go on at length about why we need this.

In my experience, anything in IETF that posits some sort of UI has
already gone off the rails. As far as common, "capable of" does not
mean "used". I stand by my assertion that this needs fleshed out a
lot more, especially as it relates to the Internet and its protocols.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Mar 2013 23:32:51 -0400

I'm curious as to why Michael's comments garnered only a single reply—I think he raised some good points.   I've been reviewing the architecture document, and it's a hard read.   I think it's actually pretty good in principle, and I know that part of the reason it's so heavy is because the authors are trying to represent a plurality of opinions, including my own.

But in a lot of cases I think it would improve the document to pare it fairly heavily—to try to tease out the essence of what everyone wants, and then leave out the details of how they propose to get it.   The architecture should be what we want, not how we propose to get it.   We don't all agree on how to get it, and perhaps those questions should be addressed separately.

I can offer more detailed comments, but it would be a pretty big message, which nobody would feel enthusiastic about reading.

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Mar 2013 18:20:35 +0000

Comments in line...

On 28 Feb 2013, at 22:09, Michael Thomas <[email-masked]> wrote:

> In general, I do not think this is ready to go. From what I can see, there is
> a significant amount of disagreement about whether mdns and/or sd have a
> place in the homenet architecture, and more than a little bit of groping
> around as to what the problems are that need to be solved. This section is
> both prescriptive in ways it ought not be, and speculative in ways that an
> architecture document shouldn't be doing. I personally think that enumerating
> requirements for what any solution ought to solve for is way more important,
> but is sadly lacking in this section.

The aim of the document is to discuss the principles involved.

> I think there is an unanswered question in this wg as to whether
> naming should take a posture of how to integrate local naming into a wider
> global scope, or figuring out how to adapt globally scoped naming into a
> local context. In practical terms: whether we start with mdns and .local
> and figure out how to hack it, or do we start with DNS and figure out how
> to make it work against requirements. I will again say that the lack of
> well agreed requirements for what we're doing hinders resolving this
> question.

I don't think that needs to be dictated here.  We should be able to drive that from the principles that we can (hopefully) reach consensus on.

> 3.7.1 Service Discovery
> 
> This section starts out with telling us how it will be presented to the user (GUI)
> without any reference to why a user or anything else needs service discovery.
> As service discovery is not common on the internet today, I think this requires
> a lot more motivation/requirements before jumping and telling us that out of
> scope GUI's will come to the rescue -- it's not even clear that machine-machine
> interfaces to find and configure, say, my IP speakers to my IP home entertainment
> system won't be the norm.

Service discovery *is* common in home networks today.  Currently users see such SD via whatever GUIs they use.  But sure, the future is likely to also include device to device SD.

> Bottom line: remove the "how" and get immediately to the "why". Then we
> can have a discussion.
> 
> 3.7.2 Assigning Names
> 
> I think this can be easily rewritten to not need any informative references to yet
> to be approved drafts that are not agreed upon.

That reference to mDNS has been removed. 

> 3.7.3 Namespaces
> 
> It's not clear to me why a single namespace is "desirable". Do rebellious teenagers
> really want to be part of their fuddy-duddy parent's namespace? Does it even
> matter, architecturally? At least some motivation would be helpful. Part of my
> uncomfort here is that there is a hidden assumption that a "home" is an indivisible
> unit. Is that really true?

A fair point, a homenet realm may have its own namespace, potentially.  Or any specific device could always independently use some 3rd party dynamic DNS service.

> I'm not sure why ISP provided naming should be considered the default: we really
> don't know what will be the case, and obviously ISP's have a big downside both
> from changing ISP's, as well as the multiple-ISP's standpoint. I think that we can more
> safely say that this service is just some "cloud" service provided somewhere on the
> net since there isn't any locality requirement that I'm aware of.

Downgraded to 'likely'.

> This section dwells in solution space far more than I think it ought, and is highly
> speculative (eg, .sitelocal, ulqdn, etc). Instead of speculating, it would be better
> to say what characteristics we want, and what requirements we need to fulfill.

Trimmed a little in response.

> 3.7.4 Homenet name service
> 
> Somewhere in this document we really need to make clear how mobility figures into
> all of this. That is, what happens when things move around and what the implications
> are for naming, both in my home, and on yours.
> 
> I don't think we should compare and contrast mdns as being "zeroconf" with
> the implication that DNS is not. You can achieve "zeroconf" using service
> announcement and not require multicast at all (at least not to announce the
> service). In fact, until we have something resembling rough consensus, I don't
> really think it's appropriate to favor one or the other in this document.

I don't think the document does favour either.  
> 
> Again, ditch the references to ISP with something "cloud-like".

Good idea. Or both.

> I don't understand what mDNS has to do with service announcement to a
> repository. mDNS is a way to find names in lieu of a repository (that is, each
> device is it's own authoritative name service). Sending naming/service announcements
> to a repository is an adjunct of the repository protocols and has nothing to do
> with mDNS that I can figure out.

Well, a device in a homenet today will commonly use both unicast and multicast DNS, the former for internal devices, the latter for external.

> More speculation about mDNS vs. SRV records without any motivation of what
> is trying to be accomplished and why... it just sort of appears out of thin air here.

So the important aspect is that devices can register themselves with a name service that would typically be hosted on the CER (and secondaried elsewhere).

> I think more thought needs to be given to adding names automatically to a
> repository. It mentions that a user may choose to do so, but what if there's
> no meaningful "user" such as my IP-speakers with no UI? Should it try or not?
> (I think it ought, but that's me). More to the point: what are the implications
> of things that don't have meaningful UI's.

To be defined.  But noted.

> There should be some more discussion of the differences between a locally
> significant domain name, and a globally significant one. What happens
> when people camp on names they don't own? How might that interact with
> mobility?

Not sure what you mean here.

> More speculation about dnydns without any motivation for why it's interesting
> and/or significant.
> 
> There seems to be no mention of the relationship between local/home resolvers
> if the local resolver isn't the authoritative resolver. In particular, it's not an
> unusual situation to have a "cloud" (read: high bandwidth, well connected...)
> authoritative dns  be a slave to a local master. Or if you don't like that, some
> other way to achieve similar goals of not wanting my home network have to
> know how to deal with ddos's on nameservers, as one for-instance.

I think that's not precluded.  The key bit is the homenet must be able to operate if disconnected.

> 3.7.5 Independent Operation
> 
> I'm generally skeptical that anything these days works well when you pull
> the plug on the Internet. There are so many hidden assumptions about
> connectivity that I don't think we should try to do anything heroic here.

Sure. It's a fair goal though.

> 3.7.6 Considerations for LLN's
> 
> First I'll say that it's not just LLN's that have problems with chatty networks:
> it's anything with a battery. This should be rewritten from that perspective and
> stay away from speculation about whether proxies are needed for a particular
> technology that doesn't necessarily have consensus.
> 
> More to the point: this architecture should have considerations throughout about
> battery driven devices and their considerations, and not just whether mdns will
> cause daily trips to the store to buy new batteries.

One for Anders to comment on, perhaps...

> 3.7.7 DNS resolver discovery
> 
> I don't understand this section: is there anything we need to do beyond what
> SLAAC and/or DHCP do now? If there is, it might be nice to enumerate what
> the problem is.

This came up from Jari's own experiments.  It implies stateless DHCP is available, or that the resolver address(es) are propagated by some other means.

> ---
> Overall, section 3.7 leaves me more confused than enlightened. It reads more
> like a stream of consciousness than an architecture.

For the reason Ted has observed.  I agree it needs to be tighter, preferably.

tim

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

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Mar 2013 18:28:05 +0000

On 13 Mar 2013, at 03:32, Ted Lemon <[email-masked]> wrote:

> I'm curious as to why Michael's comments garnered only a single reply—I think he raised some good points.   

The question is whether no one agrees.  There have been previous comments that the text both in this section and in general is OK.

> I've been reviewing the architecture document, and it's a hard read.   I think it's actually pretty good in principle, and I know that part of the reason it's so heavy is because the authors are trying to represent a plurality of opinions, including my own.

I think that's fair comment as to why the document is the way it is.  It's very difficult to be concise when there are so many views and comments being made. It can be pruned further for sure if you/the chairs want that. 

I noticed when reviewing the text to see if the hipnet draft was compliant or not that it is indeed hard to spot the requirements/principles.

I asked previously if bullet-point requirements would help, but note we previously had enumerated requirements/principles (which I thought were very clear and made the text much easier to glance through) but the WG requested these were instead presented as plain text paragraphs/wording.

We could restore bullet-point notes in each section, whether numbered or not. Another option is to add some kind of summary section listing them.

> But in a lot of cases I think it would improve the document to pare it fairly heavily—to try to tease out the essence of what everyone wants, and then leave out the details of how they propose to g…

It was always agreed that the specifics pointing to 'drafts in progress' would be trimmed in the final version, along with change notes. These have been left in as 'discussion pointers' while the architecture text is live.  I've noted to removed these in the candidate -08. 

> I can offer more detailed comments, but it would be a pretty big message, which nobody would feel enthusiastic about reading.

Well, you could wait for a -08 resulting from last call, or make them now...

Tim

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 11:41:16 -0700

On 03/13/2013 11:28 AM, Tim Chown wrote:
> The question is whether no one agrees.

There are 5 authors listed on the draft, and it's been two weeks before anybody
has said a word. If the authors don't agree, they can at least say so. Otherwise
what is the point of last call comments?

Mike

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Mar 2013 14:46:51 -0400

> Well, you could wait for a -08 resulting from last call, or make them now...

I like the "wait" proposal.   If you think the idea of tightening this up is good in principle, I will send you some samples after -08 comes out and see what you think.   They may indeed fall afoul of the "but I wanted it to say X" bugaboo, but I think to some extent we need to own that, and I say that as a frequent offender myself, so you can shame me about it later if I revert to form... :)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Mar 2013 14:48:06 -0400

> what is the point of last call comments?

I think the authors can safely plead "IETF prep/travel" for this particular two-week period... :)

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 11:51:03 -0700

> I think the authors can safely plead "IETF prep/travel" for this particular two-week period... :)
If the authors and chairs didn't have the time and energy to do a last call, the
document shouldn't have been last called.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 12:24:05 -0700

> Service discovery *is* common in home networks today.  Currently users see such SD via whatever GUIs they use.  But sure, the future is likely to also include device to device SD.

Service discovery is *not* common. Only in the rarified environment of
IETF could such a statement be made with a straight face. Just because
appletalk, lan manager protocols, etc provide such functionality doesn't
mean they are in common use in homes.

In any case, this isn't responsive to the larger point that this section
doesn't provide any motivation of why SD is needed or even important,
and if it is, what the homenet requirements are.

Mike

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Mar 2013 19:27:19 +0000

> what is the point of last call comments?

The comments are being looked at, so that the key issues can be discussed here in Orlando. 

Personally, I have had a huge workload outside of the IETF for the past month.

The question is whether we have rough consensus within the WG.

Tim

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 12:31:29 -0700

> The comments are being looked at, so that the key issues can be discussed here in Orlando.

I will not be in Orlando. Discuss them here.

Mike

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Mar 2013 19:33:45 +0000

> mean they are in common use in homes.

I guess we'll have to agree to disagree there.

> and if it is, what the homenet requirements are.

The need for SD has been implicit from the start of the process.  No one else has questioned that need, as yet.  If others agree with you, it would be good if they spoke up now.

Tim

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 12:42:59 -0700

> The need for SD has been implicit from the start of the process.  No one else has questioned that need, as yet.  If others agree with you, it would be good if they spoke up now.

Is it *really* too much to ask that an architecture document make
explicit and give motivation to its requirements?

This is last call. It's where you get questioned about implicit assumptions.

Mike

---

From: Don Sturek <[email-masked]>
Date: Wed, 13 Mar 2013 12:48:21 -0700

Speaking as someone who thinks service discovery is absolutely essential,
could someone enlighten me as to how devices communicating machine to
machine would locate compatible devices to communicate with absent service
discovery?

I also don't disagree that section 3.7.1 needs better clarity on the need
for service discovery.    I think if you ask for input you will receive
plenty of text to cover this point, however.

Don

On 3/13/13 12:33 PM, "Tim Chown" <[email-masked]> wrote:

>>> Service discovery *is* common in home networks today.  Currently users
>>>see such SD via whatever GUIs they use.  But sure, the future is likely
>>>to also include device to device SD.
>> 
>The need for SD has been implicit from the start of the process.  No one
>else has questioned that need, as yet.  If others agree with you, it
>would be good if they spoke up now.
>
>Tim

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 13:01:42 -0700

> I don't think that needs to be dictated here.  We should be able to drive that from the principles that we can (hopefully) reach consensus on.

This is an architecture document: if not here, where? This is a basic
architectural issue, and deserves to be fleshed out. What is the relationship
of homenet naming to global naming?  What happens in the face of mobility?
What is the relationship of a local naming to global naming? What are the
problems that need to be resolved if local naming is used? What are the
problems that need to be resolved if global naming is used? What are the
requirements that any proposed solution needs to fulfill?

All of this is lacking in section 3.7. If I were a contractor using this "architecture"
I wouldn't know what to build.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 13:11:12 -0700

> A fair point, a homenet realm may have its own namespace, potentially.  Or any specific device could always independently use some 3rd party dynamic DNS service.

The reason I bring this up is that I don't understand why a single namespace
is "desirable". What are the implications if that is not the case? What assumedly
bad thing will happen if that's not the case? What goodness flows if it is?

If there's some hidden assumption here, it would be nice for it to be made explicit.
If there really is no motivation for this, it should just be deleted.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 13:14:24 -0700

> net since there isn't any locality requirement that I'm aware of.

Why is it "likely"? This can very easily be rewritten to be agnostic as to
who provides a global naming service for a homenet. If there isn't anything
extenuating, that is what should be done.

Mike

---

From: DOI Yusuke <[email-masked]>
Date: Thu, 14 Mar 2013 05:28:17 +0900 (JST)

Hi,

From: Tim Chown <[email-masked]>
Subject: Re: [homenet] Why do homenets need SD? (was: last call comments on section 3.7)
Date: Wed, 13 Mar 2013 19:33:45 +0000

> The need for SD has been implicit from the start of the process.  No one else has questioned that need, as yet.  If others agree with you, it would be good if they spoke up now.

Does enumeration of somewhat-SD-based home appliances help the discussion? At least I can name more than a few based on UPnP, DLNA, ECHONET, ...

Yusuke

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Mar 2013 20:48:28 +0000

> If there really is no motivation for this, it should just be deleted.

It has been reworded to "at least one". It's "desirable" in as much as not having one is highly undesirable, at least if you want remote access.

Tim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Mar 2013 16:54:11 -0400

> I wouldn't know what to build.

The architecture document acts as a basis for the work that you, as a contractor, would build from.   You can't build from an architecture document, unless you are a lot smarter than we are.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Mar 2013 16:55:42 -0400

> bad thing will happen if that's not the case? What goodness flows if it is?

If you have devices that need to be addressed outside of the homenet, then you have to have a global namespace, and of course that means a single namespace.   And if you wander to another homenet, and devices are in the same namespace, you may wind up turning up your host's (or their neighbor's) air conditioning.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 13:57:31 -0700

> It has been reworded to "at least one". It's "desirable" in as much as not having one is highly undesirable, at least if you want remote access.

Ah, one vs none, not one vs many. Ok.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Mar 2013 16:58:36 -0400

On Mar 13, 2013, at 3:24 PM, Michael Thomas <[email-masked]> wrote:
> Service discovery is *not* common.

You have never gone to a printer dialog and found your printer?   If you have ever done that, you are using service discovery.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Mar 2013 17:01:11 -0400

> extenuating, that is what should be done.

I think agnostic is good, but illustrative examples are good as well, and the two I would suggest are that the ISP provides a mechanism for naming, and that a cloud service provides a mechanism for naming.   Obviously you can also set up your own name service, but I don't think this is a good example for the use case we are trying to address.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 14:08:41 -0700

> You have never gone to a printer dialog and found your printer?   If you have ever done that, you are using service discovery.

In fact, I haven't. Or at least not since it was real NBP instead of NBPv2.

I don't have any statistics but it wouldn't shock me to hear that usb vs.
networked printers are 10:1 more common.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 14:12:13 -0700

> I think agnostic is good, but illustrative examples are good as well, and the two I would suggest are that the ISP provides a mechanism for naming, and that a cloud service provides a mechanism for…

Illustrative works for me too. The reason I push back on "ISP" is because it can
be misconstrued to have some topological and/or security necessity. Which I'm
pretty sure the authors are not intending.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Mar 2013 17:13:01 -0400

> networked printers are 10:1 more common.

It would shock me.   Bonjour printing Just Works.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 14:24:35 -0700

> If you have devices that need to be addressed outside of the homenet, then you have to have a global namespace, and of course that means a single namespace.   And if you wander to another homenet,…

And this is both orthogonal to my concern, as well as worth mentioning in
this section, I think.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 14:48:40 -0700

> Well, a device in a homenet today will commonly use both unicast and multicast DNS, the former for internal devices, the latter for external.

I'm responding in particular to:

" For a service such as mDNS to coexist with an Internet name service, where the homenet is preferably using a global domain name, it is desirable that the zeroconf devices have a way to add their names to the global name space in use. One solution could be for zeroconf protocols to be used to indicate global FQDNs, e.g. an mDNS service could return a FQDN in a SRV record."

This just doesn't make any sense to me. mDNS is typically used to do an
A/AAAA lookup. And mDNS isn't global, so it wouldn't do me much good if
I were in Brazil. So I don't think this is a solution at all, and it definitely
doesn't seem to have anything to do with mDNS. To my mind, what would
be useful is for the device to populate a repository (zeroconf or not) via
an existing or tweaked DNS protocols (ixfr?).

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 15:01:37 -0700

> Not sure what you mean here.

If I own my CER and it hosts a DNS repository and doles itself out as
the name server via slaac/dhcp, I can set my namespace up to be pretty
much whoever i'd like to be. If I want my homenet to be jethrotull.com,
I can do that even though I don't control the global name. Are there
implications for that? Might we try to convince router manufacturers
to not allow you to do that (at least easily)? What happens if my
neighbor attaches to my fake jethrotull.com? Any weirdness there?

Mike

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Mar 2013 18:14:24 -0400

> an existing or tweaked DNS protocols (ixfr?).

Stuart Cheshire has a draft describing how to populate a DNS zone using mDNS.   It's not a bad idea, although I don't think the architecture document should mention it—there is at least one other alternative, and by mentioning solely mDNS we are making a decision that I don't think has general agreement.

---

From: Ray Bellis <[email-masked]>
Date: Wed, 13 Mar 2013 22:18:55 +0000

> It would shock me.   Bonjour printing Just Works.

It's also the only way I know of to print from an iDevice.

The 2.5 year old HP B110a printer I have at home has never been physically connected to a computer.

It has "virtual USB" drivers for Windows, but for everything else it's DNS-SD.

Ray (no hat)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Mar 2013 18:19:22 -0400

On Mar 13, 2013, at 6:01 PM, Michael Thomas <[email-masked]> wrote:
> If I want my homenet to be jethrotull.com,

I guess we could do that, but it seems somewhat out of scope.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 15:28:01 -0700

> I think that's not precluded.  The key bit is the homenet must be able to operate if disconnected.

[i'm not a namedropper, so pardon me if I screw up nomenclature]

I don't think we should be adopting requirements unless they are really
"hard" requirements. Disconnected use within a homenet seems more
aspirational than hard -- there are just so many things that will puke if
the net is down, that I don't think we should worry about it.

That said,  there seems to be an assumption that the CER would be the
logical place to house a repository. I don't recall seeing any discussion
about whether it would be what the root resolvers points to. If it is,
we definitely have to think about bandwidth, DoS, etc, etc. If it's not
the preferred means (which i don't really think it is because if nothing
else, you need failover resolvers), I think we need to flesh this out a bit
more to say that, so that we can take inventory of whether the CER could
reasonably master for a cloud-based slave. Or something else... I'm not
wedded to a solution, just want to see more clarity about the problem
space.

Mike

---

From: Don Sturek <[email-masked]>
Date: Wed, 13 Mar 2013 15:39:49 -0700

Hi Mike,

I think disconnected use is a MUST and not aspirational.

I would not want my networked printer to stop working, my smart appliances
to not be able to read my meter, etc. all because my ISP decided to do
some maintenance.

Don

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 15:49:58 -0700

> to not be able to read my meter, etc. all because my ISP decided to do

Ok, let's assume it's a MUST. That seems to imply that when I'm
at home I want my CER to serve up RR's for my domain, but when
I'm away something in the cloud is serving up my RR's because
I don't want to deal with DoS against my CER, etc, etc.

I'm not a namedropper, but that doesn't sound like kosher DNS to me...
sort of a weird split horizon.

Mike

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Mar 2013 23:44:38 +0000

> pretty sure the authors are not intending.

Agreed. The "likely" comment stems from the most likely provision coming from the entity the homenet already has a relationship with by entering into a contract for connectivity.  There are opportunities for other providers to offer services in this area in the future, for sure.

Tim

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 16:47:17 -0700

> It has "virtual USB" drivers for Windows, but for everything else it's DNS-SD.

What I find most telling is that after 25 years, printers are still the canonical
example of the "need" for SD. But printers have entire programs/wizards that
support their existence, so they're really lousy as a canonical example. It would
be nice for things to attach themselves to my net and not require their awful apps
to be installed.

Mike

---

From: Mark Andrews <[email-masked]>
Date: Thu, 14 Mar 2013 10:47:52 +1100

> sort of a weird split horizon.

It is quite common for the stealth masters to exist (not listed in
the NS RRset).  It is also quite common for recursive servers to
have local copies of zones that are in use locally but not be listed
in the NS RRset.  The update protocol supports forwarding of signed
UPDATE requests where the forwarding server does NOT have the shared
secret.

homenet  <>  CER (master) <>  listed authoritative servers <> rest of the world

Now if you want this to work with the CER turned off while you are
away and update to the zone to work then protocol work is needed
to get multi-master working.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Mar 2013 23:48:10 +0000

> And this is both orthogonal to my concern, as well as worth mentioning in

Right, so that's the concern that's been aired over both homenets using .sitelocal (or similar).

I agree with Mike though that we should say "at least one global name space", as other name spaces may map to the homenet devices/prefixes.  Or you may have a homenet that (for example) has rooms with lodgers who may want to use their own name spaces in that part of the homenet.

Tim

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Mar 2013 23:50:16 +0000

> Stuart Cheshire has a draft describing how to populate a DNS zone using mDNS.   It's not a bad idea, although I don't think the architecture document should mention it—there is at least one other a…

Agreed - so the word "zeroconf" could be removed from before the word "device", which then leaves that open.

Tim

---

From: Tim Chown <[email-masked]>
Date: Wed, 13 Mar 2013 23:54:58 +0000

> I don't want to deal with DoS against my CER, etc, etc.

This is an issue discussed in the mglt-homenet-front-end-naming-delegation and mglt-homenet-naming-delegation drafts.  Though those specific references will be removed from the final text. 

If your CER is being DOSed though, chances are you may not be able to access any home services anyway?

Tim

---

From: Tim Chown <[email-masked]>
Date: Thu, 14 Mar 2013 00:09:26 +0000

> be nice for things to attach themselves to my net and not require their awful apps

So you never use music collections on other devices, videos from a video server, or throw your laptop screen to a local plasma display for easy viewing by a group?  Those are just typical examples of common uses.  The problem though is that without manual intervention you only see the services in your local subnet.

Our university pretty much only has networked printers now, as they're "managed" and thus need to be monitored by the contractor.  My homenet has two networked printers; I don't want to rely on a specific host being up to be able to print. 

Tim

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 17:10:12 -0700

> This is an issue discussed in the mglt-homenet-front-end-naming-delegation and mglt-homenet-naming-delegation drafts.  Though those specific references will be removed from the final text.

Maybe it would be better if you broke the mdns and dns into separate subsections?
It's a little hard to follow because they're two pretty different approaches and it
all gets sort of confused.

Why will they be removed? Because you don't want to reference an ID?

> If your CER is being DOSed though, chances are you may not be able to access any home services anyway?

I think the larger issue is that I'd really rather have some critical services
like DNS professionally managed and administered. I'm ok with a toy DNS
that's inward facing and thus not having to withstand frontal assaults, but
beyond that I'd rather not have to wonder if it's been patched for the newest
race that somebody finds and looses on the net...

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 17:26:52 -0700

> So you never use music collections on other devices, videos from a video server, or throw your laptop screen to a local plasma display for easy viewing by a group?  Those are just typical examples…

Nope. What do I type into with my browser to do all of that? If the answer doesn't
involve my web browser, you've most likely lost me.

We *really* have to keep in mind the lcd here.

Mike, purposeful luddite

---

From: Don Sturek <[email-masked]>
Date: Wed, 13 Mar 2013 19:51:02 -0700

Hi Michael,

What you wrote below regarding the need for an LCD and entries typed into
a web browser is not quite right.

Our commercial group (Smart Energy Profile 2 in the ZigBee Alliance) has
created well known service names (even some that incorporate unique device
identities) that allow for machine to machine service discovery (no LCDs
and no web browser entries needed).

I would expect that if we can create service name repositories that
utilize DNS-SD names, that other commercial groups can do the same.  If we
can extend this in homenet to service global service names, all the better.

Don

On 3/13/13 5:26 PM, "Michael Thomas" <[email-masked]> wrote:

>> So you never use music collections on other devices, videos from a
>>video server, or throw your laptop screen to a local plasma display for
>>easy viewing by a group?  Those are just typical examples of common
>>uses.  The problem though is that without manual intervention you only
>>see the services in your local subnet.
>

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 20:48:53 -0700

> and no web browser entries needed).

Sorry, I meant LCD == least common denominator :)

But machine-machine is definitely an interesting subject.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Mar 2013 00:23:42 -0400

> Mike, purposeful luddite

It's worth noting that we _do_ need to serve the needs of people who buy and use modern devices, not just luddites, much as we may fondly prefer to be luddites ourselves.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Mar 2013 22:49:19 -0700

> It's worth noting that we _do_ need to serve the needs of people who buy and use modern devices, not just luddites, much as we may fondly prefer to be luddites ourselves.

My point here all along is that there is no inevitability about the so-called
status quo about the way things are named on homenets. This is still in its
infancy and we should do the right thing rather than figure out how to hack
on bad solutions to make them suck less.

Mike

---

From: Ray Hunter <[email-masked]>
Date: Thu, 14 Mar 2013 08:17:55 +0100

> Stuart Cheshire has a draft describing how to populate a DNS zone using mDNS.   It's not a bad idea, although I don't think the architecture document should mention it—there is at least one other a…

FWIW I also don't think we have consensus on mDNS, nor for that matter, DNS.

I haven't yet seen a solution for naming that ticks all boxes of the
homenet architecture, so we should really avoid referring to them in the
architecture document in a way that implies that any of them have been
"selected" for homenet.

regards
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Mar 2013 08:23:36 +0000

> be nice for things to attach themselves to my net and not require their awful apps

Exactly. That's why the architecture needs SD, in a nutshell.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Mar 2013 08:43:19 +0000

> The architecture document acts as a basis for the work that you, as a contractor, would build from.   You can't build from an architecture document, unless you are a lot smarter than we are.

OK, but that doesn't mean that the *architecture* should punt on principles
of the namespace.

I'll put down a marker: local namespaces are ambiguous and therefore should
not be part of an architecture. However, there is a way to reconcile this
with pragmatic use of .local - stipulate that when a global name is needed
for a local resource, it is <name>.local.<subscriber>.<isp>.

That requires some namespace knitting but it is architecturally clean.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 14 Mar 2013 09:19:09 -0400

>>>>> "Mark" == Mark Andrews <[email-masked]> writes:
    >> I'm not a namedropper, but that doesn't sound like kosher DNS to
    >> me...  sort of a weird split horizon.

    Mark> It is quite common for the stealth masters to exist (not
    Mark> listed in the NS RRset).  It is also quite common for
    Mark> recursive servers to have local copies of zones that are in
    Mark> use locally but not be listed in the NS RRset.  The update
    Mark> protocol supports forwarding of signed UPDATE requests where
    Mark> the forwarding server does NOT have the shared secret.

    Mark> homenet <> CER (master) <> listed authoritative servers <>
    Mark> rest of the world

    Mark> Now if you want this to work with the CER turned off while you
    Mark> are away and update to the zone to work then protocol work is
    Mark> needed to get multi-master working.

I think that you are saying that there is software work, not that there is
standards work?

-- 
Michael Richardson
-on the road-

---

From: Andrew McGregor <[email-masked]>
Date: Thu, 14 Mar 2013 09:59:15 -0400

Ah, that makes much more sense.

That's true, however there are some existing solutions that partially work,
and I don't think them bad.  Limited, yes, but not bad.  So it isn't crazy
to think of extending them.

Andrew

On Thu, Mar 14, 2013 at 1:49 AM, Michael Thomas <[email-masked]> wrote:

>> It's worth noting that we _do_ need to serve the needs of people who buy
>> and use modern devices, not just luddites, much as we may fondly prefer to
>> be luddites ourselves.
>>
>
> ______________________________**_________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/homenet<https://www.ietf.org/mailman/listinfo/homenet>
>

---

From: Simon Kelley <[email-masked]>
Date: Thu, 14 Mar 2013 14:01:44 +0000

On 13/03/13 22:14, Ted Lemon wrote:

>
> Stuart Cheshire has a draft describing how to populate a DNS zone
> using mDNS.   It's not a bad idea, although I don't think the
> architecture document should mention it—there is at least one other
> alternative, and by mentioning solely mDNS we are making a decision
> that I don't think has general agreement.
>

It would be interesting to attempt to prototype this in dnsmasq. Since 
dnsmasq is already a repository for local names harvested via DHCP or 
hand-configured, mDNS is an obvious extra source of naming information.

In the latest development version dnsmasq can export that repository (ie 
act as a target for delegation, or AXFR requests) so that makes possible 
wide-area discovery of a node on a homenet which a) gets a global IPv6 
address and b) advertises itself over mDNS. There's also some basic 
domain-rewriting in there, it would be interesting to see how that could 
be generalised to the procedure described in Stuart's draft.

Simon.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 15 Mar 2013 08:09:07 +1100

In message <[email-masked]>, Michael Richardson writes:
> >>>>> "Mark" =3D=3D Mark Andrews <[email-masked]> writes:

The DNS model is a single master server.  That server can be the
CER or a master hosted elsewhere (ISP).  Both have advantages and
disadvantages.

CER hosting:
pro: the homenet is not dependent on anything external for local DNS resolution.
con: you need the CER to always be on or else you cannot update the zone when
     you are travelling.

ISP hosting:
pro: The CER can be turned off when traveling.
con: you require the local link and ISP server to be running to make changes
     to the zone.

Now for travelling we could manually switch the server roles around.

Multi-master (if defined) would do this automatically and allow for
updates to the zone when partition whether that was due to a link
failure or powering off of the CER due to travel.

This last part requires standards work as it needs to be cross vendor.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Mar 2013 14:22:23 -0700

> This last part requires standards work as it needs to be cross vendor.

Mark, I am still confused as to whether there is anything new/unimplemented
here too. If my CER, say, is the master, but my ISP runs the globally visible
NS RRset on their servers, so far so good. But if we want my CER to *also*
act as an authoritative server within my homenet so that, for example, it still
works when my ISP link is dead, is that a problem? Of is this just some configuration
voodoo that doesn't actually need standardization?

I hadn't really considered it, but your post make me realize that the opposite
scenario could happen as well: ie, the master is actually in the cloud somewhere,
and my CER is one of its slaves which, again, would play authoritative on my
homenet. Both scenarios are interesting.

Mike

---

From: Simon Kelley <[email-masked]>
Date: Thu, 14 Mar 2013 22:13:48 +0000

> homenet. Both scenarios are interesting.

Apologies if I keep dragging the topic from theory towards running code, 
but it's really worth looking at what's in dnsmasq now, since it 
supports all these modes using existing protocols and software.

Think of dnsmasq as holding a repository of local addresses. At the 
moment they are derived from DHCP leases or local configuration 
(/etc/hosts). In the future they may come from mDNS too.

Firstly, dns acts a DNS server for all the machines on the homenet. For 
names "out there" it's just a DNS proxy, but for local names it answers 
DNS queries directly. That allows local names to resolve even on a 
disconnected net.

Secondly, it acts as an authoritative DNS server fielding queries from 
the wider internet for the local names, so that they can be resolved 
anywhere, as long the relevant domain is delegated and the ISP link is up.

Thirdly, it allows slaves "in the cloud" to request zone transfers, so 
supporting the model where the CER is not directly delegated to, either 
because of worries about DoS, or because its global address in 
insufficiently stable. I have this function working, using a standard 
DynDNS.org secondary DNS account. They run BIND, as far as I know.

Simon.

I

---

From: Mark Andrews <[email-masked]>
Date: Fri, 15 Mar 2013 09:27:06 +1100

> DynDNS.org secondary DNS account. They run BIND, as far as I know.

You are missing the point.  BIND+DHCPD can do all the above too.
It is the senario described as CER hosting above.  I've been running
that at home with BIND+DHCPD since before dnsmasq existed.

What BIND, dnsmasq or any other server can't do is muti-master there
is no specification on how to do it.  DNSEXT punted this work over
decade ago.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 15 Mar 2013 09:35:57 +1100

> is no specification on how to do it.  DNSEXT punted this work over

The reason this is important to homenet and not the general enterpises
is because people turn equipement off in homes when they go on
holiday yet take their laptops and other equipment using names
linked to the homenet with them.

With enterprises these servers are always on even when everyone is
on holidays and if they do turn the site fully off they are not
expecting to update the zone while the site is shutdown.

Mark

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Mar 2013 15:37:41 -0700

> is no specification on how to do it.  DNSEXT punted this work over

I was pretty sure this scenario was really a configuration thing that
didn't require any further protocol work, but I'm still sort of bugged by
my CER answering authoritatively when it's not an authoritative server
according to the root servers. Is that legitimate? Would that cause issues
with, say, DNSSec? The CER is essentially spoofing my domain when you
come right down to it, even if that's what I want it to do.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Mar 2013 15:48:27 -0700

On 03/14/2013 03:35 PM, Mark Andrews wrote:
> The reason this is important to homenet and not the general enterpises is because people turn equipement off in homes when they go on holiday yet take their laptops and other equipment using names linked to the homenet with them. With enterprises these servers are always on even when everyone is on holidays and if they do turn the site fully off they are not expecting to update the zone while the site is shutdown. Mark 

It's why I'm hoping that this gets captured in the -arch document.

I'm still puzzling about whether it would be better for the master to
be in the cloud or in the CER though. If the cloud is the master I can
throw my CER in the trashcan and not lose anything which is a nice
property. It's also the cloud's job to make a pretty web site to manage
all of this. I trust them far more than router vendors to make useable
UI's.

On the other hand, I'd worry that trying to auto-populate a cloud master
would be more difficult from the access control perspective: my CER
can be more liberal since it can know whether a device trying to add
a name has passed access control checks on my local network, say, where
the cloud master has no clue about that (or, say, if it was on a guestnet
or whathaveyou).

There are probably a lot more considerations too. Maybe this does beg
your multi-master question?

Mike

---

From: Mark Andrews <[email-masked]>
Date: Fri, 15 Mar 2013 09:54:49 +1100

> come right down to it, even if that's what I want it to do.

Please stop using "root servers" when you mean "parent servers".
They are *not* the same.  The root servers are only parent servers
for tld.

There are authoritative servers and listed authoritative servers.
The two sets are usually the same.  When properly configured listed
authoritative servers are a subset of authoritative servers.  When
you have overlapping or disjoint sets there is a configuration
error.

Now all authoritative servers serve the same zone content modulo
zone transfer delay unless one is running a split horizon configuration.
One of the usual reasons for running split horizon is to handle RFC
1918 / ULA addresses where the public version of the zone matches
the private version of the zone with the RFC 1918 / ULA addresses
stripped out.  Doing this is straight forward with RFC 103[45] DNS.
It is a little more complicated with DNSSEC.

Mark

---

From: Michael Thomas <[email-masked]>
Date: Thu, 14 Mar 2013 16:06:34 -0700

> They are *not* the same.  The root servers are only parent servers

You're right, my bad.

> It is a little more complicated with DNSSEC.

So the bottom line is that unlisted authoritative servers are ok
even in the face of DNSSec. That's good news.

Mike

---

From: Mark Andrews <[email-masked]>
Date: Fri, 15 Mar 2013 10:18:37 +1100

> even in the face of DNSSec. That's good news.

With DNSSEC you can prove the unlisted servers are giving you good
responses.
 
The comment about difficulties with DNSSEC was with respect to split
horizon.  You can't just strip out records.  You also need to
regenerate RRSIG (as the signatures will no longer match the RRset)
and potentially generate new NSEC/NSEC3 record chains when all the
records at a name have been stripped out.  This is not impossible
to do.  BIND already strips out and regenerates all the DNSSEC data
with for certain configuration.  Stripping out additional records
would be straight forward.

Mark

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Mar 2013 10:10:33 -0400

mcr> I think that you are saying that there is software work, not that
    mcr> there is standards work?

...

    Mark> Multi-master (if defined) would do this automatically and
    Mark> allow for updates to the zone when partition whether that was
    Mark> due to a link failure or powering off of the CER due to
    Mark> travel.

    Mark> This last part requires standards work as it needs to be cross
    Mark> vendor.

Okay, so there would be standards work to do multi-master.
I thought so, but I wasn't clear.    
Are there any multi-master implementations using proprietary protocols?

I think that multi-master isn't that important for homenet.  
I think that having a stealth master for the reverse ZONE should be a MUST.
Homenet and code point of view, the important requirement would actually be:
	    CER MUST be able to be authoritative name server for
	    at least one reverse (ip6.arpa) zone, and at least one
	    forward zone.
	    CER SHOULD support zone transfers to a secondary server,
	    which SHOULD be configurable manually, and SHOULD be
	    configurable by some TBD DHCPv6 option. 
	    CER SHOULD permit NS records for zones to be configured
	    manually, and via DHCPv6 option, and SHOULD support 
	    situation where no NS record points at CER itself.

Mark the other part is the update-reverse-zone-by-TCP DNS update,
authorized by TCP.  You've talked about this.  Do you think we need a
dnsext action to permit this, or any kind of document outside of
homenet?

-- 
Michael Richardson
-on the road-

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Mar 2013 10:23:40 -0400

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:
    Michael> Mark, I am still confused as to whether there is anything
    Michael> new/unimplemented here too. If my CER, say, is the master,

probably not, but not every piece of code out there supports the
particular characteristic.  I've seen lots of web-based DNS interfaces
that did not let you enter arbitrary NS records, lest you make a
mistake.

So, homenet wants a particular configuration, and we need to write it
down.  We also need to provide for signaling from the ISP as to what
they expect.

I think that there are four situations, and ideally, I'd like eliminate
at least two:

1) home user has no FQDN, and ISP provides none.
   There is no forward zone, and there are no "remote" updates.
   It doesn't matter where the listed dns server is.
   The home user can turn off CER as they like.

2) HOME user has own FQDN and uses it.
   I think that the ISP may offer secondary service for the zone,
   or not, it would be nice to signal this in DHCPv6 somehow, but
   if we fail, that's okay.
   Listed server likely should be CER, but generally user might be
   sophisticated and override it.
   (note that this also might apply to marksandrews-home.isc.org,
   or dawsonavenue.sandelman.ca zones, where the (virtual) corporation
   has decided to extend their zone into the SOHO, so it might not be
   just ultra-geeks.
   Home user can not turn off CER if they want roaming updates.

3) ISP provides blah-blah-blah.isp.example.net for home user,
   and user has no travel cares.
   I think that in this situation the CER should be a stealth
   primary.  The ISP's DNS servers shoud be listed.
   Home user can turn off CER, because they have no cares
   about forward names.
   I put the authoritative server at CER because it makes it
   easier and I think more reliable, to update names.

4) ISP provides premium-premium-premium.isp.example.net for
   home user, and user has travel desires. 
   In this case, it might make sense for the authoritative
   server to be at the ISP, and for the CER to update it
   only using DNS-updates.
   Home user can turn off CER.

-- 
Michael Richardson
-on the road-

---

From: Michael Thomas <[email-masked]>
Date: Fri, 15 Mar 2013 11:44:37 -0700

> that did not let you enter arbitrary NS records, lest you make a

I meant protocol-wise. I don't think there's any protocols that need
to be defined/tweaked.
> I think that there are four situations, and ideally, I'd like eliminate

Can we not use "ISP"? There's no reason why it needs to be. Maybe
DNS Service Provider (DSP) or something more neutral?

>     easier and I think more reliable, to update names.

The downside here is if my CER dies or is replaced. But that may not
be enough of a downside. Perhaps we could even finagle this because
assuming that the DSP doesn't simultaneously die, we could
always do a zone transfer from it to repopulate the master's zone. I'm
not sure whether a slave would allow a master to do a zone transfer, but
that seems more like configuration than protocol?

>     Home user can turn off CER.

I'd venture to say that the requirement ought to be that my homenet
devices MUST be able to automatically (= no human intervention) be able
to add/change RR's in my domain within some policies. I  find it a little
more plausible that there is a single point of contact between my repository
(eg, the CER) and the DSP from an auth/authz standpoint.

That is:

[mike's-toothbrush]------ixfr----->[mike's cer]--------[i]xfr------>[dns service provider]

seems more tractable than:

[mike's-toothbrush]-----ixfr------>[dns provider]-----[i]xfr------->[mike's cer]

As far as the difference between #3 & #4, it seems to be whether you plan
to travel or not? I think we should always expect that CER might be down
for some protracted amount of time, if nothing else due to connectivity
problems. I'm not sure why you label #4 as "premium"? It seems to be the
same service as #3.

In Mark's parlance if I've got it right, CER would be an unlisted authoritative
server which is a master to DSP's listed authoritative servers who
are slaves to CER for my domain. I think #2 folds into this too, because even
your own vanity domain needs a secondary NS record, so the DSP could
pretty easily perform both of those roles; it's up to the DSP whether they want
to do that from a biz perspective tho.

So maybe 2, 3, and 4 can really be combined assuming we tease out the
nuances? (maybe from a doc standpoint it would be better to enumerate
them so it's more obvious).

Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 15 Mar 2013 12:05:32 -0700

> 	    configurable by some TBD DHCPv6 option.

I'm confused, is the DHCPv6 part connected in any way to the zone
transfer part? I thought the DHCP part that Simon was talking about
was to auto-populate the (master's) zone via an existing dhcp option
(and he's doing it via DHCPv4, not v6). I don't understand where DHCP
comes in with the ability to do a zone transfer to a slave.

> 	    situation where no NS record points at CER itself.

Are you saying that the CER would use the ISP's DHCP to get the
addresses of the authoritative slave servers? What if my ISP isn't
my DSP? I think we need to be careful with any such assumption.

Mike

---

From: Mark Andrews <[email-masked]>
Date: Sat, 16 Mar 2013 07:48:13 +1100

> dnsext action to permit this, or any kind of document outside of

Given the I implemented this years ago in BIND and that you can do
unauthenticated updates over TCP the answer would be no.  That said
putting this in a BCP is another matter entirely. 

Dynamic updates to the reverse zones SHOULD be done homenet equipement.
It SHOULD be possible to configure a TSIG keys (plural) to authenticate
dynamic updates of reverse zones.  TSIG keys should be used to
authenticate the update if configured.  If TSIG keys are not
configured the update SHOULD be performed over TCP not UDP.  This
is to permit the server to use the TCP connection as a weak
authentication mechanism.

The update code should check for the presence of CNAME and DNAME
records at the well know reverse names and adjust the update requests
to update the target names of the CNAME / DNAME records.  This allows
for RFC 2317 style delegations to work.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Mar 2013 14:58:38 -0400

{a short reply, but I will keep it unread, because I have more to day}

    >> So, homenet wants a particular configuration, and we need to
    >> write it down.  We also need to provide for signaling from the
    >> ISP as to what they expect.  I think that there are four
    >> situations, and ideally, I'd like eliminate at least two:

    Michael> Can we not use "ISP"? There's no reason why it needs to
    Michael> be. Maybe DNS Service Provider (DSP) or something more
    Michael> neutral?

Well, there are three possible zones involved:

1) the reverse zone.
2) an ISP specific forward one.
3) a zone the home user provides.

(1) and (2) are *ISP* specific, so I think that actually one does need
    to say ISP, and not DSP.

(3) is, I agree, not specific to an ISP.

    Michael> I'd venture to say that the requirement ought to be that my
    Michael> homenet devices MUST be able to automatically (= no human
    Michael> intervention) be able to add/change RR's in my domain
    Michael> within some policies. I find it a little more plausible

I agree.
I found the whole "people like to turn off their CER" weird.
But, that's because sandleman.ca lives at my home, and when I'm
travelling is exactly when I don't want my CER off....   but I accept
that I'm an IETF-type geek, and this protocol isn't about me.

    Michael> In Mark's parlance if I've got it right, CER would be an
    Michael> unlisted authoritative server which is a master to DSP's
    Michael> listed authoritative servers who are slaves to CER for my
    Michael> domain. I think #2 folds into this too, because even your

Yes.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Mar 2013 15:02:58 -0400

see inline

    >> configurable by some TBD DHCPv6 option.

    Michael> I'm confused, is the DHCPv6 part connected in any way to the zone
    Michael> transfer part? I thought the DHCP part that Simon was
    Michael> talking about 

What prefix under ip6.arpa to populate depends upon the DHCPv6 PD
value(s).  If we are a listed master, then we may need to do something
in DHCP to let the ISP know where our zone is (and if we have one).

If we are an unlisted master, then we may need to configure ACLs for the
listed masters to zone transfer from us, so we need DHCP to tell us.

If we are going to do DNS update, then we need in DHCP to find out where
to update to, and to establish keying material.

    >> situation where no NS record points at CER itself.

    Michael> Are you saying that the CER would use the ISP's DHCP to get the
    Michael> addresses of the authoritative slave servers? What if my ISP isn't
    Michael> my DSP? I think we need to be careful with any such assumption.

Your ISP has to be your DSP for ip6.arpa and a sub-domain of isp.example.net.
For your own FQDN, it's whatever you want, and that's why I listed
"manually".  The no NS record points at CER itself is the unlisted
master case.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Mar 2013 15:04:28 -0400

>>>>> "Mark" == Mark Andrews <[email-masked]> writes:
    Mark> It SHOULD be possible to configure a TSIG keys (plural) to authenticate
    Mark> dynamic updates of reverse zones.  TSIG keys should be used to
    Mark> authenticate the update if configured.  If TSIG keys are not
    Mark> configured the update SHOULD be performed over TCP not UDP.  This
    Mark> is to permit the server to use the TCP connection as a weak
    Mark> authentication mechanism.

    Mark> The update code should check for the presence of CNAME and DNAME
    Mark> records at the well know reverse names and adjust the update requests
    Mark> to update the target names of the CNAME / DNAME records.  This allows
    Mark> for RFC 2317 style delegations to work.

Do you expect the client to do this, or the server?
I take it that the update goes to the host listed on the SOA record for
the zone?

---

From: Michael Thomas <[email-masked]>
Date: Mon, 18 Mar 2013 12:10:47 -0700

> (1) and (2) are *ISP* specific, so I think that actually one does need

The only one specific to an ISP is 1) since *.mikeshouse.homedns.google.com is
just as valid as *.mikeshouse.homedns.comcast.net.

> that I'm an IETF-type geek, and this protocol isn't about me.

One of the advantages of the unlisted authoritative server which is a master
to the authoritative ones in the cloud is that it doesn't much matter whether
the CER is 24/7 that I'm aware of. The slaves will not stop serving the zone
if I go off to Africa for a month vacation with my CER off afaik.

But I think that turning the CER off for non-geeks will be a lot more common
in the future if we have all kinds of "servers" in the home like cams, lighting,
jukeboxen, etc, etc.

Mike

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 18 Mar 2013 12:20:14 -0700

> in DHCP to let the ISP know where our zone is (and if we have one).

The reverse map. Yes, obviously only the address space's parent owner
can delegate to us. But that is only completely true for the reverse zone.

> to update to, and to establish keying material.

Just for the reverse zone. The forward zone(s) may have nothing to do with
an ISP, and we shouldn't expect any special relationship (this was my big problem
with the Orange draft). I think it's just as likely if not more likely that non-isp's
will perform this name service for homes -- think of the data mining possibilities for
our naming being the "product".

Mike

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Mar 2013 16:03:31 -0400

>> home user, and user has travel desires.

    Michael> As far as the difference between #3 & #4, it seems to be
    Michael> whether you plan 
    Michael> to travel or not? I think we should always expect that CER
    Michael> might be down for some protracted amount of time, if
    Michael> nothing else due to connectivity problems. I'm not sure why
    Michael> you label #4 as "premium"? It seems to be the 
    Michael> same service as #3.

I'm saying that the ISP might be doing service differentiation here, and
the difference is whether or not you get name server updates when your
CER is down.

On the other hand, we could define an architecture where the ISP always
is the authoritative master, and if the Internet service is down, the
homenet has to rely on mDNS only in order to print.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Mar 2013 16:09:59 -0400

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:
    Michael> Just for the reverse zone. The forward zone(s) may have
    Michael> nothing to do with an ISP, and we shouldn't expect any
    Michael> special relationship (this was my big problem 

That's why I listed two forward cases.
1) where the ISP delegates some forward space.
2) where the home user has their own.

We have been seriously considering making strong statements that ISPs
should do #1. (but not, require the home user to use it)

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

---

From: Michael Thomas <[email-masked]>
Date: Mon, 18 Mar 2013 13:14:44 -0700

> 2) where the home user has their own.

You're missing another case: where somebody other than the ISP delegates forward
space. Or just s/ISP/DSP;

> should do #1. (but not, require the home user to use it)

Why? I mean it would be nice if they do, but SHOULD? What bad things happen
to me if I don't get to set up the reverse map? Hopefully it won't be because
everybody wants to unknowingly run a mail server all over again :)

Mike

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Mar 2013 16:19:12 -0400

Michael> Just for the reverse zone. The forward zone(s) may have
    Michael> nothing to do with an ISP, and we shouldn't expect any
    Michael> special relationship (this was my big problem That's why I
    >> listed two forward cases.

    Michael> You're missing another case: where somebody other than the
    Michael> ISP delegates forward 
    Michael> space. Or just s/ISP/DSP;

No, I haven't.
Only the ISP can delegate something in the DHCPv6.  All other cases
communicated to the CER via a manual process involving the "home user"

---

From: Michael Thomas <[email-masked]>
Date: Mon, 18 Mar 2013 13:34:15 -0700

> communicated to the CER via a manual process involving the "home user"

Assuming that there isn't any other manual steps necessary, like say, needing
keys between the CER and their DNS servers to slave for them.

In any case, that's an advantage. But if they charge $1/month for that advantage
and Google charges $0, I think people will vote with their manual input fingers.

This points at, btw, the need to actually flesh this out as to what happens between
CER and DSP.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 19 Mar 2013 13:25:06 -0700

> Exactly. That's why the architecture needs SD, in a nutshell.

I'm not terribly convinced that SD is even the whole story which is why
I have such a hard time with the short shrift the architecture document
gives it.

After my trip down to Widgetmart I dump open a bag of ip widgets,
would they self organize? Should they self-organize? Everybody here
keeps talking about zeroconf, after all. If not, what is expected of me
(the end user) in their use and/or assembly? What problems are we
trying to solve in my home? Is SD as its currently implemented by
Apple *exactly* what we want in the long  term? How do we even know
how to answer that question if the  problem/requirements aren't even
documented?

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 19 Mar 2013 13:39:12 -0700

On 03/14/2013 01:43 AM, Brian E Carpenter wrote:
> not be part of an architecture.

I agree.

> However, there is a way to reconcile this
If you had a place to hook into the global namespace, why ever use .local
at all?

Mike

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Mar 2013 13:49:31 -0700

On 3/19/2013 1:25 PM, Michael Thomas wrote:
...
> What I find most telling is that after 25 years, printers are still
> the canonical example of the "need" for SD. But printers have entire
> programs/wizards that support their existence, so they're really
> lousy as a canonical example. It would be nice for things to attach
> themselves to my net and not require their awful apps to be
> installed.

Not much else has popped up widely yet as a "shared device that needs to 
be discovered". Network-attached storage held promise to be another 
example, until "the cloud" overtook the idea.

There are plenty of other devices that are - or soon will be - useful to 
discover. E.g., thermostats, car chargers, etc. - the 'smart grid' stuff.

Joe

---

From: Jim Gettys <[email-masked]>
Date: Tue, 19 Mar 2013 18:51:53 -0400

> discover. E.g., thermostats, car chargers, etc. - the 'smart grid' stuff.

In my house, the inventory includes today:
 o two printers
 o TV set (via apple TV and Roku)
 o HiFi equipment (my new HiFi can be controlled via phone/tablet
applications; it also does streaming audio from various services)
 o I think my Blu-Ray player is also, but I've never tried.
 o Home routers (a mesh)
 o NAS box (clouds don't provide enough performance for most people, at
least yet).
 o web server on home router gateway
 o ssh services on a number of our laptops and the home server.

The following are also in the network, but are using remote web sites,
which I'm not very happy about; I'd prefer to keep these under my personal
control.
 o thermostats
 o scale

Most of these are Linux boxes under the covers (Linux dominates the CE
device space at this point); advertising a service is a trivial Avahi
configuration that it appears the mass market is already capable already of
usually doing the right thing to make services discoverable.

To make it concrete; some of the above devices are powered off atm, but
mdns-scan reports:
jg@jg-thinkpad:/var/log$ mdns-scan
+ jg-thinkpad [08:11:96:75:1d:94]._workstation._tcp.local
+ jg-thinkpad._udisks-ssh._tcp.local
+ andi-laptop [00:13:02:46:01:75]._workstation._tcp.local
+ Secure Shell on cerowrt._ssh._tcp.local
+ Web Server on cerowrt._http._tcp.local
+ Apple TV._airplay._tcp.local
+ 5855CA4A3092@Apple TV._raop._tcp.local
+ atom [90:fb:a6:85:d1:6c]._workstation._tcp.local
+ Officejet Pro L7590 [9D5AB9]._printer._tcp.local
+ Officejet Pro L7590 [9D5AB9]._http._tcp.local
+ Officejet Pro L7590 [9D5AB9]._pdl-datastream._tcp.local
Browsing ... /

What is more, it's pretty easy to configure avahi to announce services for
other devices if they don't themselves, not that I'm happy to have lots of
multicast traffic going forward.  *That* we need to tackle head-on, anyway.
                                                             - Jim

---

From: Michael Thomas <[email-masked]>
Date: Tue, 19 Mar 2013 18:23:10 -0700

>  o ssh services on a number of our laptops and the home server.

At the risk of beating a dead horse since it's been established that mdns single
handedly rescued a major corporation, I have to wonder how many *geeks*
would even know how to log into a laptop in their home with sshd listening.
I have to say that I don't.

That's sort of the problem I have with all of this: we've been conditioned for
30 years to have a monogamous relationship with DNS and now we're being
asked to have some mdns nookie on the side. And the names aren't even pretty.

Mike

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 19 Mar 2013 22:53:26 -0400

On Tue, Mar 19, 2013 at 4:25 PM, Michael Thomas <[email-masked]> wrote:

> It's a working group document.  Feel free to contribute text as well as
criticism.

-K-

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Mar 2013 08:50:07 +0000

On 19/03/2013 20:39, Michael Thomas wrote:
>>> The architecture document acts as a basis for the work that you, as a
>>> contractor, would build from.   You can't build from an architecture
>>> document, unless you are a lot smarter than we are.

No particular need, but since .local is out there already, it seems harmless.

   Brian