Hi Alex, all,
Just following up on the comment I did ad the mic earlier today.
The drafts speaks about metrics at: device/equipment level, flow level, path
level, network level.
The device/equipment level covers power consumption per chassis, line card and
port at different loads of traffic,
On behalf of OPSAWG, thank you for your interest in the attachment circuits
work and for reaching out with this liaison statement. We just concluded the
OPSAWG session at IETF 117 where the AC work was presented.
We conducted a poll at the meeting for interest in adoption. Given that there
FYI.
As mentioned by Rob right now in OPSAWG/OPSAREA
Regards, Benoit
Forwarded Message
Subject:Welcome to the "Digitalmap-yang" mailing list
Date: Wed, 26 Jul 2023 14:36:13 -0700
From: digitalmap-yang-requ...@ietf.org
To: benoit.cla...@huawei.com
Welcome to
Dear Alex and Greg,
I reviewed draft-ietf-ippm-pam-04 and draft-clemm-opsawg-pam-ipfix-00 and have
some comments and questions.
Section 3.1 of draft-ietf-ippm-pam-04
(https://datatracker.ietf.org/doc/html/draft-ietf-ippm-pam-04#section-3.1)
mentions the term "service flow".
I haven't been
Benoit Claise wrote:
> https://datatracker.ietf.org/wg/ivy/about/ is already chartered :-)
I knew it was in process, but I didn't want to jump to the end.
> And no, those document will not move to IVY, as they address a
> different problem.
>
Guy Harris wrote:
>> We allocated a few chunks for private use years ago, and they could be
>> in use internally somewhere, so we don't want to change that. But,
>> maybe we should mark them as deprecated?
> "Deprecated" presumably means "if you want to use one of these points
Hi Michael,
https://datatracker.ietf.org/wg/ivy/about/ is already chartered :-)
And no, those document will not move to IVY, as they address a different
problem.
https://datatracker.ietf.org/doc/html/draft-havel-opsawg-digital-map-00#name-network-inventory-ivy-propo
Note: there was a side
Will documents like draft-havel-opsawg-digital-map and
draft-davis-opsawg-some-refinements-to-rfc8345 move to IVY once it is
chartered?
(Not sure if the ML will change names)
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
On Jul 26, 2023, at 10:41 AM, Michael Richardson wrote:
> mohamed.boucad...@orange.com wrote:
>
>> Some assigned types seem to be used for private use while these types
>> fall now under a specification required range. I don't know if it is
>> worth to have some consistency here and consider a
Re-,
That wouldn't be FCFS anymore but Expert Review.
Those who applies for FCFS range should be aware that no filtering is applied
other than requests are well-formed + not duplicating records.
Cheers,
Med
> -Message d'origine-
> De : Carsten Bormann
> Envoyé : mercredi 26 juillet
Re-,
Please see inline.
Cheers,
Med
> -Message d'origine-
> De : Michael Richardson
> Envoyé : mercredi 26 juillet 2023 10:41
> À : BOUCADAIR Mohamed INNOV/NET ;
> opsawg@ietf.org
> Objet : Re: [OPSAWG] PCAP documents (was Re: I-D Action: draft-
> ietf-opsawg-pcap-03.txt)
>
>
>
On 2023-07-26, at 19:41, Michael Richardson wrote:
>
> Do we need DE for FCFS?
FCFS (without DE) is a fiction if a registration requires some checking that
IANA cannot do.
Does this one?
Grüße, Carsten
___
OPSAWG mailing list
OPSAWG@ietf.org
mohamed.boucad...@orange.com wrote:
> For the specification required range, you may consider adding some
> guidance for DEs.
Yeah.
Do we need DE for FCFS?
> The initial table does not mirror the current values in
> https://www.tcpdump.org/linktypes.html. Also, some descriptions
Hi Michael,
OK, thanks. Publishing the doc as Info would be OK then.
I sent you right now a PR with some minor edits.
For the specification required range, you may consider adding some guidance for
DEs.
The initial table does not mirror the current values in
14 matches
Mail list logo
