Rushing to the bottom line:
On 21/07/2016 19:36, Toerless Eckert wrote:
...
> Sure. Lots of subtle points. To me they just add up to a negative
> on mDNS in this circumstance.
Obviously, if the bootstrap and ACP teams come to this conclusion,
this GRASP co-author will not fight it :-).
But we w
On Tue, Jul 19, 2016 at 06:19:15AM -0400, Michael Richardson wrote:
> I don't see the problem.
> a) proxy mDNS all you like, the proxy reply is supposed to be a
>link-local address, and if the mDNS was proxied, then the connection
>failed.
Unless multiple devices have the same link-local a
Inline
On Tue, Jul 19, 2016 at 10:10:29PM +1200, Brian E Carpenter wrote:
> On 19/07/2016 21:56, Michael Richardson wrote:
> >
> > Toerless Eckert wrote:
> > > 1. Most network devices i deal with do not do mDNS.
> > > i do not know enough IoT devices to have opinions about those, but
> >
Toerless Eckert wrote:
> 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.
I don't see the problem.
a) proxy mDNS all you like, the proxy reply is supposed to be a
Or to put it another way: I'm thinking about the light controller, not
the
lightblubs.
1) the concept of a 'lightblub' is very appealing.
2) on balance, I think I agree with Michael slightly more than
with Toerless. Even though this use case is strictly outside the
Anima charter, I think we'
On 19/07/2016 21:56, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> > 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.
>
> I am not mostl
Toerless Eckert wrote:
> 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.
I am not mostly *not* thinking about tiny constrained motes here.
I'm thin
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 princ
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
> disco
Hi Michael,
On 05/07/2016 07:47, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> >> 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
Brian E Carpenter wrote:
>> 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
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
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and
Approach of the IETF.
Title : Bootstrapping Remote Secure Key Infrastructures
(BRSKI)
Authors : Max Pritik
13 matches
Mail list logo
