Brian:
It sounds from your latter text as if you really wouldn't like to see b1. ;-)
Just to refine my position as contributor:
AFAIK, The MUST for mDNS was IMHO from the authors from the following
assumptions:
1. Devices already will do mDNS
2. There is nothing wrong with mDNS, anima principle, reuse existing
protocols unless proven otherwise
3. Separate code basis from GRASP used securely == highest separation of
signaling between secure / insecure.
IMHO:
1. Most network devices i deal with do not do mDNS.
i do not know enough IoT devices to have opinions about those, but
i wonder how important those are re. existing anima charter.
2. a) My main fear remains undesired proxying of mDNS messages by
some equipment, thereby creating undesired ACP connections. mDNS
proxying has become quite popular.
b) IMHO mDNS has a lot of baggage because it's built on a 25 year
old DNS arch amended with a Service Discovery extension. So
it's really a lot of complexity under the hood. Unless a solution
needs to use the DNS namespace i am not sure why it would be
a preference.
c) I can't imagine that all the IoT spaces will convege on just
one discovery protocol as heir preference, so i think it's an
illusion to think we can hit "one preferred" by all model.
Eg: DPWS (derived from WS-Discovery) is also used/preferred
in certain IoT spaces AFAIk.
3. I have never seen point 3. as a system design principle. My background
is in routing, and BGP and IGPs for examples are used extensively
in the same devices running in different instances for different
isolated domains (eg: l3vpn). Reuse of the same protocols as
much as possible, because their security properties are understood
and isolation between different instances is an accepted model of
reuse and mutual isolation (shared code, no shared data).
So, to me the best principles to adopt in bootstrap are:
-> Bootstrap Proxies should support all the discovery protocols that
their clients desire.
-> Clients that are ANIMA devices themselves have GRASP, thats
sufficient, and its a protocol we can fully control. If we discover
problems we can easier fix them as problems with a protocol that
has a lot of other pre-existing uses and our requirements could
conflict with those.
-> If any set of non-ANIMA client devices desiring bootstrap prefer
mDNS, the proxy of course should also support mDNS.
Comments welcome.
Cheers
Toerless
On Mon, Jul 18, 2016 at 09:39:44PM +1200, Brian E Carpenter wrote:
> On 01/07/2016 18:43, Brian E Carpenter wrote:
> > Hi,
> >
> >> b. MUST: Performs DNS-based Service Discovery [RFC6763] over
> >> Multicast DNS [RFC6762] searching for the service
> >> "_bootstrapks._tcp.local.".
> >
> > I missed the bit where we got consensus to only specify DNSSD for
> > discovery. My understanding was that since all ANs will contain
> > the ANI components, GRASP discovery was an equally valid option.
> >
> > DNSSD is a fine option for non-ANs that don't contain the ANI
> > components.
>
> So after some thought, I believe that we have to change this to better
> fit the ANI as a whole by changing it to something like this:
>
> b1. MUST: Performs DNS-based Service Discovery [RFC6763] over
> Multicast DNS [RFC6762] searching for the service
> "_bootstrapks._tcp.local.".
>
> b2. MUST: If the node in question supports GRASP signaling
> [I-D.ietf-anima-grasp], also perform GRASP Discovery searching
> for the Objective "_bootstrapks._tcp.local." using a loop
> count of 1 to ensure link-local scope.
>
> That allows non-Anima devices to use DNSSD if that's their bag,
> and allows Anima deployments to omit DNSSD support if they want.
> The device will use the result of whichever discovery replies first.
> We can use the same name with no problem.
>
> I would argue that since all ACP nodes will support GRASP anyway,
> ACP-creation should use GRASP discovery, so that DNSSD support doesn't
> become mandatory in the ANI. I don't really see what we win by
> inserting DNSSD unnecessarily. If it's needed for non-ANI reasons,
> that's fine of course, but the ACP doesn't need it.
>
> Regards,
>
> Brian
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
--
---
Toerless Eckert, [email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
