[Roll] Mail regarding draft-thubert-roll-asymlink

[Yoav Ben-Yehezkel <[e-mail]>]

Dear Roll-ers,

Find below comments to the draft.

Mostly editorial, I hope they make sense.

Best regards,

Yoav



Comments to Introduction section 1:

   In one hand, RPL requires bi-directional links for the control, but

   on the other, there is no requirement that the properties of a link

   are the same in both directions.  In fact, a perfect symmetry is

   rarely present in Low Power and Lossy Networks (LLNs), whether links

   are based on radios or power-line.

1.       Replace “In one hand” with “On one hand”

2.       Replace “on the other,” with “on the other hand,”.

3.       Replace “whether links are based on radios or power-line” with
“such as wireless radio or power-line links.”



   Some initial implementations require that the quality of both

   directions of a link is evaluated as very good so that the link can

   be used for control and data in both directions.  This eliminates

   asymmetrical links that are very good in one direction, but only good

   enough for scarce activity in the other direction.



4.       Replace “that the quality of both directions of a link is
evaluated as very good” with “that the quality of both directions of a link
is evaluated as operational at an acceptable level” – because they do not
necessarily have to be very good.



Comments to Terminology section 2:

   The term upwards qualifies a link, a DODAG or an instance that is

   optimal for sending traffic in the general direction of the root,

   though may be usable but suboptimal for traffic coming form the

   direction of the root.  The term downwards qualifies the same words

   for the opposite direction.

1.       Should the term “instance” be replaced with the term “RPL
instance”?

2.       What does “general direction of the root” means? Shouldn’t it
simply be “towards the root”?

3.       Replace “though may be usable but suboptimal for traffic coming *
form* the direction of the root“ with “though may be usable but suboptimal
for traffic coming *from* the direction of the root” (form=from)

4.       Replace “The term downwards qualifies the same *words* for the
opposite direction” with “The term downwards qualifies the same
*wording,* *only
*for opposite directions”

5.       Question: shouldn’t the terms “upwards” and “downwards” be
included into the terminology draft?





   bi-directional:  A link is bi-directional when traffic confirmed

      possible in both direction, in a fashion that is sufficient to

      operate RPL control.



1.       Replace “possible in both direction” with “possible in both
direction*s*” (missing ‘s’).



   asymmetric:  A link is assymetric if it is bi-directional, but

      exhibits important differences in link characteristics for both

      directions.

1.       Replace “A link is a*ssym*etric” with “A link is a*symm*etric”
(typo)

2.       Replace “important” with “major”



Comments to The asymmetrical link problem section 3:

1.       Capitalize first letter of each word like in all other sections.



Comments to Solution Overview section 4:

   One direct consequence of that design

   choice is that a topology must be very good for both upwards and

   downwards traffic;

1.       Replace “very good” with “operational at an acceptable level”.



   In that case, an asymmetrical link,

   that can only be used for traffic in one direction, can not

   participate to the routing topology.

1.       Replace “can not” with “cannot”.



   OTOH, with RPL as it is specified,...

1.       Replace “OTOH” with “On the other hand”.



   ... so that a node may transfer traffic from an instance onto another.

1.       Replace “an instance onto another” with “an upwards instance onto
the downwards instance”.



Comments to Modified DIO section 5:

   Directional (D):  The Directional (D) flag is set to indicate that

         the instance is intended for directional operation, and reset

         otherwise.  When it is set, a MOP of 0 indicates the upwards

         direction whereas any other value specified in

         [I-D.ietf-roll-rpl] indicates downwards.  All other values of

         MOP will be considered downwards unless explicitly specified

         otherwise.

1.       Replace “and reset otherwise” with “and is reset otherwise”.

2.       Replace “upwards direction” with “upwards”, or add the word
“direction” to all subsequence indications of the word “downwards”

3.       Replace “will be considered downwards” with “shall be considered
downwards”.



Comments to Operations section 6:



   This specification allows an organization of Instances as follows:

1.       Replace “Instances” with “instances” (non-capitalized ‘I’)



      The direction is indicated by the MOP field, a MOP of 0 means

      upwards and otherwise is downwards.

2.       Replace “a MOP of 0 means” with “a MOP set to a value 0 indicates”

3.       Replace “and otherwise is downwards” with “and indicates downwards
if set otherwise”.



      Transferring from an upwards instance to a downwards instance if

      generally desirable. Other forms of transfers are generally not

      desirable.  Policies MAY be put in place to ovreride that general

      guidance.



1.       Replace “if” with “is”

2.       Remove “generally” and “general” or explain what they mean.

3.       Replace “put in place” with “used”

4.       Replace “ovreride" with “override”



Comments to Backward compatibility section 7:

1.       Replace “Backward” with “Backwards”

2.       Replace “compatibility” with “Compatibility” (capital ‘C’)



   An OF is generally designed to compute a Rank of a directional link

   in a fashion that is diffent from a bidirectional link, and in

   particular will not use the same metrics and thusobtain different

   ranks for a same situation.

1.       Replace “diffent” with “different”

2.       Missing space between “thus” and “obtain”



   An OF that supports directional links SHOULD favor directional links over

   non directional links, in a fashion that is to be specified with the

   OF.  In the case of OF0 [I-D.ietf-roll-of0], the 'D' flag should be

   accounted for before the computation of item 8 in the "Selection Of

   The Preferred Parent" section 4.2.1., that is before Ranks and be

   calculated and compared.

1.       Replace “specified with the OF” with “specified by the OF”

2.       Replace “section 4.2.1.,” with “section 4.2.1,” (remove extra dot)

3.       Replace “that is before *R*anks and be calculated and
compared” with “that is before *r*anks are calculated and compared”
(is there anything else that needs comparison other than the rank?)



Comments to IANA Considerations section 8:

   This specification requires that a bit in DIO be assigned to indicate

   directional link operations as specified in section

1.       Replace “a bit in DIO be assigned” with “a bit in DIO shall be
assigned”

2.       Replace “as specified in section” with “as specified in section 5”



Comments to Security Considerations section 9:

   Security Considerations for this proposal are to be developed in

   accordance with recommendations laid out in, for example,

   [I-D.tsao-roll-security-framework].

1.       Replace “Security *C*onsiderations for this proposal” in the first
line with “Security *c*onsiderations for this proposal” (non-capitalized
‘c’)