Thank you. That works for me. I hope others agree.
Yours,
Joel
On 8/10/2023 11:04 AM, chengweiqiang wrote:
Hi Joel,
We've submitted the new version as following link:
https://www.ietf.org/archive/id/draft-cheng-spring-distribute-srv6-locator-by-dhcp-02.txt
Please review it.
Best Regards,
Weiqiang
---原始邮件---
* 发件人:* Joel Halpern <j...@joelhalpern.com>
* 发送时间:* 2023-08-09 20:30:49
* 收件人:* Weiqiang Cheng <chengweiqi...@chinamobile.com>
spring <spring@ietf.org>
* 主题:* Re: [spring] FW: New Version Notification
fordraft-cheng-spring-distribute-srv6-locator-by-dhcp-01.txt
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
