[spring] Re: Intended Status of draft-ietf-spring-srv6-security-08.txt - Re: New Version Notification for draft-ietf-spring-srv6-security-08.txt

zengguanming <zengguanming@huawei.com> Mon, 12 January 2026 12:21 UTC

Return-Path: <zengguanming@huawei.com>
X-Original-To: spring@mail2.ietf.org
Delivered-To: spring@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 0973EA661BFB; Mon, 12 Jan 2026 04:21:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level:
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_RFHKB_kAov; Mon, 12 Jan 2026 04:21:04 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 43E92A661BEF; Mon, 12 Jan 2026 04:21:04 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.224.83]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4dqWgL6yf0zHnH6P; Mon, 12 Jan 2026 20:20:46 +0800 (CST)
Received: from kwepemh500011.china.huawei.com (unknown [7.202.181.142]) by mail.maildlp.com (Postfix) with ESMTPS id 8120440086; Mon, 12 Jan 2026 20:21:02 +0800 (CST)
Received: from kwepemf200006.china.huawei.com (7.202.181.232) by kwepemh500011.china.huawei.com (7.202.181.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 12 Jan 2026 20:20:52 +0800
Received: from kwepemq100016.china.huawei.com (7.202.195.35) by kwepemf200006.china.huawei.com (7.202.181.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 12 Jan 2026 20:20:52 +0800
Received: from kwepemq100016.china.huawei.com ([7.202.195.35]) by kwepemq100016.china.huawei.com ([7.202.195.35]) with mapi id 15.02.1544.011; Mon, 12 Jan 2026 20:20:52 +0800
From: zengguanming <zengguanming@huawei.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, "Zafar Ali (zali)" <zali@cisco.com>, SPRING WG List <spring@ietf.org>
Thread-Topic: [spring] Re: Intended Status of draft-ietf-spring-srv6-security-08.txt - Re: New Version Notification for draft-ietf-spring-srv6-security-08.txt
Thread-Index: AQHcQdul9C2PP8k6Nk+wLQFBAQQYyLTLNC/rgAAC0oCARs2hAIABwuWAgBFPTgCAAXEWgIAeWJgggACQpICACYXxUA==
Date: Mon, 12 Jan 2026 12:20:52 +0000
Message-ID: <171e77227f4243b898a2acf7cdf41f85@huawei.com>
References: <176092029759.1973200.513040266258552652@dt-datatracker-84f8f646b-tg6mn> <CABUE3XnKM40NAwTTpt7tck944mNxmY4qtpA3gsrvzj6mcmGsTw@mail.gmail.com> <CAMMESsxwKcywMZrwzYY9U-ME_JLFFvVs6KLLFFO7jg-r3Qwy-Q@mail.gmail.com> <DM6PR11MB4692A2018BF03F9F9844514ADEF5A@DM6PR11MB4692.namprd11.prod.outlook.com> <CAMMESsxcQEm4AD2gJX4eGFhxOzJ7sb7AbMJ4MdehjhwOmxknuA@mail.gmail.com> <CAMMESsyB0RQUmK_okwtMC=AncVky1yhD5m2SSyzPzb10Nu+rLQ@mail.gmail.com> <0C6E17B1-65FD-4E1A-83C5-A94350B74099@cisco.com> <A816FD63-8794-4E35-8D4C-B6E21D82FF95@cisco.com> <CAMMESsx9XW2yUS5ULJtk5Si5XihOfN8UGeLFE61zFFi=DHjQ0w@mail.gmail.com> <DM6PR11MB46928577AEA77BE95798F16DDE87A@DM6PR11MB4692.namprd11.prod.outlook.com> <CAMMESsxSKDJE3xXU+_PcM+qTOaUmPYmmDCo1qcwRHKq9OGwcdQ@mail.gmail.com>
In-Reply-To: <CAMMESsxSKDJE3xXU+_PcM+qTOaUmPYmmDCo1qcwRHKq9OGwcdQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.135]
Content-Type: multipart/alternative; boundary="_000_171e77227f4243b898a2acf7cdf41f85huaweicom_"
MIME-Version: 1.0
Message-ID-Hash: 2EFMF7XYW5P2W7KDWMLXEONKRM2BSPHX
X-Message-ID-Hash: 2EFMF7XYW5P2W7KDWMLXEONKRM2BSPHX
X-MailFrom: zengguanming@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spring.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: spring Chairs <spring-chairs@ietf.org>, "draft-ietf-spring-srv6-security@ietf.org" <draft-ietf-spring-srv6-security@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [spring] Re: Intended Status of draft-ietf-spring-srv6-security-08.txt - Re: New Version Notification for draft-ietf-spring-srv6-security-08.txt
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/O4BT8Yo4rCCd59MaayTCHjPC6C0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Owner: <mailto:spring-owner@ietf.org>
List-Post: <mailto:spring@ietf.org>
List-Subscribe: <mailto:spring-join@ietf.org>
List-Unsubscribe: <mailto:spring-leave@ietf.org>

Dear WG,
I support changing the status of draft-ietf-spring-srv6-security from Standards Track (Proposed Standard) to Informational.
I believe this document’s primary purpose is not to define protocol behavior or introduce normative requirements, but rather to compile and explain security considerations associated with existing SRv6 specifications. It serves as a reference guide—offering threat models, attack scenarios, and mitigation strategies—to help implementers, operators, and architects make informed deployment decisions.
This aligns closely with the role of other IETF Informational documents such as RFC 9099, which similarly provides operational and security context without introducing new security mechanisms.
I agree with Yisong’s earlier reasoning and Zafar’s shepherd recommendation: this is fundamentally an informational reference, and its value lies in synthesis and guidance—not standardization.

Best regards,
Guanming Zeng


From: Alvaro Retana <aretana.ietf@gmail.com>
Sent: Wednesday, January 7, 2026 2:52 AM
To: Zafar Ali (zali) <zali@cisco.com>; SPRING WG List <spring@ietf.org>
Cc: spring Chairs <spring-chairs@ietf.org>; draft-ietf-spring-srv6-security@ietf.org
Subject: [spring] Re: Intended Status of draft-ietf-spring-srv6-security-08.txt - Re: New Version Notification for draft-ietf-spring-srv6-security-08.txt

[Thanks Zafar for kicking off this discussion!]


WG/authors:

We would like to hear opinions on Zafar's proposed change of Status for this document, from the Standards Track to Informational.

Please explain why you might be in favor, or against, a change in the Status.

We will take opinions until Jan/19, 2026.

Thanks!

Alvaro.


On January 5, 2026 at 10:16:22 PM, Zafar Ali (zali) (zali@cisco.com<mailto:zali@cisco.com>) wrote:
Hi Alvaro, chairs, authors, WG,

I am following up on the following comments from the chairs:
"As the Shepherd, you should start a discussion on the list about this -- including any justification for changing the current status."

Re - Q11: What status should the document have?

In my opinion, the document should progress as Informational (like the case of rfc9099).
There is some normative text and BCP 14 language, but it is mostly in restating normative language specified in existing RFCs the document cites. Some wordsmithing can fix it, without losing any substance.
I do not think an update tag is needed.

Given this hint from chairs, the intent of this email is to start that discussion.
Chairs may chime in to follow up more formally/ change subject/ formal poll, etc.


Thanks



Regards … Zafar


From: Alvaro Retana <aretana.ietf@gmail.com<mailto:aretana.ietf@gmail.com>>
Date: Wednesday, December 17, 2025 at 1:49 PM
To: Zafar Ali (zali) <zali@cisco.com<mailto:zali@cisco.com>>
Cc: spring Chairs <spring-chairs@ietf.org<mailto:spring-chairs@ietf.org>>, draft-ietf-spring-srv6-security@ietf.org<mailto:draft-ietf-spring-srv6-security@ietf.org> <draft-ietf-spring-srv6-security@ietf.org<mailto:draft-ietf-spring-srv6-security@ietf.org>>
Subject: Re: New Version Notification for draft-ietf-spring-srv6-security-08.txt
On December 16, 2025 at 8:48:08 PM, Zafar Ali wrote:

Hi Zafar!

> I have submitted a Shepherd review.

You submitted the Shepherd writeup -- thanks!
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-security/shepherdwriteup/


I have a couple of questions/comments (below). Specifically, your answer to Q11 should be discussed on the list before starting the WGLC.

In your review of the document, do you have any comments for the authors to address?


Thanks!

Alvaro.


> 10. Several IETF Areas have assembled [lists of common issues that their
>     reviewers encounter][6]. For which areas have such issues been
>     identified and addressed? For which does this still need to happen in
>     subsequent reviews?
>
> I think the document will benefit from a directorate review from OPS and
> SEC areas.
> ...
> [6]: https://wiki.ietf.org/group/iesg/ExpertTopics

I will request OPS and SEC (and RTG) directorate reviews with the WGLC.  Do you have any specific items I should point out based on [6]?



> 11. What type of RFC publication is being requested on the IETF stream
>     ([Best Current Practice][12], [Proposed Standard, Internet Standard]
>     [13], [Informational, Experimental or Historic][14])? Why is this the
>     proper type of RFC? Do all Datatracker state attributes correctly
>     reflect this intent?
>
>  Proposed Standard is requested and indicated in the title page header.
>  However, it is my opinion that the working group should discuss the
>  intentional status of the document (Standards Track, informational or BCP)
>  before the handoff.

What status should the document have?  As the Shepherd, you should start a discussion on the list about this -- including any justification for changing the current status.

We have discussed this document Updating (at least) rfc8402.  We would need this document to be on the Standards Track (or maybe a BCP) to do that.  The "Updates" tag is not ideal, but it is the only one we have.  Consider an "Update" if discussing the status on the list.



> 12. Have reasonable efforts been made to remind all authors of the
>     intellectual property rights (IPR) disclosure obligations described
>     in [BCP 79][7]? To the best of your knowledge, have all required
>     disclosures been filed? If not, explain why. If yes, summarize any
>     relevant discussion, including links to publicly-available messages
>     when applicable.
>
>   Yes, reasonable efforts been made to remind all authors of the intellectual
>   property rights (IPR) disclosure obligations. There have been IPR call as
>   part of the progression of this draft.

I'll poll again with the WGLC.  Please include links to the mail archive of that call when done (the IESG likes that).



> 19. Will publication of this document change the status of any existing
>     RFCs? If so, does the Datatracker metadata correctly reflect this and
>     are those RFCs listed on the title page, in the abstract, and discussed
>     in the introduction? If not, explain why and point to the part of the
>     document where the relationship of this document to these other RFCs is
>     discussed.
>
> No.

Based on the "Updates" discussion, this answer may need to be updated.