I look forward to seeing a draft with these changes.
Yours,
Joel
On 8/9/2023 2:43 AM, Weiqiang Cheng wrote:
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 <mailto:j...@joelhalpern.com>
*Date:* 2023-08-08 22:27
*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
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
