Subject: [SRv6OPS] Re: [spring] Second WG Last Call: draft-ietf-spring-srv6-security-14 (Ends 2026-06-02)
From: Suresh Krishnan <[email-masked]>
To: Alvaro Retana <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Fri, 29 May 2026 22:39:50 -0400
List-Id: "SRv6 Operations (SRv6OPS) Working Group List" <srv6ops.ietf.org>

Hi chairs/authors,
  Thank you for your hard work on this important document. I have reviewed draft-ietf-spring-srv6-security-14 and I think it is ready to progress further in the IETF process. I do have some minor comments that you may want to address

* Section 6.1.

This sentence is missing a verb and does not read right. Suggest rewording to

OLD:
While it is possible for packet manipulation and processing attacks against all the fields of the IPv6 header and its extension headers, this document limits itself to the IPv6 header and the SRH.

NEW:
While packet manipulation and processing attacks are possible against all the fields of the IPv6 header and its extension headers, this document limits itself to attacks on the IPv6 header and the SRH.

* Section 6.2.1.1.

This sentence is a bit confusing. Suggest rewording 

OLD:
However, it facilitates more complex on-path attacks by redirecting traffic to another node that the attacker has access to with more processing resources.

NEW:
However, it facilitates more complex on-path attacks by redirecting traffic to another node, with more processing resources, that the attacker has access to.

* Section 8.1.

Not sure what "take care of” means here? I would suggest using “handle” or “inspect” depending on what you intend to say here.

Regards
Suresh

> On May 18, 2026, at 3:44 PM, Alvaro Retana via Datatracker <[email-masked]> wrote:
> 
> This message starts a Second WG Last Call for:
> draft-ietf-spring-srv6-security-14
> 
> This Working Group Last Call ends on 2026-06-02
> 
> Abstract:
>   SRv6 is a traffic engineering, encapsulation and steering mechanism
>   utilizing IPv6 addresses to identify segments in a pre-defined
>   policy.  This document discusses security considerations in SRv6
>   networks, including the potential threats and the possible mitigation
>   methods.  The document does not define any new security protocols or
>   extensions to existing protocols.
> 
> File can be retrieved from:
> 
> Please review and indicate your support or objection to proceed with the
> publication of this document by replying to this email keeping
> [email-masked] in copy. Objections should be explained and suggestions to
> resolve them are highly appreciated.
> 
> Authors, and WG participants in general, are reminded of the Intellectual
> Property Rights (IPR) disclosure obligations described in BCP 79 [1].
> Appropriate IPR disclosures required for full conformance with the provisions
> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
> Sanctions available for application to violators of IETF IPR Policy can be
> found at [3].
> 
> Thank you.
> 
> [1] https://datatracker.ietf.org/doc/bcp78/
> [2] https://datatracker.ietf.org/doc/bcp79/
> [3] https://datatracker.ietf.org/doc/rfc6701/
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-spring-srv6-security-14.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-spring-srv6-security-14
> 
> _______________________________________________
> spring mailing list -- [email-masked]
> To unsubscribe send an email to [email-masked]