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

[[e-mail]]

Hi Philip,

Thanks for your comments.

> On 7 Oct 2020, at 14:46, Philip Homburg <[e-mail]> wrote:
> 
>>   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.

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.

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

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

> 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.

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.

> 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.

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.

> 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.

Best regards,
Ole, with individual contributor hat on.