Re: [OPSAWG] Intdir telechat review of draft-ietf-opsawg-add-encrypted-dns-10
Hi Tatuya, Thank you for the review. Please see inline. Cheers, Med > -Message d'origine- > De : Tatuya Jinmei via Datatracker > Envoyé : jeudi 9 mars 2023 23:10 > À : int-...@ietf.org > Cc : draft-ietf-opsawg-add-encrypted-dns@ietf.org; last- > c...@ietf.org; opsawg@ietf.org > Objet : Intdir telechat review of draft-ietf-opsawg-add-encrypted- > dns-10 > > Reviewer: Tatuya Jinmei > Review result: Ready with Issues > > I am an assigned INT directorate reviewer for draft-ietf-opsawg- > add-encrypted-dns-10.txt. These comments were written primarily > for the benefit of the Internet Area Directors. Document editors > and > shepherd(s) should treat these comments just like they would treat > comments from any other IETF contributors and resolve them along > with any other Last Call comments that have been received. For > more details on the INT Directorate, see > https://datatracker.ietf.org/group/intdir/about/. > > Based on my review, if I was on the IESG I would ballot this > document as DISCUSS. > > I have the following (possible) DISCUSS/ABSTAIN level issue. > > The draft states in section 5: > >Should any encrypted DNS-related information (e.g., > Authentication >Domain Name (ADN), IPv6 address) change, [...]. [Med] What is actually more important in this para is the part in [...]. That text is there to provide an example of when the attributes can be present in CoA-Request. The NAS >replaces the old encrypted DNS resolver information with the > new one >and sends a DHCPv6 Reconfigure message which leads the DHCPv6 > client >to initiate a Renew/Reply message exchange with the DHCPv6 > server. > > I suspect the use of Reconfigure is not always feasible. A > Reconfigure message needs to be authenticated (per RFC8415), and > the only available method for the authentication is the > Reconfiguration Key Authentication Protocol. But this protocol is > weak in that a shared secret first needs to be sent from the > server to the client in plain text. It may be justifiable in the > intended use case (between a CPE and NAS, and the communication > path between them can be considered reasonably protected), but I > believe such considerations should be described explicitly, > either/both in this section or/add in Section 6. > > Now, I'm not sure if such an update operation is an integral part > of this draft. If it's considered to be a minor case (e.g. the > information is mostly static and periodic renew would suffice), or > the matter of updates itself is mostly out of scope of this doc, > then my comment on this point is also minor. > On the other hand, if it's important to describe how such an > update works with this RADIUS extension, then I'd regard it as a > DISCUSS level issue. And, in the latter case, I believe DHCPv4- > specific considerations on the same point should be included, too. > [Med] These considerations are specific to the dhcp options that will be carried in the RADIUS attribute. The security considerations (including issues with the use of reconfigure) fall under this part: Security considerations specific to the DHCP options that are carried in RADIUS are discussed in relevant documents that specify these options. > The following are other (possible) issues I found with this > document that may need be addressed before publication (I don't > necessarily think these SHOULD be > "corrected"): > > (All of these are about Section 3) > > - I wonder whether the two "may"s in this text need to be > normative "MAY"s. > >RADIUS implementations may support a configuration parameter to >control the DHCP options that can be included in a DHCP*- > Options >RADIUS attribute. Likewise, DHCP server implementations may > support >a configuration parameter to control the permitted DHCP options > in a >DHCP*-Options RADIUS attribute. > [Med] I also hesitated, but MAY is not used here as this does not impact interop. I had to reread Sections 5/6 of RFC2119 regularly for may/MAY. > - This "SHOULD" looks awkward to me. While it's a nice suggestion > for implementers, it doesn't affect interoperability. I'd suggest > making it a non-normative recommendation. > >For ease of administrator configuration, the RADIUS server > SHOULD >expose the DHCP options and allow administrators to configure > them, >instead of requiring them to be entered as opaque data. > > [Med] The use of normative language is justified here because we don't want the RADIUS servers to blindly pass data. What this text says is that the attributes should not be seen as opaque data by the RADIUS server but it should understand the encoding of the enclosed options. Thanks. _ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
Re: [OPSAWG] [nmrg] New revision of "Green Networking Metrics" (draft-cx-green-metrics)
Hi Haoyu, thank you for your comments. A couple of quick replies: Re: 1) Clearly normalization is important and the challenge there is to come up with metrics which are both useful and straightforward to implement. IMHO the starting point will include the "raw" metrics; applying any formulas or factors should be done as part of second-order metrics. As for separating out how much carbon footprint should be attributed to a computation task versus a networking task for devices that perform in-networking computing, I am not sure this will always be practical. However, you could in fact use the metrics that are proposed in the draft to account for that at the networking level. Here you look at the overall energy consumption or the network as a whole, not just the sum of individual devices. This will allow you to account for "hidden" polluters etc, and use that to apply some factor or "tax" to come up with the true holistic picture. In cases where you have networking devices that have a large carbon footprint, but that obviate the need for separate devices that would otherwise not be accounted for, this factor will be a lot smaller than would otherwise be the case. Re: 2) The intent here is to focus on the "what" not on the "how". That being said I think there are a number of things that can be done to measure or at least estimate these. A simple example would, for example, determine what fraction of a device's traffic volume can be attributed to a particular flow (this is straightforward), then apply that fraction to the carbon footprint of the device overall to determine the flow's share of it. Re: 3) Of course if you send many bits you divide the share among them. What is meant here is the incremental cost of sending a bit. If you sent just a single bit, that would involve a high incremental cost (which will be incurred even if you send no further bit); if you were to send a second bit immediately after that, that one would involve a very low incremental cost. Cheers --- Alex On 3/9/2023 11:29 AM, Haoyu Song wrote: Hi Alex, This is an interesting read. Here I provide some comments and observations. 1. I think the energy consumption metrics on equipment is more meaningful when it's normalized to the device's capacity and capability. For example, energy per bit can be used to compare which is greener between two devices if they offer the same function. On the other hand, if a device does more processing (e.g., in network computing), it's likely it will consume more energy, but it also makes the overall solution more efficient, so it's still greener in this sense. 2. The flow and path energy metrics is interesting but I wonder how it can be measured in reality? If this is doable, then perhaps application/job level energy consumption metrics should also be included (e.g., in HPC DCNs, a job may involves multiple flows and multiple paths). This level of granularity may be more preferred in evaluating different solution architectures. 3. In section 3.1.1, it seems unfair to attribute the cost to only the first bit. It's meaningless to send only one bit anyway so the cost should be shared by all the bits.:) Best regards, Haoyu -Original Message- From: OPSAWG On Behalf Of Alexander L Clemm Sent: Wednesday, March 8, 2023 5:35 PM To: opsawg@ietf.org; n...@irtf.org Cc: draft-cx-green-metr...@ietf.org Subject: [OPSAWG] New revision of "Green Networking Metrics" (draft-cx-green-metrics) Hi, we just posted an updated revision of "Green Networking Metrics" (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cx-green-metrics%2F=05%7C01%7Chaoyu.song%40futurewei.com%7C2643e0c419c1408dad4a08db203e9a42%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638139225483790907%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=USheN9sfG%2FwDm8Yy9aTy20SacMv%2B1Zd6hbiiPP63iHg%3D=0), including various editorial improvements and incorporating highly useful feedback and suggestions from a number of people including Eve Schooler, Alexandru Petrescu, and Michael Welzl. The draft defines a set of "green" networking metrics that will be useful as basis for management and control applications that aim to reduce carbon footprint and hence require visibility into such metrics. We believe that in terms of scope, this draft falls into the intersection of opsawg and nmrg interest and we hope to have the opportunity to present at IETF 116 in Yokohama, hence we are crossposting to both groups. Personally I believe that opsawg may be the most suitable landing spot as the draft can be easily operationalized and is not as much concerned with open-ended research questions, but that is of course where we would appreciate feedback from the groups. Once a decision is made for the proper landing spot, hopefully immediately following IETF 116, we will post a new
[OPSAWG] Intdir telechat review of draft-ietf-opsawg-add-encrypted-dns-10
Reviewer: Tatuya Jinmei Review result: Ready with Issues I am an assigned INT directorate reviewer for draft-ietf-opsawg-add-encrypted-dns-10.txt. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/. Based on my review, if I was on the IESG I would ballot this document as DISCUSS. I have the following (possible) DISCUSS/ABSTAIN level issue. The draft states in section 5: Should any encrypted DNS-related information (e.g., Authentication Domain Name (ADN), IPv6 address) change, [...]. The NAS replaces the old encrypted DNS resolver information with the new one and sends a DHCPv6 Reconfigure message which leads the DHCPv6 client to initiate a Renew/Reply message exchange with the DHCPv6 server. I suspect the use of Reconfigure is not always feasible. A Reconfigure message needs to be authenticated (per RFC8415), and the only available method for the authentication is the Reconfiguration Key Authentication Protocol. But this protocol is weak in that a shared secret first needs to be sent from the server to the client in plain text. It may be justifiable in the intended use case (between a CPE and NAS, and the communication path between them can be considered reasonably protected), but I believe such considerations should be described explicitly, either/both in this section or/add in Section 6. Now, I'm not sure if such an update operation is an integral part of this draft. If it's considered to be a minor case (e.g. the information is mostly static and periodic renew would suffice), or the matter of updates itself is mostly out of scope of this doc, then my comment on this point is also minor. On the other hand, if it's important to describe how such an update works with this RADIUS extension, then I'd regard it as a DISCUSS level issue. And, in the latter case, I believe DHCPv4-specific considerations on the same point should be included, too. The following are other (possible) issues I found with this document that may need be addressed before publication (I don't necessarily think these SHOULD be "corrected"): (All of these are about Section 3) - I wonder whether the two "may"s in this text need to be normative "MAY"s. RADIUS implementations may support a configuration parameter to control the DHCP options that can be included in a DHCP*-Options RADIUS attribute. Likewise, DHCP server implementations may support a configuration parameter to control the permitted DHCP options in a DHCP*-Options RADIUS attribute. - This "SHOULD" looks awkward to me. While it's a nice suggestion for implementers, it doesn't affect interoperability. I'd suggest making it a non-normative recommendation. For ease of administrator configuration, the RADIUS server SHOULD expose the DHCP options and allow administrators to configure them, instead of requiring them to be entered as opaque data. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] New revision of "Green Networking Metrics" (draft-cx-green-metrics)
Hi Alex, This is an interesting read. Here I provide some comments and observations. 1. I think the energy consumption metrics on equipment is more meaningful when it's normalized to the device's capacity and capability. For example, energy per bit can be used to compare which is greener between two devices if they offer the same function. On the other hand, if a device does more processing (e.g., in network computing), it's likely it will consume more energy, but it also makes the overall solution more efficient, so it's still greener in this sense. 2. The flow and path energy metrics is interesting but I wonder how it can be measured in reality? If this is doable, then perhaps application/job level energy consumption metrics should also be included (e.g., in HPC DCNs, a job may involves multiple flows and multiple paths). This level of granularity may be more preferred in evaluating different solution architectures. 3. In section 3.1.1, it seems unfair to attribute the cost to only the first bit. It's meaningless to send only one bit anyway so the cost should be shared by all the bits.:) Best regards, Haoyu -Original Message- From: OPSAWG On Behalf Of Alexander L Clemm Sent: Wednesday, March 8, 2023 5:35 PM To: opsawg@ietf.org; n...@irtf.org Cc: draft-cx-green-metr...@ietf.org Subject: [OPSAWG] New revision of "Green Networking Metrics" (draft-cx-green-metrics) Hi, we just posted an updated revision of "Green Networking Metrics" (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-cx-green-metrics%2F=05%7C01%7Chaoyu.song%40futurewei.com%7C2643e0c419c1408dad4a08db203e9a42%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638139225483790907%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=USheN9sfG%2FwDm8Yy9aTy20SacMv%2B1Zd6hbiiPP63iHg%3D=0), including various editorial improvements and incorporating highly useful feedback and suggestions from a number of people including Eve Schooler, Alexandru Petrescu, and Michael Welzl. The draft defines a set of "green" networking metrics that will be useful as basis for management and control applications that aim to reduce carbon footprint and hence require visibility into such metrics. We believe that in terms of scope, this draft falls into the intersection of opsawg and nmrg interest and we hope to have the opportunity to present at IETF 116 in Yokohama, hence we are crossposting to both groups. Personally I believe that opsawg may be the most suitable landing spot as the draft can be easily operationalized and is not as much concerned with open-ended research questions, but that is of course where we would appreciate feedback from the groups. Once a decision is made for the proper landing spot, hopefully immediately following IETF 116, we will post a new revision under the respective working group. FYI, here is the abstract of the draft: This document explains the need for network instrumentation that allows to assess the power consumption, energy efficiency, and carbon footprint associated with a network, its equipment, and the services that are provided over it. It also suggests a set of related metrics that, when provided visibility into, can help to optimize a network's energy efficiency and "greenness". On behalf of the coauthors --- Alex ___ OPSAWG mailing list OPSAWG@ietf.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawg=05%7C01%7Chaoyu.song%40futurewei.com%7C2643e0c419c1408dad4a08db203e9a42%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638139225483790907%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=0T83gXiOGuQnhKkuwbmZ7ex7KTilOComeVuP3XIkn44%3D=0 ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
