Subject: [Roll] Clarifications on Section 16 "Manageability considerations"

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Tue, 13 Jul 2010 13:47:30 +0200

Hi All,

Just reviewed Section 16, here is some feedback that might help clarify:

- In 16.2.3, 16.2.4 It is not very clear which parameters are configured
versus negotiated dynamically through messages. 

- In 16.2.4 “A RPL implementation SHOULD allow configuring whether a
non-storing node provides the transit information in DAO messages.”
Shouldn’t a node always include the transit info in DAO messages? Aren’t the
2 first bullet related to the DAO mechanism and hence more appropriate in
Section 16.2.6 (or maybe we should just remove Section 16.2.6)

- In 16.2.5, T flag has not been removed

- In 16.2.6, this section contains legacy text (already mentioned in
previous email thread)

- In 16.6, is the DODAGID necessarily part of the policy?

- In 16.7/16.9 or 16.4. Maybe it would help to further specify what services
RPL expects to be handled by other protocols such as ND. I’m talking of
course of services that RPL directly relies on to operate. NUD is mentioned
but what about address resolution, etc. I guess this is kind of standard so
not sure if we should include it.

- In general, Sections 16.3 to 16.5 can be difficult to implement on
constrained nodes without interface or file system. I would emphasize that
it is expected that constrained nodes do not implement these parts.

Best,

Mathilde

http://www.cisco.com/swa/i/logo.gif

Durvy Mathilde
Software Engineer
Technology center

 <mailto:[email-masked]> [email-masked]
Phone: +41 21 822 1725
Mobile: +41 76 396 8116

Cisco Systems International Sàrl
Av. des Uttins, 5
CH-1180 Rolle

 <http://www.cisco.com> Cisco home page

Think before you print.Think before you print.

This e-mail may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or disclosure
by others is strictly prohibited. If you are not the intended recipient (or
authorized to receive for the recipient), please contact the sender by reply
e-mail and delete all copies of this message.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 16 Jul 2010 12:33:43 +0200

Thanks for your comments - see in line,

On Jul 13, 2010, at 1:47 PM, Mathilde Durvy (mdurvy) wrote:

> - In 16.2.3, 16.2.4 It is not very clear which parameters are  
> configured versus negotiated dynamically through messages.

All the parameters are the ones that a RPL MAY/SHOULD/MUST allow for  
configuration only. I will add some text to clarify.

> Shouldn’t a node always include the transit info in DAO messages?

Correct, what I meant was the requirement to configure the MOP (this  
was already in 16.2.5), which implies to send transit information for  
non storing mode, but this was not clear indeed. I removed it from  
there. By the way, I added the Route information and Prefix  
information that were missing.

> Aren’t the 2 first bullet related to the DAO mechanism and hence  
> more appropriate in Section 16.2.6 (or maybe we should just remove  
> Section 16.2.6)

Yes I updated 16.2.6, which was outdated after we removed the DAO FSM.  
Thanks.

> - In 16.2.5, T flag has not been removed

Fixed (old text, good catch). I also added text on DTSN.

> - In 16.2.6, this section contains legacy text (already mentioned in  

Fixed (old text, good catch)

> - In 16.6, is the DODAGID necessarily part of the policy?

Yes I agree, a MUST was too strong (I changed it or a SHOULD).

> - In 16.7/16.9 or 16.4. Maybe it would help to further specify what  
> services RPL expects to be handled by other protocols such as ND.  
> I’m talking of course of services that RPL directly relies on to  
> operate. NUD is mentioned but what about address resolution, etc. I  
> guess this is kind of standard so not sure if we should include it.

I do not think, it will belong to the Arch ID David and I should have  
started to work on ... Does not belong to this document.

> constrained nodes without interface or file system. I would  
> emphasize that it is expected that constrained nodes do not  
> implement these parts.

Not sure is you saw it, but there is already pretty explicit text in  
Section 16.1:

    RPL will be used on a variety of devices that may have resources  
such
    as memory varying from a very few Kbytes to several hundreds of
    Kbytes and even Mbytes.  When memory is highly constrained, it may
    not be possible to satisfy all the requirements listed in this
    section.  Still it is worth listing all of these in an exhaustive
    fashion, and implementers will then determine which of these
    requirements could be satisfied according to the available resources
    on the device.
Attached the changes. Let me know if you agree with the proposed  
resolution and I'll close the ticket.

Thanks.

JP.

> [email-masked]
> Cisco home page
> Think before you print.
> This e-mail may contain confidential and privileged material for the  
> sole use of the intended recipient. Any review, use, distribution or  
> disclosure by others is strictly prohibited. If you are not the  
> intended recipient (or authorized to receive for the recipient),  
> please contact the sender by reply e-mail and delete all copies of  
> this message.
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Mon, 19 Jul 2010 09:35:40 +0200

Hi JP,

Thanks for updating Section 16. A few minor points below.

Best,

Mathilde

[Mathilde] I'm not sure what you mean by 'configuration only'. Do you mean
not negotiated dynamically? Then it seems to me that parameters that are
part of the policy must be configured while other may be. For some
parameters (OCP, Route information, DODAGID, MOP) it is still not specified
in which category (may, should, must) they belong

- In 16.2.4 "A RPL implementation SHOULD allow configuring whether a
non-storing node provides the transit information in DAO messages."
Shouldn't a node always include the transit info in DAO messages? 

Correct, what I meant was the requirement to configure the MOP (this was
already in 16.2.5), which implies to send transit information for non
storing mode, but this was not clear indeed. I removed it from there. By the
way, I added the Route information and Prefix information that were missing.

[Mathilde] Shouldn't Route information and Prefix information be in 16.2.3
(right now they are also in 16.2.4 and 16.2.5, so we have a problem :-) ).
I would also add some text on what it means to configure the target prefix.
This is not very clear to me. Do you mean decide which of the node's
addresses / prefixes should be in a target option?

Aren't the 2 first bullet related to the DAO mechanism and hence more
appropriate in Section 16.2.6 (or maybe we should just remove Section
16.2.6)

[Mathilde] Thanks. Maybe 16.2.4 Target option should also go there

Not sure is you saw it, but there is already pretty explicit text in Section
16.1:

   When memory is highly constrained, it may
   not be possible to satisfy all the requirements listed in this
   section.  
[Mathilde] Well the 'may' is a bit weak in my opinion. But I'm OK to keep it
as is.

Attached the changes. Let me know if you agree with the proposed resolution
and I'll close the ticket.

[Mathilde] I think once we implement the minor changes above we can close
the ticket.

---

From: JP Vasseur <[email-masked]>
Date: Tue, 20 Jul 2010 15:02:46 +0200

Hi Mathilde,

> Thanks for updating Section 16. A few minor points below.

Sure, in line.

> [Mathilde] I'm not sure what you mean by 'configuration only'. Do  
> you mean not negotiated dynamically?

Right.

> Then it seems to me that parameters that are part of the policy must  
> be configured while other may be. For some parameters (OCP, Route  
> information, DODAGID, MOP) it is still not specified in which  
> category (may, should, must) they belong

JP> I see what you're referring to; a sentence was missing in 16.2.3  
and 16.2.4. Added.

> was already in 16.2.5), which implies to send transit information  
> for non storing mode, but this was not clear indeed. I removed it  
> from there. By the way, I added the Route information and Prefix  
> [Mathilde] Shouldn't Route information and Prefix information be in  
> 16.2.3 (right now they are also in 16.2.4 and 16.2.5, so we have a  
> problem :-) ).

JP> Yes ! Done.

> I would also add some text on what it means to configure the target  
> prefix. This is not very clear to me. Do you mean decide which of  
> the node's addresses / prefixes should be in a target option?
>

JP> Yes. I prefer to leave it as is, since the target option may be  
augmented in the future.

> Yes I updated 16.2.6, which was outdated after we removed the DAO  
> FSM. Thanks.
> [Mathilde] Well the ‘may’ is a bit weak in my opinion. But I'm OK to  
> keep it as is.
>
> [Mathilde] I think once we implement the minor changes above we can  
> close the ticket.

Here is the new version. Let me know what you think.

Cheers.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Tue, 20 Jul 2010 16:51:43 +0200

Just had a quick discussion with Mathilde to clarify a few things.  
Mathilde, here is the new version.
Let me know if we are in sync.

Cheers.

JP.

On Jul 20, 2010, at 3:02 PM, JP Vasseur wrote:

>> All the parameters are the ones that a RPL MAY/SHOULD/MUST allow  
>> for configuration only. I will add some text to clarify.
>> Then it seems to me that parameters that are part of the policy  
>> must be configured while other may be. For some parameters (OCP,  
>> Route information, DODAGID, MOP) it is still not specified in which  
>> - In 16.2.4 “A RPL implementation SHOULD allow configuring whether  
>> a non-storing node provides the transit information in DAO  
>> messages.” Shouldn’t a node always include the transit info in DAO  
>> messages?
>> Correct, what I meant was the requirement to configure the MOP  
>> (this was already in 16.2.5), which implies to send transit  
>> information for non storing mode, but this was not clear indeed. I  
>> removed it from there. By the way, I added the Route information  
>> and Prefix information that were missing.
>> - In general, Sections 16.3 to 16.5 can be difficult to implement  
>> on constrained nodes without interface or file system. I would  
>> Not sure is you saw it, but there is already pretty explicit text  
>> in Section 16.1:
>> [Mathilde] Well the ‘may’ is a bit weak in my opinion. But I'm OK  
>> to keep it as is.
>>
> <section-16-for-RPL-rev-11.pdf>

---

From: JP Vasseur <[email-masked]>
Date: Tue, 20 Jul 2010 16:53:39 +0200

Cheers.

JP.

---

From: "Mathilde Durvy (mdurvy)" <[email-masked]>
Date: Wed, 21 Jul 2010 11:22:14 +0200

Hi JP,

Perfect! Thanks.

Just a couple of typos:

- "Some of the RPL parameters are optional. The requirementS for
configuration are only applicable IF the optionS are in use.

- last sentence of 16.2.3 should probably be a bullet point. Also given the
sentence above that you added at the beginning of the Section there is
probably no need for the 'if' part of the sentence anymore.

- 16.2.5 you might want to keep the DODAG preference (while removing the MOP
of you already did)

Best,

Mathilde

From: JP Vasseur [mailto:[email-masked]] 
Sent: mardi, 20. juillet 2010 16:54
To: Mathilde Durvy (mdurvy)
Cc: roll WG
Subject: Re: [Roll] Clarifications on Section 16 "Manageability
considerations"

Just had a quick discussion with Mathilde to clarify a few things. Mathilde,
here is the new version.

Cheers.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 21 Jul 2010 20:41:02 +0200

Typos fixed. Great, I'll close the ticket then.

Thanks for your comments.

JP.

On Jul 21, 2010, at 11:22 AM, Mathilde Durvy (mdurvy) wrote:

> Hi JP,
>
> Perfect! Thanks.
>
> Just a couple of typos:
> - “Some of the RPL parameters are optional. The requirementS for  
> - last sentence of 16.2.3 should probably be a bullet point. Also  
> given the sentence above that you added at the beginning of the  
> Section there is probably no need for the ‘if’ part of the sentence  
> anymore.
> - 16.2.5 you might want to keep the DODAG preference (while removing  
> the MOP of you already did)
>
> Best,
> Mathilde
>