Many thanks Rishabh for addressing my comments. BR, Ines.
On Wed, Dec 7, 2022 at 2:29 AM Rishabh Parekh <risha...@gmail.com> wrote: > Ines, > > Please find my replies inline below @ [RP] > > >> 1- Requirements Language section should add RFC 8174, i.e. "...."NOT >> RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be >> interpreted as >> described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear >> in all >> capitals, as shown here." >> >> [RP] We will update in the next revision. > > >> 2- There is no terminology section. It would be nice to have a terminology >> section where inform to the reader which document to read to understand >> the >> terminology not defined in the document e.g. "..the operations NEXT, PUSH >> are >> defined in RFC8402 and the POP operation in RFC...; H.Encaps.Red is >> defined in >> ....." >> >> [RP] We can add a terminology section to define new terms introduced in > this draft, but I am not sure if we can list all the terms defined in other > documents referenced in this draft. > > >> 3- Page 3: "Replication-ID can be a 32-bit number, but it can be extended >> or >> modified as required... " -> to which limit can be extended? >> > > [RP] There is no "limit" as such. What the document means is that > Replication-ID can be defined by the use case of Replication segments. For > example, SR P2MP Policy > <https://datatracker.ietf.org/doc/html/draft-ietf-pim-sr-p2mp-policy> > draft (Section 3) uses <Root, Tree-ID> policy identifier as Replication-ID > of replication segments that are instantiated for a P2MP policy. > > >> 4- Question: since the replication state of the nodes can change over >> time. Is >> it possible that in some particular circumstances this change could >> trigger a >> loop in the replication segment? or this is not possible? > > > [RP] Replication within a single replication segment is loop free as long > as SIDs in segment list used to guide a packet from Replication node to > dowstrean modes are loop free. When replication segments are stitched > together for SR P2MP policy, it is upto the controller (PCE) to ensure the > P2MP tree is loop free. > > >> 5- The security considerations states: "There are no additional security >> risks >> introduced by this design". Additional to what features? This is not >> clear to >> me. Perhaps it would be nice to rephrase it to something like: "The >> security >> considerations outlined in RFC 8402, RCF... also applies to this >> document"? >> > > [RP] Sure. We will rephrase the text in the next revision. > >> >> Nits/editorial comments: >> >> 6- Page 7: all the Must and SHOULD... => all the MUST and SHOULD? >> > [RP] If you are referring to the introductory text of Implementation > Status section, it was taken verbatim from Section 2.1 of RFC 7942 where > these words are not capitalized and I don't think they need to be since > this section is to be removed before publication. > >> >> 7- Page 11- Figure 1: It would be nice if the caption of the figure could >> be >> descriptive >> > [RP] I agree - "Figure 1: Figure 1" does not describe anything :) Will > fix in the next revision. > >> >> 8- Page 13 Paragraph 8 and 9: End.Replcate => End.Replicate? >> > [RP] We will fix the typos in the next revision. > >> >> >> > Thanks for a thorough review, > -Rishabh >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
