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.

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." 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.

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
>> o) 609-377-6594
>> w) www.comcast6.net
>> e) john_brzozowski@cable.comcast.**com<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<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<https://www.ietf.org/mailman/listinfo/mdnsext>
>>>>
>>> ______________________________**_________________
>>> mdnsext mailing list
>>> mdnsext@ietf.org
>>> https://www.ietf.org/mailman/**listinfo/mdnsext<https://www.ietf.org/mailman/listinfo/mdnsext>
>>>
>>
>> ______________________________**_________________
>> mdnsext mailing list
>> mdnsext@ietf.org
>> https://www.ietf.org/mailman/**listinfo/mdnsext<https://www.ietf.org/mailman/listinfo/mdnsext>
>>
> ______________________________**_________________
> mdnsext mailing list
> mdnsext@ietf.org
> https://www.ietf.org/mailman/**listinfo/mdnsext<https://www.ietf.org/mailman/listinfo/mdnsext>
>