Jim,
Thanks for the comments. I will address the editorial comments below.

On Mon, May 22, 2023 at 6:54 AM James Guichard <
james.n.guich...@futurewei.com> wrote:

> Jim> Replication-ID is now defined twice; in the terminology section and
> in this section. If you want to keep the definition in both places then
> please make the text consistent
>
> as currently it is not.
>

[RP] I will remove it from the Terminology section.

Jim> Further I notice that the document uses both ‘Replication segment’ and
> ‘Replication Segment’. Please choose one and update the document use of the
> chosen term for consistency.
>

[RP] I will fix this. I also noticed similar issue with "Replication
state", "Replication node" and "Downstream nodes". I will fix these too.


>
>
> 144           Replication-ID is a variable length field.  In simplest
> case, it can
>
> 145           be a 32-bit number, but it can be extended or modified as
> required
>
> 146           based on specific use of a Replication segment.  When the
> PCE signals
>
>
>
> Jim> You do not specify how it can be extended or modified, neither do you
> specify any specific use cases. If this is out of scope for the document
> then please say so.
>

[RP] I will add out of scope text.


>
>
> 165           Replication SID identifies the Replication segment in the
> forwarding
>
> 166           plane.  At a Replication node, the Replication SID operates
> on local
>
> 167           state of Replication segment and the resulting behavior MAY
> be
>
> 168           similar to a Binding SID [RFC9256] of a Segment Routing
> Policy.
>
>
>
> Jim> the above paragraph mention of Binding SID still bothers me. The text
> says that it MAY behave like a Binding SID but does not specify any
> guidelines as to when it might or
>
> how it might. Is it necessary to even mention Binding SID here? if it is
> then you need to expand on the text to give the reader some guidance.
>

[RP] On further reading, I agree with you that Binding SID is not strictly
required here. It is more applicable to SR P2MP policy PIM WG draft. I will
remove it from the text.

I will publish next revision addressing your comments.

-Rishabh
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to