Topic: draft-eckert-ietf-and-energy-overview
speaker: Toerless Eckert
time slot: 5 minutes
Warren proposed at IETF115 that i first should check with OPSAWG whether there
is
interest to adopt this work as WG item before deciding to go to individual
submission
track. So hereby wanted to bring
Dear OPSAWG
https://datatracker.ietf.org/doc/draft-eckert-ietf-and-energy-overview/
At IETF115, we presented subject draft which attempts to summarize
what the IETF has done in terms of RFC/drafts to impact
energy consumption / sustainability. At that time the authors
thought this draft could go
Dear e-impaxct, opsawg:
We did push a new version of subject draft to datatracker with some minor but
hopefully
useful enhancements, and did also receive since/in last iETF some feedback that
folks found
the document a useful read, especially as background for e-impact related work
they are
eng
Dear OPSAWG,
I am looking for concrete examples of device certificates, specifically the
format of any
"identifier" field that is uniquely identifying the device, such as the
X520SerialNumber field.
I was hoping this WG would actually have folks who can look at real equipment
for example ;-))
Randomnly jumping into the discussion, probavbly too late for any impact, but:
I am not quite sure that section 6.4 "geofenced names" exactly means, a RFC
reference would help. Also a reference for the described problems.
If this geofenced is what i think, then i don't believe it is a valid argum
On Thu, Oct 26, 2023 at 09:43:57AM -0400, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> > Randomnly jumping into the discussion, probavbly too late for any
> > impact, but:
>
> > I am not quite sure that section 6.4 "geofenced names" e
On Thu, Oct 26, 2023 at 05:49:08PM -0400, Michael Richardson wrote:
> > Sure, but that DNSSEC issue equally applies to TLS proxies, right ?
> > DNSSEC is not mentioned in the docs paragraphs discussing TLS.
>
> TLS proxies do not change/break DNS(SEC).
> They "attack" at the TCP layer (in
Dear OPSAWG. I wouldlike to extend the invite for the following public
sidemeeting especially to OPSAWG
participants. Hope this is ok.
Dear colleagues @ IETF119
We hereby invite you for a public side meeting to hear from Enterprise and SP
Enterprise Services
participants about any enterprise ne
f
editing. Suggestion:
never use local recording with webex, but always only cloud recording - if you
do not want to run into
similar issues.
On Sun, Mar 17, 2024 at 10:47:38PM +0100, Toerless Eckert wrote:
> Dear colleagues @ IETF119
>
> We hereby invite you for a public side meeting to h
[Bcc: architecture-discuss]
[Thanks, Guntur for forwarding]
Guntur got some negative responses on architecture-discuss for posting
the info below, i hope questions about this to opsawg will find a
friendlier reception:
- I thought it was great to see that ISOC engages in supporting
operations,
I have been somewhat following how in the face of COVID-19,
the appropriate way to manage congestion control in the Internet
seem to be heads of countries reaching out to the one large content provider
they know (Netflix) and ask him to reduce bandwidth pressure on the
Internet. Of course, heads o
M +0300, Jonathan Morton wrote:
> > On 14 Apr, 2020, at 10:46 pm, Toerless Eckert wrote:
> >
> > I have been somewhat following how in the face of COVID-19,
> > the appropriate way to manage congestion control in the Internet
> > seem to be heads of countries reaching o
On Mon, Nov 09, 2020 at 08:23:52PM +0100, Eliot Lear wrote:
> This is good work, it???s a format used everywhere. We also need a registry
> for option extensions that IANA could provide. And we have some ideas as to
> how to use that.
A) As heart warming as all those cozy ASCII graphics in the
On Wed, Nov 11, 2020 at 02:12:46AM +0100, Carsten Bormann wrote:
> On 2020-11-10, at 22:23, Toerless Eckert wrote:
> >
> > Why is the document not using a formal language to define the
> > syntax/semantic of its formatting ? Would CBOR/CDDL not be a
> > good candida
from spec and make exensibilities easier (and i
am sure i am forgetting other benefits).
Cheers
Toerless
On Wed, Nov 11, 2020 at 09:08:17AM +0100, Juergen Schoenwaelder wrote:
> On Wed, Nov 11, 2020 at 03:22:18AM +0100, Toerless Eckert wrote:
> > On Wed, Nov 11, 2020 at 02:12:46AM
Thanks for explaining. Cc'in ISE to keep me honest:
I don't think this process ("IETF bless this protocol, no, we can't change
anything
significant") is appropriate for an Internet Standards Track RFC. I can not
even see informatinal as appropriate if WG consensus is constrained by
pre-existing
Let me know which of my asks you think is frivolous.
Cheers
Toerless
> Eliot
>
> > On 11 Nov 2020, at 10:21, Toerless Eckert wrote:
> >
> > Thanks for explaining. Cc'in ISE to keep me honest:
> >
> > I don't think this process ("IETF bless this
to ask questions like 'did you consider X?' but
> it feels entirely wrong to tell them 'you should be doing X'.
That is external spec blessing process, that is not WG spec development.
See above: i am all for blessing, i am just not for cunfusing blessing with
WG spec developm
On Wed, Nov 11, 2020 at 03:15:30PM +, Blumenthal, Uri - 0553 - MITLL wrote:
> On 11/11/20, 10:09, "OPSAWG on behalf of Toerless Eckert"
> wrote:
>
> >> This is really a win-win opportunity. The PCAP developers need a
> place that helps them formally
On Wed, Nov 11, 2020 at 11:08:03AM -0500, Warren Kumari wrote:
> > What is the WG allowed to design for this protocol spec ? Wordsmithing
> > and blessing ? Anything else ?
> >
> >
> > Everything else.
>
>
> Yup, the IETF has published a number of documents which are
> descriptions of how things
On Wed, Nov 11, 2020 at 06:02:28PM +0100, Carsten Bormann wrote:
> On 2020-11-11, at 17:33, Toerless Eckert wrote:
> >
> > Correct me if i am wrong, but i don't think that this would include at
> > least in recent
> > decades standards track documents, or
On Wed, Nov 11, 2020 at 12:12:34PM -0500, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> > Why is the document not using a formal language to define the
> > syntax/semantic of its formatting ? Would CBOR/CDDL not be a
> > good candidate ? Any other
Bormann wrote:
> On 2020-11-11, at 19:13, Toerless Eckert wrote:
> >
> > Agreed. but this is in contradiction to what others here on the thread
> > claimed
> > would be in scope of changes toward RFC, such as "anything", so everybody
> > seems
> &g
Worth documenting in the draft ;-)
On Wed, Nov 11, 2020 at 05:05:45PM -0500, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> >> On 2020-11-10, at 22:23, Toerless Eckert wrote:
> >> >
> >> > Why is the document not using a formal l
at 21:15, Brian E Carpenter
> > wrote:
> >
> > On 12-Nov-20 04:07, Toerless Eckert wrote:
> >> On Wed, Nov 11, 2020 at 10:34:25AM +0100, Eliot Lear wrote:
> >>> Hang on a moment.
> >>>
> >>> The PCAP community has been looking
On Wed, Nov 11, 2020 at 06:06:11PM -0500, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> > I am mostly worried to figure out if we can try to lock in the
> admissable changes to
> > the document as early as possible.
>
> You can change anything you
Regards
>Brian
> >
> > Eliot
> >
> >> On 11 Nov 2020, at 21:15, Brian E Carpenter >> <mailto:brian.e.carpen...@gmail.com>> wrote:
> >>
> >> On 12-Nov-20 04:07, Toerless Eckert wrote:
> >>> On Wed, Nov 11, 2020 at 10:34:2
pcap2010
On Wed, Nov 11, 2020 at 06:40:50PM -0500, Michael Richardson wrote:
>
> Brian E Carpenter wrote:
> > On 12-Nov-20 10:47, Eliot Lear wrote:
> >> We didn???t use the ISE for JSON. Why should we use it here?
>
> > I have no idea what the arguments were for JSON. Carsten alrea
+1300, Brian E Carpenter wrote:
> On 12-Nov-20 23:24, tom petch wrote:
> > From: OPSAWG on behalf of Toerless Eckert
> >
> > Sent: 11 November 2020 20:24
> >
> > I am mostly worried to figure out if we can try to lock in the admissable
> > changes to
> >
e is a non-starter. Retronym, yes.)
> >>
> >> Grüße, Carsten
> >>
> >>
> >>> On 2020-11-12, at 07:55,
> >> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> I echo what Brian said.
> >>>
> >>
On Fri, Nov 13, 2020 at 12:52:10PM +, tom petch wrote:
> From: OPSAWG on behalf of Carsten Bormann
>
> Sent: 13 November 2020 06:48
> On 2020-11-13, at 07:18, Eliot Lear wrote:
> >
> > bureaucratic process
>
> The discussion is really frustrating.
And by not saying why you are frustrated
One hought that cam up when reading subject draft:
SBOM is likely something many devices may want to keep confidential.
But SBOM may also be highly beneficial for attestation during bootstrap.
In BRSKI (RFC8995), we have a boostrap TLS connection for which the client
device
receives a very stron
On Fri, May 28, 2021 at 10:23:21AM -0400, Michael Richardson wrote:
>
> Toerless Eckert wrote:
> > SBOM is likely something many devices may want to keep confidential.
>
> I think that national security will eventually trump (might be a
> pun, not sure), emot
ot;
cert if it can not be fully trusted because of its SBOM.
Cheers
Toerless
> Eliot
>
> On 28.05.21 01:38, Toerless Eckert wrote:
> > One hought that cam up when reading subject draft:
> >
> > SBOM is likely something many devices may want to keep confidential.
On Fri, May 28, 2021 at 06:59:53PM +0200, Eliot Lear wrote:
>
> On 28.05.21 17:31, Toerless Eckert wrote:
> > On Fri, May 28, 2021 at 07:24:45AM +0200, Eliot Lear wrote:
> >
> > Explain to me how this work flow would allow for the registrar to
> > decide whether
impossible dynamic
update of such cloud based SBOM information.
Cheers
Toerless
>
> Eliot
>
> On 28.05.21 19:49, Toerless Eckert wrote:
> > On Fri, May 28, 2021 at 06:59:53PM +0200, Eliot Lear wrote:
> > > On 28.05.21 17:31, Toerless Eckert wrote:
> > >
On Fri, May 28, 2021 at 08:37:54PM +0200, Eliot Lear wrote:
> Toerless,
>
> Feel free to come up with whatever work flows you want. However... I'm
> less fine with is creating a new endpoint to retrieve the exact same
> information.
Agreed.
But: when we want to make attestation information ava
On Fri, May 28, 2021 at 06:08:27PM -0400, Michael Richardson wrote:
> > Can not quite parse this. Rephrase pls. I was just thinking about known
> > exploits for specific software versions as the reason for not making
> > the SBOM available to anyone who asks.
>
> The need for all entit
Hah. But thats an even earlier step than what i was thinking of. Yes,
attestation during voucher setup is an interesting option to. It just
would put the pledge into the "even more under control by the manufacturer"
bucket. Which some users will prefer, and some will not like.
Cheers
Toerless
On Sat, May 29, 2021 at 04:06:29PM +0200, Eliot Lear wrote:
> So this raises an interesting question, which is probably more appropriate
> for RATS. What information should be shared with whom and how? The voucher
> is shipped in the clear without much prompting. There are different views
> abou
Reminds me of the concern about authentication of addressing i just
brought up on another mailing list to you ;-)
On Thu, Jul 15, 2021 at 08:39:44PM +0200, Carsten Bormann wrote:
> On 15. Jul 2021, at 20:16, Michael Richardson wrote:
> >
> > As an example of a TCP connection that would be hard t
On Tue, Aug 30, 2022 at 04:17:12PM -0400, Alan DeKok wrote:
> Using a standard format such as CBOR means that the initial cost to
> implementations is large. But any further extensions are likely to be
> trivial.
IMHO:
The initial cost for greenfield implementation with CBOR
should be smalle
42 matches
Mail list logo
