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 <mailto:j...@joelhalpern.com>
*Date:* 2023-08-07 22:10
*To:* Weiqiang Cheng <mailto:chengweiqi...@chinamobile.com>;
spring <mailto:spring@ietf.org>
*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,
Wehave updated the draft and addressed the comments received
during the adoption call.
The main updates include:
1. 1) Adding a detailed description of the trusted domain in the
Security Considerations section.
2. 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 <mailto:internet-dra...@ietf.org>
*Date:* 2023-08-07 14:46
*To:* Changwang Lin <mailto:linchangwang.04...@h3c.com>; Geng
Zhang <mailto:zhangg...@chinamobile.com>; Ruibo Han
<mailto:hanru...@chinamobile.com>; Weiqiang Cheng
<mailto:chengweiqi...@chinamobile.com>; Yuanxiang Qiu
<mailto:qiuyuanxi...@h3c.com>
*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
