[mdnsext] mDNSext features/requirements rollup

RJ Atkinson <rja.lists@gmail.com> Mon, 28 January 2013 16:51 UTC

Return-Path: <rja.lists@gmail.com>
X-Original-To: mdnsext@ietfa.amsl.com
Delivered-To: mdnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0770721F88B9 for <mdnsext@ietfa.amsl.com>; Mon, 28 Jan 2013 08:51:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNcKtptqBMw1 for <mdnsext@ietfa.amsl.com>; Mon, 28 Jan 2013 08:51:12 -0800 (PST)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB3B21F8871 for <mdnsext@ietf.org>; Mon, 28 Jan 2013 08:51:07 -0800 (PST)
Received: by mail-qa0-f51.google.com with SMTP id cr7so643138qab.10 for <mdnsext@ietf.org>; Mon, 28 Jan 2013 08:51:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; bh=zm31TR+1p1VmqtnCEf/h2eB5uwBoWckYa0JC+il8mFQ=; b=shy+gEtH5pm/+VhMHiHXuG4c2HqFBRcYFU3IjW/JfS4j3Idhw1AJlT8obXXLdnW3RZ v/wmS7oxs4KshJH/k49ymHH6iSGCNmWwluaOKF5iSqiULzvW6oi1WGbkBFIY8tu9BeUr 32ajeOIVZeYyiCmm+X7CavRy/Pg/5VdmmQmWTK/BRfnE6lbuaomF6qG0sgFWqp5kv0rd dWBk3iyiQ5Ih3sH0PuQIF4/x/nJudJ5lcCPJzOwiNbFrEboPwohV4nWTTdSj7HkkBiEz J3kUo9pDmbDEYQJbXZEElFVCZZr2132pHWPcIP/6/dFhbDjnrGteXSKyS0v4QpfiQaIY FL0Q==
X-Received: by 10.224.34.195 with SMTP id m3mr7135134qad.77.1359391864238; Mon, 28 Jan 2013 08:51:04 -0800 (PST)
Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id r13sm5992720qeu.11.2013.01.28.08.51.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 08:51:03 -0800 (PST)
From: RJ Atkinson <rja.lists@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Mon, 28 Jan 2013 11:51:02 -0500
Message-Id: <01E33CD1-89B4-4088-B2BC-F01E34DF6F57@gmail.com>
To: mdnsext@ietf.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
Subject: [mdnsext] mDNSext features/requirements rollup
X-BeenThere: mdnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <mdnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mdnsext>
List-Post: <mailto:mdnsext@ietf.org>
List-Help: <mailto:mdnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Jan 2013 16:51:13 -0000

Some of us would like to see mDNS support multiple IP subnets
(e.g. multiple buildings, multiple groups, multiple (V)LANs)
within a single administrative domain (e.g. university campus,
corporate campus).  

  This implies having a straight-forward way to configure 
  networking devices (e.g. firewalls, routers) at the edge 
  of one's administrative domain to exclude certain interfaces 
  (e.g. exterior uplink interfaces) from all mDNS traffic 
  of the administrative domain using mDNS.

To a first approximation, the facility/capability provided 
by (old) Apple EtherTalk would do very nicely. 

Kindly note that the ability to group a resource into a 
non-topological "zone" within that single administrative domain 
would be most helpful.

Overall bandwidth efficiency is also important as a design
goal.  Some of us have a mixture of different links/subnets
with different technologies and bandwidth limitations --
not everything is running at Gbps speeds, over fibre, or
over uncontested radio spectrum.[1]

Ran

[1] Exempli Gratia:   IEEE 802.11n does NOT operate at full 
    theoretical performance in typical 2.4 GHz deployments,
    because of the widespread use of the 2.4 GHz band for
    a wide range of things -- other 802.11 deployments,
    cordless telephones, and so on.  While the 5 GHz band
    often has less interference at present, that also is
    shared, so interference there will tend to grow over
    time.