The assurance yang module needs to be updated
", "time": "2022-07-29T14:04:14Z"}, {"author": "Mohamed Boucadair", "text": "I don't think it passed formally the WGLC!
", "time": "2022-07-29T14:04:33Z"}, {"author": "Joe Clarke", "text": "Yes, I don't think the WG LC has been concluded formally, but this is something we need to close on.
", "time": "2022-07-29T14:06:17Z"}, {"author": "Mohamed Boucadair", "text": "I know there are pending changes from Benoit and Jean to address some of my pending comments. Once that version is published, I think we are ready to move forward.
", "time": "2022-07-29T14:08:03Z"}, {"author": "Mohamed Boucadair", "text": "@Tiru: Should DNR be cited for this part of the draft \"A
\n network-designated DoH/DoT server is necessary to allow MUD policy
\n enforcement on the local network\"?
Regarding to the assurance yang, we still need to address the YANG doctors comments
", "time": "2022-07-29T14:12:54Z"}, {"author": "Tirumaleswar Reddy.K", "text": "@Med, Yes, we will update the draft to point to both DNR and DNR specs.
", "time": "2022-07-29T14:13:54Z"}, {"author": "Beno\u00eet Claise", "text": "btw, on the SRv6 & IPFIX draft, I believe that we are closed to WGLC, once adopted. I believe we addressed all points.
", "time": "2022-07-29T14:18:41Z"}, {"author": "Joe Clarke", "text": "I think we did something similar with the last IPFIX extension draft that Thomas worked on.
", "time": "2022-07-29T14:19:13Z"}, {"author": "Beno\u00eet Claise", "text": "Exactly. We followed the same process.
", "time": "2022-07-29T14:19:41Z"}, {"author": "Mohamed Boucadair", "text": "This is useful work. Thanks Thomas
", "time": "2022-07-29T14:31:29Z"}, {"author": "Juan Cardona", "text": "The data manifest should just follow the rules of\"on-charge\" for updates, no?
", "time": "2022-07-29T14:46:44Z"}, {"author": "Joe Clarke", "text": "<contributor>@Juan, I would think so. This was the point I was trying to make.
", "time": "2022-07-29T14:47:28Z"}, {"author": "Mohamed Boucadair", "text": "I support this work
", "time": "2022-07-29T14:48:38Z"}, {"author": "George Michaelson", "text": "We are not energy economics experts and I think we should discount comments to national energy policy and focus on information on energy use, and patterns which reduce energy budget
", "time": "2022-07-29T15:03:39Z"}, {"author": "George Michaelson", "text": "on that basis, I support work in this space. It's important. Metrics drafts are helpful
", "time": "2022-07-29T15:04:04Z"}, {"author": "Tianran Zhou", "text": "no matter the carbon footprint, at least energy saving is useful.
", "time": "2022-07-29T15:05:39Z"}, {"author": "Adrian Farrel", "text": "The sort of thing we can work on, is models for recording and reporting energy use. But, not sure we correctly understand what information to collect and report. A lot of the work I have seen so far does not seem to understand how a router consumes power differently depending on a number of factors (not limited to congestion, load, buffer usage, complexity of packet processing)
", "time": "2022-07-29T15:06:25Z"}, {"author": "Mohamed Boucadair", "text": "We do already have eman as a starting point, Adrian.
", "time": "2022-07-29T15:07:11Z"}, {"author": "Adrian Farrel", "text": "Tianran Zhou said:
\n\n\nno matter the carbon footprint, at least energy saving is useful.
\n
All energy saving is good
", "time": "2022-07-29T15:07:15Z"}, {"author": "Mohamed Boucadair", "text": "As recorded in draft-eckert-ietf-and-energy-overview, a concrete action would be \" There are currently no YANG equivalent modules. Such modules would
\n not only be designed to echo the EMAN MIBs but would also allow to
\n control dedicated power optimization engines instead of relying upon
\n static and frozen vendor-specific optimization.\"
Yep, let's start somewhere. Or do we just say we can't do anything? We can understand the problem, and understand the hardware standards that the protocol is carried through. Can we change the protocol in ways that give less energy consumption in the hardware? Are there ways in which the hardware could be changed so we could make protocols more energy efficient?
", "time": "2022-07-29T15:10:46Z"}, {"author": "Warren Kumari", "text": "Yes, but we also clearly shouldn't not just solve the \"green\" problem without more clearly defining what we mean/are talking about. If we try boil the ocean in the interests of virtue-signalling... well, boiling an ocean takes lots of energy...
", "time": "2022-07-29T15:13:12Z"}, {"author": "Warren Kumari", "text": "Stolen from the Internet: Energy required to boil the ocean: 5.3 \u00d7 10^26 J...
", "time": "2022-07-29T15:14:31Z"}, {"author": "George Michaelson", "text": "good use of \"boil the ocean\" contextually Warren. Well done
", "time": "2022-07-29T15:14:39Z"}, {"author": "Tianran Zhou", "text": "maybe boiling the ocean is a good way to store enegy:-)
", "time": "2022-07-29T15:14:45Z"}, {"author": "Anthony Somerset", "text": "and using lots of energy could just end up boiling the ocean in the longer term.... self fulfilling prophecy
", "time": "2022-07-29T15:14:55Z"}, {"author": "Warren Kumari", "text": "Yeah. my point is that we are much better at actually solving clearly scoped and defined problems. E.g: we can 'solve' how to encrypt a packet, but we cannot 'solve' privacy.
", "time": "2022-07-29T15:19:39Z"}, {"author": "Warren Kumari", "text": "Having an unscoped problem leads to people spending much time in rooms pontificating about stuff, without actually making any progress..
", "time": "2022-07-29T15:20:21Z"}, {"author": "Warren Kumari", "text": "We can hear!
", "time": "2022-07-29T15:21:54Z"}, {"author": "Alexander Clemm", "text": "We have divided the work into two drafts. One outlines challenges and opportunities. It does not state that any of these are problems that we want to address, but it frames the overall problem space - it maps the ocean, if you will. Which part to address is still open there and to be discussed. Not _all_ will be addressed, but it is not the choice between \"all\" or \"none\", we can do incremental. The second one on energy metrics is very specific, concrete, actionable. Maybe we can jump into YANG module definition there. It's a common piece that will be needed in many places. Yes, we can outline specific problems it can solve
", "time": "2022-07-29T15:59:06Z"}]