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

From: [email-masked]
Date: Wed, 7 Oct 2020 13:40:40 +0200

I posted an update to the Universal Configuration option draft yesterday.
Changes:
  - removed the experimental part of it.

I think the draft is ready for working group adoption.
Anyone else interested in this work?

(If the group decides to adopt it would be good with an additional author, or an editor replacing me.
From a number of hats to juggle perspective.)

Written with indivudal contributor hat on,
Ole

> Begin forwarded message:
> 
> From: <[email-masked]>
> Subject: New Version Notification for draft-troan-6man-universal-ra-option-03.txt
> Date: 6 October 2020 at 22:21:59 CEST
> To: "O. Troan" <[email-masked]>, Ole Troan <[email-masked]>
> 
> 
> A new version of I-D, draft-troan-6man-universal-ra-option-03.txt
> has been successfully submitted by O. Troan and posted to the
> IETF repository.
> 
> Name:		draft-troan-6man-universal-ra-option
> Revision:	03
> Title:		The Universal IPv6 Configuration Option
> Document date:	2020-10-06
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/id/draft-troan-6man-universal-ra-option-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-troan-6man-universal-ra-option/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-troan-6man-universal-ra-option
> Htmlized:       https://tools.ietf.org/html/draft-troan-6man-universal-ra-option-03
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-troan-6man-universal-ra-option-03
> 
> Abstract:
>   One of the original intentions for the IPv6 host configuration, was
>   to configure the network-layer parameters only with IPv6 ND, and use
>   service discovery for other configuration information.  Unfortunately
>   that hasn't panned out quite as planned, and we are in a situation
>   where all kinds of configuration options are added to RAs and DHCP.
>   This document proposes a new universal option for RA and DHCP in a
>   self-describing data format, with the list of elements maintained in
>   an IANA registry, with greatly relaxed rules for registration.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 7 Oct 2020 14:22:21 +0200

I think why this will not be implemented in linux radvd is because of
the syntax of CDDL and CBOR being different than the radvd.conf syntax. 
I suspect the various dhcp daemon conf files would likely not understand
CDDL and CBOR either.  Probably conversions will be needed.

But I agree with the idea of the universal IPv6 configuration option to
be carried either by RA or by DHCP.

>   Fields:
> 
>    Type:  42 for Universal IPv6 Configuration Option
> 
>    Length:  The length of the option (including the type and length
>       fields) in units of 8 octets.
> 
>    Data:  CBOR encoded data.
> 
>    The Option is zero-padded to nearest 8-octet boundary.
> 
>    Example:
> 
>    {
>        "ietf":

That is an Example of just the Data field, I think.  The Example does
not seem to include Type and Length fields, which is ok.  It might be
sufficient to indent the word Example more to the right.

> The universal IPv6 Configuration option MUST be small enough to fit 
> within a single IPv6 ND or DHCPv6 packet.

I am not sure about this requirement... Idont know what is the size of a
single IPv6 ND packet, or of a DHCPv6 packet.

There is a field in the IP header containing the length of the packet in
(16bit, i.e. 65535 bytes max) but not in ND (ICMP) or DHCP headers.

There is a minimal MTU requirement but that is prior to fragmentation.
If fragmentation is in place then packets could be bigger.

Given that, I dont think one needs to compress data to fit in somewhere.

I agree that faced with sending human-readable ASCII data on an
otherwise low-level configuration protocol one might prefer to compress
that, as a principle of keeping human-readable data only at upper layers.

Alex

Le 07/10/2020 à 13:40, [email-masked] a écrit :
>> *From: *<[email-masked] <mailto:[email-masked]>>
>> *Subject: **New Version Notification for 
>> draft-troan-6man-universal-ra-option-03.txt*
>> *Date: *6 October 2020 at 22:21:59 CEST
>> *To: *"O. Troan" <[email-masked] <mailto:[email-masked]>>, Ole Troan 
>> <[email-masked] <mailto:[email-masked]>>
>>
>>
>> Name:draft-troan-6man-universal-ra-option
>> Revision:03
>> Title:The Universal IPv6 Configuration Option
>> Document date:2020-10-06
>> Group:Individual Submission
>> Pages:8
>> URL: 
>> https://www.ietf.org/id/draft-troan-6man-universal-ra-option-03.txt 
>> <https://www.ietf.org/id/draft-troan-6man-universal-ra-option-03.txt>
>> Status: 
>> https://datatracker.ietf.org/doc/draft-troan-6man-universal-ra-option/ 
>> <https://datatracker.ietf.org/doc/draft-troan-6man-universal-ra-option/>
>> Htmlized: 
>> https://datatracker.ietf.org/doc/html/draft-troan-6man-universal-ra-option 
>> <https://datatracker.ietf.org/doc/html/draft-troan-6man-universal-ra-option>
>> Htmlized: 
>> https://tools.ietf.org/html/draft-troan-6man-universal-ra-option-03 
>> <https://tools.ietf.org/html/draft-troan-6man-universal-ra-option-03>
>> Diff: 
>> https://www.ietf.org/rfcdiff?url2=draft-troan-6man-universal-ra-option-03 
>> <https://www.ietf.org/rfcdiff?url2=draft-troan-6man-universal-ra-option-03>
>>
>> Abstract:
>> until the htmlized version and diff are available at tools.ietf.org 
>> <http://tools.ietf.org>.
>>
>> The IETF Secretariat
>>
>>
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Philip Homburg <[email-masked]>
Date: Wed, 07 Oct 2020 14:46:52 +0200

>    Anyone else interested in this work?

I think this draft is going in the wrong direction.

A new RA (or DHCP) option has two aspects: syntax and semantics. What this
draft does is introduce a more complex low level syntax for RA and DHCP
options. I.e., the relatively simple, fixed length fields in RA and DHCP
options are replaced with a generic, compressed, self-describing format.

However, the complete syntax for an option still needs the names of fields,
use of arrays and dicts, etc.

Beyond that, encoding options in CBOR does nothing for the semantics of
an option. And it seems to me that most of the discussion is regarding 
semantics.

I think that encoding options in CBOR can have two benefits: 
1) it makes it possible to have experimental options without explictly
allocating code points from a small space to those options.
2) it make things possible that are hard to express in the current option
format, .i.e options with optional fields, multiple variable length
lists, etc.

So the text:
"While this proposal does not resolve the DHCP vs RA debate, it
"proposes a solution to the problem of a very slow process of
"standardizing new options, and the IETF spending an inordinate
"amount of time arguing over new configuration options.

is not clear to me. It seems to me that any standards track option would
still require an RFC that defines the option's syntax and semantics.

At the same time, if we feel that there are not enough code points to have
options defined by individual informational RFCs, then that is something that
can be addressed in other ways as well.

---

From: [email-masked]
Date: Wed, 7 Oct 2020 15:32:28 +0200

Hi Philip,

Thanks for your comments.

> On 7 Oct 2020, at 14:46, Philip Homburg <[email-masked]> wrote:
> 
>>   Changes:
>> 

The idea of the encoding is to use a higher level more modern level abstraction.
Parsing implementation would be done once for all possible options, and most likely an implementor of the general option could use existing libraries for that.

So while the work of supporting the option infrastructure in itself is more work than the simple TVL option, adding new data to the option has very little overhead.
The architectural change that this brings, is that no longer is changes to router operating systems or the host stack kernel required.
Thereby taking the network vendors and host vendors (and the IETF) out of the loop. Only the network operator needs to add the configuration information to the network devices, and the applications requiring the option would have to update code. The expectation of implementations is that the users of this infrastructrure will deal with JSON objects, not CBOR encoding.

> use of arrays and dicts, etc.

Right, that's modelled in CDDL in the IANA registry.

> an option. And it seems to me that most of the discussion is regarding 

You get some of that from CDDL. If the author of a new configuration information deems it necessary, then of course a more thorough description of logical behaviour can be done.
The idea is to not require that for all possible configuration information using this option though.

> still require an RFC that defines the option's syntax and semantics.

Why would an option be "standards track"?
Nothing prohibiting standards track for a universal configuration option either, but the proposal here is that only expert review is required to define new options.

> can be addressed in other ways as well.

Best regards,
Ole, with individual contributor hat on.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Oct 2020 22:38:15 +0900

On Wed, Oct 7, 2020 at 9:47 PM Philip Homburg <
[email-masked]> wrote:

> [...]

+1. Defining an RA (or DHCP, or whatever) option is not just about defining
the syntax. That's actually the easy part. It's about defining the
semantics of the option, and what behaviour should occur in response by
hosts and routers. The reasons this is important are the same reasons we
have all standards: interoperability, vendor independence, ability to
engineer networks based on expected behaviour instead of building them
empirically around implementation behaviour, etc.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Oct 2020 22:43:43 +0900

On Wed, Oct 7, 2020 at 10:32 PM <[email-masked]> wrote:

> The architectural change that this brings, is that no longer is changes to
> router operating systems or the host stack kernel required.
>

I don't see how this is an advantage of this particular proposal. Changing
RA options is possible today; there is nothing stopping an implementation
such as radvd from allowing the user to configure arbitrary options. For
hosts, Linux already has the ability to pass arbitrary RA options to
userspace via the RTM_NEWNDUSEROPT netlink message which contains the
option. And of course, it's possible to get the raw RA in userspace via a
packet socket. Other OSes almost certainly provide the latter.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 07 Oct 2020 15:54:34 +0200

> The idea of the encoding is to use a higher level more modern level
> abstraction.  Parsing implementation would be done once for all
> possible options, and most likely an implementor of the general
> option could use existing libraries for that.

This means extra code which could be an issue for embedded systems. For 
systems that process RAs in the operation system kernel, this may mean linking
with a library that potentially causes remotely expoitable security holes.

> So while the work of supporting the option infrastructure in itself
> is more work than the simple TVL option, adding new data to the
> option has very little overhead.  The architectural change that
> this brings, is that no longer is changes to router operating
> systems or the host stack kernel required.  

I don't think something like CBOR is required for this. A router can have
a setup where an external service supplies options. 

The DHCP world never felt the need to come up with a high level encoding and
DHCP has a huge number of options.

> Right, that's modelled in CDDL in the IANA registry.

I don't think it is progress to publish protocols in the IANA registry.
The IANA registry should be for code points (private or public) and data
extracted from RFCs.

I think it would be really bad if IANA would be the sole place where 
essential RAs options are decribed. 

> Why would an option be "standards track"? Nothing prohibiting
> standards track for a universal configuration option either, but
> the proposal here is that only expert review is required to define
> new options.

To give a couple of examples:
1) For some reason we don't have a DHCPv6 option for default router. This is
   commonly requested, is not a particularly complex option, and DHCPv6 
   has plenty of code points. This is a discussion we should have out in the
   open, but as some expert review for an IANA registry.

2) We have a DHCPv6 IA_PD with poorly defined semantics. Again, a simple
   option but with complex semantics. This is again a case where we should
   have a public discussion.

3) We had an endless discussion about an 'IPV4-only' option. Again this 
   requires more discussion than just a bit of expert review.

I think that all options that we want to rely on in other RFCs should be
standards track. Yes, if some vendor has a private light bulb protocol, it
should be easy to get a code point for that. But anything that is required
for most routers or hosts should have rough consensus.

---

From: [email-masked]
Date: Wed, 7 Oct 2020 16:01:50 +0200

> I don't see how this is an advantage of this particular proposal. Changing RA options is possible today; there is nothing stopping an implementation such as radvd from allowing the user to configure arbitrary options. For hosts, Linux already has the ability to pass arbitrary RA options to userspace via the RTM_NEWNDUSEROPT netlink message which contains the option. And of course, it's possible to get the raw RA in userspace via a packet socket. Other OSes almost certainly provide the latter.

Not without hijacking the numbering space.

This draft was experimental previously, for this reason. What would be the consequence of the IETF letting go of control.
How much standardisation is required depends very much on the configuration information. E.g. I doubt that RFC3898 information has much consequence apart from between the network operator and whatever daemon running on the hosts. While other configuration information has wider consequences, and may or may not benefit from being standardized.
This option proposes an opaque transport mechanism that makes it optional to involve the IETF or not. Is that scary for people in the IETF... likely. ;-)

Best regards,
Ole

---

From: [email-masked]
Date: Wed, 7 Oct 2020 16:47:49 +0200

Philip,

> with a library that potentially causes remotely expoitable security holes.

The CBOR parser is quite simple. Having one parser for all options is possibly more efficient that having to parse each option separately with it's different representations of IPV6 prefixes etc. Same thing might apply security wise too, although allowing for passing "anything" might also open new security issues in implementation.

> DHCP has a huge number of options.

No, CBOR isn't required. The original proposal was to carry text encoded JSON objects.
The previous discussions on this draft resulted in CBOR as a more effective encoding.
Using CDDL also gives us a modelling language.

> essential RAs options are decribed. 

It depends.
If I develop an application that just needs a configuration option from the network, then fine.
Like e.g. the boot URL option that's been suggested in 6man.
If it's an option that revamps the behaviour of the whole host stack, whatever that would be, perhaps not.

> for most routers or hosts should have rough consensus.

This option would resolve all those discussions. It's partly a proposal to free all the time spent on 6man solutions. ;-)
(only partly tongue in cheek).

Best regards,
Ole

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 7 Oct 2020 15:16:35 +0000

+1 on semantics
The progress on SDN and automation in general is so miserable because it has been discovered that everybody is using different YANG model, and number of YANG models is already 600+.
Therefore, this draft would be useless without strict data model attached.

I have 1 additional comment on syntax:
The world has moved from hard-coded SNMP to flexible (and human-readable) Netcong/YANG. Many other examples exist from management domain. Hence, it looks like the trend.
But where it should stop?
Low level data plane details should definitely stay TLV – XML parsing in ASIC is overkill.
We are talking here about control plane protocol that typically has TLV format for all data.
I did not hear (my problem) that BGP or ISIS have intention to move out of TLV format to something human readable and flexible as XML.
Why? Probably performance problem. Parsing is more resource-consuming.
Will all other control plane protocols migrate to XML in the future? It is an open question.
I am just trying to understand why ND should be the 1st on this path. ISIS and BGP is not supposed to operate in IoT, but ND should.
Is anybody aware about any other control plane protocol that has started migration to XML-like?

Eduard
From: ipv6 [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: 7 октября 2020 г. 16:38
To: Philip Homburg <[email-masked]>
Cc: IETF IPv6 Mailing List <[email-masked]>
Subject: Re: Fwd: New Version Notification for draft-troan-6man-universal-ra-option-03.txt

On Wed, Oct 7, 2020 at 9:47 PM Philip Homburg <[email-masked]<mailto:[email-masked]>> wrote:

+1. Defining an RA (or DHCP, or whatever) option is not just about defining the syntax. That's actually the easy part. It's about defining the semantics of the option, and what behaviour should occur in response by hosts and routers. The reasons this is important are the same reasons we have all standards: interoperability, vendor independence, ability to engineer networks based on expected behaviour instead of building them empirically around implementation behaviour, etc.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 8 Oct 2020 09:01:37 +1300

> The CBOR parser is quite simple. Having one parser for all options is possibly more efficient that having to parse each option separately with it's different representations of IPV6 prefixes etc. S…

I think it's worth re-reading the Abstract of the CBOR spec:

   The Concise Binary Object Representation (CBOR) is a data format
   whose design goals include the possibility of extremely small code
   size, fairly small message size, and extensibility without the need
   for version negotiation.

That's why future embedded systems are highly likely to include a CBOR
encoder/decoder anyway, and as anyone who has used them knows, cbor
loads() and dumps() make life very easy for the programmer.

(I happen to have written a Python package to simulate loads() and dumps() 
for TLVs. That made it possible to play with a direct comparison between
coding a CBOR application or a TLV application for the same purpose.
If you care, https://github.com/becarpenter/tlv )

>>> is more work than the simple TVL option, 

I'm not sure that's even true.

>>> adding new data to the

Which supports JSON trivially, if needed.

    Brian

> .

---

From: Philip Homburg <[email-masked]>
Date: Thu, 08 Oct 2020 16:03:18 +0200

>If you care, https://github.com/becarpenter/tlv )

I'm confused. Do you feel this code is typical for an RA implementation on
an embedded system?

I.e., does a typical embedded system implement RA in python? Does a 
typical embedded system parse RAs using a generic load dump mechanism?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Oct 2020 12:32:03 -0400

> loads() and dumps() make life very easy for the programmer.

This is great marketing copy. That said, having recently re-implemented a protocol that previously used a JSON-like data structure for transport as a TLV protocol, my experience has been that the TLV protocol is definitely less work. The bulk of the work is not encapsulation/decapsulation, but validation. It’s really easy to validate a TLV-based encapsulation because any spurious data is a syntax error. Validating a JSON dictionary that contains the same data requires you to make sure that all the keys are there, that there are no extra keys, that each data element is the right type, and so on. It winds up being quite a lot of code, more like an XML validator than a wire format parser.

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.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Oct 2020 14:09:50 -0400

Ted Lemon <[email-masked]> 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.

[%] - but, micropython on all the Adafruit line of things.
      It's the Napster-like toolkit of IoT.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 8 Oct 2020 21:15:19 +0200

Le 08/10/2020 à 20:09, Michael Richardson a écrit :
>> 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 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 <[email-masked]>   . o O ( IPv6 IøT
> consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 8 Oct 2020 21:18:42 +0200

> typical embedded system parse RAs using a generic load dump mechanism?

I know you dont ask me but allow me a comment here.

It is possible to use python to put some behaviour in some embedded 
systems.  I think it's called '-freeze' option.  It generates an 
executable only while keeping most of python kitchen out of the runtime 
system (libraries, etc.)

Such a frozen executable would not be slowed down by the interpreter 
kind of working, even though it would be large.

But indeed not all embedded systems can accept such files.  Some 
embedded systems are not even on linux but on some other smaller OS. 
Some are so proprietary that are almost unknown to large communities.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 9 Oct 2020 10:17:55 +1300

> I'm confused. Do you feel this code is typical for an RA implementation on

Absolutely not, because it isn't in C++ which I tend to expect to be
more used in such systems. (But who knows in the long run, given the
way our technology keeps changing?)

> typical embedded system parse RAs using a generic load dump mechanism?

I'm sure that is not the case today. But given that CBOR was designed
for low end devices and that programming styles have evolved enormously
in recent years, I wouldn't bet on that remaining true.

Regards
    Brian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Oct 2020 18:09:13 -0400

> both once, then your comparison is valid.

You missed my main point, which is that you have to write a validator for each data object. So yes, maybe in the ideal case you have a really great CBOR parser that even lives up to some of the promises that Brian quoted from the abstract. And maybe you have good validators for some data objects, and not as good validators for other data objects. Who knows?

> *applications* (not kernels) that need them.

“the CBOR parser?”

I don’t disagree that it would be nice to have a common TLV format document that specified all the data types, how arrays are represented, how dictionaries are represented, etc. What I am saying is simply that specifying CBOR not only doesn’t automatically make things safe, but in fact actually makes it a lot easier to write code that is unsafe, for exactly the reason Brian mentioned—it’s really easy to throw a binary blob at a CBOR parser and get a data structure back, and it’s really easy to not fully validate that data structure. You can always do that later.

What you really want is something like what PHB did a while back: define the data encapsulation as a grammar from which a parser can simply be compiled.

---

From: Ole Troan <[email-masked]>
Date: Fri, 9 Oct 2020 00:17:22 +0200

Which is why the objects are described in CDDL. 

Ole

> On 9 Oct 2020, at 00:10, Ted Lemon <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Oct 2020 18:19:05 -0400

> Which is why the objects are described in CDDL. 

That’s lovely, but then why not just compile the CDDL into a TLV parser?

---

From: Ole Troan <[email-masked]>
Date: Fri, 9 Oct 2020 00:31:50 +0200

> On 9 Oct 2020, at 00:19, Ted Lemon <[email-masked]> wrote:
> 

The idea here is to allow users of the option to use existing tools and libraries. Shouldn’t we all be tired of hand crafting C code to parse packets by now?

If you want to build a toolset around a modeling language and TLV representations to compete with CDDL, CBOR, JSON feel free. But I don’t think you should expect us to wait for you. :-)

Ole

---

From: Brian Carpenter <[email-masked]>
Date: Fri, 9 Oct 2020 14:02:38 +1300

The big difference is that CBOR items are self-describing and TLVs are not.

Regards
    Brian
    (via tiny screen & keyboard)

On Fri, 9 Oct 2020, 11:32 Ole Troan, <[email-masked]> wrote:

> The idea here is to allow users of the option to use existing tools and
> libraries. Shouldn’t we all be tired of hand crafting C code to parse
> packets by now?
>
> If you want to build a toolset around a modeling language and TLV
> representations to compete with CDDL, CBOR, JSON feel free. But I don’t
> think you should expect us to wait for you. :-)
>
> Ole

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 9 Oct 2020 01:32:39 +0000

That may be useful in some applications, but self describing doesn’t communicate how to use the data and that’s often the more complicated. Knowing what the data types are doesn’t tell one how to use the data.

- Bernie

On Oct 8, 2020, at 9:03 PM, Brian Carpenter <[email-masked]> wrote:

Regards
    Brian

On Fri, 9 Oct 2020, 11:32 Ole Troan, <[email-masked]<mailto:[email-masked]>> wrote:

On 9 Oct 2020, at 00:19, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

On Oct 8, 2020, at 6:17 PM, Ole Troan <[email-masked]<mailto:[email-masked]>> wrote:
Which is why the objects are described in CDDL.

Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Oct 2020 22:10:37 -0400

Brian, that’s what I’m saying is a problem. You don’t want self describing encodings when the data format is required to be fixed: that just adds an extra step. 

That said, Ole’s point that we don’t have a CDDL-to-tlv compiler is somewhat compelling. 

> On Oct 8, 2020, at 21:02, Brian Carpenter <[email-masked]> wrote:
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 9 Oct 2020 18:04:56 +1300

> Brian, that’s what I’m saying is a problem. You don’t want self describing encodings when the data format is required to be fixed: that just adds an extra step. 

Why is it required to be fixed? That exactly what Ole's proposal changes.

I haven't at all looked into whether CDDL has value for describing TLV formats. But the whole business of a CDDL-driven message parser is quite complex and it doesn't get you away from what Bernie said:

>> Knowing what the data types are doesn’t tell one how to use the data.

Even the best syntax driven parser in the world has problems with that. The question is really what's the best way to get to the point where you have to decide how to use the data.

I don't think Ole is suggesting that his way is the only way to do that.

    Brian 
>> On Fri, 9 Oct 2020, 11:32 Ole Troan, <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>
>>
>>>     On 9 Oct 2020, at 00:19, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>     On Oct 8, 2020, at 6:17 PM, Ole Troan <[email-masked] <mailto:[email-masked]>> wrote:
>>     [email-masked] <mailto:[email-masked]>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Oct 2020 07:47:45 -0400

> Why is it required to be fixed? That exactly what Ole's proposal changes.

The current draft specifies a single dictionary with sub-dictionaries each of which have predefined content types and fixed format. 

> I don't think Ole is suggesting that his way is the only way to do that.

Well, we do have a proposal to adopt this as a working group draft, so I think Ole is at least saying that he thinks this is the best way he knows of to do it. 

Given that Ole has an implementation, and given that this document defines a new way of sending the same data currently sent by RA, it might be interesting to see a side by side comparison of the new encoding versus the old.

---

From: [email-masked]
Date: Fri, 9 Oct 2020 14:28:04 +0200

Hi Ted,

> Given that Ole has an implementation, and given that this document defines a new way of sending the same data currently sent by RA, it might be interesting to see a side by side comparison of the n…

Let me clarify I few things, with regards to my intentions.

- I'm not suggesting to replace old options with this.
  Although for lack of other examples excisting options are put in the registry

- It started out as experimental. That's still an option.
  The experiment would be:
   - what's the consequence of using a "modern" tool-set and modelling and representation,
     combined with an opaque (not requiring network OS nor host kernel changes) transport between network and host application
   - what's the consequence of using the IANA registry as the "protocol specification"
   - what's the consequence of taking IETF review out of the definition of new configuration information

The motivation for this work was to "make 6man out of a job", since I thought we spent way too much time discussing configuration information options. :)

Do you have other concerns around this too Ted?
It's hard to predict how this could be used of course. I suppose you could define an DHCP route option with this. But you'd still need an agent in the OS that would act upon that configuration. And if you had that, you could obviously also do that with whatever other protocol you'd like to invent.

Cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Oct 2020 12:09:23 -0400

> It's hard to predict how this could be used of course. I suppose you could define an DHCP route option with this. But you'd still need an agent in the OS that would act upon that configuration. And…

I think your motivation is interesting, but you’re still going to need a WG to write documents describing new options in this new format—we still need interop.

The DHC working group actually wrote a document on how to encode TLVs because we saw the same problem; this predated CBOR, and I don’t know if we would have been tempted by CBOR had it been available. My parser in ISC DHCP had a little option definition language that was used to parse options. Not exactly CDDL, but same idea.

I think formal descriptions of options as you have done with CDDL is definitely a good idea. I’m less enamored of CBOR simply because it’s the wrong tool for the job—we have to do extra work because it does extra stuff we don’t need. I get that because there are CBOR parsers readily available, it’s the most attractive nuisance, and I am not necessarily saying “definitely not,” but as I’ve already expressed, I definitely have reservations about it. 

It would be interesting to think through what we get extra with CBOR that actually matters for this use case—I’m obviously highlighting the negatives, but perhaps there are positives I’m missing other than “there are already high quality parsers available.”  E.g., one advantage I can see for CBOR with a validator is that if the two ends don’t actually agree on the data format, you’ll notice the problem quickly, whereas if you were just parsing a binary blob it might be less obvious that you, e.g., got the fields out of order or something.

I think if you aren’t actually proposing to redo existing options in CBOR, it would be good to make that really clear. I will admit that I skimmed, so I might have missed your dire warnings to that effect.

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 9 Oct 2020 17:32:07 +0100

> Anyone else interested in this work?

we may benefit from having a more open discussion about the main problem 
statement, namely the intent to smooth over difficult political issues 
by introducing a layer of technical indirection.

 From the technical point of view, the indirection mechanism allows 
plenty of freedom in terms of providing a structured data blob.  The 
exactly encoding mechanism is not that important from the point of view 
of whether the WG ought to adopt the draft, or not.

 From a political point of view, the extra difficulty in implementing 
new options and the high likelihood that any new option would not see 
widescale rollout due to the technical high risk status of the universal 
RA option, could be viewed as making any new option less politically 
unpalatable and therefore more likely to be adopted.  This is, on the 
face of it, both the draft's strength and its weakness.  The gain is 
more consensus and potentially more progress if it shows promise; the 
loss is more effort and a fossil legacy if it fails.

Nick

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Oct 2020 17:24:26 -0400

Nick Hilliard <[email-masked]> wrote:
    > statement, namely the intent to smooth over difficult political issues by
    > introducing a layer of technical indirection.

I agree with you.

In particular, if BFP vendor X, Y and Z implements this universal-RA option
in it's RA configuration, then it makes it *significantly* easier to do experiments as
to whether some new thing or not is useful or not.

It gets us back into running-code and then rough consensus space.

DHCP already has vendor extensions which provide for something equivalent,
but with less imposed structure.

    > From a political point of view, the extra difficulty in implementing new
    > options and the high likelihood that any new option would not see widescale
    > rollout due to the technical high risk status of the universal RA option,
    > could be viewed as making any new option less politically unpalatable and
    > therefore more likely to be adopted.  This is, on the face of it, both the
    > draft's strength and its weakness.  The gain is more consensus and
    > potentially more progress if it shows promise; the loss is more effort and a
    > fossil legacy if it fails.

Agreed.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [