Subject: [mdnsext] New participant from guifi.net Community Network and the Clommunity project
From: Javi Jiménez <[email-masked]>
To: [email-masked]
Date: Fri, 11 Oct 2013 14:05:50 +0200
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <mdnsext.ietf.org>

Greetings,

Recently we got news about the WG in the mailing list of the Clommunity 
project [1] a project about building a cloud in a box for Community 
Networks. One subtask of the Clommunity project is related to the 
subject of the mdnsext mailing list. In the received message we were 
invited to participate in the current mailing list.

We'd like to present a project [2] (ddnsc) related to the pourpose of 
this working group, we're in the first developing stages of the project 
and it's an script which publishes DNS registers to a global DNS server 
using the 'nsupdate' program. At the moment it's possible to publish and 
browse services, we need to test and improve it. The work is related to 
GNU/Linux and the Avahi Zeroconf implementation.

We continue developing the idea, which is basically to publish the 
services of a Community Network in a DNS server reachable using an 
anycast address for all the distributed DNS servers, with the anycast 
address we can replicate the servers (we already replicate DNS servers 
in the CN using geographical zones), with the anycast we try to avoid 
the overloading of unique DNS servers. The services are in a particular 
subdomain, as for example 'guifi', and all the users could browse the 
services inside the Community Network.

Related to the script, have to say that security is a problem, because 
right now anyone is allowed to update the bind DNS registers 
(allow-update {any}; it's aimed for all the users who want to publish 
services), perhaps we need an ACL to only allow to publish (only) new 
services pointing to the IP which is sending the publication. Due that 
reaseon, we've not public DNS service yet, it's being worked only under 
a development environment.

We don't know if the linked code it could be useful but the linked 
project is part of current research.

The referred code is a result of various documents, meetings and working 
groups present in the references and covers it in part.

Personally I work for the "Fundació Privada per a la Xarxa Oberta, 
Lliure i Neutral guifi.net" [3] (guifi.net Foundation Network Common 
Open, Free and Neutral) Foundation about the guifi.net Community Network 
[4] with more than 22.000 nodes and we're participating in the 
Clommunity European project. I'm not representing but giving 
information, and with your permission, willing to participate in the 
mailing list discussing topics as best as I can.

Best Regards.

[1] http://clommunity-project.eu/
[2] https://github.com/javi-jimenez/ddnsc
[3] http://blogs.guifi.net/fundacio/
[4] http://guifi.net/ - English: http://guifi.net/en/node/38392

-- 
Javi Jiménez
Fundació Privada per a la Xarxa Oberta, Lliure i Neutral guifi.net

Date: Mon, 07 Oct 2013 05:46:44 +0200
From: macbroadcast <[email-masked]>
To: [email-masked]
Subject: Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

Am 03.10.2013 21:05, schrieb manning bill:
> but the "To Subscribe" pointer is busted….
>
>
> /bill

and your system time is incorrect ;)

/marc

-- 
Les enfants terribles / Marc Manthey
50823 Köln, germany
Vogelsangerstr.97
Mobile : 0049-1577-3329231
Fingerprint: B045 9750 C2CB 06C3 3782 A264 A47F 3645 0E19 8512
Website: https://let.de
Twitter: https://twitter.com/macbroadcast
Facebook: https://www.facebook.com/opencu

From: Ralph Droms <[email-masked]>
Date: Thu, 3 Oct 2013 18:09:45 -0400
To: Jaap Akkerhuis <[email-masked]>
Cc: "[email-masked] mdnsext" <[email-masked]>, Tim Chown <[email-masked]>, "<[email-masked]> Discussion" <[email-masked]>, IETF-Announce <[email-masked]>, manning bill <[email-masked]>
Subject: Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

On Oct 3, 2013, at 3:46 PM, Jaap Akkerhuis <[email-masked]> wrote:

>=20
>    but the "To Subscribe" pointer is busted.
>=20
> According to <https://www.ietf.org/mailman/listinfo> the list is supposed
> to be <https://www.ietf.org/mailman/listinfo/mdnsext>.

[email-masked] was used for the two BoFs.  The WG will be dnssd, and the m=
ailing list will be [email-masked] (which, I air, is not what is shown in th=
e charter header).

- Ralph

>=20
>    jaap
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext

To: manning bill <[email-masked]>
From: Jaap Akkerhuis <[email-masked]>
Comments: In-reply-to manning bill <[email-masked]> message dated "Thu, 03 Oct 2013 12:05:51 -0700."
Date: Thu, 03 Oct 2013 21:46:36 +0200
Cc: "[email-masked] mdnsext" <[email-masked]>, Tim Chown <[email-masked]>, "<[email-masked]> Discussion" <[email-masked]>, IETF-Announce <[email-masked]>
Subject: Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

    but the "To Subscribe" pointer is busted.

According to <https://www.ietf.org/mailman/listinfo> the list is supposed
to be <https://www.ietf.org/mailman/listinfo/mdnsext>.

	jaap

From: Ted Lemon <[email-masked]>
To: manning bill <[email-masked]>
Date: Thu, 3 Oct 2013 19:20:10 +0000
Accept-Language: en-US
Cc: "[email-masked] mdnsext" <[email-masked]>, Tim Chown <[email-masked]>, "<[email-masked]> Discussion" <[email-masked]>, IETF-Announce <[email-masked]>, Ralph Droms <[email-masked]>
Subject: Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

On Oct 3, 2013, at 3:05 PM, manning bill <[email-masked]> wrote:
> but the "To Subscribe" pointer is busted=85.

Correct.   I should have gotten the information right before sending out th=
e announcement, but I blew it=97sorry about that.

From: Ted Lemon <[email-masked]>
To: Tim Chown <[email-masked]>
Date: Thu, 3 Oct 2013 19:16:57 +0000
Accept-Language: en-US
Cc: "[email-masked] mdnsext" <[email-masked]>, Ralph Droms <[email-masked]>, "<[email-masked]> Discussion" <[email-masked]>, IETF-Announce <[email-masked]>, manning bill <[email-masked]>
Subject: Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

Discussion of IETF consensus activities is supposed to occur on the IETF ma=
iling list, not on the working group mailing list, which doesn't yet exist.=
  We'll set up the new mailing list when the working group is approved.   S=
orry for the confusion.

From: manning bill <[email-masked]>
Date: Thu, 3 Oct 2013 12:05:51 -0700
To: Tim Chown <[email-masked]>
Cc: "[email-masked] mdnsext" <[email-masked]>, Lemon Ted <[email-masked]>, "<[email-masked]> Discussion" <[email-masked]>, IETF-Announce <[email-masked]>, Ralph Droms <[email-masked]>
Subject: Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

but the "To Subscribe" pointer is busted=85.

/bill

On 3October2013Thursday, at 11:43, Tim Chown wrote:

> On 3 Oct 2013, at 18:07, manning bill <[email-masked]> wrote:
>=20
>>  ----- The following addresses had permanent fatal errors -----
>> <[email-masked]>
>>   (reason: 550 5.1.1 <[email-masked]>: Recipient address =
rejected: User unknown in virtual alias table)
>=20
> I think the active list is still [email-masked]?
> See: =
http://www.ietf.org/mail-archive/web/mdnsext/current/maillist.html
>=20
> And the 'header' information below should now probably read something =
like this:
>=20
> --- snip ---
>=20
> Scalable DNS Service Discovery  (dnssd)
> ------------------------------------------------
> Current Status: Proposed WG
>=20
> Chairs:
>  Ralph Droms <[email-masked]>
>  Tim Chown <[email-masked]>
>=20
> Assigned Area Director:
>  Ted Lemon <[email-masked]>
>=20
> Mailing list
>  Address: [email-masked]
>  To Subscribe: [email-masked]
>  Archive: http://www.ietf.org/mail-archive/web/dnssd
>  Pre-WG BoF Archive: http://www.ietf.org/mail-archive/web/mdnsext=20
>=20
>=20
> --- snip ---
>=20
> Tim
>=20
>>=20
>>=20
>>=20
>> On 3October2013Thursday, at 8:42, The IESG wrote:
>>=20
>>> A new IETF working group has been proposed in the Internet Area. The =
IESG
>>> has not made any determination yet. The following draft charter was
>>> submitted, and is provided for informational purposes only. Please =
send
>>> your comments to the IESG mailing list (iesg at ietf.org) by =
2013-10-10.
>>>=20
>>> Extensions for Scalable DNS Service Discovery  (dnssd)
>>> ------------------------------------------------
>>> Current Status: Proposed WG
>>>=20
>>> Chairs:
>>> Ralph Droms <[email-masked]>
>>> Tim Chown <[email-masked]>
>>>=20
>>> Assigned Area Director:
>>> Ted Lemon <[email-masked]>
>>>=20
>>> Mailing list
>>> Address: [email-masked]
>>> To Subscribe: [email-masked]
>>> Archive: http://www.ietf.org/mail-archive/web/dnssdext
>>>=20
>>> Charter:
>>>=20
>>> Background
>>> ----------
>>>=20
>>> Zero configuration networking protocols are currently well suited to
>>> discover services within the scope of a single link.  In particular,
>>> the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes
>>> referred to using Apple Computer Inc.'s trademark, Bonjour) are
>>> widely used for DNS-based service discovery and host name resolution
>>> on a single link.
>>>=20
>>> The DNS-SD/mDNS protocol suite is used in many scenarios including
>>> home, campus, and enterprise networks.  However, the zero =
configuration
>>> mDNS protocol is constrained to link-local multicast scope by =
design,
>>> and therefore cannot be used to discover services on remote links.
>>>=20
>>> In a home network that consists of a single (possibly bridged) link,
>>> users experience the expected discovery behavior; available services
>>> appear because all devices share a common link.  However, in =
multi-link
>>> home networks (as envisaged by the homenet WG) or in routed campus =
or
>>> enterprise networks, devices and users can only discover services on
>>> the same link, which is a significant limitation.  This has led to
>>> calls, such as the Educause petition, to develop an appropriate =
service
>>> discovery solution to span multiple links or to perform discovery =
across
>>> a wide area, not necessarily on directly connected links.
>>>=20
>>> In addition, the "Smart Energy Profile 2 Application Protocol =
Standard",
>>> published by ZigBee Alliance and HomePlug Powerline Alliance =
specifies
>>> the DNS-SD/mDNS protocol suite as the basis for its method of zero
>>> configuration service discovery.  However, its use of wireless mesh
>>> multi-link subnets in conjunction with traditional routed networks =
will
>>> require extensions to the DNS-SD/mDNS protocols to allow operation
>>> across multiple links.
>>>=20
>>> The scenarios in which multi-link service discovery is required may
>>> be zero configuration environments, environments where =
administrative
>>> configuration is supported, or a mixture of the two.
>>>=20
>>> As demand for service discovery across wider area routed networks
>>> grows, some vendors are beginning to ship proprietary solutions.  It
>>> is thus both timely and important that efforts to develop improved,=20=

>>> scalable, autonomous service discovery solutions for routed networks=20=

>>> are coordinated towards producing a single, standards-based =
solution.
>>>=20
>>> The WG will consider the tradeoffs between reusing/extending =
existing
>>> protocols and developing entirely new ones.  It is highly desirable
>>> that any new solution is backwardly compatible with existing =
DNS-SD/mDNS
>>> deployments.  Any solution developed by the dnssd WG must not =
conflict
>>> or interfere with the operation of other zero-configuration service =
and
>>> naming protocols such as uPnP or LLMNR.  Integration with such =
protocols
>>> is out of scope for this WG.
>>>=20
>>> The focus of the WG is to develop a solution for extended, scalable=20=

>>> DNS-SD.  This work is likely to highlight problems and challenges =
with=20
>>> naming protocols, as some level of coexistence will be required =
between=20
>>> local zero configuration name services and those forming part of the=20=

>>> global DNS.  It is important that these issues are captured and=20
>>> documented for further analysis; solving those problems is however =
not=20
>>> within the scope of this WG.
>>>=20
>>> Working Group Description
>>> -------------------------
>>>=20
>>> To that end, the primary goals of the dnssd WG are as follows:
>>>=20
>>> 1. To document a set of requirements for scalable, autonomous
>>>  DNS-based service discovery in routed, multi-link networks in the
>>>  following five scenarios:
>>>=20
>>>  (A) Personal Area networks, e.g., one laptop and one printer.
>>>      This is the simplest example of a service discovery network,
>>>      and may or may not have external connectivity.=20
>>>=20
>>>  (B) Home networks, as envisaged by the homenet WG, consisting of=20
>>>      one or more exit routers, with one or more upstream providers=20=

>>>      or networks, and an arbitrary internal topology with=20
>>>      heterogeneous media where routing is automatically configured.=20=

>>>      The home network would typically be a single zero configuration=20=

>>>      administrative domain with a relatively limited number of=20
>>>      devices.=20
>>>=20
>>>  (C) Wireless 'hotspot' networks, which may include wireless =
networks
>>>      made available in public places, or temporary or permanent
>>>      infrastructures targeted towards meeting or conference style
>>>      events, e.g., as provided for IETF meetings.  In such
>>>      environments other devices may be more likely to be 'hostile'
>>>      to the user.
>>>=20
>>>  (D) Enterprise networks, consisting of larger routed networks,=20
>>>      with large numbers of devices, which may be deployments=20
>>>      spanning over multiple sites with multiple upstreams, and
>>>      one more more administrative domains (depending on internal
>>>      administrative delegation).  The large majority of the=20
>>>      forwarding and security devices are configured.  These may
>>>      be commercial or academic networks, with differing levels=20
>>>      of administrative control over certain devices on the network,
>>>      and BYOD devices commonplace in the campus scenario.
>>>=20
>>>  (E) Mesh networks such as RPL/6LoWPAN, with one or more links per
>>>      routable prefix, which may or may not have external =
connectivity.
>>>      The topology may use technologies including 802.11 wireless,=20
>>>      HomePlug AV and GP, and ZigBee IP.=20
>>>=20
>>>  In the above scenarios, the aim is to facilitate service discovery=20=

>>>  across the defined site.  It is also desirable that a user or =
device,=20
>>>  when away from such a site, is still able to discover services=20
>>>  within that site, e.g. a user discovering services in their home=20
>>>  network while remote from it.
>>>=20
>>>  It is also desirable that multiple discovery scopes are supported,
>>>  from the point of view of announcements and discovery, be the
>>>  scope 'site', 'building', or 'room'.  A user for example may only
>>>  be interested in devices in the same room.
>>>=20
>>> 2. To develop an improved, scalable solution for service discovery=20=

>>>  that can operate in multi-link networks, where devices may be
>>>  in neighboring or non-neighboring links, applicable to
>>>  the scenarios above.  The solution will consider tradeoffs between
>>>  reusing/extending existing protocols and developing entirely new
>>>  protocols.=20
>>>=20
>>>  The solution should include documentation or definition of the
>>>  interfaces that can be implemented, separately to transport of=20
>>>  the information.
>>>=20
>>> 3. To document challenges and problems encountered in the =
coexistence=20
>>>  of zero configuration and global DNS name services in such=20
>>>  multi-link networks, including consideration of both the name=20
>>>  resolution mechanism and the namespace.
>>>=20
>>> It is important that the dnssd 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 dnssd WG, but
>>> coordination between the WGs is desirable.
>>>=20
>>> Deliverables:
>>>=20
>>> The WG will produce three documents: an Informational RFC on the
>>> requirements for service discovery protocols operating on =
potentially
>>> non-neighboring multi-link networks as described above; a Standards
>>> Track RFC documenting an extended, scalable service discovery =
solution=20
>>> that is applicable to those scenarios; and an Informational RFC=20
>>> describing the problems arising when developing the extended SD =
solution=20
>>> and how it affects the integration of local zero configuration and =
global
>>>=20
>>> DNS name services.
>>>=20
>>> Milestones:
>>> Sep 2013 - Formation of the WG
>>> Oct 2013 - Adopt requirements draft as WG document
>>> Jan 2014 - Submit requirements draft to the IESG as an Informational
>>> RFC
>>> Mar 2014 - Adopt wide-area service discovery solution draft as WG
>>> document=20
>>> Mar 2014 - Adopt Informational document on the problems and =
challenges
>>> arising for zeroconf and unicast DNS name services
>>> Sep 2014 - Submit wide-area service discovery solution draft to the
>>> IESG as Standards Track RFC=20
>>> Sep 2014 - Submit the zeroconf and unicast DNS "problems and
>>> challenges" draft to the IESG as Informational.
>>>=20
>>>=20
>>=20
>=20

From: Tim Chown <[email-masked]>
Date: Thu, 3 Oct 2013 19:43:24 +0100
To: manning bill <[email-masked]>
Cc: "[email-masked] mdnsext" <[email-masked]>, Lemon Ted <[email-masked]>, "<[email-masked]> Discussion" <[email-masked]>, IETF-Announce <[email-masked]>, Ralph Droms <[email-masked]>
Subject: Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

--Apple-Mail=_2193BD6E-6B92-4549-A4F3-42F75A2BC089
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 3 Oct 2013, at 18:07, manning bill <[email-masked]> wrote:

>  ----- The following addresses had permanent fatal errors -----
> <[email-masked]>
>   (reason: 550 5.1.1 <[email-masked]>: Recipient address =
rejected: User unknown in virtual alias table)

I think the active list is still [email-masked]?
See: http://www.ietf.org/mail-archive/web/mdnsext/current/maillist.html

And the 'header' information below should now probably read something =
like this:

--- snip ---

Scalable DNS Service Discovery  (dnssd)
------------------------------------------------
Current Status: Proposed WG

Chairs:
 Ralph Droms <[email-masked]>
 Tim Chown <[email-masked]>

Assigned Area Director:
 Ted Lemon <[email-masked]>

Mailing list
 Address: [email-masked]
 To Subscribe: [email-masked]
 Archive: http://www.ietf.org/mail-archive/web/dnssd
 Pre-WG BoF Archive: http://www.ietf.org/mail-archive/web/mdnsext=20

--- snip ---

Tim

>=20
>=20
>=20
> On 3October2013Thursday, at 8:42, The IESG wrote:
>=20
>> A new IETF working group has been proposed in the Internet Area. The =
IESG
>> has not made any determination yet. The following draft charter was
>> submitted, and is provided for informational purposes only. Please =
send
>> your comments to the IESG mailing list (iesg at ietf.org) by =
2013-10-10.
>>=20
>> Extensions for Scalable DNS Service Discovery  (dnssd)
>> ------------------------------------------------
>> Current Status: Proposed WG
>>=20
>> Chairs:
>> Ralph Droms <[email-masked]>
>> Tim Chown <[email-masked]>
>>=20
>> Assigned Area Director:
>> Ted Lemon <[email-masked]>
>>=20
>> Mailing list
>> Address: [email-masked]
>> To Subscribe: [email-masked]
>> Archive: http://www.ietf.org/mail-archive/web/dnssdext
>>=20
>> Charter:
>>=20
>> Background
>> ----------
>>=20
>> Zero configuration networking protocols are currently well suited to
>> discover services within the scope of a single link.  In particular,
>> the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes
>> referred to using Apple Computer Inc.'s trademark, Bonjour) are
>> widely used for DNS-based service discovery and host name resolution
>> on a single link.
>>=20
>> The DNS-SD/mDNS protocol suite is used in many scenarios including
>> home, campus, and enterprise networks.  However, the zero =
configuration
>> mDNS protocol is constrained to link-local multicast scope by design,
>> and therefore cannot be used to discover services on remote links.
>>=20
>> In a home network that consists of a single (possibly bridged) link,
>> users experience the expected discovery behavior; available services
>> appear because all devices share a common link.  However, in =
multi-link
>> home networks (as envisaged by the homenet WG) or in routed campus or
>> enterprise networks, devices and users can only discover services on
>> the same link, which is a significant limitation.  This has led to
>> calls, such as the Educause petition, to develop an appropriate =
service
>> discovery solution to span multiple links or to perform discovery =
across
>> a wide area, not necessarily on directly connected links.
>>=20
>> In addition, the "Smart Energy Profile 2 Application Protocol =
Standard",
>> published by ZigBee Alliance and HomePlug Powerline Alliance =
specifies
>> the DNS-SD/mDNS protocol suite as the basis for its method of zero
>> configuration service discovery.  However, its use of wireless mesh
>> multi-link subnets in conjunction with traditional routed networks =
will
>> require extensions to the DNS-SD/mDNS protocols to allow operation
>> across multiple links.
>>=20
>> The scenarios in which multi-link service discovery is required may
>> be zero configuration environments, environments where administrative
>> configuration is supported, or a mixture of the two.
>>=20
>> As demand for service discovery across wider area routed networks
>> grows, some vendors are beginning to ship proprietary solutions.  It
>> is thus both timely and important that efforts to develop improved,=20=

>> scalable, autonomous service discovery solutions for routed networks=20=

>> are coordinated towards producing a single, standards-based solution.
>>=20
>> The WG will consider the tradeoffs between reusing/extending existing
>> protocols and developing entirely new ones.  It is highly desirable
>> that any new solution is backwardly compatible with existing =
DNS-SD/mDNS
>> deployments.  Any solution developed by the dnssd WG must not =
conflict
>> or interfere with the operation of other zero-configuration service =
and
>> naming protocols such as uPnP or LLMNR.  Integration with such =
protocols
>> is out of scope for this WG.
>>=20
>> The focus of the WG is to develop a solution for extended, scalable=20=

>> DNS-SD.  This work is likely to highlight problems and challenges =
with=20
>> naming protocols, as some level of coexistence will be required =
between=20
>> local zero configuration name services and those forming part of the=20=

>> global DNS.  It is important that these issues are captured and=20
>> documented for further analysis; solving those problems is however =
not=20
>> within the scope of this WG.
>>=20
>> Working Group Description
>> -------------------------
>>=20
>> To that end, the primary goals of the dnssd WG are as follows:
>>=20
>> 1. To document a set of requirements for scalable, autonomous
>>  DNS-based service discovery in routed, multi-link networks in the
>>  following five scenarios:
>>=20
>>  (A) Personal Area networks, e.g., one laptop and one printer.
>>      This is the simplest example of a service discovery network,
>>      and may or may not have external connectivity.=20
>>=20
>>  (B) Home networks, as envisaged by the homenet WG, consisting of=20
>>      one or more exit routers, with one or more upstream providers=20
>>      or networks, and an arbitrary internal topology with=20
>>      heterogeneous media where routing is automatically configured.=20=

>>      The home network would typically be a single zero configuration=20=

>>      administrative domain with a relatively limited number of=20
>>      devices.=20
>>=20
>>  (C) Wireless 'hotspot' networks, which may include wireless networks
>>      made available in public places, or temporary or permanent
>>      infrastructures targeted towards meeting or conference style
>>      events, e.g., as provided for IETF meetings.  In such
>>      environments other devices may be more likely to be 'hostile'
>>      to the user.
>>=20
>>  (D) Enterprise networks, consisting of larger routed networks,=20
>>      with large numbers of devices, which may be deployments=20
>>      spanning over multiple sites with multiple upstreams, and
>>      one more more administrative domains (depending on internal
>>      administrative delegation).  The large majority of the=20
>>      forwarding and security devices are configured.  These may
>>      be commercial or academic networks, with differing levels=20
>>      of administrative control over certain devices on the network,
>>      and BYOD devices commonplace in the campus scenario.
>>=20
>>  (E) Mesh networks such as RPL/6LoWPAN, with one or more links per
>>      routable prefix, which may or may not have external =
connectivity.
>>      The topology may use technologies including 802.11 wireless,=20
>>      HomePlug AV and GP, and ZigBee IP.=20
>>=20
>>  In the above scenarios, the aim is to facilitate service discovery=20=

>>  across the defined site.  It is also desirable that a user or =
device,=20
>>  when away from such a site, is still able to discover services=20
>>  within that site, e.g. a user discovering services in their home=20
>>  network while remote from it.
>>=20
>>  It is also desirable that multiple discovery scopes are supported,
>>  from the point of view of announcements and discovery, be the
>>  scope 'site', 'building', or 'room'.  A user for example may only
>>  be interested in devices in the same room.
>>=20
>> 2. To develop an improved, scalable solution for service discovery=20
>>  that can operate in multi-link networks, where devices may be
>>  in neighboring or non-neighboring links, applicable to
>>  the scenarios above.  The solution will consider tradeoffs between
>>  reusing/extending existing protocols and developing entirely new
>>  protocols.=20
>>=20
>>  The solution should include documentation or definition of the
>>  interfaces that can be implemented, separately to transport of=20
>>  the information.
>>=20
>> 3. To document challenges and problems encountered in the coexistence=20=

>>  of zero configuration and global DNS name services in such=20
>>  multi-link networks, including consideration of both the name=20
>>  resolution mechanism and the namespace.
>>=20
>> It is important that the dnssd 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 dnssd WG, but
>> coordination between the WGs is desirable.
>>=20
>> Deliverables:
>>=20
>> The WG will produce three documents: an Informational RFC on the
>> requirements for service discovery protocols operating on potentially
>> non-neighboring multi-link networks as described above; a Standards
>> Track RFC documenting an extended, scalable service discovery =
solution=20
>> that is applicable to those scenarios; and an Informational RFC=20
>> describing the problems arising when developing the extended SD =
solution=20
>> and how it affects the integration of local zero configuration and =
global
>>=20
>> DNS name services.
>>=20
>> Milestones:
>> Sep 2013 - Formation of the WG
>> Oct 2013 - Adopt requirements draft as WG document
>> Jan 2014 - Submit requirements draft to the IESG as an Informational
>> RFC
>> Mar 2014 - Adopt wide-area service discovery solution draft as WG
>> document=20
>> Mar 2014 - Adopt Informational document on the problems and =
challenges
>> arising for zeroconf and unicast DNS name services
>> Sep 2014 - Submit wide-area service discovery solution draft to the
>> IESG as Standards Track RFC=20
>> Sep 2014 - Submit the zeroconf and unicast DNS "problems and
>> challenges" draft to the IESG as Informational.
>>=20
>>=20
>=20

--Apple-Mail=_2193BD6E-6B92-4549-A4F3-42F75A2BC089
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><div>On 3 Oct 2013, at 18:07, manning bill &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
wrote:</div><br><blockquote type=3D"cite"> &nbsp;----- The following =
addresses had permanent fatal errors -----<br>&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt=
;<br> &nbsp;&nbsp;(reason: 550 5.1.1 &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt=
;: Recipient address rejected: User unknown in virtual alias =
table)<br></blockquote><div><br></div>I think the active list is still =
<a =
href=3D"mailto:[email-masked]">[email-masked]</a>?</div><div>See:&nbsp=
;<a =
href=3D"http://www.ietf.org/mail-archive/web/mdnsext/current/maillist.html=
">http://www.ietf.org/mail-archive/web/mdnsext/current/maillist.html</a></=
div><div><br></div><div>And the 'header' information below should now =
probably read something like this:</div><div><br></div><div>--- snip =
---</div><div><br></div><div>Scalable DNS Service Discovery =
&nbsp;(dnssd)<br>------------------------------------------------<br>Curre=
nt Status: Proposed WG<br><br>Chairs:<br>&nbsp;Ralph Droms &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br>&nb=
sp;Tim Chown &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br><br>Ass=
igned Area Director:<br>&nbsp;Ted Lemon &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br><br=
>Mailing list<br>&nbsp;Address:&nbsp;<a =
href=3D"mailto:[email-masked]">[email-masked]</a><br>&nbsp;To =
Subscribe:&nbsp;<a =
href=3D"mailto:[email-masked]">[email-masked]</a><br>&n=
bsp;Archive:&nbsp;<a =
href=3D"http://www.ietf.org/mail-archive/web/dnssd">http://www.ietf.org/ma=
il-archive/web/dnssd</a></div><div>&nbsp;Pre-WG BoF Archive:&nbsp;<a =
href=3D"http://www.ietf.org/mail-archive/web/">http://www.ietf.org/mail-ar=
chive/web/</a>mdnsext&nbsp;</div><div><br></div><div><br></div><div>--- =
snip ---</div><div><br></div><div>Tim</div><div><br><blockquote =
type=3D"cite"><br><br><br>On 3October2013Thursday, at 8:42, The IESG =
wrote:<br><br><blockquote type=3D"cite">A new IETF working group has =
been proposed in the Internet Area. The IESG<br>has not made any =
determination yet. The following draft charter was<br>submitted, and is =
provided for informational purposes only. Please send<br>your comments =
to the IESG mailing list (iesg at <a =
href=3D"http://ietf.org">ietf.org</a>) by 2013-10-10.<br><br>Extensions =
for Scalable DNS Service Discovery =
&nbsp;(dnssd)<br>------------------------------------------------<br>Curre=
nt Status: Proposed WG<br><br>Chairs:<br> Ralph Droms &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br> =
Tim Chown &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br><br>Ass=
igned Area Director:<br> Ted Lemon &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br><br=
>Mailing list<br> Address: <a =
href=3D"mailto:[email-masked]">[email-masked]</a><br> To =
Subscribe: <a =
href=3D"mailto:[email-masked]">[email-masked]</a><br=
> Archive: <a =
href=3D"http://www.ietf.org/mail-archive/web/dnssdext">http://www.ietf.org=
/mail-archive/web/dnssdext</a><br><br>Charter:<br><br>Background<br>------=
----<br><br>Zero configuration networking protocols are currently well =
suited to<br>discover services within the scope of a single link. =
&nbsp;In particular,<br>the DNS-SD [RFC 6763] and mDNS [RFC6762] =
protocol suite (sometimes<br>referred to using Apple Computer Inc.'s =
trademark, Bonjour) are<br>widely used for DNS-based service discovery =
and host name resolution<br>on a single link.<br><br>The DNS-SD/mDNS =
protocol suite is used in many scenarios including<br>home, campus, and =
enterprise networks. &nbsp;However, the zero configuration<br>mDNS =
protocol is constrained to link-local multicast scope by design,<br>and =
therefore cannot be used to discover services on remote links.<br><br>In =
a home network that consists of a single (possibly bridged) =
link,<br>users experience the expected discovery behavior; available =
services<br>appear because all devices share a common link. =
&nbsp;However, in multi-link<br>home networks (as envisaged by the =
homenet WG) or in routed campus or<br>enterprise networks, devices and =
users can only discover services on<br>the same link, which is a =
significant limitation. &nbsp;This has led to<br>calls, such as the =
Educause petition, to develop an appropriate service<br>discovery =
solution to span multiple links or to perform discovery across<br>a wide =
area, not necessarily on directly connected links.<br><br>In addition, =
the "Smart Energy Profile 2 Application Protocol Standard",<br>published =
by ZigBee Alliance and HomePlug Powerline Alliance specifies<br>the =
DNS-SD/mDNS protocol suite as the basis for its method of =
zero<br>configuration service discovery. &nbsp;However, its use of =
wireless mesh<br>multi-link subnets in conjunction with traditional =
routed networks will<br>require extensions to the DNS-SD/mDNS protocols =
to allow operation<br>across multiple links.<br><br>The scenarios in =
which multi-link service discovery is required may<br>be zero =
configuration environments, environments where =
administrative<br>configuration is supported, or a mixture of the =
two.<br><br>As demand for service discovery across wider area routed =
networks<br>grows, some vendors are beginning to ship proprietary =
solutions. &nbsp;It<br>is thus both timely and important that efforts to =
develop improved, <br>scalable, autonomous service discovery solutions =
for routed networks <br>are coordinated towards producing a single, =
standards-based solution.<br><br>The WG will consider the tradeoffs =
between reusing/extending existing<br>protocols and developing entirely =
new ones. &nbsp;It is highly desirable<br>that any new solution is =
backwardly compatible with existing DNS-SD/mDNS<br>deployments. =
&nbsp;Any solution developed by the dnssd WG must not conflict<br>or =
interfere with the operation of other zero-configuration service =
and<br>naming protocols such as uPnP or LLMNR. &nbsp;Integration with =
such protocols<br>is out of scope for this WG.<br><br>The focus of the =
WG is to develop a solution for extended, scalable <br>DNS-SD. =
&nbsp;This work is likely to highlight problems and challenges with =
<br>naming protocols, as some level of coexistence will be required =
between <br>local zero configuration name services and those forming =
part of the <br>global DNS. &nbsp;It is important that these issues are =
captured and <br>documented for further analysis; solving those problems =
is however not <br>within the scope of this WG.<br><br>Working Group =
Description<br>-------------------------<br><br>To that end, the primary =
goals of the dnssd WG are as follows:<br><br>1. To document a set of =
requirements for scalable, autonomous<br> &nbsp;DNS-based service =
discovery in routed, multi-link networks in the<br> &nbsp;following five =
scenarios:<br><br> &nbsp;(A) Personal Area networks, e.g., one laptop =
and one printer.<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;This is the simplest =
example of a service discovery network,<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;and may or may not have external =
connectivity. <br><br> &nbsp;(B) Home networks, as envisaged by the =
homenet WG, consisting of <br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;one or more =
exit routers, with one or more upstream providers <br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;or networks, and an arbitrary internal =
topology with <br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;heterogeneous media =
where routing is automatically configured. <br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The home network would typically be a =
single zero configuration <br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;administrative domain with a relatively =
limited number of <br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;devices. <br><br> =
&nbsp;(C) Wireless 'hotspot' networks, which may include wireless =
networks<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;made available in public =
places, or temporary or permanent<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;infrastructures targeted towards meeting =
or conference style<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;events, e.g., as =
provided for IETF meetings. &nbsp;In such<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;environments other devices may be more =
likely to be 'hostile'<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;to the =
user.<br><br> &nbsp;(D) Enterprise networks, consisting of larger routed =
networks, <br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;with large numbers of =
devices, which may be deployments <br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;spanning over multiple sites with multiple =
upstreams, and<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;one more more =
administrative domains (depending on internal<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;administrative delegation). &nbsp;The =
large majority of the <br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;forwarding and =
security devices are configured. &nbsp;These may<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;be commercial or academic networks, with =
differing levels <br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of administrative =
control over certain devices on the network,<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;and BYOD devices commonplace in the campus =
scenario.<br><br> &nbsp;(E) Mesh networks such as RPL/6LoWPAN, with one =
or more links per<br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;routable prefix, =
which may or may not have external connectivity.<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;The topology may use technologies =
including 802.11 wireless, <br> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;HomePlug =
AV and GP, and ZigBee IP. <br><br> &nbsp;In the above scenarios, the aim =
is to facilitate service discovery <br> &nbsp;across the defined site. =
&nbsp;It is also desirable that a user or device, <br> &nbsp;when away =
from such a site, is still able to discover services <br> &nbsp;within =
that site, e.g. a user discovering services in their home <br> =
&nbsp;network while remote from it.<br><br> &nbsp;It is also desirable =
that multiple discovery scopes are supported,<br> &nbsp;from the point =
of view of announcements and discovery, be the<br> &nbsp;scope 'site', =
'building', or 'room'. &nbsp;A user for example may only<br> &nbsp;be =
interested in devices in the same room.<br><br>2. To develop an =
improved, scalable solution for service discovery <br> &nbsp;that can =
operate in multi-link networks, where devices may be<br> &nbsp;in =
neighboring or non-neighboring links, applicable to<br> &nbsp;the =
scenarios above. &nbsp;The solution will consider tradeoffs between<br> =
&nbsp;reusing/extending existing protocols and developing entirely =
new<br> &nbsp;protocols. <br><br> &nbsp;The solution should include =
documentation or definition of the<br> &nbsp;interfaces that can be =
implemented, separately to transport of <br> &nbsp;the =
information.<br><br>3. To document challenges and problems encountered =
in the coexistence <br> &nbsp;of zero configuration and global DNS name =
services in such <br> &nbsp;multi-link networks, including consideration =
of both the name <br> &nbsp;resolution mechanism and the =
namespace.<br><br>It is important that the dnssd WG takes input from =
stakeholders in<br>the scenarios it is considering. &nbsp;For example, =
the homenet WG is<br>currently evaluating its own requirements for =
naming and service<br>discovery; it is up to the homenet WG as to =
whether it wishes to<br>recommend adoption of the solution developed in =
the dnssd WG, but<br>coordination between the WGs is =
desirable.<br><br>Deliverables:<br><br>The WG will produce three =
documents: an Informational RFC on the<br>requirements for service =
discovery protocols operating on potentially<br>non-neighboring =
multi-link networks as described above; a Standards<br>Track RFC =
documenting an extended, scalable service discovery solution <br>that is =
applicable to those scenarios; and an Informational RFC <br>describing =
the problems arising when developing the extended SD solution <br>and =
how it affects the integration of local zero configuration and =
global<br><br>DNS name services.<br><br>Milestones:<br> Sep 2013 - =
Formation of the WG<br> Oct 2013 - Adopt requirements draft as WG =
document<br> Jan 2014 - Submit requirements draft to the IESG as an =
Informational<br>RFC<br> Mar 2014 - Adopt wide-area service discovery =
solution draft as WG<br>document <br> Mar 2014 - Adopt Informational =
document on the problems and challenges<br>arising for zeroconf and =
unicast DNS name services<br> Sep 2014 - Submit wide-area service =
discovery solution draft to the<br>IESG as Standards Track RFC <br> Sep =
2014 - Submit the zeroconf and unicast DNS "problems and<br>challenges" =
draft to the IESG as =
Informational.<br><br><br></blockquote><br></blockquote></div><br></body><=
/html>=

--Apple-Mail=_2193BD6E-6B92-4549-A4F3-42F75A2BC089--

From [email-masked]  Tue Oct 15 15:25:49 2013
From: "Ralph Droms (rdroms)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 15 Oct 2013 22:25:40 +0000
Accept-Language: en-US
Cc: "[email-masked] mdnsext" <[email-masked]>
Subject: [dnssd] Announcing the dnssd WG and mailing list

Welcome to the [email-masked] mailing list.

In conjunction with the formation of the dnssd WG, the [email-masked]
mailing list has been created.  It has been initially populated with
the subscription list from the [email-masked] mailing list.
[email-masked] will be closed, and the archive will be retained for
reference.

The dnssd WG will be formally created before IETF 88.  Tim Chown and I
are the dnssd WG co-chairs.  Thanks to Tim for taking on the co-chair
job and thanks to Ted Lemon for his help and guidance as AD to get the
dnssd WG chartered.

dnssd will hold it first meeting in Vancouver.  The agenda for the
meeting is available at datatracker.ietf.org/meeting/88/agenda/dnssd

We're looking for volunteers to take minutes and act as jabber
scribes.  Please contact Tim or me to sign up for one of those jobs.

- Ralph

From [email-masked]  Thu Oct 17 04:48:17 2013
Date: Thu, 17 Oct 2013 13:47:48 +0200
From: peter van der Stok <[email-masked]>
To: [email-masked]
Organization: vanderstok consultancy
Mail-Reply-To: [email-masked]
Subject: [dnssd] Fwd: New Version Notification for draft-vanderstok-dnssd-building-requirements-00.txt
Reply-To: [email-masked]

Dear dnssd,

Kerry and I have submitted a draft which describes the requirements on 
multi-link discovery from a building control perspective.
This draft is complementary to the existing requirements draft.
Given a more constrained environment, requirements can be made in 
reasonable detail.

Looking forward to comments,

Peter and kerry

-------- Oorspronkelijke bericht --------
Onderwerp: New Version Notification for 
draft-vanderstok-dnssd-building-requirements-00.txt
Datum: 2013-10-17 13:42
Afzender: [email-masked]
Ontvanger: Peter van der Stok <[email-masked]>, Kerry Lynn 
<[email-masked]>, Peter Van der Stok <[email-masked]>

A new version of I-D, 
draft-vanderstok-dnssd-building-requirements-00.txt
has been successfully submitted by Peter van der Stok and posted to the
IETF repository.

Filename:	 draft-vanderstok-dnssd-building-requirements
Revision:	 00
Title:		 Building control requirements
Creation date:	 2013-10-17
Group:		 Individual Submission
Number of pages: 17
URL:             
http://www.ietf.org/internet-drafts/draft-vanderstok-dnssd-building-requirements-00.txt
Status:          
http://datatracker.ietf.org/doc/draft-vanderstok-dnssd-building-requirements
Htmlized:        
http://tools.ietf.org/html/draft-vanderstok-dnssd-building-requirements-00

Abstract:
The draft describes an interface to the discovery of services on a
bounded network segment from a building control perspective.
Building control has special boundary conditions related to: (1)
management of devices and services, (2) an installation involving
stand-alone networks (3) (dis)connecting network (from) to Internet
without renaming services and devices.  Roaming devices are not
considered in this version.

Note

Discussion and suggestions for improvement are requested, and should
be sent to [email-masked].

Please note that it may take a couple of minutes from the time of 
submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

From [email-masked]  Mon Oct 21 17:36:05 2013
Sender: [email-masked]
Date: Mon, 21 Oct 2013 20:35:39 -0400
From: Kerry Lynn <[email-masked]>
To: [email-masked]
Subject: [dnssd] Fwd: New Version Notification for draft-lynn-dnssd-requirements-00.txt

--047d7bf0d52474ef2704e949943c
Content-Type: text/plain; charset=ISO-8859-1

Greetings,

This draft of the requirements is a minor update on the previous version.

Not all of the suggestions made at the last BoF could be recovered from
the meeting notes prompts, so please start a thread using this version
as a basis if your comments at the BoF were not adequately addressed.

Please also note that the WG page is not set up yet, so New Version
Notifications are not automatically going out to <[email-masked]>.  In
particular, I'd like to call your attention to:
http://tools.ietf.org/html/draft-sullivan-dnssd-label-miprofile, and
http://tools.ietf.org/html/draft-vanderstok-dnssd-building-requirements

Regards, -K-

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, Oct 21, 2013 at 7:50 PM
Subject: New Version Notification for draft-lynn-dnssd-requirements-00.txt
To: Stuart Cheshire <[email-masked]>, Kerry Lynn <[email-masked]>

A new version of I-D, draft-lynn-dnssd-requirements-00.txt
has been successfully submitted by Kerry Lynn and posted to the
IETF repository.

Filename:        draft-lynn-dnssd-requirements
Revision:        00
Title:           Requirements for Scalable DNS-SD/mDNS Extensions
Creation date:   2013-10-22
Group:           Individual Submission
Number of pages: 10
URL:
http://www.ietf.org/internet-drafts/draft-lynn-dnssd-requirements-00.txt
Status:
http://datatracker.ietf.org/doc/draft-lynn-dnssd-requirements
Htmlized:        http://tools.ietf.org/html/draft-lynn-dnssd-requirements-00

Abstract:
   DNS-SD/mDNS is widely used today for discovery and resolution of
   services and names on a local link, but there are use cases to extend
   DNS-SD/mDNS to enable service discovery beyond the local link.  This
   document provides a problem statement and a list of requirements.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--047d7bf0d52474ef2704e949943c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Greetings,<br></div><div><br>This draft of =
the requirements is a minor update on the previous version.<br><br></div>No=
t all of the suggestions made at the last BoF could be recovered from<br></=
div>
the meeting notes prompts, so please start a thread using this version<br>a=
s a basis if your comments at the BoF were not adequately addressed.<br><br=
></div><div>Please also note that the WG page is not set up yet, so New Ver=
sion<br>
Notifications are not automatically going out to &lt;<a href=3D"mailto:dnss=
[email-masked]">[email-masked]</a>&gt;.=A0 In<br></div><div>particular, I&#39;d=
 like to call your attention to:<br><a href=3D"http://tools.ietf.org/html/d=
raft-sullivan-dnssd-label-miprofile">http://tools.ietf.org/html/draft-sulli=
van-dnssd-label-miprofile</a>, and<br>
<a href=3D"http://tools.ietf.org/html/draft-vanderstok-dnssd-building-requi=
rements">http://tools.ietf.org/html/draft-vanderstok-dnssd-building-require=
ments</a><br><br></div>Regards, -K-<br><br><div><div><div><div><br><div cla=
ss=3D"gmail_quote">
---------- Forwarded message ----------<br>From: <b class=3D"gmail_senderna=
me"></b> <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">=
[email-masked]</a>&gt;</span><br>Date: Mon, Oct 21, 2013 at 7:50 =
PM<br>
Subject: New Version Notification for draft-lynn-dnssd-requirements-00.txt<=
br>To: Stuart Cheshire &lt;<a href=3D"mailto:[email-masked]">cheshire@a=
pple.com</a>&gt;, Kerry Lynn &lt;<a href=3D"mailto:[email-masked]">kerlyn@=
ieee.org</a>&gt;<br>
<br><br><br>
A new version of I-D, draft-lynn-dnssd-requirements-00.txt<br>
has been successfully submitted by Kerry Lynn and posted to the<br>
IETF repository.<br>
<br>
Filename: =A0 =A0 =A0 =A0draft-lynn-dnssd-requirements<br>
Revision: =A0 =A0 =A0 =A000<br>
Title: =A0 =A0 =A0 =A0 =A0 Requirements for Scalable DNS-SD/mDNS Extensions=
<br>
Creation date: =A0 2013-10-22<br>
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission<br>
Number of pages: 10<br>
URL: =A0 =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.ietf.org/internet-drafts=
/draft-lynn-dnssd-requirements-00.txt" target=3D"_blank">http://www.ietf.or=
g/internet-drafts/draft-lynn-dnssd-requirements-00.txt</a><br>
Status: =A0 =A0 =A0 =A0 =A0<a href=3D"http://datatracker.ietf.org/doc/draft=
-lynn-dnssd-requirements" target=3D"_blank">http://datatracker.ietf.org/doc=
/draft-lynn-dnssd-requirements</a><br>
Htmlized: =A0 =A0 =A0 =A0<a href=3D"http://tools.ietf.org/html/draft-lynn-d=
nssd-requirements-00" target=3D"_blank">http://tools.ietf.org/html/draft-ly=
nn-dnssd-requirements-00</a><br>
<br>
<br>
Abstract:<br>
=A0 =A0DNS-SD/mDNS is widely used today for discovery and resolution of<br>
=A0 =A0services and names on a local link, but there are use cases to exten=
d<br>
=A0 =A0DNS-SD/mDNS to enable service discovery beyond the local link. =A0Th=
is<br>
=A0 =A0document provides a problem statement and a list of requirements.<br=
>
<br>
<br>
<br>
<br>
Please note that it may take a couple of minutes from the time of submissio=
n<br>
until the htmlized version and diff are available at <a href=3D"http://tool=
s.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br>
<br>
The IETF Secretariat<br>
<br>
</div><br></div></div></div></div></div>

--047d7bf0d52474ef2704e949943c--

From [email-masked]  Mon Oct 21 19:50:23 2013
Date: Mon, 21 Oct 2013 22:50:13 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: [dnssd] request for review [[email-masked]: New Version Notification for draft-sullivan-dnssd-label-miprofile-00.txt]

Dear colleagues,

One of the issues I've raised more than once has to do with the way
resolultion of names in the DNS and resolution of names under mDNS are
different in practice, particularly as applications and even OSes use
IDNA2008.

The draft mentioned below is an effort to suggest a common,
interoperable subset of label patterns that would permit seamless use
of a given name in mDNS and DNS.  It's particularly written with an
eye to internationalization, though that's not the only possible area
where there's an issue.

As I understand it, the actual lookup mechanism for DNS-SD is outside
of our charter, so this draft is strictly off-topic for the WG.  I'm
only posting this here as a solicitation for feedback.  If you have
comments, please send them directly to me.

Thanks,

A

----- Forwarded message from [email-masked] -----

Date: Sat, 19 Oct 2013 12:20:19 -0700
From: [email-masked]
To: Andrew Sullivan <[email-masked]>
Subject: New Version Notification for
	draft-sullivan-dnssd-label-miprofile-00.txt

A new version of I-D, draft-sullivan-dnssd-label-miprofile-00.txt
has been successfully submitted by Andrew Sullivan and posted to the
IETF repository.

Filename:	 draft-sullivan-dnssd-label-miprofile
Revision:	 00
Title:		 Using Labels With DNS-Based Service Discovery, mDNS, and DNS
Creation date:	 2013-10-18
Group:		 Individual Submission
Number of pages: 8
URL:             http://www.ietf.org/internet-drafts/draft-sullivan-dnssd-label-miprofile-00.txt
Status:          http://datatracker.ietf.org/doc/draft-sullivan-dnssd-label-miprofile
Htmlized:        http://tools.ietf.org/html/draft-sullivan-dnssd-label-miprofile-00

Abstract:
   Despite its name, DNS-Based Service Discovery can use naming systems
   other than the Domain Name System when looking for services.
   Different name systems use different conventions for the characters
   allowed in any name.  In order for DNS-SD to be used effectively in
   environments where multiple different name systems are in use, it is
   important to follow a common set of conventions for naming.  This
   memo presents a convention for maximizing such interoperability.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

----- End forwarded message -----

-- 
Andrew Sullivan
[email-masked]

From [email-masked]  Thu Oct 24 12:40:26 2013
Sender: [email-masked]
Date: Thu, 24 Oct 2013 15:40:20 -0400
From: Kerry Lynn <[email-masked]>
To: [email-masked]
Subject: [dnssd] Discovery Scope(s)

--001a11c24a52dd789704e981cdc3
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Greetings,

I'd like to prompt some discussion of Discovery Scope(s) in advance of the
dnssd WG meeting.  I know there was discussion of this at the last BoF but
I attended remotely and didn't get a feeling for any consensus.  So please,
add your comments below or add new issues to this thread.

I would ultimately like the WG to prioritize the requirements in order of
importance.  I think this will help us to resolve the inevitable
tradeoffs.  So
how does this one rank for you?

Currently, http://tools.ietf.org/html/draft-lynn-dnssd-requirements-00
REQ3 states:

        For use cases D and E, there should be a way to configure the
        scope of the discovery and also support both smaller (ex:
        department) and larger (ex: campus-wide) discovery scopes.

I think this requirement is driven primarily by building control
applications
http://tools.ietf.org/html/draft-vanderstok-dnssd-building-requirements-00.
For example, it is easy to imagine wanting to control all of the lights in =
a
room/floor/building.

- How important is this requirement in other applications?

- How would it be accomplished in normal DNS?

- What are the various ways this could be implemented with DNS-SD/mDNS
  extensions?

- What is the additional configuration burden, if any?

- Is the perceived benefit of this feature worth the extra cost (measured a=
s
  config burden, extra code, or other metrics)?

I also became aware after the draft update was submitted that Dave Thaler
and Ralph Droms had a sidebar on this topic during the BoF:

RD: 3a) There should be multiple, potentially orthogonal, scopes?
DT: =93multiple=94 is ambiguous.  What are the requirements?  2?  Arbitrary
number?
E.g. if you have 1000 custom scopes (say one per person in an organization)
is
that ok?   Is the *ability* to nest required to support if one desires?  If
so, how
many levels of nesting must be supported?

RD: 3b) Scopes should be definable on geographic or organizational
boundaries?
DT: ...or topological boundaries=85 ?

RD: 3c) The scope or scopes into which a discoverable entity is placed
should
be configurable by the network administrator, the entity or the user?
DT: Re 3b and c.  Can the advertiser configure their own scope or are they
limited to scopes predefined by a network admin?

Are these the right questions?  Are we missing any?  Other thoughts on the
topic?

Thanks, -K-

--001a11c24a52dd789704e981cdc3
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div>Greetings,<br></div><div><br>I&#39;d l=
ike to prompt some discussion of Discovery Scope(s) in advance of the<br>dn=
ssd WG meeting.=A0 I know there was discussion of this at the last BoF but<=
br>
</div><div>I attended remotely and didn&#39;t get a feeling for any consens=
us.=A0 So please,<br></div><div>add your comments below or add new issues t=
o this thread.<br><br></div><div>I would ultimately like the WG to prioriti=
ze the requirements in order of<br>
</div><div>importance.=A0 I think this will help us to resolve the inevitab=
le tradeoffs.=A0 So<br></div><div>how does this one rank for you?<br><br></=
div><div><br></div>Currently, <a href=3D"http://tools.ietf.org/html/draft-l=
ynn-dnssd-requirements-00" target=3D"_blank">http://tools.ietf.org/html/dra=
ft-lynn-dnssd-requirements-00</a><br>

REQ3 states:<br><br>=A0=A0=A0 =A0=A0=A0 For use cases D and E, there should=
 be a way to configure the<br>=A0=A0=A0=A0=A0=A0=A0 scope of the discovery =
and also support both smaller (ex:<br>=A0=A0=A0=A0=A0=A0=A0 department) and=
 larger (ex: campus-wide) discovery scopes.<br>

<br><br></div><div>I think this requirement is driven primarily by building=
 control applications<br></div><div><a href=3D"http://tools.ietf.org/html/d=
raft-vanderstok-dnssd-building-requirements-00">http://tools.ietf.org/html/=
draft-vanderstok-dnssd-building-requirements-00</a>.<br>
For example, it is easy to imagine wanting to control all of the lights in =
a<br>room/floor/building.<br>
</div><div><br></div><div>- How important is this requirement in other appl=
ications?<br><br></div><div>- How would it be accomplished in normal DNS?<b=
r><font><span style=3D"font-family:arial,helvetica,sans-serif"><br></span><=
/font>- What are the various ways this could be implemented with DNS-SD/mDN=
S<br>

=A0 extensions?<br></div><div><br></div><div>- What is the additional confi=
guration burden, if any?<br><br></div><div>- Is the perceived benefit of th=
is feature worth the extra cost (measured as<br></div><div>=A0 config burde=
n, extra code, or other metrics)?<br>

</div><div><br><br></div>I also became aware after the draft update was sub=
mitted that Dave Thaler<br></div>and Ralph Droms had a sidebar on this topi=
c during the BoF:<br><br></div><font>RD: <span>3a) There should be multiple=
, potentially orthogonal, scopes?</span></font><div>
<div><font><span style=3D"font-family:arial,helvetica,sans-serif">DT: <span=
>=93multiple=94
 is ambiguous.=A0 What are the requirements?=A0 2?=A0 Arbitrary number? <br=
>E.g.
 if you have 1000 custom scopes (say one per person in an organization)=20
is<br>that ok?=A0=A0 Is the *ability* to nest required to support if one=20
desires?=A0 If so, how<br>many levels of nesting must be supported?<br><br>=
</span></span></font></div><div><font><span style=3D"font-family:arial,helv=
etica,sans-serif"><span>RD: </span></span><span>3b) Scopes should be defina=
ble on geographic or organizational boundaries?</span></font></div>
<div><font><span style=3D"font-family:arial,helvetica,sans-serif">DT: ...or=
 topological boundaries=85 ?<br><br></span></font></div><div><font><span st=
yle=3D"font-family:arial,helvetica,sans-serif">RD: 3c) </span><span>The sco=
pe or scopes into which a=20
discoverable entity is placed should<br>be configurable by the network=20
administrator, the entity or the user?<br></span></font></div><div><font><s=
pan style=3D"font-family:arial,helvetica,sans-serif"><span>DT: </span>Re 3b=
 and c.=A0 Can the advertiser configure their own scope or are they limited=
 to scopes predefined by a network admin?<br>
<br></span></font></div><div><font><span style=3D"font-family:arial,helveti=
ca,sans-serif"><br>Are these the right questions?=A0 Are we missing any?=A0=
 Other thoughts on the topic?<br><br></span></font></div><div><font><span s=
tyle=3D"font-family:arial,helvetica,sans-serif">Thanks, -K-<br>
</span></font></div></div></div>

--001a11c24a52dd789704e981cdc3--

From [email-masked]  Thu Oct 24 12:40:27 2013
Sender: [email-masked]
Date: Thu, 24 Oct 2013 15:40:23 -0400
From: Kerry Lynn <[email-masked]>
To: [email-masked]
Subject: [dnssd] Security Issues

--001a11c2f3a6018e7404e981ceb7
Content-Type: text/plain; charset=ISO-8859-1

Greetings,

I'd like to prompt some discussion of Security Issues in advance of the
dnssd WG meeting.  I expect the security requirements will expand well
beyond what's in the current draft:
http://tools.ietf.org/html/draft-lynn-dnssd-requirements-00

I'd like us to thoroughly understand the security implications of DNS-SD/
mDNS extensions, but also to be mindful about which problems we address
and how.

I added a few paragraphs to the current draft based mainly on
off-list conversations:

   DNSSEC can assert the validity but not the veracity of records in a
   zone file.  The trust model of the global DNS relies on the fact that
   human administrators either a) manually enter resource records into a
   zone file, or b) configure the DNS server to authenticate a trusted
   device (e.g., a DHCP server) that can automatically maintain such
   records.

   By contrast, the "plug-and-play" nature of mDNS devices has up to now
   depended only on physical connectivity.  If a device is visible via
   mDNS then it is assumed to be trusted.  This is no longer likely to
   be the case in larger networks.  Still, the new solution SHOULD
   leverage existing security solutions and not invent new ones.

   Mobile devices such as smart phones that can expose the location of
   their owners by registering services in arbitrary zones pose a risk
   to privacy.  Such devices MUST NOT register their services in
   arbitrary zones without the approval of their operators.  However, it
   SHOULD be possible to configure one or more "home" zones, e.g., based
   on subnet prefix, in which mobile devices may automatically register
   their services.

Are there other significant topics that we are missing from the current draft?

Thanks, -K-

--001a11c2f3a6018e7404e981ceb7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Greetings,<br><div><br>I&#39;d like to prompt some discuss=
ion of Security Issues in advance of the<br>dnssd WG meeting.=A0 I expect t=
he security requirements will expand well<br>beyond what&#39;s in the curre=
nt draft:<br>
<a href=3D"http://tools.ietf.org/html/draft-lynn-dnssd-requirements-00" tar=
get=3D"_blank">http://tools.ietf.org/html/draft-lynn-dnssd-requirements-00<=
/a><br><br></div><div>I&#39;d like us to thoroughly understand the security=
 implications of DNS-SD/<br>
mDNS extensions, but also to be mindful about which problems we address<br>=
</div><div>and how.<br><br></div><div>I added a few paragraphs to the curre=
nt draft based mainly on<br></div><div>off-list conversations:<br><pre clas=
s=3D"">
<font><span style=3D"font-family:arial,helvetica,sans-serif">   DNSSEC can =
assert the validity but not the veracity of records in a
   zone file.  The trust model of the global DNS relies on the fact that
   human administrators either a) manually enter resource records into a
   zone file, or b) configure the DNS server to authenticate a trusted
   device (e.g., a DHCP server) that can automatically maintain such
   records.

   By contrast, the &quot;plug-and-play&quot; nature of mDNS devices has up=
 to now
   depended only on physical connectivity.  If a device is visible via
   mDNS then it is assumed to be trusted.  This is no longer likely to
   be the case in larger networks.  Still, the new solution SHOULD
   leverage existing security solutions and not invent new ones.

   Mobile devices such as smart phones that can expose the location of
   their owners by registering services in arbitrary zones pose a risk
   to privacy.  Such devices MUST NOT register their services in
   arbitrary zones without the approval of their operators.  However, it
   SHOULD be possible to configure one or more &quot;home&quot; zones, e.g.=
, based
   on subnet prefix, in which mobile devices may automatically register
   their services.<br><br><br></span></font></pre><pre class=3D""><font><sp=
an style=3D"font-family:arial,helvetica,sans-serif">Are there other signifi=
cant topics that we are missing from the current draft?<br><br></span></fon=
t></pre>
<pre class=3D""><font><span style=3D"font-family:arial,helvetica,sans-serif=
">Thanks, -K-<br></span></font></pre><pre class=3D""><span class=3D""></spa=
n></pre></div></div>

--001a11c2f3a6018e7404e981ceb7--

From [email-masked]  Fri Oct 25 05:58:02 2013
From: Michael Richardson <[email-masked]>
To: Kerry Lynn <[email-masked]>
Date: Fri, 25 Oct 2013 08:57:37 -0400
Cc: [email-masked]
Subject: Re: [dnssd] Discovery Scope(s)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Kerry Lynn <[email-masked]> wrote:
    > I'd like to prompt some discussion of Discovery Scope(s) in advance of
    > the dnssd WG meeting.=C2=A0 I know there was discussion of this at th=
e last
    > BoF but I attended remotely and didn't get a feeling for any
    > consensus.=C2=A0 So please, add your comments below or add new issues=
 to
    > this thread.

    > I would ultimately like the WG to prioritize the requirements in order
    > of importance.=C2=A0 I think this will help us to resolve the inevita=
ble
    > tradeoffs.=C2=A0 So how does this one rank for you?

    > Currently, http://tools.ietf.org/html/draft-lynn-dnssd-requirements-00
    > REQ3 states:

    > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 For use cases D and E, there sh=
ould be a way to configure the
    > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scope of the discovery and=
 also support both smaller (ex:
    > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 department) and larger (ex=
: campus-wide) discovery scopes.

When you say "discovery scopes" I think of two things, and this might be a
result of the "scope 3" discussion over in ROLL.

a) how far would the service request travel. (this is a plumbing question)
b) what devices would reply because they believe they are in scope.
I think you mean (b), but I wonder if your question doesn't have some of
(a) in it as well.

The two boundaries may often coinside, particularly for the "site" boundary.
For the floor/department boundary might be very different: a printer
located on the floor, shared by two departments, might on in the *building*
LAN,  but configured to answer queries from either department's discovery
scope.

    > I think this requirement is driven primarily by building control
    > applications

    > For example, it is easy to imagine wanting to control all of the ligh=
ts
    > in a room/floor/building.

First, that's use case F, which true, does include C,D and E.
Second, I don't think building control is the primary concern.
That's because in enterprise/commercial buildings, I think that there
will be few direct connections to buildings from departments (they will go
through a gateway. Finding that *gateway* is in scope)

I think it's about finding a printer in your building/floor, or the
appropriate service proxy of some sort.

    > - How would it be accomplished in normal DNS?

How would *I* build this in normal DNS?
Some series of SRV records that I'm not awake enough to write leading to:
    _lights.floor1.site12.locationB.example.com IN AAAA FF05::dead:beef

e.g: I think that I would have a site-wite multicast address for each floor.
If instead, there was a controller that I should talk to, it would list
itself as a unicast address.

It might be good if we used the term "discovery scope"

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

--=-=-=
Content-Type: application/pgp-signature

--=-=-=--

From [email-masked]  Fri Oct 25 06:17:18 2013
From: Michael Richardson <[email-masked]>
To: Kerry Lynn <[email-masked]>
Date: Fri, 25 Oct 2013 09:17:14 -0400
Cc: [email-masked]
Subject: Re: [dnssd] Security Issues

--=-=-=

Kerry Lynn <[email-masked]> wrote:
    >    Mobile devices such as smart phones that can expose the location of
    > their owners by registering services in arbitrary zones pose a risk to
    > privacy.  Such devices MUST NOT register their services in arbitrary
    > zones without the approval of their operators.  However, it SHOULD be
    > possible to configure one or more "home" zones, e.g., based on subnet
    > prefix, in which mobile devices may automatically register their
    > services.

I don't think this quite goes far enough.
I think that when one configures a "home" zone, that one also has to
configure what services appear, and by what name.

The device might well be told to configure and announce it's services under
some either deterministic or pseudo-random name.

For instance, my device could well present it's offer of a chess match
under the name, "purple-bearded-guy-in-window" when I'm in the StarBucks'
at 5th Avenue and Broadway.    But, at the StarBucks' where AA meets,
I'm "wishIwassober435234", and the number changes every time.

While this sounds like a device specific feature, and not a protocol concern,
there are some important IPv6 privacy extensions ideas which need to be
brought up a layer here.  In particular, it might be appropriate to bind
the service announcement to a long-lived, but private address which is
reused.  (draft-rafiee-6man-ssas might be useful)

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

--=-=-=
Content-Type: application/pgp-signature

--=-=-=--

From [email-masked]  Fri Oct 25 10:06:47 2013
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Auto-Submitted: auto-generated
Date: Fri, 25 Oct 2013 10:06:40 -0700
Cc: dnssd WG <[email-masked]>
Subject: [dnssd] WG Action: Formed Extensions for Scalable DNS Service Discovery	(dnssd)

A new IETF working group has been formed in the Internet Area. For
additional information please contact the Area Directors or the WG
Chairs.

Extensions for Scalable DNS Service Discovery  (dnssd)
------------------------------------------------
Current Status: Proposed WG

Chairs:
  Ralph Droms <[email-masked]>
  Tim Chown <[email-masked]>

Assigned Area Director:
  Ted Lemon <[email-masked]>

Mailing list
  Address: [email-masked]
  To Subscribe: https://www.ietf.org/mailman/listinfo/dnssd
  Archive: http://www.ietf.org/mail-archive/web/dnssd

Charter:

Background
----------

Zero configuration networking protocols are currently well suited to
discover services within the scope of a single link.  In particular,
the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes
referred to using Apple Computer Inc.'s trademark, Bonjour) are
widely used for DNS-based service discovery and host name resolution
on a single link.

The DNS-SD/mDNS protocol suite is used in many scenarios including
home, campus, and enterprise networks.  However, the zero configuration
mDNS protocol is constrained to link-local multicast scope by design,
and therefore cannot be used to discover services on remote links.

In a home network that consists of a single (possibly bridged) link,
users experience the expected discovery behavior; available services
appear because all devices share a common link.  However, in multi-link
home networks (as envisaged by the homenet WG) or in routed campus or
enterprise networks, devices and users can only discover services on
the same link, which is a significant limitation.  This has led to
calls, such as the Educause petition, to develop an appropriate service
discovery solution to span multiple links or to perform discovery across
a wide area, not necessarily on directly connected links.

In addition, the "Smart Energy Profile 2 Application Protocol Standard",
published by ZigBee Alliance and HomePlug Powerline Alliance specifies
the DNS-SD/mDNS protocol suite as the basis for its method of zero
configuration service discovery.  However, its use of wireless mesh
multi-link subnets in conjunction with traditional routed networks will
require extensions to the DNS-SD/mDNS protocols to allow operation
across multiple links.

The scenarios in which multi-link service discovery is required may
be zero configuration environments, environments where administrative
configuration is supported, or a mixture of the two.

As demand for service discovery across wider area routed networks
grows, some vendors are beginning to ship proprietary 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.

Working Group Description
-------------------------

The focus of the WG is to develop a solution for extended, scalable 
DNS-SD.  This work is likely to highlight problems and challenges with 
naming protocols, as some level of coexistence will be required between 
local zero configuration name services and those forming part of the 
global DNS.  It is important that these issues are captured and 
documented for further analysis; solving those problems is however not 
within the scope of this WG.

The WG will consider the tradeoffs between reusing/extending existing
protocols and developing entirely new ones.  It is highly desirable
that any new solution is backwardly compatible with existing DNS-SD/mDNS
deployments.  Any solution developed by the dnssd WG must not conflict
or interfere with the operation of other zero-configuration service and
naming protocols such as uPnP or LLMNR.  Integration with such protocols
is out of scope for this WG.

Current zero configuration discovery protocols are constrained to
operate within a single link, which implicitly limits the scope of
discovery. In extending service discovery protocols to operate over
multiple links, devices will inherently become discoverable over a
wider area, which may introduce security or privacy concerns. The WG
will consider such concerns when exploring the solution space for
multi-link service discovery.

To that end, the primary goals of the dnssd 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 five scenarios:
      
   (A) Personal Area networks, e.g., one laptop and one printer.
       This is the simplest example of a service discovery network,
       and may or may not have external connectivity. 
		       
   (B) Home networks, as envisaged by the homenet WG, consisting of 
       one or more exit routers, with one or more upstream providers 
       or networks, and an arbitrary internal topology with 
       heterogeneous media where routing is automatically configured. 
       The home network would typically be a single zero configuration 
       administrative domain with a relatively limited number of 
       devices. 
								    
   (C) Wireless 'hotspot' networks, which may include wireless networks
       made available in public places, or temporary or permanent
       infrastructures targeted towards meeting or conference style
       events, e.g., as provided for IETF meetings.  In such
       environments other devices may be more likely to be 'hostile'
       to the user.
       
   (D) Enterprise networks, consisting of larger routed networks, 
       with large numbers of devices, which may be deployments 
       spanning over multiple sites with multiple upstreams, and
       one more more administrative domains (depending on internal
       administrative delegation).  The large majority of the 
       forwarding and security devices are configured.  These may
       be commercial or academic networks, with differing levels 
       of administrative control over certain devices on the network,
       and BYOD devices commonplace in the campus scenario.

   (E) Mesh networks such as RPL/6LoWPAN, with one or more links per
       routable prefix, which may or may not have external connectivity.
       The topology may use technologies including 802.11 wireless, 
       HomePlug AV and GP, and ZigBee IP. 

   In the above scenarios, the aim is to facilitate service discovery 
   across the defined site.  It is also desirable that a user or device, 
   when away from such a site, is still able to discover services 
   within that site, e.g. a user discovering services in their home 
   network while remote from it.

   It is also desirable that multiple discovery scopes are supported,
   from the point of view of either performing discovery within a 
   specified scope or advertisement within a specified scope, and 
   being able to discover (enumerate) the set of scopes such that 
   an application could then choose to do either. It should be noted
   that scope in this sense might refer to 'building' or 'room' and thus 
   might have no correlation to network topology.

2. To develop an improved, scalable solution for service discovery 
   that can operate in multi-link networks, where devices may be
   in neighboring or non-neighboring links, applicable to
   the scenarios above.  The solution will consider tradeoffs between
   reusing/extending existing protocols and developing entirely new
   protocols. 

   The solution should include documentation or definition of the
   interfaces that can be implemented, separately to transport of 
   the information.

3. To document challenges and problems encountered in the coexistence 
   of zero configuration and global DNS name services in such 
   multi-link networks, including consideration of both the name 
   resolution mechanism and the namespace.

It is important that the dnssd 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 dnssd WG, but
coordination between the WGs is desirable.

Milestones:
  Sep 2013 - Formation of the WG
  Oct 2013 - Adopt requirements draft as WG document
  Jan 2014 - 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 Informational document on the problems and challenges
arising for zeroconf and unicast DNS name services
  Sep 2014 - Submit wide-area service discovery solution draft to the
IESG as Standards Track RFC 
  Sep 2014 - Submit the zeroconf and unicast DNS "problems and
challenges" draft to the IESG as Informational.

From [email-masked]  Sun Oct 27 09:02:52 2013
From: Tim Chown <[email-masked]>
Date: Sun, 27 Oct 2013 16:02:21 +0000
To: [email-masked]
Subject: [dnssd] WG tools page set up

--Apple-Mail=_C931A122-0B9D-4308-A3D4-223B69F757E5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

The dnssd WG tools page is now available at:
http://tools.ietf.org/wg/dnssd/

Authors of individual drafts have been kind enough to renam their =
drafts, such that they automatically get listed here.  I will ask for =
these to be linked back to the previously named versions where =
necessary.

Many thanks as ever to Henrik and the tools team.

Tim=

--Apple-Mail=_C931A122-0B9D-4308-A3D4-223B69F757E5
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi,<div><br></div><div>The dnssd WG tools page is now available at:</div><div><a href="http://tools.ietf.org/wg/dnssd/">http://tools.ietf.org/wg/dnssd/</a></div><div><br></div><div>Authors of individual drafts have been kind enough to renam their drafts, such that they automatically get listed here. &nbsp;I will ask for these to be linked back to the previously named versions where necessary.</div><div><br></div><div>Many thanks as ever to Henrik and the tools team.</div><div><br></div><div>Tim</div></body></html>
--Apple-Mail=_C931A122-0B9D-4308-A3D4-223B69F757E5--

From [email-masked]  Sun Oct 27 13:57:33 2013
From: Tim Chown <[email-masked]>
Date: Sun, 27 Oct 2013 20:57:16 +0000
To: Michael Richardson <[email-masked]>
Cc: Kerry Lynn <[email-masked]>, [email-masked]
Subject: Re: [dnssd] Discovery Scope(s)

--Apple-Mail=_45A99785-7424-421E-A919-08172EDB33A3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

Thanks for starting this discussion Kerry.

On 25 Oct 2013, at 13:57, Michael Richardson <[email-masked]> =
wrote:

> Kerry Lynn <[email-masked]> wrote:
>=20
>> Currently, =
http://tools.ietf.org/html/draft-lynn-dnssd-requirements-00
>> REQ3 states:
>=20
>>         For use cases D and E, there should be a way to configure the
>>         scope of the discovery and also support both smaller (ex:
>>         department) and larger (ex: campus-wide) discovery scopes.
>=20
> When you say "discovery scopes" I think of two things, and this might =
be a
> result of the "scope 3" discussion over in ROLL.

Here, I'd refer the discussion to the Charter, which says:

"It is also desirable that multiple discovery scopes are supported,
from the point of view of either performing discovery within a=20
specified scope or advertisement within a specified scope, and=20
being able to discover (enumerate) the set of scopes such that=20
an application could then choose to do either. It should be noted
that scope in this sense might refer to 'building' or 'room' and thus=20
might have no correlation to network topology."

So that sets the context.  Which I think means REQ3 isn't sufficient.

> a) how far would the service request travel. (this is a plumbing =
question)
> b) what devices would reply because they believe they are in scope.
> I think you mean (b), but I wonder if your question doesn't have some =
of
> (a) in it as well.
>=20
> The two boundaries may often coinside, particularly for the "site" =
boundary.
> For the floor/department boundary might be very different: a printer
> located on the floor, shared by two departments, might on in the =
*building*
> LAN,  but configured to answer queries from either department's =
discovery
> scope.

Right, should we be saying that scope can be expressed in terms of =
physical space (e.g., the same room), or administratively (e.g., the =
same department) rather than being treated similarly to multicast =
propagation?  This is what the Charter implies.

>> I think this requirement is driven primarily by building control
>> applications
>=20
>> For example, it is easy to imagine wanting to control all of the =
lights
>> in a room/floor/building.
>=20
> First, that's use case F, which true, does include C,D and E.
> Second, I don't think building control is the primary concern.
> That's because in enterprise/commercial buildings, I think that there
> will be few direct connections to buildings from departments (they =
will go
> through a gateway. Finding that *gateway* is in scope)

Our university has some "interesting" ways of plumbing/trunking VLANs.  =
I'm not sure what assumptions it's safe to make.

> I think it's about finding a printer in your building/floor, or the
> appropriate service proxy of some sort.

Or a display in the same room.  Or a printer in the room you're going =
to.  Or perhaps web information about a department.

>> - How would it be accomplished in normal DNS?
>=20
> How would *I* build this in normal DNS?
> Some series of SRV records that I'm not awake enough to write leading =
to:
>    _lights.floor1.site12.locationB.example.com IN AAAA FF05::dead:beef
>=20
> e.g: I think that I would have a site-wite multicast address for each =
floor.
> If instead, there was a controller that I should talk to, it would =
list
> itself as a unicast address.

Treading a bit into solution space...

> It might be good if we used the term "discovery scope"

OK, but as per charter we also need to consider the advertisement scope =
as well as the discovery scope.

Tim

> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
>=20
>=20
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

--Apple-Mail=_45A99785-7424-421E-A919-08172EDB33A3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space;">Hi,<div><br></div><div>Thanks for starting this =
discussion Kerry.</div><div><br><div><div>On 25 Oct 2013, at 13:57, =
Michael Richardson &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
wrote:</div><br><blockquote type=3D"cite">Kerry Lynn &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
wrote:<br><br><blockquote type=3D"cite">Currently, <a =
href=3D"http://tools.ietf.org/html/draft-lynn-dnssd-requirements-00">http:=
//tools.ietf.org/html/draft-lynn-dnssd-requirements-00</a><br>REQ3 =
states:<br></blockquote><br><blockquote type=3D"cite">&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp; For use cases D and E, there should be a way to =
configure the<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; scope of the =
discovery and also support both smaller =
(ex:<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; department) and =
larger (ex: campus-wide) discovery scopes.<br></blockquote><br>When you =
say "discovery scopes" I think of two things, and this might be =
a<br>result of the "scope 3" discussion over in =
ROLL.<br></blockquote><div><br></div>Here, I'd refer the discussion to =
the Charter, which says:</div><div><br></div><div>"<span =
style=3D"line-height: 16px;">It is also desirable that multiple =
discovery scopes are supported,</span><br style=3D"line-height: =
16px;"><span style=3D"line-height: 16px;">from the point of view of =
either performing discovery within a&nbsp;</span><br style=3D"line-height:=
 16px;"><span style=3D"line-height: 16px;">specified scope or =
advertisement within a specified scope, and&nbsp;</span><br =
style=3D"line-height: 16px;"><span style=3D"line-height: 16px;">being =
able to discover (enumerate) the set of scopes such that&nbsp;</span><br =
style=3D"line-height: 16px;"><span style=3D"line-height: 16px;">an =
application could then choose to do either. It should be noted</span><br =
style=3D"line-height: 16px;"><span style=3D"line-height: 16px;">that =
scope in this sense might refer to 'building' or 'room' and =
thus&nbsp;</span><br style=3D"line-height: 16px;"><span =
style=3D"line-height: 16px;">might have no correlation to network =
topology."</span></div><div><span style=3D"line-height: =
16px;"><br></span></div><div><span style=3D"line-height: 16px;">So that =
sets the context. &nbsp;Which I think means REQ3 isn't =
sufficient.</span></div><div><font face=3D"arial, helvetica, clean, =
sans-serif" size=3D"2"><span style=3D"line-height: =
16px;"><br></span></font><blockquote type=3D"cite">a) how far would the =
service request travel. (this is a plumbing question)<br>b) what devices =
would reply because they believe they are in scope.<br>I think you mean =
(b), but I wonder if your question doesn't have some of<br>(a) in it as =
well.<br><br>The two boundaries may often coinside, particularly for the =
"site" boundary.<br>For the floor/department boundary might be very =
different: a printer<br>located on the floor, shared by two departments, =
might on in the *building*<br>LAN, &nbsp;but configured to answer =
queries from either department's =
discovery<br>scope.<br></blockquote><div><br></div>Right, should we be =
saying that scope can be expressed in terms of physical space (e.g., the =
same room), or administratively (e.g., the same department) rather than =
being treated similarly to multicast propagation? &nbsp;This is what the =
Charter implies.</div><div><br></div><div><blockquote =
type=3D"cite"><blockquote type=3D"cite">I think this requirement is =
driven primarily by building =
control<br>applications<br></blockquote><br><blockquote type=3D"cite">For =
example, it is easy to imagine wanting to control all of the =
lights<br>in a room/floor/building.<br></blockquote><br>First, that's =
use case F, which true, does include C,D and E.<br>Second, I don't think =
building control is the primary concern.<br>That's because in =
enterprise/commercial buildings, I think that there<br>will be few =
direct connections to buildings from departments (they will =
go<br>through a gateway. Finding that *gateway* is in =
scope)<br></blockquote><div><br></div>Our university has some =
"interesting" ways of plumbing/trunking VLANs. &nbsp;I'm not sure what =
assumptions it's safe to make.</div><div><br><blockquote type=3D"cite">I =
think it's about finding a printer in your building/floor, or =
the<br>appropriate service proxy of some =
sort.<br></blockquote><div><br></div>Or a display in the same room. =
&nbsp;Or a printer in the room you're going to. &nbsp;Or perhaps web =
information about a department.</div><div><br><blockquote =
type=3D"cite"><blockquote type=3D"cite">- How would it be accomplished =
in normal DNS?<br></blockquote><br>How would *I* build this in normal =
DNS?<br>Some series of SRV records that I'm not awake enough to write =
leading to:<br> &nbsp;&nbsp;&nbsp;_lights.floor1.<a =
href=3D"http://site12.locationB.example.com">site12.locationB.example.com<=
/a> IN AAAA FF05::dead:beef<br><br>e.g: I think that I would have a =
site-wite multicast address for each floor.<br>If instead, there was a =
controller that I should talk to, it would list<br>itself as a unicast =
address.<br></blockquote><div><br></div>Treading a bit into solution =
space...</div><div><br><blockquote type=3D"cite">It might be good if we =
used the term "discovery scope"<br></blockquote><div><br></div>OK, but =
as per charter we also need to consider the advertisement scope as well =
as the discovery =
scope.</div><div><br></div><div>Tim</div><div><br><blockquote =
type=3D"cite">--<br>Michael Richardson &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;, =
Sandelman Software =
Works<br><br><br>_______________________________________________<br>dnssd =
mailing list<br><a =
href=3D"mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.org/=
mailman/listinfo/dnssd<br></blockquote></div><br></div></body></html>=

--Apple-Mail=_45A99785-7424-421E-A919-08172EDB33A3--

From [email-masked]  Sun Oct 27 14:46:30 2013
From: Tim Chown <[email-masked]>
Date: Sun, 27 Oct 2013 21:45:49 +0000
To: Michael Richardson <[email-masked]>
Cc: Kerry Lynn <[email-masked]>, [email-masked]
Subject: Re: [dnssd] Security Issues

Hi,

Again, thanks for starting the discussion Kerry.

On 25 Oct 2013, at 14:17, Michael Richardson <[email-masked]> =
wrote:

> Kerry Lynn <[email-masked]> wrote:
>>   Mobile devices such as smart phones that can expose the location of
>> their owners by registering services in arbitrary zones pose a risk =
to
>> privacy.  Such devices MUST NOT register their services in arbitrary
>> zones without the approval of their operators.  However, it SHOULD be
>> possible to configure one or more "home" zones, e.g., based on subnet
>> prefix, in which mobile devices may automatically register their
>> services.
>=20
> I don't think this quite goes far enough.

A reminder of the charter text for this subject, to frame the =
discussion:

"Current zero configuration discovery protocols are constrained to
operate within a single link, which implicitly limits the scope of
discovery. In extending service discovery protocols to operate over
multiple links, devices will inherently become discoverable over a
wider area, which may introduce security or privacy concerns. The WG
will consider such concerns when exploring the solution space for
multi-link service discovery."

> I think that when one configures a "home" zone, that one also has to
> configure what services appear, and by what name.
>=20
> The device might well be told to configure and announce it's services =
under
> some either deterministic or pseudo-random name.
>=20
> For instance, my device could well present it's offer of a chess match
> under the name, "purple-bearded-guy-in-window" when I'm in the =
StarBucks'
> at 5th Avenue and Broadway.    But, at the StarBucks' where AA meets,
> I'm "wishIwassober435234", and the number changes every time.
>=20
> While this sounds like a device specific feature, and not a protocol =
concern,
> there are some important IPv6 privacy extensions ideas which need to =
be
> brought up a layer here.  In particular, it might be appropriate to =
bind
> the service announcement to a long-lived, but private address which is
> reused.  (draft-rafiee-6man-ssas might be useful)

So one thing here is that, as per Charter, we have the notion of =
discovery scope and advertisement scope, and an API to allow an =
application to control that.  So part of that could be a cautious =
default advertisement scope, for example. =20

As was pointed out in IESG charter review, there's the potential for a =
vendor device to try to harvest information about devices over a much =
bigger scope than previously.  Kerry has captured this in one of his =
paragraphs, but maybe it could be made more explicit,

The homenet view might be, for example, devices in the guest net only by =
default discovering other devices in the guest net.=20

We also need to be careful about how far we stray towards naming issues, =
but I agree the ability to choose a name depending on locale may be =
useful. There's also the potential for a device to have a "nice name", =
stored on the device, like "Home Office Printer", as well as its network =
name.

I suggest we document the above considerations, so we have a record that =
they have been considered, regardless of whether they are deemed =
significant when we distill the resulting requirements.

Tim=