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

[Ines Robles <[e-mail]>]

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]>
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:
>
> 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]>
> *Sent:* vendredi 30 décembre 2022 21:03
> *To:* [e-mail]
> *Cc:* dominique barthel <[e-mail]>; roll <
> [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.
>