Re: [Roll] Write Up draft-ietf-roll-dao-projection-30

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

Hello Ines

The sentence « under the heading » derives  ce from IANA ´s recommended formulation.
Apart from that I’ll make your proposed changes as well as Alvaro’s in github, and publish later with Alvaro’s review if that’s ok with you?
About code 8 we’ll great catch; as you say IANA will fix that, but I can always suggest a new one.

All the best,

Pascal

Le 3 janv. 2023 à 22:00, Ines Robles <[e-mail]> a écrit :


Many thanks Pascal for addressing the comments, found minor issues in version 31 (apologizes if I miss them in version 30).

Section 11.2: "...under the heading "Routing Protocol for Low Power and Lossy Networks (RPL)", should it be " ..under the header "IPv6 Low Power Personal Area Network Parameters".." based on
https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#elective-6lowpan-routing-header-type

Same as section 11.3: "...under the heading "Routing Protocol for Low Power and Lossy Networks (RPL)", should it be " ..under the header "IPv6 Low Power Personal Area Network Parameters".." based on
https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#critical-6lowpan-routing-header-type

Section 11.15:

1- ..ICMPv6 Code Fields Registry --> ICMPv6 "Code" Fields Registry
2- ICMPv6 Message Type 1 --> ICMPv6 Message Type 1 "Destination Unreachable" ?
3- The code 8 is already assigned to "Headers too long" [ RFC8883], but I think IANA can assign another code number

Section 11.16: Statuss --> Status

Many thanks and Happy New Year

Ines.

On Tue, Jan 3, 2023 at 4:57 PM Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>> wrote:

Dear Ines



Many thanks for your in depth shepherd review!



Let's see below,



1-Section 2.4.5.1 states "A RPL Local Instance ID", based on section 4.1.1

trackID definition includes global as well, thus TrackID in section 2.4.5.1

should it be "A RPL Local (or Global) Instance ID ...?"



> It can be either though the expectation is to use local instances. I'm scanning through the doc to ensure its left open.



2- Section 2.4.5.3 states: "A Track that has only one path", should it be: "A

Track that has only one path from Ingress to Egress?"



> WFM



3- Section 2.4.5.8.1: The segment example, could it be formulated based on

Figure 1 or Figure 6? If so, could the figure number be added into brackets for

better understanding of the reader.



> good idea, done.



4- In Section 3.5.1.1 reads: "Packets originated by A to F ....", should it be

" Data Packets originated by A to F ...?"



Well there's no checking in the forwarding operation that it is a "Data" packet.





5- Section 3.5.2.3<http://3.5.2.3>:

5.1: "are sent A" --> "are sent to A"



> OK



5.2: Table 16. Column P-DAO 1 to C, row Targets. It is empty, is that Ok, or

should it be "E"?



> See in section 3.5. Serial Track Signaling: "the Egress of a Non-Storing Mode P-DAO is an implicit Target that is not listed in the RPL Target Options." So there's no target signaled (no RTO) but E is implicitly a destination as shown in the RIB in table 17.



6- Section 3.6: the sentence "...and Inter-Leg Segments (aka North-South), such

as Segment 2 above which joins Leg 1 and Leg 2..."



6.1: Should it be Segment 5 instead of 2? (Segment 5 is North-South?)



> oups yes! Thanks 😊



6.2: Or it is Segment 2 and both legs 1 and 2 are joined by node "E"?



> E is the Egress (and I is the Ingress)



6.3: Segment 5 is composed only by nodes "B" and "H", right?



> right in this picture. Could be more hops.



7- Section 4.1: "as usual" --> "as specified in https://datatracker.ietf.org/doc/rfc6550/" ?



> Well that's true for all IP routing, longest match in FIB. I changed to "as normal".



8- Section 4.1.1: "...The 'P' flag is encoded in bit position 2 (to be

confirmed by IANA)..." It would be nice to point the IANA Section where it

belongs, e.g. "...The 'P' flag is encoded in bit position 2 (IANA Request

section 11.13 or Table 31)..."



> done





9- Section 4.1.2: Same as above for "1-bit flag (position to be confirmed by

IANA)", for IANA Section 11.14/Table 32



> done





10- Section 5.3:

10.1- Figure 16: "Type" --> "Option Type"



> done



10.2- In The Field descriptions, the description of the "Flags" field is

missing. It would be nice to add 1 sentence about the flags.



>  done



10.2.1- Is this flags field related to the IANA Request of Section 11.11? If

so, please add it into the description.



> done for SIO and VIO



11-Section 5.4: it reads "...An industrial Alliance that uses RPL for a

particular use / environment MAY redefine the use of this field to fit its

needs..." It would be nice to adapt it to include wider scenarios/use cases.

For e.g. "In some scenarios such as the case of an Industrial Alliances that

uses RPL for a particular use / environment MAY redefine the use of this field

to fit its needs..."



> done





12- Section 6.4.2: Figure 18, It would be nice to mark in the Figure the

Ingress and the Egress as in Figure 19.



> done



13- Section 11.11, reads "No bit is currently assigned for the PDR-ACK Flags."

--> "No bit is currently assigned for the VIO Flags." ?



> done



I pushed the result as https://github.com/roll-wg/dao-projection/commit/217e5c5442df82266bb4d29888e4a450278e303e, and resolved issue 20 since there was no contentious item. I also published https://www.ietf.org/staging/draft-ietf-roll-dao-projection-31.html, the ball is now back in your camp 😊



Many thanks again, Ines, and Happy new year!



Pascal






From: Ines Robles <[e-mail]<mailto:[e-mail]>>
Sent: vendredi 30 décembre 2022 21:03
To: [e-mail]<mailto:[e-mail]>
Cc: dominique barthel <[e-mail]<mailto:[e-mail]>>; roll <[e-mail]<mailto:[e-mail]>>
Subject: Write Up draft-ietf-roll-dao-projection-30

Dear authors,

Please find the write up for dao projection: https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/shepherdwriteup/

There are some minor issues for version 30 created in the ticket https://github.com/roll-wg/dao-projection/issues/20. As soon as these issues are resolved, we believe, it can be submitted to the IESG.

Many thanks and happy 2023!!!

Ines.