Dear Joel, Thank you for sharing your comments. We would like to address each of your points as follows:
Firstly, we will explicitly state that the CPE must be operator-managed in the text. Secondly, we understand your reservations about the assumption of multi-operator trust domains. We will only cover the situations where different arms of the same company operate their portions of the network separately but trust each other. Lastly, we appreciate your suggestion to rephrase the text accompanying Figure 1 to make it an active statement about the requirement for all relevant components to be part of a single trust domain. We will update the text accordingly. Once again, thank you for bringing these comments. Best regards, Weiqiang From: Joel Halpern Date: 2023-08-08 22:27 To: Weiqiang Cheng; spring Subject: Re: [spring] FW: New Version Notification for draft-cheng-spring-distribute-srv6-locator-by-dhcp-01.txt I have three concerns with this. The first concern is that I do not see where the text is explicit that the CPE MUST be operator-managed. That seems to me to be necessary no matter what one assumes about operator relationships. The second concern is about the assumption of multi-operator trust domains. If by that you mean a situation where multiple arms of the same company operate their portions of the network separately, but trust each other, then yes, I understand how that can be a single trust domain. However, that is a single operator, not multi-operator. I have never seen any siutation in which actually distinct operators trust each other and trust each other's security mechanisms enough to be treated as a single trust domain. And what little text we have defining trust domains does not suggest such an interpretation. I am not comfortable with that, and I would expect pushback when we as a WG tried to publish the document if we made such an assertion. Third, as a lesser matter, I would prefer if the text that went with figure one started with "This deployment assumes that all of the relevvent componenbts in figure one are part of a single trust domain". That is an active statement about a requirement by this document, not a passive observation. Yours, Joel On 8/7/2023 10:01 PM, Weiqiang Cheng wrote: 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
