Re: [Roll] Closing on Ticket #10

["Pascal Thubert (pthubert)" <pthubert at cisco.com>]

Complete agreement with Michael. 

RPL abstracts the OCP and enables a lot of freedom in supporting many of
them.

Consequently, a reasonable implementation will enable the
additions/deletion of OCPs unless that's really impossible for that
platform.
Like a plugin in a web browser if you wish. So adding and removing OCP
code should be similar to reconfiguring the device.

If OCP0 (and/or whatever OCPs we place in the minimum Interop set) is
not needed in a given deployment, it could be uninstalled by conscious
choice.
If devices are delivered partially preconfigured without OCP0 for a
given application that does not require OCP0, I'd be fine, but:

* the possibility to reinstall it on the device must exist.
* standard devices with no configuration must work and interoperate out
of the box (right now that means that OCP0 is the default OCP)

Pascal

>-----Original Message-----
>From: roll-bounces at ietf.org [mailto:roll-bounces at ietf.org] On Behalf Of
Michael Richardson
>Sent: vendredi 13 novembre 2009 03:11
>To: roll WG
>Subject: Re: [Roll] Closing on Ticket #10
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>>>>>> "JP" == JP Vasseur <jvasseur at cisco.com> writes:
>    JP> Now the question is whether or not RPL mandates the support of
>    JP> OF0.
>
>    JP> Again two options:
>
>    JP> 1) We remove OF0 from the core spec. And nodes are free to
>    JP> implement the OF that they want
>
>    JP> 2) We do mandate for each node to support OF0
>
>...
>
>    JP> If the support of OF0 in no longer mandatory, nodes operating
in
>    JP> an environment requiring a specific OF just have to implement
>    JP> that OF.  On the other hand, when mixing nodes that do not
>    JP> support the same OF, they do not interoperate.
>
>What is the real code complexity of an OF?
>My impression is that it is not a lot of code.
>
>My opinion is that without a mandatory to implement set of options in
>the core specification, it is not a standard.  There is ample
experience
>within the IETF (and even more outside the IETF) with what happens when
>you do not have a mandatory to implement subset to guarantee
>interoperability.
>
>There will be many implementations which are created and sold as
>libraries and as part of commodity operating systems which will
>implement only the minimal subset. If OF0 is not required, it won't be
>there.
>
>If there is a subset of RPL use cases that do not need OF0, and for
whom
>having that code present is make or break, then that group should write
>a standards track document which says what they need to implement.
Those
>products will not declare themselves as "RFC1234"(RPL) compliant, but
>instead as "RFC2345"(pool-shed-light-switch-only).
>
>- --
>]       He who is tired of Weird Al is tired of life!           |
firewalls  [
>]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
architect[
>] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device
driver[
>   Kyoto Plus: watch the video
<http://www.youtube.com/watch?v=kzx1ycLXQSE>
>	               then sign the petition.
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.9 (GNU/Linux)
>Comment: Finger me for keys
>
>iQEVAwUBSvzAIYCLcPvd0N1lAQJ6XAf/bwBVAnKJYc+U4IRAdIfqve9H8NAYwM//
>248uvPfPb+IbBGblUO7EXOqw40RIj8nksJ0kEWKeZ6aH8OgAoew82KGxpRDEz8wD
>iOmjILPu1Vn+TUOw3hksoQB1ueIiZLAHJxOKhPudWGqOSjM5+ixiefVZ28bRAcgZ
>OI8mZtjnBa3+HUeBjXkALFvWRL9ifhzo3CebZs/YlyngtkJEIQLNxu3o2waCeANl
>VLyD+FFtJeal9P4et6J8200Q9BZ0D+uRDd1h5vRkXVogFLwq6OV7Yn0PwaZg4w2X
>dM9/u7lzCb3XL5KpBPp+k4Z+KogrN9T6nlIl39GycTABneUXIf/CWQ==
>=ddwI
>-----END PGP SIGNATURE-----
>_______________________________________________
>Roll mailing list
>Roll at ietf.org
>https://www.ietf.org/mailman/listinfo/roll