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

[Philip Homburg <[e-mail]>]

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

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

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.