Hi Joel, Thank you very much for your comments. I agree that all network elements, such as BRAS, CRx, Backbone, and CPE, belong to the same operator, and this scenario indeed constitutes a trusted domain. However, a trusted domain can indeed extend beyond a single operator. In cases where multiple operators authenticate and trust each other's network infrastructure, they can form a collective trusted domain. This allows them to collaborate and leverage the resources of multiple trusted operators when providing services. It is important to consider such scenarios and ensure that the concept of a trusted domain is flexible enough to accommodate diverse network environments.
How about if the author were to include text similar to the following: "While in this document we describe a trusted domain consisting of network elements from the same operator, it is important to note that a trusted domain is not necessarily limited to a single operator. In the real world, multiple operators can establish mutual trust, authenticate each other's network infrastructure, and form a collective trusted domain. In such cases, they can collaborate and leverage the resources of multiple trusted operators to provide services. Therefore, we encourage readers to maintain flexibility in understanding the concept of a trusted domain and consider the possibilities of cooperation and trust among different operators." Including such text would provide a clearer expression of the author's understanding of the concept of a trusted domain and remind readers to consider the potential for cooperation and trust among multiple operators in practical applications. B.R. Weiqiang From: Joel Halpern Date: 2023-08-07 22:10 To: Weiqiang Cheng; spring Subject: Re: [spring] FW: New Version Notification for draft-cheng-spring-distribute-srv6-locator-by-dhcp-01.txt For now speaking personally, although this may require chairs' intervention, I do not find the trust domain text to be sufficient. While I am not sure it would suffice, I would expect the text that goes with figure 1 to explicitly state both that the CPE are under operator control and that the BRAS, CRx, and Backbone devices are all run by a single operator that is the same as the operator managing the CPE. And that they form a trust domain or are all part of a single larger trust domain. Yours, Joel On 8/7/2023 3:08 AM, Weiqiang Cheng wrote: Dear Chairs and Group, We have updated the draft and addressed the comments received during the adoption call. The main updates include: 1) Adding a detailed description of the trusted domain in the Security Considerations section. 2) Optimizing the text based on the received comments. For a detailed overview of the changes, please refer to the following diff link: https://author-tools.ietf.org/iddiff?url2=draft-cheng-spring-distribute-srv6-locator-by-dhcp-01 If you have any further comments or feedback, please feel free to share. B.R. Weiqiang Cheng From: internet-drafts Date: 2023-08-07 14:46 To: Changwang Lin; Geng Zhang; Ruibo Han; Weiqiang Cheng; Yuanxiang Qiu Subject: New Version Notification for draft-cheng-spring-distribute-srv6-locator-by-dhcp-01.txt A new version of I-D, draft-cheng-spring-distribute-srv6-locator-by-dhcp-01.txt has been successfully submitted by Ruibo Han and posted to the IETF repository. Name: draft-cheng-spring-distribute-srv6-locator-by-dhcp Revision: 01 Title: Distribute SRv6 Locator by DHCP Document date: 2023-08-07 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/archive/id/draft-cheng-spring-distribute-srv6-locator-by-dhcp-01.txt Status: https://datatracker.ietf.org/doc/draft-cheng-spring-distribute-srv6-locator-by-dhcp/ Htmlized: https://datatracker.ietf.org/doc/html/draft-cheng-spring-distribute-srv6-locator-by-dhcp Diff: https://author-tools.ietf.org/iddiff?url2=draft-cheng-spring-distribute-srv6-locator-by-dhcp-01 Abstract: In a SRv6 network, each SRv6 Segment Endpoint Node must be assigned a locator, and segment IDs are generated within the address space of this locator. This document describes a method for assigning locators to SRv6 Segment Endpoint Nodes through DHCPv6. The IETF Secretariat
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
