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

[Philip Homburg <[e-mail]>]

>    Changes:
> 
>      - removed the experimental part of it.
> 
>    I think the draft is ready for working group adoption.
> 
>    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.