Re: [mdnsext] Discussion of BoF during Berlin IETF

On Wed, Jun 5, 2013 at 9:42 AM, Michael Richardson <mcr+ietf@sandelman.ca>wrote:

>
> >>>>> "Albrecht," == Albrecht, Harald <harald.albrecht@siemens.com>
> writes:
>     >> -----Ursprüngliche Nachricht-----
>     >> Von: mdnsext-bounces@ietf.org [mailto:mdnsext-bounces@ietf.org] Im
>     >> Auftrag von Michael Richardson
>     >> Gesendet: Dienstag, 4. Juni 2013 15:46
>     >> An: mdnsext@ietf.org
>     >> Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF
>
>     >> I think that they are very different, and I think that we need to
> leave the
>     >> door open to that commercial enterprise networks might be ruled out
> of
>     >> bounds for mDNS.  That is, it might be that all that we wind up
> with is a way
>     >> to signal that mDNS is *not* to be used on a particular
>     >> network.   I do not believe that we have many operators of such
> networks
>     >> at IETF meetings to represent their point of view.  (I think about
> the
>     >> operators of the government networks near me... they have many
>     >> conflicting requirements, but few clues as to how to put them
> together)
>
>     Albrecht> My understanding of the ongoing discussion so far is, that
>     Albrecht> the charter is not focusing solely on mDNS as the
>     Albrecht> underlying technology only, but with a somewhat broader
>     Albrecht> scope of service discovery; thus, also including DNS for
>     Albrecht> those scenarios (use cases) where an IT infrastructure is
>     Albrecht> present. At least to some extent. My impression was that
>     Albrecht> the (pending?) renaming of the upcoming WG reflects this
>     Albrecht> situation. Or did I misunderstand this?
>
> Your understanding is correct.

> Yes, it's true that going to infrastructure DNS is useful.
>
> But, that doesn't prevent or clearly signal, that mDNS may be
> *unwelcome* on a particular network.   Enterprise folks might want to do
> that. I'm not claiming that they will, or should, succeed, btw.  I'm
> pointing out that we don't know what they want, because they don't tend
> to participate.
>
> One critical idea that I want to interject is that the list of use cases
presented
in the requirements draft (which Michael transcribed in an earlier message
on
this thread) was a *delta* beyond what is currently provided by mDNS.  The
next version will point out that the base case for mDNS is still valid.  (I
refer
to the limiting case as the "one laptop, on printer" scenario.  Substitute
"one
bulb, one switch" or whatever you like.)  The point is that mDNS
functionality
as described in RFCs 6763/6762 isn't going away anytime soon (if ever) and
is therefore available to be leveraged by sdnssd work.  We will certainly
try
to limit the multicast traffic in some of the more advanced use cases - e.g.
perhaps to locate a DNS-SD server.

On naming the WG, I think "sdnssd" contains the critical ideas of the
proposed
charter, that we're focused on a) using DNS for service discovery - not
uPNP,
HTTP, or other method, and b) that we're interested in a relatively scalable
user experience from the one laptop, one printer scenario through fully
managed
DNS.  With respect to adding "autonomous" to the mix, to me that implies
"without user intervention".  I think this might be possible for some use
cases,
e.g. multi-link residential deployments with no externally visible
services.  But
as we get into the more advanced use cases (e.g. university networks) these
will require policy or security administration.  We can certainly strive to
limit
the amount of admin necessary, but I think having "autonomous" in the WG
name is potentially as confusing as having "multicast" there.

    >> It's not that mDNS and global
>     >> DNS *services* or even protocols have difficulties co-existing.
>  They do
>     >> that just fine.   It is a question of them *interacting*.  The place
>     >> where they interact is on the *host*.
>
>     Albrecht> How true, that's where the devil is in the details. mDNS
>     Albrecht> uses UTF-8 encoding on the wire and DNS uses (at least for
>     Albrecht> host domain names) ASCII/IDNA-2008. Throw in different
>     Albrecht> resolver libs and IDNA support and you are ready for an
>     Albrecht> instant recipe disaster.
>
> I will still like someone to generate a very simple example that
illustrates the
difficulty so I can include it in the requirements draft.  It is my
understanding
that the <Instance> part of a DNS-SD name (i.e. the name of the SRV and TXT
records) can be arbitrary Net-Unicode text [RFC5198] excluding the control
chars
0x00-0x1F and 0x7F.  It is silent, so far as I can tell, on host names.  It
may be
that OS X allows UTF-8 host names, which subsequently occur in mDNS
packets...

-K-

It might be that some vendor find they have to greenfield things.
> My preference would be to stub out the libc stub resolver, and force all
> resolution to 127.0.0.1 (::1), and do all the rest.  That's already the
> case for some systems, but it has failed to become an architectural norm.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails
>    [
>
>
> _______________________________________________
> mdnsext mailing list
> mdnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/mdnsext
>
>