Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF

From: Ralph Droms <[email-masked]>
Date: Sat, 1 Jun 2013 07:32:37 -0400

On May 31, 2013, at 5:18 AM 5/31/13, Daniel Park <[email-masked]> wrote:

> Just curious why mDNS was originally developed for a single link? Any special reasons from the beginning?

Scaling - managing the amount of multicast traffic, which otherwise can become burdensome across a larger scope.

- Ralph

> 
> Soohong Daniel Park
> 
> 2013. 5. 31. 오후 12:26에 "Ralph Droms" <[email-masked]>님이 작성:
> REMINDER!!!!
> 
> I'm looking for review and discussion of the BoF proposal and draft charter here: http://www.ietf.org/mail-archive/web/mdnsext/current/msg00149.html
> 
> The mailing list has been quiet (0 responses so far).  Is there still interest in taking on this work?
> 
> - Ralph
> 
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 1 Jun 2013 13:58:00 +0000

Ralph,

Apologies for the delay, I am interested in this work and will try to read
up and send comments.  Progress here is important and I fear we are
already getting behind.

With this said I am looking forward to the meeting in Berlin and hope to
send comments shortly.

John
=========================================
John Jason Brzozowski
Comcast Cable
m) 484-962-0060
o) 609-377-6594
w) www.comcast6.net
e) [email-masked]
=========================================

-----Original Message-----
From: Ralph Droms <[email-masked]>
Date: Thursday, May 30, 2013 11:24 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF

>REMINDER!!!!
>
>I'm looking for review and discussion of the BoF proposal and draft
>charter here: 
>http://www.ietf.org/mail-archive/web/mdnsext/current/msg00149.html
>

---

From: "Brzozowski, John" <[email-masked]>
Date: Sat, 1 Jun 2013 14:07:50 +0000

I just took a quick look at the proposal as well, seems to cover most
essential areas.  I see that Zigbee was called out, it might be good to
ensure that it is clear that the home is called out as a key use case.

Peter,

Regarding your comment below what are your thought around separately
internal and external access to SD data.  Specifically I am thinking SD
within the home as alluded below can and perhaps should be autonomous.  I
think it may be useful to split up how SD is performed in a premise from
how it may be made available northbound either by a service provider or
other third party.  Separating the work can help to ensure that we move
parts of this work forward independently.

John

-----Original Message-----
From: peter van der Stok <[email-masked]>
Organization: vanderstok consultancy
Reply-To: "[email-masked]" <[email-masked]>
Date: Friday, May 31, 2013 2:24 AM
To: "[email-masked]" <[email-masked]>
Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF

>Ralph,
>
>I am certainly interested in this work and agree with the charter,
>which has improved with respect to the former version.
> From the point of view of building control, it is essential to do
>disovery on a multilink stand-alone network, and not needing to change
>the applications when the network is connected to a backbone with access
>to DNS. From the outside the resources on the now connected network
>should be visible with the same names, possibly suffixed with additional
>domain name information.
>
>In the past I have commented on the requirements and I am looking
>forward to a new version.
>
>Peter van der Stok.
>
>Ralph Droms schreef op 2013-05-31 05:24:
>> REMINDER!!!!
>>

---

From: Scott Herscher <[email-masked]>
Date: Sun, 2 Jun 2013 14:06:33 -0700

We're very interested in this work.  Collobos Software is currently in beta with an AirPrint print server product that has an embedded dns server in it for handling unicast dns-sd queries.  We are planning to build on our work to create a separate standalone product that realizes the ideas laid out in this proposal.

Scott

---

From: peter van der Stok <[email-masked]>
Date: Mon, 03 Jun 2013 10:20:06 +0200

Hi John,

Very few, naive wishes about autonomous SD data access.
The home, and also the buiding control installation, can and will be 
separated temporarily from the internet connection provided by Internet 
providers.
Having autonomous access to SD data in the home (building), with a 
painless (dis)connection to(from) the Internet provider, is one of my 
prime concerns for joining this wg.
Scalability of the SD data access inside the autonomous network (using 
a server) is equally important.

Naming inside and outside home should be consistent.

My examples:
Inside names: like mydevice.a-local-domain, where a-local-domain can be 
empty
Outside names like mydevice.a-local-domain.xs4all-given-domain.
or myhost.mydomain.my-outside-domain-name.
Possibly, the dot for specifying FQDN can be used to distinguish 
autonomous SD data from fully qualified outside data.
If local. suffix is needed, a special layer to filter out the local. to 
the application would be welcome.

Separating the work such that parts of the work are moved forward 
independently, but in mutual agreement, sounds great.

Peter

Brzozowski, John schreef op 2013-06-01 16:07:
>>> The mailing list has been quiet (0 responses so far).  Is there 
>>> still
>>> interest in taking on this work?
>>> 
>>> - Ralph
>>>

---

From: "Albrecht, Harald" <[email-masked]>
Date: Mon, 3 Jun 2013 10:15:34 +0000

Ralph, Peter,

now coming forward as I have been a lurker on this mailing list for some time. Multi-link networks without DNS infrastructure are a topic I'm also interested in; and also optionally handling hierarchical mDNS domains. I'll most probably attend the IETF 87 meeting in Berlin.

-- Harald

Siemens AG
Industry Sector
Industry Automation Division
Industrial Automation Systems
I IA AS CTO DH 1
Gleiwitzer Str. 555
90475 Nuernberg, Germany
Tel: +49  911  895-3847
Fax: +49  911  895-2105
Mobile: +49 16093785110
mailto:[email-masked]

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Peter Loescher, Chairman, President and Chief Executive Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Suess; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im
> Auftrag von peter van der Stok
> Gesendet: Freitag, 31. Mai 2013 08:24
> An: [email-masked]
> Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF
> 
> Ralph,
> 
> I am certainly interested in this work and agree with the charter, which has
> improved with respect to the former version.
>  From the point of view of building control, it is essential to do disovery on a
> multilink stand-alone network, and not needing to change the applications
> when the network is connected to a backbone with access to DNS. From the
> outside the resources on the now connected network should be visible with
> the same names, possibly suffixed with additional domain name information.
> 
> In the past I have commented on the requirements and I am looking forward
> to a new version.
> 
> Peter van der Stok.
>

---

From: Mark Townsley <[email-masked]>
Date: Mon, 3 Jun 2013 13:41:45 +0200

With my co-chair hat on, I would like to reinforce that this topic is of great importance to the homenet WG (i.e., we are chartered to solve it whether this WG exists or not). If this WG exists, there is perhaps a better chance that the homenet solution ends up with common components, usable outside of a residential solution. That would be a good thing.

- Mark

On May 22, 2013, at 7:58 PM, Ralph Droms wrote:

> After a pretty good discussion of requirements and related considerations, traffic on the mailing list has been pretty quiet.  Looking ahead to a request for a BoF in Berlin, I've updated the draft request and charter (only a little) and included them below.
> 
> What we need now is careful review and discussion of the text below, and explicit expressions of interest in the topic and support for the specific direction laid out in the BoF request and charter.
> 
> Perhaps the most obvious change I suggest is to change the name from mdnsext to sadnssd (scalable, autonomous DNS-SD).  This change follows the direction of the earlier mailing list discussion away from extensions to mDNS to higher level consideration of scalable DNS-SD.
> 
> - Ralph
> 
> BoF scheduling information:
> 
> a. Scalable, Autonomous DNS-Based Service Discovery (sadnssd)
> 
> b. Internet Area
> 
> c. Conflicts: 6man homenet dhc apparea appsawg intarea sdnrg v6ops dnsop and dnsext
> 
> d. Expected Attendance: 200 (at least 164 attended at IETF85)
> 
> e. Special requests: None
> 
> f. Number of sessions: 1
> 
> g. Length of session: 2 hours 
> 
> 
> Draft agenda:
> --------------------
> 
> 1. Administravia (Chairs, 5 mins)   
>    Note Well and agenda bashing
> 
> 2. Goals of the BoF (Chairs, 15 mins)
>    Review of IETF 85 mdsnext BoF and progress since then
> 
> 3. Requirements (Kerry Lynn, 30 mins)
>    draft-lynn-sadnssd-requirements-01
> 
> 4. Open discussion (Chairs, 40 mins)
>    Open mic; includes draft charter and deliverables
> 
> 5. Key questions (Chairs, 30 mins)
>    Are we ready to form a WG with the agreed charter, subject to mail
>      list confirmation?  
>    Note RFC5434 section 1.
> 
> 
> Draft charter:
> -------------------
> 
> Currently, zeroconf networking protocols are generally used to
> discover services within the scope of a single link. In particular,
> the Bonjour protocols suite, comprising mDNS (RFC 6762) and DNS-SD
> (RFC 6763), are widely used for discovery and resolution of services
> and names on a single link.
> 
> The Bonjour protocol suite is commonly used in many scenarios,
> including home networks, commercial and campus enterprise networks,
> and may be of use in certain mesh networks.  However, the multicast
> Bonjour protocols are constrained to link-local scope, so can only be
> used to discover services on the same link. In a typical current home
> network, which is a single link, users should experience the desired
> discovery behavior. However, in future multi-link home networks (as
> envisaged by the homenet WG) and in routed campus or enterprise
> networks, devices and thus users can only discover services on the
> same link, which is a significant limitation. Such limitations have
> led to calls, such as those by the Educause petition, to develop an
> appropriate solution to span multiple links, or to perform discovery
> across a wide area (not necessarily on directly connected links).
> 
> In addition, the ZigBee Alliance Smart Energy Profile 2.0 commercial
> standard currently under development has specified the Bonjour
> protocols as its method of zero configuration discovery. However, its
> use of wireless mesh multi-link subnets and its use across traditional
> routed networks will require extensions to the Bonjour protocols to
> allow operation across multiple links.
> 
> As demand for service discovery across wider area routed networks
> grows, some vendors are beginning to ship their own early
> solutions. It is thus both timely and important that efforts to
> develop improved, scalable, autonomous service discovery solutions for
> routed networks are coordinated towards producing a single, standards-
> based solution.
> 
> Goals
> 
> To that end, the primary goals of the sadnssd WG are as follows:
> 
> 1. To document a set of requirements for scalable, autonomous
>   DNS-based service discovery in routed, multi-link networks in the
>   following four scenarios:
> 
>    a) Commercial enterprise networks
>    b) Academic/educational/university campus networks
>    c) Multi-link home networks, such as those envisaged by the
>       HOMENET WG 
>    d) Multi-link/single subnet (mesh) networks, such as those
>       described by the ZigBee Alliance Z-IP specification
> 
> 2. To develop an improved, scalable solution for wide-area service
>   discovery that can operate in multi-link networks, applicable to
>   the scenarios above.
> 
> 3. To develop a BCP for the coexistence of zeroconf (mDNS) and unicast
>   (global DNS) name services in such multi-link networks, which
>   should include consideration of both the name resolution mechanism
>   and the namespace.
> 
> It is important that the sadnssd WG takes input from stakeholders in
> the scenarios it is considering. For example, the homenet WG is
> currently evaluating its own requirements for naming and service
> discovery; it is up to the homenet WG as to whether it wishes to
> recommend adoption of the solution developed in the mdsnext WG, and
> thus coordination between the WGs is desirable.
> 
> Deliverables
> 
> The WG will produce three documents: an Informational RFC on the
> requirements for wide-area service discovery protocols; a Standards
> Track RFC documenting a wide-area service discovery solution that is
> applicable to those scenarios; and a BCP document describing the most
> effective method to integrate mDNS and global DNS name services.
> 
> Milestones
> 
> Sep 2013 Formation of the WG
> Oct 2013 Adopt requirements draft as WG document
> Nov 2013 Submit requirements draft to the IESG as an Informational RFC
> Mar 2014 Adopt wide-area service discovery solution draft as WG
>         document 
> Mar 2014 Adopt zeroconf and unicast DNS integration BCP draft as WG
>         document 
> Sep 2014 Submit wide-area service discovery solution draft to the IESG
>         as Standards Track RFC 
> Sep 2014 Submit zeroconf and unicast DNS integration solution draft to
>         the IESG as BCP 
>

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 3 Jun 2013 08:42:57 -0400

> Very few, naive wishes about autonomous SD data access.

IMO, "autonomous" is a worthy goal but probably not attainable.
Nevertheless, any
required configuration MUST be kept to a minimum.

As an example, under DNS-SD/mDNS the user has always had the option of
choosing
a meaningful <Instance> label for a given service.  If the scope in which
this label must
be unique is too large, the task of name conflict resolution becomes more
complex.  This
may be mitigated by autonomously choosing names with a very low probability
of collision,
but these are user unfriendly.  We need to strike a balance.

> painless (dis)connection to(from) the Internet provider, is one of my prime
> concerns for joining this wg.
> Scalability of the SD data access inside the autonomous network (using a
> server) is equally important.
>
> Do you mean that the <Instance> label must be unique both locally and
within some
global DNS hierarchy?

> Inside names: like mydevice.a-local-domain, where a-local-domain can be

Certainly the issue of local TLDs must be addressed by the WG.  IMO, every
server
that is deployed today MUST continue to work under the "new" rules, which
means
that "local." is not going away anytime soon.  We can be sure beyond doubt
that this
TLD will never be assigned, but we should work with ICANN to assign a new
local
TLD for future growth.

> Outside names like mydevice.a-local-domain.**xs4all-given-domain.
> or myhost.mydomain.my-outside-**domain-name.
>

Can we stick with conventions like "example.com." for domain names?

Possibly, the dot for specifying FQDN can be used to distinguish autonomous
> SD data from fully qualified outside data.
> I don't think we can alter domain name semantics (i.e. the meaning of the
final dot '.')
without triggering a severe immune response from the DNS police.  OTOH, it
seems
as though defining new resource record types should be possible.  I've been
thinking
along the lines of a user-visible "alias" for domain names, e.g.
"foo.local." might be
made to appear in a SD browser as "Living Room".  Here it seems that mobile
devices
would need a mechanism to discover when they're on "known" networks and
probably
tailor their SD display and advertisement behavior accordingly.

> Yes, we definitely need to prioritize the requirements in order to produce
the initial
proposed standard, but also need a clear vision of future work so that we
don't limit
our options.

I am not yet certain I'll be in Berlin (lacking corporate sponsorship for
this work) but I'll
do what I can to advance the base documents and write up a -00 proposal.

Regards, -K-

>> ==============================**===========
>> John Jason Brzozowski
>> Comcast Cable
>> m) 484-962-0060
>> o) 609-377-6594
>> w) www.comcast6.net
>> e) [email-masked].**com<[email-masked]>
>> ==============================**===========
>>
>>
>>
>>
>>
>>
>>>> http://www.ietf.org/mail-**archive/web/mdnsext/current/**msg00149.html<http://www.ietf.org/mail-archive/web/mdnsext/current/msg00149.html>
>>>>
>>>> ______________________________**_________________
>>>> mdnsext mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/**listinfo/mdnsext<https://www.ietf.org/mailman/listinfo/mdnsext>
>>>>
>>> ______________________________**_________________
>>> mdnsext mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/mdnsext<https://www.ietf.org/mailman/listinfo/mdnsext>
>>>
>>
>> ______________________________**_________________
>> mdnsext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/mdnsext<https://www.ietf.org/mailman/listinfo/mdnsext>
>>
> ______________________________**_________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mdnsext<https://www.ietf.org/mailman/listinfo/mdnsext>
>

---

From: Michael Sweet <[email-masked]>
Date: Mon, 03 Jun 2013 09:40:28 -0400

Kerry,

On 2013-06-03, at 8:42 AM, Kerry Lynn <[email-masked]> wrote:
> On Mon, Jun 3, 2013 at 4:20 AM, peter van der Stok <[email-masked]> wrote:
> Hi John,
> 
> IMO, "autonomous" is a worthy goal but probably not attainable.  Nevertheless, any
> As an example, under DNS-SD/mDNS the user has always had the option of choosing
> a meaningful <Instance> label for a given service.  If the scope in which this label must
> be unique is too large, the task of name conflict resolution becomes more complex.  This
> may be mitigated by autonomously choosing names with a very low probability of collision,

One of the things we did for the latest Bonjour Printing specification (and I'm hoping that will actually get published to developer.apple.com soon) is to clarify the default instance naming for printers - by default, use a "make and model" string, e.g., "Acme Laser Printer", and if there is a collision either do the normal numbering stuff ("Acme Laser Printer N") or just add a unique identifier that is affixed to the printer - typically a serial number or the last 6 digits of the MAC address, e.g., "Acme Laser Printer (12:34:56)". Not super user-friendly, but at least something a customer can look for on the printer should they actually own two of the same printer.

In addition to showing the printer name in our UI, we also show the location (if set) or serial number (if we have it) under the name - something like the following feeble ASCII art:

    +-----------------------+
    | ACME LASER PRINTER    |     (actual name is "Acme Laser Printer (12:34:56)")
    |   (12;34:56)          |     (no location string, so we show the serial number)
    +-----------------------+
    | ACME LASER PRINTER    |     (actual name is "Acme Laser Printer (78:9A:BC)")
    |   (78:9A:BC)          |     (no location string, so we show the serial number)
    +-----------------------+
    | ACME LASER PRINTER    |     (actual name is "Acme Laser Printer (FE:DC:BA)")
    |   coffee mess         |     (location string set)
    +-----------------------+
    | ACME INKJET PRINTER   |     (actual name, no location or serial)
    +-----------------------+
    | ACME INKJET PRINTER 2 |     (actual name using numbered method)
    |   mike's desk         |     (location string set)
    +-----------------------+

And of course the customer can change the name and location strings if they wish, typically through the printer's web interface.

(Perhaps including a location key in TXT record should be encouraged/required for usability?)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: peter van der Stok <[email-masked]>
Date: Mon, 03 Jun 2013 15:44:19 +0200

Hi Kerry,

reacting to:

> under DNS-SD/mDNS the user has always had
the option of choosing

> a meaningful <Instance> label for a given
service. If the scope in

> which this label must

> be unique is too
large, the task of name conflict resolution becomes

> more complex.

<Instance> being unique within the autonomous network and
<Instance>.example.com being globally unique is enough for me.

Reacting to:

>I've been thinking 
along the lines of a user-visible
"alias" for domain names, e.g. "foo.local." might be 
made to appear in
a SD browser as "Living Room". 

or even may look like: "foo.".

Peter

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 4 Jun 2013 00:41:37 +0000

I think we are on the same page, thanks Peter.  I agree with the below and
do not disagree with the items you enumerated in your reply.

John

---

From: "Brzozowski, John" <[email-masked]>
Date: Tue, 4 Jun 2013 00:47:51 +0000

Kerry,

See below.

John
-----Original Message-----
From: Kerry Lynn <[email-masked]>
Date: Monday, June 3, 2013 8:42 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF

>required configuration MUST be kept to a minimum.
[jjmb] definitely agree to keeping configuration to a minimum.  I am not
sure I follow why autonomous is not attainable, I can envision how within
a premise data can be learned and collected while separating how the same
is made available upstream.  Am I over simplifying?
>Certainly the issue of local TLDs must be addressed by the WG.  IMO,
>every server
>that "local." is not going away anytime soon.  We can be sure beyond
>doubt that this
>Can we stick with conventions like "example.com <http://example.com>."
>for domain names?
>
>
>
>without triggering a severe immune response from the DNS police.  OTOH,
>it seems
>as though defining new resource record types should be possible.  I've
>been thinking
>made to appear in a SD browser as "Living Room".  Here it seems that
>mobile devices
>Yes, we definitely need to prioritize the requirements in order to
>produce the initial
[jjmb] I think it would be good to arrive at some consensus on this
prioritized list.
>m) 484-962-0060 <tel:484-962-0060>
>o) 609-377-6594 <tel:609-377-6594>
>w) www.comcast6.net <http://www.comcast6.net>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Jun 2013 09:45:31 -0400

{I have no travel budget to be in Berlin}

I think that the BOF proposal is very sane and very well thought out.
I question the need for a BOF at this point. I think our set of
requirements and goals is very well understood: I think that there is
enough material there to charter a WG already. 

I am pleased that the commercial enterprise networks and the
R&E campus network scenarios are broken out.  To repeat:

    a) Commercial enterprise networks ("Fortune500")
    b) Academic/educational/university campus networks (R&E)
    c) Multi-link home networks, such as those envisaged by the
       HOMENET WG 
    d) Multi-link/single subnet (mesh) networks, such as those
       described by the ZigBee Alliance Z-IP specification (LLN/LWIG)

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)

I am unconvinced that (c)HOMENET and (d)LLNs are in the same problem
space, but I also have no evidence that they aren't.  I think that there
is a scaling of complexity problem that we need to deal with here.

I am very much sure that (a)Fortune500 and (b)R&E do not share very much
in common with (c)/(d), except that the things being plugged into these
networks are from the same vendors, and that some of the devices that get
plugged in tend to travel among all these various places.

I think that 

   3. To develop a BCP for the coexistence of zeroconf (mDNS) and
   unicast (global DNS) name services in such multi-link networks, which
   should include consideration of both the name resolution mechanism
   and the namespace.

may be incomplete or even mis-guided.   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*.

We are not writing a network protocol!
We are creating a clear state machine that a host implements that takes
inputs ("replies"/"responses") from existing network protocols and acts
in deterministic and user-useful ways.

Our documents should not have time-sequence diagrams in it, assuming
that we are god and can control the other hosts.  Rather, it should have
inputs and state changes for a host, and yes, even messages to users
and/or applications about what is available.

-- 
]               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: "Albrecht, Harald" <[email-masked]>
Date: Wed, 5 Jun 2013 07:05:39 +0000

> Auftrag von Michael Richardson
> Gesendet: Dienstag, 4. Juni 2013 15:46
> An: [email-masked]

> 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

My understanding of the ongoing discussion so far is, that the charter is not focusing solely on mDNS as the underlying technology only, but with a somewhat broader scope of service discovery; thus, also including DNS for those scenarios (use cases) where an IT infrastructure is present. At least to some extent. My impression was that the (pending?) renaming of the upcoming WG reflects this situation. Or did I misunderstand this?

If we talk about the scenario a), we are most probably talking about what is also termed "IT networks", right? That is, a network for office IT? At least with respect to network policies, I know that there are quite some differences compared to networks used in production plants (manufacturing) or control networks.

> It's not that mDNS and global

How true, that's where the devil is in the details. mDNS uses UTF-8 encoding on the wire and DNS uses (at least for host domain names) ASCII/IDNA-2008. Throw in different resolver libs and IDNA support and you are ready for an instant recipe disaster.

-- Harald

> Auftrag von Michael Richardson
> Gesendet: Dienstag, 4. Juni 2013 15:46
> An: [email-masked]

> 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
> space, but I also have no evidence that they aren't.  I think that there is a
> scaling of complexity problem that we need to deal with here.
> 
> inputs ("replies"/"responses") from existing network protocols and acts in
> deterministic and user-useful ways.
> 
> Our documents should not have time-sequence diagrams in it, assuming that
> we are god and can control the other hosts.  Rather, it should have inputs
> and state changes for a host, and yes, even messages to users and/or
> applications about what is available.
> 
> 
> --

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Jun 2013 09:42:48 -0400

>>>>> "Albrecht," == Albrecht, Harald <[email-masked]> writes:

    >> 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? 

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.

    >> 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. 

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.

---

From: Kerry Lynn <[email-masked]>
Date: Fri, 7 Jun 2013 12:17:46 -0400

On Wed, Jun 5, 2013 at 9:42 AM, Michael Richardson <[email-masked]>wrote:

> Your understanding is correct.

> 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.

> 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-

---

From: David Farmer <[email-masked]>
Date: Mon, 10 Jun 2013 15:45:59 -0500

> pointing out that we don't know what they want, because they don't tend

While I wouldn't recommend general use of such a mode of operation I do 
see some special situations where I think it could be necessary, even on 
my own network, especially in networks or subnets with high security 
requirements.

More fundamentally, I would prefer to see a graceful mechanism to 
achieve this policy, rather than requiring traffic filtering or another 
blunt force mechanism to achieve such a policy.  If someone feels they 
need such a policy they will find a way.  I believe it is far better for 
the protocol to give them a way to achieve their policy goals then to 
force them to use other possibly more drastic mechanisms to achieve 
their policy goal.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 10 Jun 2013 18:28:45 -0400

On Mon, Jun 10, 2013 at 4:45 PM, David Farmer <[email-masked]> wrote:

> see some special situations where I think it could be necessary, even on my
> own network, especially in networks or subnets with high security
> requirements.
>
> More fundamentally, I would prefer to see a graceful mechanism to achieve
> this policy, rather than requiring traffic filtering or another blunt force
> mechanism to achieve such a policy.  If someone feels they need such a
> policy they will find a way.  I believe it is far better for the protocol
> to give them a way to achieve their policy goals then to force them to use
> other possibly more drastic mechanisms to achieve their policy goal.
>
> The policy goal being "black hole all FF02::FB traffic"?

-K-

>
> --
> ==============================**==================
> ==============================**==================
>

---

From: David Farmer <[email-masked]>
Date: Mon, 10 Jun 2013 18:24:30 -0500

On 6/10/13 17:28 , Kerry Lynn wrote:
> On Mon, Jun 10, 2013 at 4:45 PM, David Farmer <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     While I wouldn't recommend general use of such a mode of operation I
>     do see some special situations where I think it could be necessary,
>     even on my own network, especially in networks or subnets with high
>     security requirements.
>
>     achieve this policy, rather than requiring traffic filtering or
>     another blunt force mechanism to achieve such a policy.  If someone
>     feels they need such a policy they will find a way.  I believe it is
>     far better for the protocol to give them a way to achieve their
>     policy goals then to force them to use other possibly more drastic
>     mechanisms to achieve their policy goal.
>

I would put it slightly differently, "not allowing multicast service 
discovery."  One option could be to "black hole all FF02::FB" and 
224.0.0.251 traffic.  However, a mechanism designed into the protocol 
could be more graceful, allowing an appropriate error message to be 
returned to an application or user.  Whereas, black holing all FF02::FB 
and 224.0.0.251 traffic wouldn't generally provide a useful error 
message, other than maybe a ICMP administratively not allowed. And, only 
if the filtering device is so kind as to actually return an ICMP 
message, which is kind of rare these days unfortunately.  Most things 
that filter just black hole things these days, because "that is more 
secure", BAH!!

Also, a mechanism designed into the protocol could allow more subtle 
policies like "allowing service discovery without allowing service 
registration" with something like the hybrid draft Stuart proposed, or 
"only allowing registration of certain type of services".

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Jun 2013 20:11:00 -0400

>>>>> "David" == David Farmer <[email-masked]> writes:

    David> While I wouldn't recommend general use of such a mode of
    David> operation I do see 
    David> some special situations where I think it could be necessary,
    David> even on my own 
    David> network, especially in networks or subnets with high security
    David> requirements. 

Exactly (we are in violent agreement).
Or where having nodes "find" each other automatically is undesireable.

Do you feel you can represent the Enterprise administrator?
Do we need to reach out some other place? 

There may also be situations where multicast is harmful (heavily
congested wifi, LLNs which do not implement whatever LLN friendly mDNS
we make).

Blackholing multicast traffic may result in timeouts.

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 10 Jun 2013 22:38:55 -0400

On Mon, Jun 10, 2013 at 8:11 PM, Michael Richardson
<[email-masked]>wrote:

> The train has left the station.  There are probably millions of deployed
devices
that already exhibit DNS-SD/mDNS behavior.  How is Enterprise IT to thwart
this existing behavior (e.g. probe and announce) except by black-holing mDNS
traffic *at L2*?  I guess you could hobble the OS somehow, but you're not
going to selectively disable firmware in a printer.

> I'd put disabling existing functionality pretty far down the list of
priorities, since
the main problem seems to be how to make it work over a wider area, in more
cases.  I think the list of use cases previously mentioned run the spectrum
from
no management/no external servers to (potentially) fully managed DNS.  There
is also a spectrum of security concerns, and I will crank up a new thread
on that
topic tomorrow unless someone beats me to it.

-K-

---

From: "Albrecht, Harald" <[email-masked]>
Date: Tue, 11 Jun 2013 09:08:47 +0000

Kerry,

thank you for the clarification.

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Kerry Lynn
Gesendet: Freitag, 7. Juni 2013 18:18
An: Michael Richardson; Albrecht, Harald
Cc: [email-masked]
Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF
    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..

No problem ... at least I hope this example to be sufficient simple enough. I'm illustrating the issue for name-address resolution and not service discovery, but the underlying issue is the same. It is just that name-address resolution is more basic as we always need it and most people are more interested in it as they see immediate use.

My analysis bases on the GNU libc as one example, other implementations may differ very well (and most probably will). Code base is glib 2.17 as available from the FSF ftp servers. I tried to make sure that I did not make any (gross) mistakes in my analysis. However, caveat emptor, and if you find errors in my analysis please explain them to us so I (and maybe others) can learn.

The IDNA "theory" (at least to my understanding from reading the IDNA 2008 RFCs, which are in my opinion very well written) is as follows:
1. a user enters some internationalized domain name, for instance through a UI. Say, she enters "ship.fløtsäm" (with a nod to Peter Gabriel). We don't care about the concrete encoding here, it may be UTF-16 for instance.
2. Feed this into getaddrinfo() - now, we need to use the AI_IDN flag here. So what will happen inside getaddrinfo()?
3. We don't know at this point which specific resolver will resolve the given "ship.fløtsäm", but we have this AI_IDN flag! With glibc, getaddrinfo() (in systeps/posix/getaddrinfo.c) somehow ends up in gaih_inet(), where AI_IDN gets checked for. If it is set and a name present, then IDNA conversion takes place, where the given name in the current locale encoding gets translated into ACE: "ship.xn--fltsm-jra1l".
4. Only later comes the "hosts" lookup, that is, the call to __nss_database_lookup ("hosts",...) where the dispatch to the DNS or mDNS resolver(s) steps in. Unfortunately, we already have IDN invoked.

So what has happened here? ACE (ASCII compatible encoding) gets always invoked if the caller specifies AI_IDN. However, if mDNS is later used for resolving this is not what should have been done: mDNS specifies immediate UTF-8 encoding and not ACE. However, for DNS we need ACE. So we end up in the unfortunate situation that the application has to know in advance what resolver will be used ... but it cannot, as the domain name given may be relative. And yes, the RFCs also say that the DNS server search list is to be applied only to DNS and not mDNS. But this still doesn't help us with the problem that the application has to know whether a domain name belongs to mDNS or not.

At least according to my current (limited) understanding, something seems to be borked here... ;) Any enlightment is highly appreciated!

With best regards,
Harald

Harald Albrecht
Siemens AG
Industry Sector
Industry Automation Division
Industrial Automation Systems
I IA AS CTO DH 1
Gleiwitzer Str. 555
90475 Nürnberg, Deutschland
Tel: +49 911 895-3847
Fax: +49 911 895-2105
mailto:[email-masked]

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand: Peter Löscher, Vorsitzender; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Süß; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322

---

From: Michael Sweet <[email-masked]>
Date: Tue, 11 Jun 2013 07:55:53 -0400

Albrecht,

On 2013-06-11, at 5:08 AM, "Albrecht, Harald" <[email-masked]> wrote:
> ... 

As a user of getaddrinfo, I know for sure that the AI_IDN flag is a non-standard glibc extension.  And IMHO it is a poorly thought-out addition to the API - such decisions need to be made in the underlying resolvers (all those plugins you can specify in /etc/nsswitch.conf for "hosts") and not in the application which then needs to have a much greater understanding of which DNS is being used, etc.  The original proposal [1] gives some background on the addition, but I personally would not rely on the application asking the system to Do The Right Thing (tm).

........
[1] http://www.gnu.org/software/libidn/getaddrinfo-idn.txt

---

From: "Albrecht, Harald" <[email-masked]>
Date: Tue, 11 Jun 2013 12:08:10 +0000

Michael,

thank you very much for the clarification. What I see as a big stumbling block in service discovery usage are such architectural issues that can basically make a good idea unworkable, at least in some environments. Do you have more information as to what Microsoft does? From reading their MSDN pages I could not get a clear picture whether they are tripping into the same pit as the glibc does and I unfortunately lack some knowledge in order to fully understand what's going on in the mDNS resolver DLL. Can you provide some insight?

My impression is that the face-to-face meeting in Berlin will surely have some very interesting topics to discuss - or rather, where I hope to learn more about so I don't put forward too many dumb questions.

-- Harald

Siemens AG
Industry Sector

Von: Michael Sweet [mailto:[email-masked]]
Gesendet: Dienstag, 11. Juni 2013 13:56
An: Albrecht, Harald
Cc: [email-masked]
Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF

Albrecht,

On 2013-06-11, at 5:08 AM, "Albrecht, Harald" <[email-masked]<mailto:[email-masked]>> wrote:
...
My analysis bases on the GNU libc as one example, other implementations may differ very well (and most probably will). Code base is glib 2.17 as available from the FSF ftp servers. I tried to make sure that I did not make any (gross) mistakes in my analysis. However, caveat emptor, and if you find errors in my analysis please explain them to us so I (and maybe others) can learn.

........

---

From: David Farmer <[email-masked]>
Date: Tue, 11 Jun 2013 07:16:23 -0500

On 6/10/13 21:38 , Kerry Lynn wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
....
> cases.  I think the list of use cases previously mentioned run the
> spectrum from
> is also a spectrum of security concerns, and I will crank up a new
> thread on that

If you are saying the only solution a network operator has to 
controlling current mDNS traffic is black-holing it; Then we have to 
make what ever the new solution is work in the presence of black-holing 
of current mDNS traffic, including both registration and query of 
services.  One of the use case requirements from the educause petition 
is a non-multicast solution or at least a greatly reduced multicast 
solution, for heavily congested Wifi networks as mentioned below.

This is not the vision I would prefer, but I'm more interested in a 
workable solution than getting my way.

---

From: Michael Sweet <[email-masked]>
Date: Tue, 11 Jun 2013 11:04:05 -0400

Albrecht,

On 2013-06-11, at 8:08 AM, "Albrecht, Harald" <[email-masked]> wrote:
> Michael,
>  
> thank you very much for the clarification. What I see as a big stumbling block in service discovery usage are such architectural issues that can basically make a good idea unworkable, at least in some environments. Do you have more information as to what Microsoft does? From reading their MSDN pages I could not get a clear picture whether they are tripping into the same pit as the glibc does and I unfortunately lack some knowledge in order to fully understand what’s going on in the mDNS resolver DLL. Can you provide some insight?

From MSDN [2]:

On Windows 8 and Windows Server 2012, the getaddrinfo function provides support for IRI or Internationalized Domain Name (IDN) parsing applied to the name passed in the pNodeName parameter. Winsock performs Punycode/IDN encoding and conversion. This behavior can be disabled using the AI_DISABLE_IDN_ENCODING flag discussed below.

On Windows 7 and Windows Server 2008 R2 or earlier, the getaddrinfo function does not currently provide support for IRI or Internationalized Domain Name (IDN) parsing applied to the name passed in thepNodeName parameter. Winsock does not perform any Punycode/IDN conversion. The wide character version of the GetAddrInfo function does not convert a Unicode name to Punycode format as per RFC 3490. The wide character version of the GetAddrInfo function when querying DNS encodes the Unicode name in UTF-8 format, the format used by Microsoft DNS servers in an enterprise environment.

So for current Windows, applications automatically get the encoding applied for traditional DNS unless they specify otherwise - basically the "opt out" approach for applications that are written specifically to do their own "DNS thing".  And if I fully understand the Windows namespace provider interface :) the mDNS provider will likely just get the original, unencoded name and will be able to Do The Right Thing...  But I have to admit that I haven't tested this myself to see whether it works for real on Windows 8 (it does on Windows 7 but then IDN isn't supported directly on Windows 7...)

........

[2] http://msdn.microsoft.com/en-us/library/windows/desktop/ms738520(v=vs.85).aspx

>  
> My impression is that the face-to-face meeting in Berlin will surely have some very interesting topics to discuss – or rather, where I hope to learn more about so I don’t put forward too many dumb questions.
>  
> -- Harald
> 
> Siemens AG
> Industry Sector

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Jun 2013 13:31:31 -0400

>>>>> "David" == David Farmer <[email-masked]> writes:
    David> If you are saying the only solution a network operator has to controlling
    David> current mDNS traffic is black-holing it; Then we have to make what ever the
    David> new solution is work in the presence of black-holing of
    David> current mDNS traffic, 
    David> including both registration and query of services.  One of
    David> the use case

What David said +5.

Kerry, many **enterprises** do *not* have any mDNS traffic, because they
won't let any non-IT person plug ANYTHING in.   

Those enterprises/IT-divisions are either gonna change (and we can help them),
or they will go the way of the mainframe operators.

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 11 Jun 2013 15:39:53 -0400

On Tue, Jun 11, 2013 at 1:31 PM, Michael Richardson
<[email-masked]>wrote:

> How does an IT person disable intrinsic mDNS probing/announcing/responding
behavior in a commercial printer?  I guess those same enterprises also ban
OS X
entirely?

It seems to me that to carry this conversation forward we need to a) define
sdnssd requirements for Enterprise, which I think we've already hinted we're
not well qualified to do, and b) rank those requirements against those of
homenet and higher ed, which we arguably know much better.

I just may have gotten off on the wrong foot with this discussion,
misunderstanding
the original point.  If it was that enterprise customers do not like
excessive link-
local multicast, then I agree that one major objective of this work is to
decrease
reliance on it by e.g. introducing name caches and client libraries that
unicast
queries to them when possible.  We can't eliminate all link-local
multicasting in
general, or a number of things stop working.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Jun 2013 16:43:24 -0400

>>>>> "Kerry" == Kerry Lynn <[email-masked]> writes:
    Kerry> How does an IT person disable intrinsic mDNS probing/announcing/responding
    Kerry> behavior in a commercial printer?  I guess those same enterprises also ban
    Kerry> OS X
    Kerry> entirely?

Yes, and mDNS would be an excuse for them to continue to do so.
WINS resolution can be turned off by group policy, I'm told.

    Kerry> It seems to me that to carry this conversation forward we need to a) define
    Kerry> sdnssd requirements for Enterprise, which I think we've already hinted we're
    Kerry> not well qualified to do, and b) rank those requirements against those of
    Kerry> homenet and higher ed, which we arguably know much better.

*my* original point was that I was glad that we split off Enterprise as
a separate use case, ask if we really a clue what it might mean, and
point one at least one knob that we may need to include.

I don't think the enterprise IT-clueless people care (or even
understand) about multicast traffic. What they care about is controlling
the namespace(s) that can be seen by internal devices.