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

[[e-mail]]

Hi Ted,

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

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