Re: [Roll] WGLC on draft-ietf-roll-turnon-rfc8138-04

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Dominique;

Many thanks for this!


First of all, I accepted (gladly) your proposed changes in github.

There was one that did not fit in 5.2, and rereading the text around I realized it needed realignment with USEofRPLinfo and unaware-leaves.

The point is that a 6LR does not need to be the endpoint of a tunnel to undo the compression. It does that as part of the forwarding.



Suggested 5.2 is now:




5.2.  Single RPL Instance Scenario

   In a Single RPL Instance Scenario, nodes that support [RFC8138] are
   configured with a new OCP, that may use the same OF operation or a
   variation of it.  The Root sets the "T" flag at the time it migrates
   to the new OCP.  As a result, a node that does not support [RFC8138]
   joins as a leaf, which is an IPv6 Host, and does not forward packets.

   The parent - which supports [RFC8138] - compresses the packets
   originated from the leaf and uncompresses the packets going to the
   leaf.  This may be done on the fly by the parent if the leaf behaves
   as a RAL or using a tunnel between the parent and the Root, if the
   leaf behaves as a RUL, as described in section 7, 8, and 9 of
   [USEofRPLinfo].  Note that though tunneling from the Root to the
   parent is the generic case for RULs, it is possible for the Root to
   avoid it for the traffic that it originates.

> Regarding the title change to turnon-6LoRH: I understand that 8138 might get updated in the future. However, should the "T" bit mean that 6LoRH compression is in effect, irrespective of the version of this compression, or precisely that 8138 compression is in effect? If the former, what is the plan for managing the RPL nodes when successive versions of 6LoRH are introduced?
The plan is to use the capabilities once available with MoP > 7.

> Section 4, "delivering to a leaf that is not known to support RFC8138". Wouldn't a reference to the capabilities draft be appropriate here?
I’m concerned that people may want to make capabilities a normative reference, in which case I’ll have to remove that text.
I preferred to do that change in the first occurrence, in the introduction,  as below:

   With RPL, a leaf is an IPv6 Host, which implies that leaves do not
   forward packets.  This specification provides scenarios that force a
   non-capable RPL-Aware Node (RAN) to become a leaf.  The parent router
   must know, e.g., by configuration, or leveraging "RPL Capabilities"
   [CAPABILITIES], when a leaf does not support the compression defined
   in [RFC8138].  This is implicitly the case for a RPL-Unaware Leaf
   (RUL) but is not known for a RPL-Aware Leaf (RAL).  The parent router
   must uncompress the packets before delivering them to a non-capable
   leaf and it must compress the traffic from the leaf.

> Section 5: "A node that supports [RFC8138] but not this specification can only be used in a homogeneous network and an upgrade requires a "flag day" where all nodes are updated and then the network is rebooted with implicitly RFC 8138 compression turned on with the "T" flag set on." This sentence is too long. It could be broken in two after "flag day". "implicitely" seems strange, the RPL implementation would be hard-coded to use RFC8138 compression, very explicitly. "with the T flag set on" seems strange too, it seems to me the T flag would not be on if the nodes don't know this specification. Isn't it the whole purpose of the node configuration to explicitly override the "off" T bit? This paragraph need a little attention.
Well that’s when the is not ‘T’ at all known to the code, for code written between RFC 8138 and now. So how about:
   A node that supports [RFC8138] but not this specification can only be
   used in an homogeneous network.  Enabling the [RFC8138] compression
   requires a "flag day"; all nodes must be upgraded, and then the
   network can be rebooted with the [RFC8138] compression turned on.
> Section 6, Table 1: it seems unfortunate that the second column is entitled "Capability Description". This name conflicts with the capabilities of the RPL nodes. This bit is a configuration option flag. By the way, RFC6550 20.14 does not say "Capability Description", but simply "Description". Why not stick with "Description" for this column in this table?
I aligned to: https://www.iana.org/assignments/rpl/rpl.xhtml#dodag-config-option-flags which maps to the text in RPL above though not in the table.
Note that RPL uses capability throughout (see 20.4!). So the term is largely overloaded already, unsure we can still do anything.

I added my on editorial changes and published 05:

https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-turnon-rfc8138-05
Please let me know if that solves the issues you raised.
Again, many thanks.
Keep safe!
Pascal


From: [e-mail] <[e-mail]>
Sent: lundi 23 mars 2020 18:42
To: Routing Over Low power and Lossy networks <[e-mail]>; Pascal Thubert (pthubert) <[e-mail]>
Subject: Re: [Roll] WGLC on draft-ietf-roll-turnon-rfc8138-04

Hello Pascal, all,

I've read version –04 of draft-ietf-roll-turnon-rfc8138.
I've submit a Pull Request on GitHub with some nit fixes.
I have a few questions and comments:

  *   Regarding the title change to turnon-6LoRH: I understand that 8138 might get updated in the future. However, should the "T" bit mean that 6LoRH compression is in effect, irrespective of the version of this compression, or precisely that 8138 compression is in effect? If the former, what is the plan for managing the RPL nodes when successive versions of 6LoRH are introduced?
  *   Section 4, "delivering to a leaf that is not known to support RFC8138". Wouldn't a reference to the capabilities draft be appropriate here?
  *   Section 5: "A node that supports [RFC8138] but not this specification can only be used in a homogeneous network and an upgrade requires a "flag day" where all nodes are updated and then the network is rebooted with implicitly RFC 8138 compression turned on with the "T" flag set on." This sentence is too long. It could be broken in two after "flag day". "implicitely" seems strange, the RPL implementation would be hard-coded to use RFC8138 compression, very explicitly. "with the T flag set on" seems strange too, it seems to me the T flag would not be on if the nodes don't know this specification. Isn't it the whole purpose of the node configuration to explicitly override the "off" T bit? This paragraph need a little attention.
  *   Section 6, Table 1: it seems unfortunate that the second column is entitled "Capability Description". This name conflicts with the capabilities of the RPL nodes. This bit is a configuration option flag. By the way, RFC6550 20.14 does not say "Capability Description", but simply "Description". Why not stick with "Description" for this column in this table?
Notwithstanding these questions and comments, I personally support this work and wish to see it move forward.
Best regards,

Dominique

De : Roll <[e-mail]<mailto:[e-mail]>> on behalf of "Pascal Thubert (pthubert)" <pthubert=[e-mail]<mailto:pthubert=[e-mail]>>
Répondre à : "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date : Tuesday 10 March 2020 14:50
À : "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Objet : Re: [Roll] WGLC on draft-ietf-roll-turnon-rfc8138-04

I agree with Rahul on both counts, taking the doc to the next step (as author) and changing the title (as participant).

…

Our milestone is to submit it this month and I intend to put a focus on this;

All the best, and for those who still plan to fly to IETF 107, sorry I will not be in Vancouver to meet you : (

Pascal

From: Roll <[e-mail]<mailto:[e-mail]>> On Behalf Of Rahul Jadhav
Sent: lundi 9 mars 2020 09:40
To: roll <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Roll] WGLC on draft-ietf-roll-turnon-rfc8138-04

Hello All,

As someone who had previously reviewed the draft, I would like this work to be taken to the next logical step.

Also is it possible to rename the draft as "turnon-6LoRH" rather than "turnon-rfc8138"? Isn't it possible for RFC 8138 to be updated in the future? Similarly, the title may be "Configuration Option for 6LoRH" in place of "Configuration Option for 8138". Just a thought.

Best,
Rahul

________________________________
From: Roll <[e-mail]<mailto:[e-mail]>> on behalf of [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: 06 March 2020 03:38 PM
To: roll <[e-mail]<mailto:[e-mail]>>
Cc: Ines Robles <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Roll] WGLC on draft-ietf-roll-turnon-rfc8138-04

Working Group,

The WGLC for draft-ietf-roll-turnon-rfc8138-04 was due to expire yesterday.
No comment was received so far.
Before we equate silence with agreement, please take some time to reflect on this draft, maybe even review it and most importantly send your thoughts.
Simple responses like "yes", "I approve it" are valid, too.
As chairs, we need to gauge consensus. Please help us serving the community.
Best regards

Inès & Dominique

De : "mariainesrobles@googlemail..com<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date : Thursday 20 February 2020 10:16
À : "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc : Dominique Barthel <[e-mail]<mailto:[e-mail]>>
Objet : WGLC on draft-ietf-roll-turnon-rfc8138-04

Dear all,

This is a Working Group Last call for draft-ietf-roll-turnon-rfc8138-04

Please send your comments by 5th March 2020

Thank you very much in advance,

Ines and Dominique.

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.