Re: [Anima-bootstrap] M_FLOOD and mDNS (was Re: Anima bootstrap: discover protocol multicast notes)

[peter van der Stok <[e-mail]>]

> 
>     > <pvds> The beginning of section 8 says: " Whenever a Multicast 
> DNS
>     > responder starts up, wakes up from sleep, receives an indication 
> of a
>     > network interface "Link Change" event, or has any other reason to
>     > believe that its network connectivity may have changed in some
>     > relevant way, it MUST perform the two startup steps below: 
> Probing
>     > (Section 8.1) and Announcing (Section 8.3).  " Much of the text 
> of
> 
> Yes, that's the case on the first interval.  Once it's none that, it's 
> not
> supposed to be proactively announce itself again, from what I 
> understand.
> It's a service, so it doesn't to defend it's name.
> 
>     > rfc6762 is about suppressing superfluous traffic.  The method 
> relies
>     > on repetitive querying and reactive responding, with a response 
> at
>     > responder re-activation (see above).  There is a lot of 
> operational
>     > experience here, and deserves attention.  </pvds>
> 
> Okay, but would this be a valid implementation:
>       unsigned char stuff[]={ 0x01,0x02, /* encoded DNS-SD reply */
>       while(true) {
>                   sleep(60);
>                   sendmsg(stuff, multicast-address, port-5353);
>       }
> 
This looks like a caricature of the mDNS text regarding the sleep.
I don't think the text is intended for lots of sleepy sensors.
 From an inter-operability point of view it looks OK.  One can argue 
about the load generated on the network.
> ?
> 
>     >> It might be that in the end we don't care about the anonimity of 
> the
>     >> pledge.
> 
>     > <pvds> Did we? IMO, almost impossible in an unsecured 
> bootstrapping
>     > network.  Once keys are distributed, pledge looses it identity 
> and
>     > starts afresh (I reckoned) </pvds>
> 
> Okay, *DO YOU* care about anonimity of the pledge?
> Do *YOU* care if the pledge must solicit a Join Proxy by multicasting a 
> query?
*I* don't. preferably link-local though.
> 
>     >> If the pledge can ask the network about Join Proxy, then there 
> is
>     >> nothing to stop us from using mDNS here.
> 
>     > <pvds> Or anything else dependent on the operational environment 
> of
>     > the SDO using the bootstrapping protocol.  </pvds>
> 
> Agreed.
> What would you like to chose here?  Tell us your opinion.
personally I would use CoAP discovery; we talk about CoAP here.
And specify a join-proxy resource-type in the coap registry.
> Don't be shy.
Try to be bold.
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-