Subject: [mdnsext] draft-lynn-mdnsext-requirements-01.txt

From: Stuart Cheshire <[email-masked]>
Date: Thu, 24 Jan 2013 21:41:43 -0800

We just submitted draft-lynn-mdnsext-requirements-01.txt

<http://www.ietf.org/id/draft-lynn-mdnsext-requirements-01.txt>

Please review and give feedback.

The deadline is next Thursday for the IESG to decide whether to schedule an mdnsext BoF meeting at IETF 86 in March, so any discussion before that date is useful for helping them make their decision.

Stuart Cheshire

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 Jan 2013 11:28:20 -0500

>>>>> "Stuart" == Stuart Cheshire <[email-masked]> writes:
    Stuart> We just submitted draft-lynn-mdnsext-requirements-01.txt

    Stuart> <http://www.ietf.org/id/draft-lynn-mdnsext-requirements-01.txt>

    Stuart> Please review and give feedback.

I read this document.

>Service discovery beyond the local link is probably the most	
>      important feature missing currently in the DNS-SD/mDNS framework.
>      The following describes some of the issues.

I think it's important that we take these words in account, and maybe we
should rename the effort sto something like:
       DNS-based site-wide service discovery

(DBSWSD? DSSD?... maybe someone else will come up with a nice IETF WG
acronym).

I think that we will make better progress is we talk more about the
problem, with the understanding that it involves extending mdns/DNS-SD,
but that it isn't just mDNS.

I find the document is very clear, and I think that it is a good problem
statement for creation of a group.    I very much appreciate that
non-multicast things are being considered.

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

---

From: Tim Chown <[email-masked]>
Date: Mon, 28 Jan 2013 22:47:54 +0000

> (DBSWSD? DSSD?... maybe someone else will come up with a nice IETF WG

The proposal we just put in says "Wide area DNS-SD". We chose at this stage to keep mdnsext as the acronym to match up with the mail list name and with the previous BoF effort.

Should there be enough progress to warrant a WG, then the name can be revisited.  That, at the moment, is by no means our main concern.  What we need is healthy list discussion on the issues, in particular pushing forward the good work on the requirements draft, and seeing evidence of commitment to do work.

> but that it isn't just mDNS.

Indeed.

> non-multicast things are being considered.

We have 4 weeks to work on the requirements text.  It would be very desirable to see a version that would be adoptable as a WG item (were we a WG) by then. That would certainly help the cause for forming a WG.

The actual deadline is Mon 25th Feb:
http://www.ietf.org/meeting/cutoff-dates-2013.html

Tim

---

From: David Farmer <[email-masked]>
Date: Thu, 31 Jan 2013 18:40:46 -0600

> The deadline is next Thursday for the IESG to decide whether to schedule an mdnsext BoF meeting at IETF 86 in March, so any discussion before that date is useful for helping them make their decisio…

Here are a few comments;

1. In the second paragraph of of the Intro, I'd like to add the concern 
that the different ad-hoc techniques, when used together at best will 
likely produce unpredictable results, and at worst will be completely 
incompatible and break services.

2. Section 2.1 seems focused on supporting the large scale enterprise 
network environment, especially the technical summary.  While it is 
important to have solutions for these large scale enterprise network 
environments with 10s of thousands of devices on the network, this is 
just the opposite extreme from the link-local environment.  We MUST NOT 
forget the 20 to 200 node network that is just big enough to need more 
than one link segment, maybe just simply separate wired and wireless 
segments, but probably no more than a hand full of segments.  The more 
important issue here is they might have a jack-of-all-trades one-(wo)man 
IT department, but probably not specialized networking staff, an surely 
not a fully qualified network engineering staff.

So the requirement for a breadth or continuum of solutions should be 
made more clear.

3. While Section 2.2 is true in general, this is particularly 
problematic in very large scale 802.11 networks, that are focused on 
density of coverage, with hundreds to thousands of devices in the same 
air space using the same network.

4. Namespace Scope, Address Scope, v4-v6 Dual-Stack, packet TTL, and 
policy;  The interaction namespace with GUA and link-local addressing, 
IPv4 and IPv6, and the TTL that applications use after service discovery 
needs discussion along with global vs ".local" namespaces.

- If ".local" is to remain a link-local only name space then some kind 
of ".site" namespace needs to be considered, and maybe ad-hoc local or 
site namespaces as well.  I can easily see wanting to keep your 
authoritative global DNS namespace separate from this local or site 
service discovery namespace.  Or the policy and security consideration 
for local or site namespace are very much different from authoritative 
global DNS namespace for most organizations.  At the very least these 
trade-offs need to be discussed.

- mDNS use of IPv6 link-local means multi-link use is currently 
restricted to IPv4, because host use their IPv4 GUA address if they have 
one.  So the address scope used has impacts on reachability of services 
and the usability  the namespace.

- Some applications highly restrict the TTL (I've seen TTL=2 for 
instance) of the packets used once a service is discovered.  This means 
it could be possible to discover a service but have it maybe fail 
silently after discover because packet TTLs are exceeded between, this 
is especially possible if the service discovery path is incongruent to 
the packet forwarding path.

5. Location Services - Mobile devices (laptops, pads, phones, etc...) 
generally have very good location services these days, generally good 
enough to locate within the correct building or even a quadrant of a 
building.  When you start dealing with locations privacy can become an 
issue, so we have to be careful, but this seem like a very useful 
concept to bring to bear when dealing with actual humans looking for 
things.  Sort the list services closest to furthest.  From a privacy 
point of view you probably want services to advertize their location and 
the querying device to order the list based on its location.  Rather 
than the query including the location and disclosing the users location. 
  I think this is too powerful and useful to be ignored.

Flipping this around, there could be interesting considerations for 
networks that are themselves mobile.  Think about Wifi networks on 
planes, trains, buses, and ships, telling the devices where the network 
is currently located or what services are available while in port or at 
the current station.

I think that is enough for now, I'll let you chew on that for a while.

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