Re: [mdnsext] Discussion of BoF during Berlin IETF

"Brzozowski, John" <John_Brzozowski@Cable.Comcast.com> Tue, 04 June 2013 01:30 UTC

Return-Path: <john_brzozowski@cable.comcast.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 F009921F997E for <mdnsext@ietfa.amsl.com>; Mon, 3 Jun 2013 18:30:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.572
X-Spam-Level:
X-Spam-Status: No, score=-101.572 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqHRspOFt6lL for <mdnsext@ietfa.amsl.com>; Mon, 3 Jun 2013 18:30:07 -0700 (PDT)
Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4BF21E80C5 for <mdnsext@ietf.org>; Mon, 3 Jun 2013 17:47:59 -0700 (PDT)
Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.54380651; Mon, 03 Jun 2013 20:45:34 -0400
Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.173]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Mon, 3 Jun 2013 20:47:51 -0400
From: "Brzozowski, John" <John_Brzozowski@Cable.Comcast.com>
To: Kerry Lynn <kerlyn@ieee.org>, "consultancy@vanderstok.org" <consultancy@vanderstok.org>
Thread-Topic: [mdnsext] Discussion of BoF during Berlin IETF
Thread-Index: AQHOYDN5ldFGvOVfHUCwamdaDY33MZkkMmaAgACHoAA=
Date: Tue, 4 Jun 2013 00:47:51 +0000
Message-ID: <BD87928F6BFAEF4EBEB883E1C4F58772342B6321@PACDCEXMB01.cable.comcast.com>
In-Reply-To: <CABOxzu3TCqL5JXi+UMSA66oRuzo5uWYUaDp-bQbmz-eaOxbG1w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.4.130416
x-originating-ip: [24.40.55.71]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <70529389F79E1C4A9A820E239DD75602@cable.comcast.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mdnsext@ietf.org" <mdnsext@ietf.org>
Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF
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: Tue, 04 Jun 2013 01:30:22 -0000

Kerry,


See below.

John
-----Original Message-----
From: Kerry Lynn <kerlyn@ieee.org>
Date: Monday, June 3, 2013 8:42 AM
To: "consultancy@vanderstok.org" <consultancy@vanderstok.org>
Cc: "mdnsext@ietf.org" <mdnsext@ietf.org>
Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF

>
>
>
>On Mon, Jun 3, 2013 at 4:20 AM, peter van der Stok <stokcons@xs4all.nl>
>wrote:
>
>Hi John,
>
>Very few, naive wishes about autonomous SD data access.
>
>
>
>IMO, "autonomous" is a worthy goal but probably not attainable.
>Nevertheless, any
>required configuration MUST be kept to a minimum.
[jjmb] definitely agree to keeping configuration to a minimum.  I am not
sure I follow why autonomous is not attainable, I can envision how within
a premise data can be learned and collected while separating how the same
is made available upstream.  Am I over simplifying?
>
>As an example, under DNS-SD/mDNS the user has always had the option of
>choosing
>a meaningful <Instance> label for a given service.  If the scope in which
>this label must
>be unique is too large, the task of name conflict resolution becomes more
>complex.  This
>may be mitigated by autonomously choosing names with a very low
>probability of collision,
>but these are user unfriendly.  We need to strike a balance.
> 
>
>
>The home, and also the buiding control installation, can and will be
>separated temporarily from the internet connection provided by Internet
>providers.
>Having autonomous access to SD data in the home (building), with a
>painless (dis)connection to(from) the Internet provider, is one of my
>prime concerns for joining this wg.
>Scalability of the SD data access inside the autonomous network (using a
>server) is equally important.
>
>Naming inside and outside home should be consistent.
>
>
>
>Do you mean that the <Instance> label must be unique both locally and
>within some
>global DNS hierarchy?
> 
>
>
>My examples:
>Inside names: like mydevice.a-local-domain, where a-local-domain can be
>empty
>
>
>
>Certainly the issue of local TLDs must be addressed by the WG.  IMO,
>every server
>that is deployed today MUST continue to work under the "new" rules, which
>means
>that "local." is not going away anytime soon.  We can be sure beyond
>doubt that this
>TLD will never be assigned, but we should work with ICANN to assign a new
>local
>TLD for future growth.
> 
>
>
>Outside names like mydevice.a-local-domain.xs4all-given-domain.
>or myhost.mydomain.my-outside-domain-name.
>
>
>
>Can we stick with conventions like "example.com <http://example.com>."
>for domain names?
>
>
>
>Possibly, the dot for specifying FQDN can be used to distinguish
>autonomous SD data from fully qualified outside data.
>If local. suffix is needed, a special layer to filter out the local. to
>the application would be welcome.
>
>
>
>I don't think we can alter domain name semantics (i.e. the meaning of the
>final dot '.')
>without triggering a severe immune response from the DNS police.  OTOH,
>it seems
>as though defining new resource record types should be possible.  I've
>been thinking
>along the lines of a user-visible "alias" for domain names, e.g.
>"foo.local." might be
>made to appear in a SD browser as "Living Room".  Here it seems that
>mobile devices
>would need a mechanism to discover when they're on "known" networks and
>probably
>tailor their SD display and advertisement behavior accordingly.
>
>
>
>Separating the work such that parts of the work are moved forward
>independently, but in mutual agreement, sounds great.
>
>
>
>Yes, we definitely need to prioritize the requirements in order to
>produce the initial
>proposed standard, but also need a clear vision of future work so that we
>don't limit
>our options.
[jjmb] I think it would be good to arrive at some consensus on this
prioritized list.
>
>I am not yet certain I'll be in Berlin (lacking corporate sponsorship for
>this work) but I'll
>do what I can to advance the base documents and write up a -00 proposal.
>
>Regards, -K-
> 
>
>
>Peter
>
>Brzozowski, John schreef op 2013-06-01 16:07:
>
>
>I just took a quick look at the proposal as well, seems to cover most
>essential areas.  I see that Zigbee was called out, it might be good to
>ensure that it is clear that the home is called out as a key use case.
>
>Peter,
>
>Regarding your comment below what are your thought around separately
>internal and external access to SD data.  Specifically I am thinking SD
>within the home as alluded below can and perhaps should be autonomous. I
>think it may be useful to split up how SD is performed in a premise from
>how it may be made available northbound either by a service provider or
>other third party.  Separating the work can help to ensure that we move
>parts of this work forward independently.
>
>John
>=========================================
>John Jason Brzozowski
>Comcast Cable
>m) 484-962-0060 <tel:484-962-0060>
>o) 609-377-6594 <tel:609-377-6594>
>w) www.comcast6.net <http://www.comcast6.net>
>e) john_brzozowski@cable.comcast.com
>=========================================
>
>
>
>
>
>
>-----Original Message-----
>From: peter van der Stok <stokcons@xs4all.nl>
>Organization: vanderstok consultancy
>Reply-To: "consultancy@vanderstok.org" <consultancy@vanderstok.org>
>Date: Friday, May 31, 2013 2:24 AM
>To: "mdnsext@ietf.org" <mdnsext@ietf.org>
>Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF
>
>Ralph,
>
>I am certainly interested in this work and agree with the charter,
>which has improved with respect to the former version.
>From the point of view of building control, it is essential to do
>disovery on a multilink stand-alone network, and not needing to change
>the applications when the network is connected to a backbone with access
>to DNS. From the outside the resources on the now connected network
>should be visible with the same names, possibly suffixed with additional
>domain name information.
>
>In the past I have commented on the requirements and I am looking
>forward to a new version.
>
>Peter van der Stok.
>
>Ralph Droms schreef op 2013-05-31 05:24:
>REMINDER!!!!
>
>I'm looking for review and discussion of the BoF proposal and draft
>charter here:
>http://www.ietf.org/mail-archive/web/mdnsext/current/msg00149.html
>
>The mailing list has been quiet (0 responses so far).  Is there still
>interest in taking on this work?
>
>- Ralph
>
>_______________________________________________
>mdnsext mailing list
>mdnsext@ietf.org
>https://www.ietf.org/mailman/listinfo/mdnsext
>
>
>_______________________________________________
>mdnsext mailing list
>mdnsext@ietf.org
>https://www.ietf.org/mailman/listinfo/mdnsext
>
>
>
>_______________________________________________
>mdnsext mailing list
>mdnsext@ietf.org
>https://www.ietf.org/mailman/listinfo/mdnsext
>
>
>_______________________________________________
>mdnsext mailing list
>mdnsext@ietf.org
>https://www.ietf.org/mailman/listinfo/mdnsext
>
>
>
>
>
>