Re: [Roll] Ticket #10: Closed

[Michael Richardson <mcr at sandelman.ca>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>>>>> "Julien" == Julien Abeille <(jabeille)" <jabeille at cisco.com>> writes:
    >> And if done correctly, interop does happen by magic.  You are
    >> reading this email, because email was standardized.

    Julien> Well I am reading this email because I have a laptop that
    Julien> supports a bunch of RFCs, and bunch of email standards.

Right. When you purchased the laptop, did you have to tell the
salesperson that you would be using the laptop for *IETF* emails?
Did you load an *IETF* *WG* profile into your email system?

You can, ad-hoc, send email to any other email system in the world, for
a variety of purposes.  You can even send voice mail between systems
using SMTP, but it turned out that a restricted profile (a subset) of
SMTP (vpim) is useful. 

    Julien> So I guess we disagree on benefits vs costs. And again if
    Julien> the root does not send OCP0, the game boy having OCP0 is
    Julien> useless. Are we trying to solve an adhoc network problem? Do
    Julien> the requirements drafts and RFCs require this kind of
    Julien> scenario?

If the root node your game boy can see right now does not send OCP0,
then the DAG anchored by that root node is not useful to your game boy.

Being a game boy, it's mobile, and it might see another root node that
is more to its liking.  Also, being mobile, it may well *BECOME* a root
node (an ungrounded one), and maybe I'll play head to head with some
other guy in the next train car.

If that original root node has been configured not to send the OCP0, that's a
configuration decision.  If it can not be configured to send OCP0, then
it's not interoperable.  That might be okay -- you might write a subset
profile of RPL that mandates a different OCPx, and permits OCP0 to be
eliminated -- but you'd claim compliance to that RFC, not the RPL STD.

Almost all WGs (and other SDOs) that build general protocols where there
is not a minimal subset that is MUST, have wound up having to multiple
"profile" documents, and in the end, regularly fail to interop in the field.
(X.500->X509->X509.v3->PKIX->PKI4IPSEC comes to mind)

So the answer is: if a device claims that it supports RPL, then it yes,
it should be possible to configure it to work in an adhoc network.
If all light switches in a home automation application need to support
OCP4 (as specified in RFCXYZQ), and you order them from the factory 
with that as the default, then great.  If the device supports RPL, I
expect to be able to pull the units out of my home (after that kitchen
fire which writes my house off, maybe), and use them at my cottage,
where OCP0 is going to be used.  Maybe I gotta tweak some config
options.

(my last email on this)

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

iQEVAwUBSviyKoCLcPvd0N1lAQI8kgf+IdfKj3o9+BqQhgWLPb8rZPgo8qCuK/lv
B5jUyTXHu/eQmqV5SZXe/FswcAbLu8IE5qc8Hst44H2ZBRcnV2/v2+UnuhxT1WJW
WrBMIzMzeblvq9T+mOajc80fpiq5Ccgjjr/jhE0pbQsKFopjaPCHaOmQd7h6Jksi
SG/1PgFHYVGhULPr+oZQIs7W26cVUTwDcA7DdxqG7B/JiaOPs4p3/R0hfIRnFda4
krxhBDyKblA9k9qkazF/k0B2C2nZuUjX9HZ6d6fN9fAMgKjYsskIUfkTCv6+LO80
4P3ca2u4InaNTFdDu5cDALcW2jTs7dT6ZoVLgXZhF4dFXH3xid+LHg==
=eAVn
-----END PGP SIGNATURE-----