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

[David Farmer <[e-mail]>]

On 1/24/13 23:41 , Stuart Cheshire wrote:
> 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.

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: [e-mail]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: [phone]
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================