[Idr] (Returning doc to WG) AD review of draft-ietf-idr-ts-flowspec-srv6-policy-10

[Ketan Talaulikar <[e-mail]>]

Hello Authors/WG.

I do not see this document as ready for publication as a Proposed Standard
in its current state. In consultation with the shepherding co-chair and the
IDR chairs, I am sending this document back to the WG.

Since this is a Proposed Standard document, it must first and foremost
cover the protocol specification. This aspect was likely missed when the
document changed its track from Informational.

The core of the document is section 3 and this should be perhaps named
Procedures instead of Operations. In this section, please specify the
sender's and receiver's behavior clearly and in detail. How is the flowspec
route formed, and what are the semantics of ECs and BGP Prefix SID Attr
(including which TLVs are used and which SIDs are signaled). Perhaps
specify the common aspects first, followed by the SR-MPLS and SRv6 parts.
Consider rolling the examples (from sections 4 and 5) into the text but
ensure the normative text fully describes the procedures without relying on
the examples.

If authors would like to describe the operations or the use-case, please
place this description in a section before the Procedures so readers can
better understand the context. Feel free to add operational considerations.

I would also like the WG to consider if this document really updates
RFC8669. If this is only about using the BGP Prefix SID Attribute with the
flowspec address family, then this is not changing what RFC8669 specified,
as it explicitly allowed future documents to do so (see below).

The BGP Prefix-SID attribute defined in this document can be attached to
prefixes from Multiprotocol BGP IPv4/IPv6 Labeled Unicast ([RFC4760
<https://www.rfc-editor.org/rfc/rfc8669.html#RFC4760>] [RFC8277
<https://www.rfc-editor.org/rfc/rfc8669.html#RFC8277>]). *Usage of the BGP
Prefix-SID attribute for other Address Family Identifier (AFI) / Subsequent
Address Family Identifier (SAFI) combinations is not defined herein but may
be specified in future specifications.*

Other suggestions:
a) The document spends too much text describing Segment Routing and SR
Policies and it uses language that doesn't align with those specifications.
This can be trimmed by simply referencing RFC8402 and RFC9256. If you must
provide an overview, use language directly from those documents.
b) Remove all references to and discussion of FSv1 and v2. At this point in
the process, the term FSv1 does not exist, and FSv2 is something still with
the WG. So, just referring to FlowSpec (RFC8955/6) is sufficient.
c) Rename "Running Code" to Implementation Status and add a note for RFC
Editor to remove that section before publication.
d) In the security considerations, at a minimum refer to the security
considerations of base flowspec and quite likely also the relevant Segment
Routing RFCs. There may be something more, but I suggest getting another
Secdir review after the document better reflects the procedures.
e) Please consider submitting the XML so that reviewers see a proper HTML
rendering.

A clearer and tighter protocol specification will help progress this
document on the proposed standards track through further reviews.

Thanks,
Ketan