Le 2012-07-27 à 16:20, Wojciech Dec a écrit : > > > On 25 July 2012 16:13, Rémi Després <despres.r...@laposte.net> wrote: > > Le 2012-07-25 à 15:59, Wojciech Dec (wdec) a écrit : > > > > > > > On 25/07/2012 15:47, "Rémi Després" <despres.r...@laposte.net> wrote: > > > >> > >> > >> > >>> take it to 6man. > >> > >> 6man has to be involved, sure, but Softwire should first be clear about > >> the purpose, and possible drawbacks if any. > >> If you see such drawbacks, please clarify. > > > > Here's one: > > I'd like my <insert name of your favorite device class> to be guaranteed > > *never ever* to conflict. Can I also get a V octet for <$my_device_class>? > > Sorry I couldn't decipher this. > > How many V-octets do you think the IETF should assign, and why should the > V-octed belong to your proposed device/use-category? One may want the V-octet > to be used for "Next gen TVs", etc. > This is a problem & discussion for 6man, which has been said before...
1. Well, the term "V octet" only identifies a particular value of the interface ID first octet. "u" octet identifies another value of this same octet (but a value that, contrary to the V-octet value, can be found in local-scope addresses, and therefore isn't reserved). What name NNN will be given to this field in general (independently of its reserved values) remains open. I agree that this is is a 6man matter. 2. You ask how many values of the NNN field the IETF should assign in the future. This is is obviously uncertain. OTOH, What is sure is that, with 6 free bits and only assigned value for V, there is plenty room for future uses, especially since: - no other use has been identified in 14 years - one future value can be reserved to identify an extended format, thus largely increasing the number of reservable patterns. 3. If no WG would be allowed to propose using the extension mechanism of RFC2373/4291, what, in your understanding, would be its purpose? RD > > -Woj. > > RD > > > > > -Woj. > >> > >> Thanks, > >> RD > >> > >> > >> > >> > >>> > >>> cheers, > >>> Ole > >>> > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
