Re: New Version Notification for draft-troan-6man-universal-ra-option-03.txt

Le 08/10/2020 à 20:09, Michael Richardson a écrit :
> 
> Ted Lemon <mellon@fugue.com> wrote:
>> The reason you want a JSON-like encapsulation for data is that you
>> want to be able to send arbitrary data. If your protocol does not
>> need the ability to send arbitrary data, a JSON-like encapsulation
>> is always going to be more work, and more prone to security issues
>> when the validator isn’t quite right.
> 
> Assuming you only write one TLV parser, and one JSON parser, and you
> use them both once, then your comparison is valid.
> 
> How many TLV formats does the IETF have?  Seven? Ten?
> 
> How many are written with the same care as the CBOR (apples to apples
> here), parser? The goal here is not to enable embedded systems to
> parse RA option in python[%], but to enable new RA options to be
> passed through to *applications* (not kernels) that need them.

Here I disagree, Michael.

I think one of the reasons why SLAAC is so successful compared to DHCP
is that its Host part (the most numerous) is in the kernel.  YEs, a
monolithic large kernel, but still a kernel.  Everyone getting a unix
system gets SLAAC with it because it's in the kernel; the user apps are
all optional.

In that direction, I think to replicate that success for DHCP parts that
are absent from SLAAC is to move these parts into the kernel.  To that
end, we worked to put a DHCP-PD client implementation in the kernel
instead of being in the typical userspace.

As such, a direction where the config option is facilitated more to
userspace apps - what this draft and your direction of thought proposes
- is useless to the kernel implementations of DHCP-PD.

(and yes, I also know of directions that consider protocol overloads
like Mobile IP to be better away from kernel into userspace; and the
directions of 'micro-'kernel; despite that still I consider DHCP-PD
client in the kernel to be a good potential way for wider DHCP-PD adoption).

Alex

> 
> 
> [%] - but, micropython on all the Adafruit line of things. It's the
> Napster-like toolkit of IoT.
> 
> -- Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT
> consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
> 