Subject: [mdnsext] mdnsext requirements

From: peter van der Stok <[email-masked]>
Date: Wed, 17 Oct 2012 09:15:38 +0200

Dear Stuart and Kerry,

The requirements are quite high level and seem to cover the subject 
reasonably well.

However, the subject of network join and network partition does not 
seem to be covered.
The joining of local networks can have an impact on the names which may 
be ambiguous after the join.
The joining of a local network to global also has an impact on the 
naming.
I would appreciate if the requirements could reflect that rules for 
handling the (re)naming of nodes during these joins and partitions are 
necessary.

Although scalability is explicitly mentioned, it may help me if mention 
is made of the introduction of a directory to mDNS.

Greetings,

peter

-- 
Peter van der Stok
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 17 Oct 2012 09:16:12 -0400

Peter,

Thank you for your comments; see below...

On Wed, Oct 17, 2012 at 3:15 AM, peter van der Stok <[email-masked]>wrote:

> However, the subject of network join and network partition does not seem
> to be covered.
>

I agree that this topic should be explicitly in scope.  The question of
what is meant
by "join" should be addressed.  I expect it will apply to L3 (adding new
subnets) as
well as L2.

Note that in a strictly L2 scenario, mDNS does attempt to mitigate this
issue (see
"Passive Conflict Detection" in the mDNS draft).  However, simply flooding
mDNS
queries and responses across routed links is problematic in the face of
routing
loops, which we must assume to be present.

The joining of local networks can have an impact on the names which may be
> ambiguous after the join.
>

I have ideas on this, but I typically think in "solution space" so a new
thread is
probably warranted.

> The joining of a local network to global also has an impact on the naming.
>

Iff one expects the instance part of the DNS name to be unique in all
scopes,
which may be desirable but practically very difficult.

> Not to mention how to detect the topology change in the first place.

> Although scalability is explicitly mentioned, it may help me if mention is
> made of the introduction of a directory to mDNS.
>
> The final requirements may inevitably lead to this conclusion.  However,
I'll
leave it to the list to decide whether this should be in the requirements
I-D
or in the charter/scope.  I'll post the draft charter in a new thread.

Regards, -K-

> ______________________________**_________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mdnsext<https://www.ietf.org/mailman/listinfo/mdnsext>
>