Hi Ketan,

Jumping directly to...

>
>> 15              draft-ietf-pce-segment-routing-policy-cp-15
>>>
>>> 17 Abstract
>>>
>>> 19   Segment Routing (SR) allows a node to steer a packet flow along any
>>> 20   path.  SR Policy is an ordered list of segments (i.e., instructions)
>>> 21   that represent a source-routed policy.  Packet flows are steered
>>> into
>>> 22   an SR Policy on a node where it is instantiated called a headend
>>> 23   node.  An SR Policy is made of one or more candidate paths.
>>>
>>> 25   This document specifies Path Computation Element Communication
>>> 26   Protocol (PCEP) extension to associate candidate paths of the SR
>>> 27   Policy.  Additionally, this document updates [RFC8231] to allow
>>> 28   stateful bringup of an SR LSP, without using PCReq/PCRep messages.
>>> 29   This document is applicable to both Segment Routing over MPLS and to
>>> 30   Segment Routing over IPv6 (SRv6).
>>>
>>>
>>>
>>> *[major] This document has the specifications that actually align the
>>> PCEPextensions (e.g. RFC8664) for SR defined prior to this document to the *
>>> *SR Policy architecture RFC9256. This should be the most important thing
>>> to call out and that this spec formally updates RFC8664 and *
>>> *RFC-draft-ietf-pce-segment-routing-ipv6.*
>>>
>>>
>> Dhruv: Happy for the authors to make it clearer but I don't think there
>> is a need for a formal update. "Update" makes sense when there is some text
>> in those RFCs that require changes. It is just a normal extension. From
>> PCEP POV, SR-MPLS and SRv6 extensions for those path setup types exist on
>> their own. If SR Policy is in use, then of course this document should be
>> used.
>>
>
> KT> What is being signaled via RFC8664 is something that is not defined in
> SR Architecture but those specs are still called SR extensions. Putting a
> formal "update" points readers that this document is what extends those
> previous documents for SR Policy (and thereby SR) extensions.
>
>

Dhruv: It is a classic discussion of what does "update" mean :)
See https://datatracker.ietf.org/doc/html/draft-kuehlewind-update-tag
Till things change, in PCE WG, we apply "update" only when there is a
change in text in a previously published RFC. I personally would like to
keep it that way. Authors can add text in abstract/introduction to make
your point explicit.

Thanks!
Dhruv

>
>>
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Reply via email to