Hi John,
Thank you very much for pointing this out. I completely agree that they should be applied thoughtfully rather than indiscriminately, However, I think capitalization is more appropriate in the following cases.
-But the RPL routing information headers may not be supported on all type of routed network infrastructures, especially not in high-speed routers.
-The RPL Root must add a source routing header to all downward packets.
-If the 'K' Flag is present in the P-DAO, the P-DAO must be acknowledged using a DAO-ACK that is sent back to the address of the Root from which the P-DAO was received.
-A P-DAO that creates or updates a protection path MUST be sent to a GUA or a ULA of the Ingress of the protection path; it must contain the full list of hops in the protection path unless the protection path is being removed.
-The router MAY install additional routes towards the Via Addresses that appear in the SM-VIO after its own address, if any, but in case of a conflict or a lack of resource, the route(s) to the Target(s) are the ones that must be installed in priority.
-When injecting a packet in a Track, the Ingress router must encapsulate the packet using IP-in-IP to add the Source Routing Header with the final destination set to the Track Egress.
-With this specification, only the Root may generate P-DAO messages. PDR messages may only be sent to the Root.
-That trust should propagate from Egress to Ingress in the case of a Storing Mode P-DAO.
Best Regards,
Ran
Thanks for the review. I have one comment; your first nit is:
> -I suggest BCP14 (may=> MAY, should=>SHOULD, must => MUST) change
I would strongly caution against blindly doing replacements as described; RFC 2119 keywords are supposed to be used sparingly. Quoting RFC 2119 Section 6,
Imperatives of the type defined in this memo must be used with care
and sparingly.
Indeed, if you use the all-caps version everywhere those words occur, I can almost guarantee pushback during IESG review.
Of course, if there are specific places in the present document where a keyword would help, that’s fine. (I did look for such things during my review and it seemed fine, but I’m fallible.)
Thanks,
—John
> On Mar 5, 2025, at 10:07 AM, Ran Chen via Datatracker <noreply@xxxxxxxx> wrote:
>
> [External Email. Be cautious of content]
>
>
> Reviewer: Ran Chen
> Review result: Has Nits
>
> # OPSDIR review of draft-ietf-roll-dao-projection
>
> I have reviewed this document as part of the Operational directorate's ongoing
> effort to review all IETF documents being processed by the IESG. These
> comments were written with the intent of improving the operational aspects of
> the IETF drafts. Comments that are not addressed in the last call may be
> included in AD reviews during the IESG review. Document editors and WG chairs
> should treat these comments just like any other last-call comments.
>
> This document extends RFC 6550, RFC 6553, and RFC 8138, introducing the DAO
> Projection
> mechanism to enhance RPL. It enables the RPL root or an external controller to
> proactively install optimized routes, improving routing efficiency,
> reliability, and resource utilization. Additionally, the draft addresses
> backward compatibility, all nodes involved in P-DAO processing must support
> this specification. The document is clear and well-written. The motivation is
> described well. The document is almost ready for publication.
> ## Nits
> -I suggest BCP14 (may=> MAY, should=>SHOULD, must => MUST) change
> -The document use TrackID, Trackid, trackID, it is recommended to unify them.
> -s/additional paths betwwen nodes/ additional paths between nodes/
> -s/ oriented From Ingress / oriented from Ingress /
> -s/ Building Tracks With RPL/ Building Tracks with RPL/
> -s/ edges leads to/ edges lead to/
> -s /may be ommitted/ may be omitted/
> -s/ The latter is often is preferred/ The latter is often preferred/
> -s/ the position preceeding the one/ the position preceding the one/
> -s/ The (suggected)/ The (suggested)/
>
>
>
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
